Peter Van Eeckhoutte's Blog

Posts Tagged ‘exploit’

About 3 months after finishing my previous exploit writing related tutorial, I finally found some time and fresh energy to start writing a new article.
In the previous tutorials, I have explained the basics of stack based overflows and how they can lead to arbitrary code execution. I discussed direct RET overflows, SEH based exploits, Unicode and other character restrictions, the use of debugger plugins to speed up exploit development, how to bypass common memory protection mechanisms and how to write your own shellcode.
While the first tutorials were really written to learn the basics about exploit development, starting from scratch (targeting people without any knowledge about exploit development) you have most likely discovered that the more recent tutorials continue to build on those basics and require solid knowledge of asm, creative thinking, and some experience with exploit writing in general.
Today’s …

Hi all,

I just wanted to drop a few lines to let you know that, earlier today, my exploit write-up article about this vulnerability was published on www.abysssec.com.

You can find the article here : http://www.abysssec.com/blog/2010/03/ken-ward-zipper-stack-bof-0day-a-not-so-typical-seh-exploit/

Enjoy ! Read more »

Hi all.   I just wanted to drop a quick note that I have released part 2 of the QuickZip 0day vulnerability exploit on the Offensive Security Blog just a few moments ago.   You can find the article here. Have fun & cheers ! Read more »

A few moments ago I published a detailed write-up, explaining the steps I took to build a 0day exploit for a zip file handling bug in QuickZip, on the Offensive Security blog. You can read the article here : http://www.offensive-security.com/blog/vulndev/quickzip-stack-bof-0day-a-box-of-chocolates/ Read more »

Over the last couple of months, I have written a set of tutorials about building exploits that target the Windows stack. One of the primary goals of anyone writing an exploit is to modify the normal execution flow of the application and trigger the application to run arbitrary code… code that is injected by the attacker and that could allow the attacker to take control of the computer running the application. This type of code is often called “shellcode”, because one of the most used targets of running arbitrary code is to allow an attacker to get access to a remote shell / command prompt on the host, which will allow him/her to take further control of the host.  While this type of shellcode is still used in a lot of cases, tools such as Metasploit have …

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 …