Comments on: How the ESP trick actually works

By: moiciotohiz

moiciotohiz — Tue, 07 Jul 2009 01:06:34 +0000

Excellent blog! Very interesting themes. I will often read it. Also e-mailed on rss.

By: moiciotohiz

moiciotohiz — Mon, 06 Jul 2009 01:17:14 +0000

Awesome blog! Subscribed on rss. Regular will read it. Good job.

By: Unpacking Themida 2.0.8.0 - The World of Game Hacking

Unpacking Themida 2.0.8.0 - The World of Game Hacking — Mon, 29 Jun 2009 05:20:19 +0000

[...] jmp to OEP is push/ret to OEP after the popad. Once at OEP, dump file and fix imports with ImpRec. How the ESP trick actually works – KOrUPt Of course, themida may not use this method in which case my advice would be useless. But a cool [...]

By: KOrUPt

KOrUPt — Mon, 22 Dec 2008 22:58:13 +0000

Nice to see smart people on board … Thanks for the comment Meh(Do you have a handle you care to use?)…

I didn’t want to confuse a potential newbie reading my post so I kept the description perhaps a little too vague. I agree it is inaccurate. Thanks for taking the time to correct me on that one.

Also, I’ve slightly edited your above comment and corrected a few grammatical mistakes, I hope you don’t mind.

KOrUPt.

By: meh

meh — Mon, 22 Dec 2008 22:43:04 +0000

Yeah like metr0 noted, that section on software BP isn’t entirely accurate, or at least not very clear.

int3 just triggers an interrupt(the hardware does this) causing an interrupt handler(checks the descriptor at idtr register + 8 * 3, the hardware does this too) to run (it typically notifies the parent process(debugger)), which re-replaces the 0xCC byte with the original value.

If the debugee notices this in any way other than the CC instruction being in memory before the breakpoint triggers there is a bug I guess. The context switching should be transparent to the debugee otherwise packets arriving on the network card or moving the mouse would change the registers too . The instruction being in memory however could invalidate self CRC checks and such. But UPX has none of that.

But course, here it is indeed the fact that we want to have a data breakpoint. And hence we need to to write the address in one of the dr0-3(that’s why you can only have 4) registers and set some bits in dr7 .

Killboy: yeah learning RE is like “breaking the magicians code”. You always knew that the lady wasn’t really sawed in half but… We all need to go through this at several levels of the software stack So I figured I’d throw in some ring0 stuff in this post to break a bit more of the magic of ollydbg No more magic ‘hardware’ breakpoints

By: KOrUPt

KOrUPt — Mon, 22 Dec 2008 22:11:42 +0000

Thanks for the feedback guys!… It’s nice to read others opinions and get a little discussion flowing every now and then .

@metr0: Good point, I’ll edit the post accordingly later tonight. Thanks.

KOrUPt.

By: Killboy

Killboy — Mon, 22 Dec 2008 22:07:23 +0000

This trick has been explained so many times in various tutorials, the first time I read about it was in ARTeam’s Olly beginners tutorials, lena covers it and it’s the topic of a bunch of threads in every decent RE forum.
Yet explanations don’t stop popping up

If you believe the ‘urban myth’, it’s like the most explained and less understood ‘trick’ out there. Not sure this is true though, I just believe every halfway decent reverser feels like having to explain this trick after he actually understood how it works and loses its ‘magic’.

No criticism, just reflecting on it as I went through this myself

By: metr0

metr0 — Mon, 22 Dec 2008 22:00:53 +0000

“You may be wondering why we need a hardware breakpoint as oppose to a software breakpoint, the problem with software breakpoints is that our debugger places an int3 instruction(0xCC byte) at our target address, this will corrupt our registers contents… Which is not what we want.”

You might also want to clearify that a software bp would just trigger on execution, which is not what would help us here (and mem bps using page guard are simply too slow).

Nice to see your blog back in action, mate!