Government Security
Network Security Resources

Jump to content


Windows Shellcode

- - - - - windows exploit shell
  • 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:


#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.

#18 nazinofix



  • 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.

#19 Guest_archphase_*

  • Guests

Posted 13 February 2004 - 04:36 PM

oh yeh i just scanned that thing and didn't see it. woops :-/

Also tagged with one or more of these keywords: windows, exploit, shell