You are browsing the archive for Random ideas.

Regedit.exe and a possible race condition

April 1, 2018 in Anti-*, Random ideas

Regedit.exe accepts two less known command line arguments:

  • regserver
  • unregserver

When launched with any of these it will call the advpack.dll!RegInstallW function passing to it one of the section names (called RegExe or UnregExe respectively) that are defined inside the .inf file embedded directly in the regedit.exe file:

The extracted .inf file is first saved into a temporary file with a name %Temp%\RGI<random>.tmp file.

It is then interpreted like any standard .inf file.

One can use these commands to do at least two things:

  • unregister regedit file association – see the pasted info below; other than damage, it may render some system repair more difficult (.reg files can’t be used)
  • attempt to exploit a race condition and swap the temporary .inf file with one of attackers’, forcing regedit.exe to run the .inf file of attackers’ choice; it’s a tricky one to pull of, but the possibility exists

The Regshot diff from running the regedit /unregserver command on a test Windows 7 system is shown below:

Keys deleted:17

Values deleted:14
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.reg\PersistentHandler\: "{5e941d80-bf96-11cd-b579-08002b30bfeb}"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.reg\: "regfile"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regedit\shell\open\command\: "regedit.exe %1"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regedit\: "Registration Entries"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\edit\command\: *%SystemRoot%&#x5C;system32&#x5C;notepad.exe "%1"*
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\open\command\: "regedit.exe "%1""
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\print\command\: *%SystemRoot%&#x5C;system32&#x5C;notepad.exe /p "%1"*
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\open\: "Mer&#x26;ge"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\open\MUIVerb: "@regedit.exe,-310"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}\: "{1531d583-8375-4d3f-b5fb-d23bbd169f22}"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\DefaultIcon\: "regedit.exe,1"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\EditFlags: 0x00100000
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\: "Registration Entries"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\FriendlyTypeName: "@regedit.exe,-309"

Weird DLL behavior

December 28, 2017 in Random ideas

I was toying around with the static DLL loading and came across a very strange behavior.

So… I created a small .exe file that depends on dll1.dll and dll2.dll, linked statically, and calls function1 and function2 from each DLL respectively.

 invoke function1 ; from dll1.dll
 invoke function2 ; from dll2.dll
 invoke ExitProcess,0

When loaded (and when the respective function is called) the DLLs create one of the following files:

  • DLL1.DLL
    • c:\test\dll1_attached – DLL is loaded (attached)
    • c:\test\dll1_detached – DLL is unloaded (detached)
    • c:\test\dll1_function – ‘function’ is called
  • DLL2.DLL
    • c:\test\dll2_attached – DLL is loaded (attached)
    • c:\test\dll2_detached – DLL is unloaded (detached)
    • c:\test\dll2_function – ‘function’ is called

I then modified the section attributes for dll2.dll so that its .text section doesn’t have code execution rights.

 Name: .text
 VirtualSize: 0x00000070
 VirtualAddress: 0x00001000
 SizeOfRawData: 0x00000200
 PointerToRawData: 0x00000400
 PointerToRelocations: 0x00000000
 PointerToLinenumbers: 0x00000000
 NumberOfRelocations: 0x0000
 NumberOfLinenumbers: 0x0000
 Characteristics: 0x00000000 <---- no flags

The dll1.dll .text section looks like this:

 Name: .text
 VirtualSize: 0x00000070
 VirtualAddress: 0x00001000
 SizeOfRawData: 0x00000200
 PointerToRawData: 0x00000400
 PointerToRelocations: 0x00000000
 PointerToLinenumbers: 0x00000000
 NumberOfRelocations: 0x0000
 NumberOfLinenumbers: 0x0000
 Characteristics: 0x60000020 <---- (CODE, EXECUTE, READ)

I then tested this file set on on Win 10 x64. After dropping the files into VM I ran the test.exe.

The first run shows the expected behaviour – i.e. the application crashes:

There is an event logged in the Event Logs as well:

To my surprise, when I re-run the test.exe it… actually works:

Running it again and again I am getting inconsistent results. I drop the files into a win10 VM and sometimes it crashes with the first run, same as described above. And sometimes it runs smoothly.

For the same set of files tested on Win7 x64 – I get the ‘dll1_attached’ created, but then the test.exe crashes.

When dropped into XP VM, it works w/o any issues (files are created).

When I manipulate .text section attributes for dll1.dll the application always crashes. So, it would seem that the section of the first DLL cannot be modified, but the second one can.

I am now scratching my head… Looks like a potential DLL mapping bug?

The memory layout looks like this:


You can grab the files here.