Does anyone know the whereabouts of any info on how to write shellcode for windows. I am looking to understand how various exploits work and hopefully to write my own.

Thank you for your time

Codecfault

Been trying to learn myself. I posted a good into into into buffer overflows in the sticky above and I've found this article to be really helpfull. I'd be interested if anyones got anmy good asm tuts

great link thanks pr0t0type

thanks alot guys im also trying to learn to code /etc

http://www.hick.org/code/skape/papers/win32-shellcode.pdf

Thanks to all who posted links on this subject, the last 2 look very useful, and have to go and read them, been looking around but never saw these.

thanks a lot nazinofix great link

thx nazinofix
very interesting link

byee

great work.

http://www.shellcode.com.ar has some windows shell code. I've learned a few sweet tricks from code available there.

http://www.cs.fit.edu/~tr/cs-2002-12.pdf

W32 buffer overflow froma A to Z .

wow thx m8!!! that's a realy good documentation about buffer overflows!!

these 2 pdfs are a real nice reading..
thnx for shaing

Windows shellcode is a bitch too write. All of those win32 shellcode papers show how to get it by SEH or you can get it by using the TEB block i think or whatever is at fs:[30]..but i think the more code efficent way is like this..or atleast i think it is.

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?

another nice site:

http://www.metasploit.com/

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.

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