Hi Peter, I don’t write in english but I try… I have practiced and seen those tutorials 1,2,3 and 3B and they are very interesting and very educational. thank you for your time!, I have learned so much… Martín
Very good, though I noticed hat the file must be have an .mpf extension, rather than the .m3u for the exploit to work. I have successfully got it working with c0d3r.mpf but if I change the script to generate c0d3r.m3u, nothing happens. If I simply rename the file to .m3u from .mpf, it does not trigger the exploit. Thought you should know that.
I like your SEH overwrite. Lacking some important steps. 1) keep in mind when writing your own exploit that you still need to trigger the SEH. 2) if dep, then note that when SEH !exchain will not be allowed to execute stack-based code. This is a really easy thing newbies are not used to but should see it in action so when it happens to them, they know how to identify this technique. 3) application level code/logic may prevent developer from triggering their exploit. For example, what if the input parameter triggering SEH is a UserID and the application only likes ASCII sets (they are checked) – then you have to find and place a good pop/pop/ret that is coming from some module that is usable within ASCII code set. this requires getting good with searching. test what you get with what is expected when your dumping memory to find out why the pop/pop/ret was not working. 4) I windbg “lm” to search loaded mods and find my pop/pop/rets manually, but using metasploit’s msfpescan script against the binairies or loaded dlls is easier. Im old fashioned so I use meta_asm_shell.rb to get opcodes that could do pop/pop/ret equivalents. 5) Using Byakugan compiled for your target helps finding the depth to SEH much faster. pattern_create/pattern_find work too. Or, you can count the distance.
Peter, If I have a small buffer for my payload after jumping to my shellcode, is there anyway I can find a space that can find a bigger buffer for my payload. So I have junk(320) + nseh(4) + seh(4) + shell(112) As you can see, I only have 112 bytes to play with for a shell. Thanks for your help
Working on this tutorial parts 3 and 3b was happyness, thanks for sharing your knowledge. A little question though, regarding the offset, where is located the address to the next exception registration record. We use the MSF pattern, and find the offset of the value that overwrite the so called nseh. For me, these offsets are 4105 for mpf, and 4103 for m3u. But they are computed independently of the ‘http://’ prefix. Does this mean that the string we are using while overwriting the stack starts at AAA.A.. and not at http://AAAAA… ? There may be a variable or parameter that points to an address I’ve seen, that points to ascii AAA.A… How would you investigate on this ? Cause you have to know this to get the correct offest to nseh. As always, any advice is appreciated. Thanks, dru1d0k