Comments on: Shellcode: finding the base address of kernel32 in Windows 7

By: alu

alu — Tue, 12 Jul 2011 10:25:12 +0000

old entry, but anyway.

The unicode string is actually a structure that looks like this:

struct UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
}

So could do something like:

mov ebx, [fs:0x30] ; get PEB base address
mov ebx, [ebx + 0xc] ; get PEB.Ldr
mov ebx, [ebx + 0x1c] ; get PEB.Ldr.InInitOrder
.loop:
mov eax, [ebx + 0x8] ; get base dll addr
movzx esi, word [ebx + 0x1c] ; get length
mov ebx, [ebx] ; get next entry
cmp si, 0×18
jne .loop

By: Finding Kernel32 Base Address Shellcode « Insanely Low-Level

Finding Kernel32 Base Address Shellcode « Insanely Low-Level — Thu, 07 Jul 2011 20:58:44 +0000

[...] based my code on: http://skypher.com/index.php/2009/07/22/shellcode-finding-kernel32-in-windows-7/ AFAIK, who based his post on: [...]

By: SkyLined

SkyLined — Tue, 25 Jan 2011 20:06:09 +0000

I haven’t got a copy to check your claims, but it used to work fine on my x64 Vista SP2 (in x86 WoW64 mode of course). The check does indeed make assumptions that do not NEED to be true for all OS/SPs, but you’re the first to report issues. Did you run the code to make sure it fails? If not, could you give it a try and let me know if it does not, so I can consider other options?

By: SkyLined

SkyLined — Tue, 25 Jan 2011 20:01:50 +0000

Not sure how to find the structure you’re referring to, but I assume you’ll need a few more instructions to do that. The above code is intended to be as small as possible and still work.

By: sippy

sippy — Fri, 21 Jan 2011 23:58:05 +0000

Actually, Vista Ultimate SP1 x64 (maybe other versions) has a bunch of nulls after ntdll.dll, so this method doesn’t work for all platforms mentioned. I tried to post sample windbg output but wordpress hates me.

By: sippy

sippy — Fri, 21 Jan 2011 23:49:09 +0000

Why not insure you have the right module by validating the .Length field of the UNICODE_STRING structure for module_name is 12?

By: Exploit writing tutorial part 9 : Introduction to Win32 shellcoding | Peter Van Eeckhoutte's Blog

Fri, 25 Jun 2010 07:02:27 +0000

[...] This is what I meant with “think goal oriented”. The code does exactly what it needs to do, without imposing any restrictions. You can still use this code to execute something else, and the method to get the WinExec function address is generic. So my assumption that I needed to find 2 function addresses is wrong – all I really needed to focus on is getting calc executed. You can find more information on skylined’s approach to finding a function address here [...]

By: Aniway

Aniway — Mon, 30 Nov 2009 15:26:30 +0000

Cheers:)

By: SkyLined

SkyLined — Mon, 30 Nov 2009 15:10:28 +0000

Ah, that makes sense: the code assumes that the “ntdll.dll” string is followed by bytes that do not contain a NULL byte at offset +12 from the start of the string. It appears this is true for all versions of Windows after w2k (though I have not tested them all to confirm this). It seems that win2k happens to have a NULL byte at this offset after the string, causing the code to mistakenly assume it is kernel32.dll. Checking for a WORD NULL at that location solves this. Thanks for the feedback!

By: aniway

aniway — Fri, 27 Nov 2009 04:15:34 +0000

Hi Skylined,

Just let you know that I figured it out.

As the first module name being checked is ntdll.dll, on win2k, the unicode name and the data following it is as below:

6e 00 74 00 64 00 6c 00 6c 00 2e 00 64 00 6c 00 ntdll.dl 6c 00 00 00 42 00 08 00 00 01 l.B.. ^^ This is the byte we are checking.
As you can see, if we only check one byte, the code will think ntdll.dll is kernel32.dll. Checking 2 bytes fixes that problem.

Cheers,

Aniway