
Bypassing Windows ASLR using "skype4COM" protocol handler - ColinWright
http://www.greyhathacker.net/?p=641
======
to3m
Poor old Skype. I can only assume they switched this off for debugging
purposes, because debugging with ASLR can be such a massive pain in the arse.
With no global "no ASLR for this process while being debugged"-type option
that you can switch on, at least none that I could ever find, one's options
are a bit limited.

~~~
loeg
Just curious, how does ASLR make debugging painful for you?

~~~
barrkel
Hardware breakpoints on memory accesses.

This is a somewhat common technique for tracing the value of a variable
backwards in time in native code, particularly in the presence of buffer
overflows or other memory corruption. When debugging, you find out that a
variable has a weird value, a value it could never have according to the code.
So you put a hardware breakpoint on the variable's address and restart the
program. Play around with the step count on the breakpoint, and you can find
the write that messes things up.

It only works when you can reliably reproduce the same execution steps every
run, including heap addresses. And ASLR breaks the technique.

ASLR also tends to make buffer overflows and other memory corruption appear
randomly rather than consistently.

~~~
ghratch
On Linux you could try using the Fast Reversible Debugger
(<https://github.com/fred-dbg/fred>) for its memory-accurate record/replay
feature. Full disclosure: I was a contributor on that project at one point.

~~~
loeg
I haven't tried it yet myself, but supposedly GDB has supported reversible
debugging since 2009[0] — any experience with that? Limitations?

[0]: <https://www.gnu.org/software/gdb/news/reversible.html>

