In this post i will quickly show you an integer overflow found in OllyDbg v1.10. This leads to a buffer overflow, which can be exploited to execute code arbitrarily.

In brief, all you have to do is set the size of Resource table to 0xFFFFFFF7.
http://3.bp.blogspot.com/-Hx-reft8rAQ/T3SmECkhOTI/AAAAAAAAAdo/TXfv6hNiSek/s1600/Untitled.png
Olly adds 0x9 to 0xFFFFFFF7, which sums up to Zero due to an integer overflow. Zero byte is then allocated by calling the "GlobalAlloc" function. Finally the "_Readmemory" function is called to copy 0xFFFFFFF7 bytes to the newly allocated memory causing a buffer overflow. See the image below.
http://3.bp.blogspot.com/-0Ze-APopdEg/T3SpW4vc28I/AAAAAAAAAdw/9ft2VVXB1Do/s1600/resource_overflow.png
But wait, there is a minor issue that i need to shed some light on. The "_Readmemory" function, as its name implies, is a wrapper of the kernel32.dll "ReadProcessMemory" function. So why did this call succeed if the number of bytes to copy is that huge? the reason behind this is that the "_Readmemory" function checks to see if data at the target address is cached. If it is cached, the "memcpy" function is directly called and this is where the buffer overflow occurs.
http://1.bp.blogspot.com/-xjxucmGmi7s/T3SuJCeq1ZI/AAAAAAAAAd4/xJhY7mVbuNo/s1600/overrrrr.png
Here you can find the demo.
http://ollybugs.googlecode.com/files/you.exe

Hi walied,

today I've read through the posts you've made so far, the googlecode site of yours and through your blog.
Let me say, that I find your work pretty impressive.
May I ask what your intention is? I mean, do you report these bugs to Oleh also? Are you doing this to show people why Olly sometimes don't work as they expect. To show software developers how they can implement a better debug protection? Or is it just from curiosity?
Please, don't get me wrong. I'm really greatly impressed by your work and there is no offense intended.
I'm just curious.

Keep up the good work!

Best regards
darkelf

My intention is to be one step ahead of malware using anti-olly tricks that hinder the reversing process and also to provide some new anti-tricks for software protection tools, actually, the FPU bug of Olly v1.10 (implemented in Themida) inspired me to start the whole thing.

I did not contact Oleh for the Olly v1.10 bugs since it is discontinued and no longer supported. As for Olly v2.0 bugs, i tried to contact Oleh, but he was not responsive.

If you have noticed, one of the most vulnerable functions in Olly is the PE header parsing function. This shows us how Oleh did not understand the PE format very well and many other stuff.

I will be very glad to see new protectors deploying my own bugs and exploits.

walied: "If you have noticed, one of the most vulnerable functions in Olly is the PE header parsing function. This shows us how Oleh did not understand the PE format very well and many other stuff."

keep a good work.. but on you last comment i would like to say you are missing the point of OLLY.. its debuger.. and it should debug and make a process of debuging easy for us... which it does.. i dont see a point of Oleg looking into pe format and fixing all the crush points you found.. i rather see that it works and debugs perfectly as it does.. adding new stuff optiomation,., plugins new ideas.. then fixing section holes.. which makes olly crush.. you can patch exe easy....you can alwasy find overflow points in every program....so you can in olly .. no matter how much time he spend fixies wholes .. it will alwasy have something still to fix... if you ask me i rather see major wholes fixied then your pe format things.. Above all you can alwasy fix exe easyer then you can fix olly:P


aha here is project for you .. you can do the same with windows media player as you are doing with olly.. its just a matter of time how many bugs you will find...