Description: In this video we discuss how to find where EIP is overwritten using Binary Reduction (aka Binary Search)
External Links:
Dino Dai Zovi Teaches Exploitation -
http://pentest.cryptocity.net/exploitation/
Part 1: http://youtu.be/8S0SqXIGv98
Part 6: http://youtu.be/HiZ7_BuFK0k
Tags: Hacking , buffer overflow , exploit , stack , EIP overwrite , EIP , registers , assembly , linux ,
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.
I realise that it was *relatively* straightforward to find the point where EIP was overwritten by a "divide and conquer" approach as this was within the first 32 bytes. However, I don't think I would have wanted to watch you find it if the EIP-overwrite had been at, say, 634 bytes!
I know there is pattern_create.rb in Metasploit and just wonder if a similar approach could be used here? I'm far from an expert in perl, but know that it's good with files. How about a text file containing:
Aa0Aa1Aa2Aa3 ... Zz7Zz8Zz9
as a single line and have the perl send, say, the first 100, 250, 500 etc. of these characters to the executable? I imagine the executable would spew back the hex equivalent and it would be easy enough to convert it back to ascii then calculate how far into the file the relevant characters were situated.
Is this feasible?
Yes, You can use pattern_create.rb in the metasploit tools to create the pattern, store it in a file and have perl print that pattern, you could also just paste it in. You have to consider that the pattern does have its limitation though. So you might want to do a few binary reductions, to get close, then use the pattern to hit the exact spot. Sometimes buffer overflows could require 10,000 bytes, from my experience, using pattern create to make a 10,000 byte pattern wont give you an accurate result and you should reduce it to somewhere under 5k.
Hope that answers your question.