patrickthomassen@xxxxxxxxx wrote in news:20060116012440.17540.qmail@xxxxxxxxxxxxxxxxx > Because the buffer is only very small, I had to write small shellcode. > The code is less than 100 bytes, and there are 6 bytes left. So there > is still space to improve it. The stack seems to be static, every run > at the exact same location. > > I used the Import Address Table (that looks like this): > > (taken from v5.1) > Import Address Table > 00447230 (send) > 00447234 (recv) > 00447238 (accept) > 00447240 (listen) > 0044724C (connect) > 00447268 (closesocket) > 00447284 (bind) > 00447288 (socket) > > Using that shellcode I retrieve the "second" shellcode. This can be ANY > code, and ANY size. No limitations. If you want to make your 1st stage _really_ small, you could look further up the stack in a debugger at the time the overflow hits and see if there's a local variable there with a handle to the incoming socket on which the overflow was received. Then you could just recv() more data from it directly in-line with the overflow packet. Shoudl be able to get it down to 20-30 bytes that way. > // 'START' > > // Move the stackpointer. (0x0012F??? -> 0x0012F000) > "\xC1\xEC\x0C" // SHR ESP, 0x0C Right about now would be an "interesting" time to get scheduled / interrupted / have an APC delivered... ! > "\xC1\xE4\x0C" // SHL ESP, 0x0C cheers, DaveK -- Can't think of a witty .sigline today....
