This is basically a native application that can modify the registry during the early boot stage.

So what's a native application?An excellent description can be found by Mark at Sysinternals; http://technet.micro...s/bb897447.aspxIn short it is an application you can configure to run before the Win32 subsystem is loaded, similar to autochk,exe. What this means is that we can halt the Windows boot while in native mode (NT) and do whatever we programmed our native app to do. To give an idea of roughly when this occurs during boot, it is right after the system thread has finished phase 1 (executive and kernel initialization considered complete), and the session manager (smss.exe) has been started. In fact, it is smss.exe that starts configured native applications. It does so by reading the registry key: HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\BootExecute. However at this stage, no other registry hives than then SYSTEM have been loaded (and obviously that is what this application can modify), and only 2 processes are running (system and smss). Csrss comes into play later when the subsystem is loaded. For this reason, a native application can not use the Windows API (kernel32.dll etc), but must use the NT API (ntdll.dll). So it has some similarity to kernel mode coding, though the native apps are actually running in user mode, almost right after user mode has been created. But since it is compiled with subsystem=native, it will not be possible to run it like other exe's (when win32 subsystem is loaded). To speed up the testing of such an application it is therefore an advantage to compile a win32 equivalent to execute directly within Windows.

What operations are supported?

Modify existing Value's data or type

Create new value

Create new key

Delete value

Delete key

How to configure OSThe application file must be located within the \Windows\System32 folder. And the relevant registry key are:

The included reg file will import the correct setting, as shown in the above image.

Configuration of applicationIt will search in the root of all volumes for a file name NativeRegMod.config. The config file must have 1 configuration/modification per line (new line), and all settings must be comma separated. Currently 3 reg types are supported: REG_SZ, REG_DWORD and REG_BINARY. Due to the comma as separator, any key/value name must not have comma in it. The structure of this file is:

Create the key "NewKey2" under the key created in first line. Then create a value "test_sz" of type REG_SZ with the data "something".

Update the data of an existing REG_DWORD value with name "test_dword" with the new data of decimal 10.

Update the data of an existing REG_BINARY value with name "test_binary" with the new data of "00112233445566778899AABBCCDDEEFF".

Delete the key \Registry\Machine\SYSTEM\Setup\OldKey

Delete the value named "OldValueName" under the key \Registry\Machine\SYSTEM\Setup\OldKey2

If the reg value does not exist, it will be created. However if a key does not exist, the function fails.

WarningThe error checking is far from perfect, and the input evaluation is limited. It is expected to be correct. It should not be regarded as a safe C implementation. However from all my tests, the worst thing that have happened, is that the application crash and Windows continue booting fine. Of course if you are modifying system critical registry parts, then chances are good that you may mess up the system. And actually, that is the kind of use the application was made for. So, ideally you would be testing with it in a virtual machine where you have snapshots to revert.

What can it be used for?That's up to you to figure out. However if you are still reading and find it interesting, you likely will come up with something.

Target OSShould really run on any modern Windows version and architecture. Has been tested on:

XP SP2 32-bit

Windows 7 SP1 32-bit

Windows 7 SP1 64-bit

Even though there exist compiled versions for both 32 and 64-bit, the 32-bit also works on 64-bit as long as WoW64 is present (default except for standard WinPE).ToDo

Updated it and added support for deleting keys and values, as well as creating new keys/values. Also fixed a bug with memory cleanup (caused subsequent REG_SZ of varying length to corrupt next value.

Works on 32 and 64-bit, but the 64-bit version is strictly only required when WoW64 is not available (as with standard WinPE). Think it also works on Windows 8, but have not been tested there.

The source will be released too, when cleaned up. Besides that, compiling this in VS2012, likely deserves a tutorial on its own. And actually I also had to manually modify the final exe in a PE-editor to make it work.

I imagine you may also be aware of the Native Shell, an evolution, created by amdf, of the famous TinyKRNL Project's shell, but I'm mentioning it here just in case, since that's related material, too, after all.

I imagine you may also be aware of the Native Shell, an evolution, created by amdf, of the famous TinyKRNL Project's shell, but I'm mentioning it here just in case, since that's related material, too, after all.

If you are into this, then probably the Alex Ionescu's native nt toolkit:

....
2) Provide a *single* and *correct* set of headers for *all* community members who need access to Native API. Too many people get it wrong, or get it right but had to spend 2 months duplicating effort that someone may already have been made.
.....

I strongly urge and recommend anyone writing native applications to use the NDK instead of their own header files and please let me know any issues you encounter. As far as naming and structure format goes, the ones in the NDK are the official Microsoft-internal names (which were obtained either from symbols or strings inside binaries) --not guesses. So they supercede information found on other websites, if contradictory (of course, if you have a really good argument against a field name, feel free to drop me a note -- everyone makes mistakes).

.....

seems to me like "sound", as I have seen a lot of "guesses" when it comes to native apps.

The Native Shell and NDK is also nice resources for the topic of native application. However I did not use it for this tool. In that sense, it's a bit of a shame since I've likely re-invented some of the native wheels, in a not so elegant way as Alex have.

Anyways, trying to solve the "detect commandline passed from registry" challenge. Will take a new look at those projects to see if it is already solved there. If not, I still have a good clue, just need to solve it in C..

If I believe NativeRegMod can be executed from NativeShell (being a native app).

/erwan

Yes it fills in some missing stuff in the Native Shell. I think it can be started directly from within Native Shell too, since both are native apps. If not you can still configure them run after each other by adding entries in the registry at BootExecute. I am not aware of any restriction there.

And *somehow* build something a little beyond the "POC" level, particularly as a "building environment" as - as Joakim just reported - it seems to be particularly difficult to actually compile anything working in "native" mode.

Still (nth attempt to draw attention of good programmers to this ) a minlogon replacement would allow to have a real NTCLI (or XPCLI, 7CLI, etc.) i.e. what I see as a good replacement for the Recovery Console and for most PE's when it comes to small mods/repairs):

It needs to be explored a bit more I think. Regarding usb boot, I think it may be too late in the boot process, but testing may be required to conclude.

Regarding native cli, you sure can access it and then continue booting into the win32 subsystem of Windows. Having an option to reboot I think already is there, or else could probably be added with little effort.

About registry modification, we have certain restrictions, to what hives actually are loaded and available at the time of NT mode. It is only SYSTEM and HARDWARE, which means SAM, SOFTWARE and the rest are not yet loaded. Though I guess we can load them, modify and then unload them..