Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

Sponsored by: █ Sparkhost - Hosting Without Compromises! █ Hybrid Performance Web Hosting █ Spark Host Stream Hosting █ Hybrid IRC & IRCd Server Shell Accounts

Windows Shellcode

Started by Codecfault , Oct 22 2003 11:19 PM

Prev

Please log in to reply

18 replies to this topic

#16 beenal

Private First Class

Members
32 posts

Posted 11 February 2004 - 10:15 PM

another nice site:

http://www.metasploit.com/

Back to top

#17 Guest_archphase_*

Guests

Posted 12 February 2004 - 06:26 PM

The 'Understanding Windows Shellcode' paper cited earlier in this thread covers the technique of walking down in increments of 16 pages (64KB) to locate the MZ header associated with kernel32 by taking an address that is known to be inside kernel32. It applies this technique with both walking the SEH list to the last handler as well as using a known offset from the top of the stack which is in the TEB. The latter ends up being about 25 bytes all told. Is this what you're describing?

Naw..i mailed HDM but havent got a response.

When windows spawns a new process it calls CreateProcess which makes a call after the pe loader has done everything. So that means esp on entry is = to somewhere in kernel32. So if the compiler builds a stack frame like most vc++ apps then it'll do like:

push ebp
mov ebp, esp

which means that you can do:

mov eax, [esp+4]; account for push ebp

and youll find somewhere in kernel32 where i just decriment 1 byte and check for MZ signiture then you can go from there.

like that code above i think would generate 15 bytes vs. 25 if you were trying to find the base.

Back to top

#18 nazinofix

Private

Members
4 posts

Posted 12 February 2004 - 10:17 PM

Yeah, I understand what you're saying. The concept you're describing is discussed under the TOPSTACK method in the PDF. The difference is that instead of making use of the TEB you're using a constant offset. While technically useful, and indeed smaller, this method is vulnerability dependant and thus not as robust. It also relies on the fact that the vulnerability is realized through a constant call stack (which generally speaking is the case, so this point isn't a big one). Granted, robustness isn't really a big concern in the exploit world, but the lack of robustness is the reason it isn't covered in such a fashion in the PDF, but rather is discussed in the context of a more reliable approach.

The method you describe is definitely viable, just pointing out why it is approached differently in general.