Peter Van Eeckhoutte's Blog

Posts Tagged ‘eip’

Introduction Easter is still far away, so this is probably the right time to talk about ways to hunting for eggs (so you would be prepared when the easter bunny brings you another 0day vulnerability) In the first parts of this exploit writing tutorial series, we have talked about stack based overflows and how they can lead to arbitrary code execution. In all of the exploits that we have built so far, the location of where the shellcode is placed is more or less static and/or could be referenced by using a register (instead of a hardcoded stack address), taking care of stability and reliability. In some parts of the series, I have talked about various techniques to jump to shellcode, including techniques that would use one or more trampolines to get to the shellcode.  In …

Finally … after spending a couple of weeks working on unicode and unicode exploits, I’m glad and happy to be able to release this next article in my basic exploit writing series : writing exploits for stack based unicode buffer overflows (wow – that’s a mouthful). You may (or may not) have encountered a situation where you’ve performed a stack buffer overflow, overwriting either a RET address or a SEH  record, but instead of seeing 0×41414141 in EIP, you got 0×00410041. Sometimes, when data is used in a function, some manipulations are applied. Sometimes data is converted to uppercase, to lowercase, etc…  In some situations data gets converted to unicode.  When you see 0×00410041 in EIP, in a lot of cases, this probably means that your payload had been converted to unicode before it was put on the …

In the first parts of this exploit writing tutorial, I have mainly used Windbg as a tool to watch registers and stack contents while evaluating crashes and building exploits. Today, I will discuss some other debuggers and debugger plugins that will help you speed up this process. A typical exploit writing toolkit arsenal should at least contain the following tools : windbg (for a list of Windbg commands, click here) ollydbg immunity debugger (requires python) metasploit pyDbg (if you are using python and want to build your own custom debugger, as explained in the awesome Gray Hay Python book scripting tools …

In the previous tutorial post, I have explained the basics of SEH based exploits. I have mentioned that in the most simple case of an SEH based exploit, the payload is structured like this : [Junk][next SEH][SEH][Shellcode]

I have indicated that SEH needs to be overwritten by a pointer to “pop pop ret” and that next SEH needs to be overwritten with 6 bytes to jump over SEH… Of course, this structure was based on the logic of most SEH based vulnerabilities, and more specifically on the vulnerability in Easy RM to MP3 Player. So it’s just an example behind the concept …

Where do you want to jmp today ? In one of my previous posts (part 1 of writing stack based buffer overflow exploits), I have explained the basisc about discovering a vulnerability and using that information to build a working exploit. In the example I have used in that post, we have seen that ESP pointed almost directly at the begin of our buffer (we only had to prepend 4 bytes to the shellcode to make ESP point directly at the shellcode), and we could use a “jmp esp” statement to get the shellcode to run. Note : This tutorial heavily builds on part 1 of the tutorial series, so please take the time to fully read and understand part 1 before reading part 2. The fact that we could use “jmp esp” was an …

Last friday (july 17th 2009), somebody (nick)named ‘Crazy_Hacker’ has reported a vulnerability in Easy RM to MP3 Conversion Utility (on XP SP2 En), via packetstormsecurity.org. (see http://packetstormsecurity.org/0907-exploits/). The vulnerability report included a proof of concept exploit (which, by the way,  failed to work on my MS Virtual PC based XP SP3 En). Another exploit was released just a little bit later. Nice work.  You can copy the PoC exploit code, run it, see that it doesn’t work (or if you are lucky, conclude that it works), or… you can try to understand the process of building the exploit so you can correct broken exploits, or just build your own exploits from scratch. (By the way : unless you can disassemble, read and comprehend shellcode real fast, I would never advise you to just …