Runscanner commands?
#1 Sirquil
- Location: Indianapolis, Indiana
- United States
I am trying to use Runscanner and need some help -please.
Want to select remote Windows installations (Win 2k, Win XP. Vista, Win 7) then select a user profile, then launch program.
All that I have been able to do is select the windows installation it errors, «Target is not Windows 2000 or later».
This is what I have tried:
Add_Shortcut,StartMenu,Security,#$pSystemRoot#$p\System32\RunScanner.exe,program.exe,#$pSystemRoot#$p\System32,»/t 750 /ec /m /s /sd /sv /u #$q%PE_Programs%\%ProgramFolder%\program.exe#$q»,%PE_Programs%\%ProgramFolder%\program.exe
Add_Shortcut,Desktop,,#$pSystemRoot#$p\System32\RunScanner.exe,program.exe,#$pSystemRoot#$p\System32,»/t 750 /ec /m /s /sd /sv /u #$q%PE_Programs%\%ProgramFolder%\program.exe#$q»,%PE_Programs%\%ProgramFolder%\program.exe
This is my first experience using runscanner
I have Paraglider’s document that gives the Runscanner commands. Have not been able to create the right combination. More I try; the more confused I am.
Project is MultiPE v21 download —Windows 7
#2 paraglider
- Location: NC,USA
- United States
Only specify one of /s /sd /sv. I always use /sd only. Never tried it against w2k. It requires several files to be present to be considered a valid windows installation. As I am away from home at the moment don’t remember exactly what files are examined — I think ntdll.dll ( extracts the file version from the file ) and the software / system and a few other hives have to be present.
You could run sysinternals procmon to see what files are examined. Also using sysinternals dbgview along with /d on the runscanner command line outputs and captures debug information.
#3 Sirquil
- Location: Indianapolis, Indiana
- United States
Thank you for your reply and your contributions to the community.
Here is what I have done:
Add_Shortcut,StartMenu,Security,#$pSystemRoot#$pSystem32RunScanner.exe,%ProgramTitle%,#$pSystemRoot#$pSystem32,»/t 1000 /d /ec /m /sv /u #$q%PE_Programs%%ProgramFolder%%ProgramEXE%#$q»,#$q%PE_Programs%%ProgramFolder%%ProgramEXE%#$q
Add_Shortcut,Desktop,,#$pSystemRoot#$pSystem32RunScanner.exe,%ProgramTitle%,#$pSystemRoot#$pSystem32,»/t 1000 /d /ec /m /sv /u #$q%PE_Programs%%ProgramFolder%%ProgramEXE%#$q»,#$q%PE_Programs%%ProgramFolder%%ProgramEXE%#$q
Variables are defined in the script.
This is giving me choice of Windows installations and choice of User profiles; however, I am getting Runscanner Error —«Create of target process failed, ret=2:
The system could not fine the file specified»
You gave mention of two utilites: dbgview and procmon
How are they used? Will look for these two utilities and documentation.
#4 paraglider
- Location: NC,USA
- United States
They are downloadable from live.sysinternals.com. You just run them. There are pe plugins available for both programs.
If you get the file not found error then it probably means the file path of the last command line parameter is not correct. Did you check that the expanded path ( check the generated config file ) or the properties of the shortcut references a file that exists in your running pe.
Does your target program run if run directly i.e. not via runscanner? That must be verified first. Create a shortcut:
and see if that works.
#5 Sirquil
- Location: Indianapolis, Indiana
- United States
Inside the booted MultiPE-Win7 I am able to use command prompt, «X:\Program Files\PKExplorer\runscanner productkeyexplorer /t /ec /sv /m /u
Works correctly productkeyexplorer.exe launches.
Could someone please take a look at these two attempts to add shortcuts and see if there are syntax errors?
Add_Shortcut,StartMenu,Security,#$pSystemRoot#$p\System32\RunScanner.exe,%ProgramTitle%,#$pSystemRoot#$p\System32,»/t 1000 /d /ec /m /sv /u #$q%PE_Programs%\%ProgramFolder%\%ProgramEXE%#$q»,#$q%PE_Programs%\%ProgramFolder%\%ProgramEXE%#$q
Add_Shortcut,Desktop,,#$pSystemRoot#$p\System32\RunScanner.exe,%ProgramTitle%,#$pSystemRoot#$p\System32,»/t 1000 /d /ec /m /sv /u #$q%PE_Programs%\%ProgramFolder%\%ProgramEXE%#$q»,#$q%PE_Programs%\%ProgramFolder%\%ProgramEXE%#$q
Need some fresh eyes to take a look.
#6 RoyM
- Interests: «Booting and Owning».
- United States
Add_Shortcut,Desktop,,»%SystemRoot%system32Runscanner.exe»,»%ProgramTitle%»,»%SystemRoot%system32″,»/t 1000 /d /ec /m /sv /u %PE_Programs%%ProgramFolder%%ProgramEXE%»,»%PE_Programs%%ProgramFolder%%ProgramEXE%»,1
Add_Shortcut,StartMenu,Security,»%SystemRoot%system32Runscanner.exe»,»%ProgramTitle%»,»%SystemRoot%system32″,»/t 1000 /d /ec /m /sv /u %PE_Programs%%ProgramFolder%%ProgramEXE%»,»%PE_Programs%%ProgramFolder%%ProgramEXE%»,1
#7 Sirquil
- Location: Indianapolis, Indiana
- United States
Thanks for the reply; I made some changes:
Add_Shortcut,Desktop,,»%SystemRoot%system32Runscanner.exe»,»%ProgramTitle%»,»%SystemRoot%system32″,»/t 1000 /s /ec %SystemDrive%Program Files%ProgramFolder%%ProgramEXE%»,»%SystemDrive%Program Files%ProgramFolder%%ProgramEXE%»,1
Add_Shortcut,StartMenu,Security,»%SystemRoot%system32Runscanner.exe»,»%ProgramTitle%»,»%SystemRoot%system32″,»/t 1000 /s /ec %SystemDrive%Program Files%ProgramFolder%%ProgramEXE%»,»%SystemDrive%Program Files%ProgramFolder%%ProgramEXE%»,1
Both shortcuts working.
The variable in MultiPE project, «%PE_Programs%» returns «#$pSystemDrive#$p@_@» in Allan’s Win7PE_SE project «%PE_Programs%» returns «Y:Programs»; this is the reason I made changes to «%PE_Program%.»
#8 pscEx
- Location: Korschenbroich, Germany
- Interests: What somebody else cannot do.
- European Union
The variable in MultiPE project, «%PE_Programs%» returns «#$pSystemDrive#$p@_@» in Allan’s Win7PE_SE project «%PE_Programs%» returns «Y:Programs»; this is the reason I made changes to «%PE_Program%.»
Just for the record:
in multiPE there are three possible values:
This avoids the ingenious hardcoded Y: drive.
The PEFactory resolves @_@ to the source CD’s «Program Files» translation when it generates the shortcuts.
Процессор не поддерживает данную версию Windows. Что это значит?
Microsoft продолжает усиленно радовать, удивлять и шокировать своих пользователей. Буквально на днях ко мне обратился коллега с такой проблемой: он приобрел и собрал новый ПК на базе нового процессора Intel Core i3 7100. На собранный компьютер был успешно установлен образ Windows 7. Но через некоторое время, после того, как Windows 7 закачала и установила все обновления через Windows Update, система перестала получать новые обновления со следующей ошибкой:
Unsupported hardware
Your PC uses a processor that is designed for the latest version of Windows. Because the processor is not supported together with the Windows version that you are currently using, your system will miss important security updates.
Не поддерживаемое оборудование
Ваш процессор не поддерживает данную версию Windows, вы не сможете получать обновления.
Несовместимое оборудование
Ваш компьютер оборудован процессоров, предназначенным для последней версии Windows, вы пропустите важные обновления системы безопасности.
При попытке выполнить поиск обновления через Windows Update появляется ошибка:
Code 80240037 Windows Update encountered an unknown error.
Неподдерживаемые процессоры для Windows 7 и Windows 8.1
Дело в том, Microsoft еще в прошлом году анонсировала, что все обладатели новейших процессоров должны использовать только последнюю версию клиентской платформы — Windows 10. Для более старых версий Windows будет созданы ограничения для использования данных моделей процессоров.
Ограничения распространяется на следующие поколения процессоров:
- 7-ое — поколение процессоров Intel Core (микроархитектура Kaby Lake , выпуск начался в 2017 году)
- Седьмое поколение процессоров AMD (микроархитектура Bristol Ridge , выпуск начался в 3 квартале 2016 года)
- Qualcomm 8996 (в основном используется для мобильных устройств)
В апреле 2017 года MSFT выпустило специальные патчи для предыдущих версий ОС
- KB4012218 – для Windows 7 SP1 и Windows Server 2008 R2
- KB4012219 – для Windows 8.1 и Windows Server 2012 R2
В описании патчей заявляется о появление функционала определения поколения процессора и поддерживаемого оборудования при поиске обновлений через Windows Update.
Enabled detection of processor generation and hardware support when PC tries to scan or download updates through Windows Update.
Соответственно, после установки данных обновлений, система начинает блокировать загрузку новых обновлений (в т.ч для MS Office) и драйверов на старых версиях ОС с ошибкой 80240037 , тем самым вынуждая пользователей переходить на Windows 10 /Windows Server 2016. Таким образом, все старые системы с новым оборудованием перестают получать обновления безопасности и переходят в разряд уязвимых. Похоже на шантаж…
Конечно, временно поможет удаление этих обновлений (wusa.exe /quiet /uninstall /kb:4012218 /promptrestart или wusa.exe /quiet /uninstall /kb:4012219 /promptrestart ) и блокировка их установки, но с высокой долей вероятности они прилетят в следующем месяце в обновлении Monthly Rollup (в рамках новой концепции накопительной модели кумулятивных обновлений ).
Кроме того, блокируется установка драйверов для видеоадаптеров на базе графических процессоров Intel седьмого поколения (Intel HD Graphics 610 — 650). В Windows 7 SP1 он определяется как стандартный VGA графический адаптер.
При попытке установить скачанный с драйвера производителя подписанный видео драйвер, появляется ошибка «Эта система не удовлетворяет минимальным требованиям для установки программного обеспечения».
Как вы видите, непосредственно в установщике драйвера указано, что на оборудовании с седьмым поколением процессоров Intel, драйвер может быть установлен только в Windows 10 x64.
Wufuc – патч для восстановления Windows Update
Существует неофициальный обходной метод, позволяющий убрать сообщение «Оборудование не поддерживается» и восстановить возможность получения и установки обновлений безопасности на компьютерах с Windows 7 и 8.1 с процессорами Intel Kaby Lake, AMD Ryzen, и другими не поддерживаемыми CPU.
Пользователь GitHub под ником Zeffy выпустил небольшой патч Wufuc (windows update …. ну вы поняли), который позволяет избавиться от проблемы «несовместимого оборудования». Патч отключает сообщение Центра обновлений о несовместимости оборудовании и разрешает компьютеру получать обновления с Windows Update. Последнюю стабильную версию патча Wufuc можно скачать тут: https://github.com/zeffy/wufuc/releases/latest .
Есть версия Wufuc как для x86, так и для x64 систем.
Согласно информации от Zeffy функция обнаружения типа процессора и запрета получения обновлений находится в библиотеке wuaueng.dll . Первоначально патч Wufuc заменял данный файл, но т.к. данное решение неустойчиво против обновления файла очередным обновлением Windows Update, в последующих релизах Wufuc логика работы патча была изменена.
Теперь фактическая замена файла wuaueng.dll не производится. Установщик wufuc_setup_x64.msi регистрирует новое задание планировщика, которое запускает wufuc при загрузке компьютера. Затем wufuc внедряет себя в процесс service host или службу wuauserv и перехватывает вызов функций IsDeviceServiceable и IsCPUSupported, модифицируя возвращаемый ответ.
Таким образом патч wufuc отключает сообщение «Оборудование не поддерживается» в Windows Update, и позволяет продолжать устанавливать обновления на системах Windows 7 и 8.1.
visual studio 2012 win32 project targeting windows 2000
I need to modify a very old project written some years ago in win32 that MUST run on windows 2000 server.
Having recently upgraded my computer i moved to visual studio 2012 and hence my problems.
Ihave read a lot of posts here, and i kinda got confused.
first using platform toolsets i need to install vs2008 & vs2010 right? this is unacceptable.
second, some posts say that i need to overwrite the function DecodePointer/EncodePointer .
third, just be using the defines
option 1 is not acceptable. which of the other 2 options work with vs2012.
3 Answers 3
The runtime for the VS2012 compiler supports targetting XP, but does not support earlier versions. In fact, on release, XP targetting was not supported and that was added in a later update. If you must support Win2k, you must use the toolset from an earlier version of VS that does support Win2k.
Here’s an expansion on Cody Gray’s code for VS2017. It could use a few extra eyeballs to ensure it would work properly. As of now apps will start and run on NT4 built with VS2017. It will also work on Win98 if using MS Layer for Unicode (unicows).
There is a part 2 as well:
VS 2008 works to target Windows 2000 out of the box, as you said. You don’t need anything extra. If you prefer to use a newer version of the IDE, installing multiple versions of Visual Studio simultaneously (always install the oldest versions first, working «forward» in time) will allow you to, e.g., work in VS 2010 but tell it to build using the VS 2008 toolchain. You obviously won’t be able to benefit from compiler features introduced with VS 2010, but you will get to use the newer IDE.
You can use VS 2010 to target Windows 2000 with the EncodePointer/DecodePointer trick. The issue here is that the VS 2010 C runtime library (CRT) requires these functions (it calls them internally), but these functions do not exist on versions of the OS prior to Windows XP SP2. However, if you write stubs and link your executable against those (while also statically linking to the CRT, so it will actually find and use those stubs), then you can run a VS 2010-compiled EXE on Windows 2000. Note that you will also need to set the minimum required version to 5.0 in the linker settings. (You’ll get a link-time warning that this is not a valid, supported version when you do so, but you can simply ignore this warning. It does work, and the field does get properly set in the PE header.) This is undoubtedly a dirty trick, but I know that it works very well; I do it in several of my projects. My stubs dynamically call the real EncodePointer/DecodePointer functions if they are available on the current OS, and if not, fall back to basically a no-op (giving up the security benefits on these downlevel OSes). Suma has already covered this trick quite well in an answer to a related question.
The WINVER and _WIN32_WINNT defines really don’t have anything to do with this. They just control which function prototypes the Windows SDK headers actually define. The idea is that you set these to your target Windows version, and then you will only be able to statically link to functions that actually exist on that version of Windows. You can still dynamically call (via GetModuleHandle/LoadLibrary → GetProcAddress) newer functions when running on an appropriate version of Windows, and gracefully fall back if they are not supported. If you try to statically link to functions that do not exist, the loader will generate an error when you try to run your application. This is easy, though, because this is something that is entirely within your control as a developer. The problem is when the CRT (a library that you don’t control) calls functions that don’t exist, like EncodePointer. That’s why the above-described workaround is required. The values of WINVER and _WIN32_WINNT have no actual effect on the compiler or the linker.
You can probably get away with a similar trick for VS 2012. I started working on this a while back with VS 2015 using the built-in XP-targeting support, and I did manage to get a «Hello world» app running on Windows 2000. If anything, it should be easier with VS 2012 than VS 2015. But it was not easy, and it would probably be a support nightmare for any real-world application. Still, it was a fun experiment, and it confirms what everyone already knows: the problem here is not the compiler or the linker. The PE format is still the same; any compiler or linker that targets Win32 can build binaries that run on any version of Windows NT. The problem is just the C runtime library attempting to call functions that do not exist on downlevel operating systems.
The way to go about testing this is to compile an EXE with VS 2012 using the above-described trick for EncodePointer/DecodePointer. You will also, of course, need to make sure that you’ve set the minimum required version to 5.0 in the linker settings. (If this doesn’t work, and it might not, you will need to manually change it as a post-build step using editbin.exe .) Then, simply try running that executable on Windows 2000. You will undoubtedly get an error message indicating that the application cannot start because of a missing statically-linked function. You’ll then need to research that function and stub it out, just as you had to do for EncodePointer/DecodePointer. Chances are, it will be more difficult, because it is probably going to be a function that does meaningful work, which means that you can’t simply NOP it out. Once you’ve fixed the dependency on that function, repeat the process again for each function that the W2K loader complains about. (You can also use Dependency Walker or equivalent utilities to obtain this information.) Once you work through all of the non-existent functions, you’ll finally have an EXE that runs.
For VS 2015, I had to write stubs for InitializeSListHead, GetModuleHandleEx, and SystemFunction036 (which is the export name for RtlGenRandom), in addition to EncodePointer and DecodePointer. I expect you’ll have a similar experience with VS 2012. Replacing the first two is actually relatively straightforward. For InitializeSListHead, I just reverse-engineered the corresponding functions on Windows XP, and wrote my own implementation for downlevel OS versions. For GetModuleHandleEx, it’s only called by the CRT in a context that enables support for managed apps. Since I didn’t care about those, I just turned it into a no-op that returns failure. SystemFunction036 (RtlGenRandom) is more difficult, but if you’re not using rand (and you probably shouldn’t be), then you don’t need it either. I just stubbed it as a breakpoint ( int 3 ). You could also stub it to call CryptGenRandom. If you do better with code than prose, here is an approximation of the stubs I used in my «Hello world» app:
Roy points out in a comment that Microsoft has provided an MIT-licensed implementation of SList that only requires InterlockedCompareExchange(). This will make your job slightly easier, as you won’t have to reverse-engineer any of the SList functions as I did.
It goes without saying that you should avoid at all costs MFC, ATL, and other libraries whose source code is outside of your control. They will drag in dependencies on functions that are not available on downlevel versions of the operating system, causing even more work for you. You will really need to limit yourself to raw Win32, meaning that the only library you’ll have to worry about is the CRT.
Whew! That should get you started. If, instead of being intrigued, you’re massively intimidated by this, you almost certainly have no business with hacks such as this. Use an older version of the compiler.