Bypassing Windows ASLR using "skype4COM" protocol handler(greyhathacker.net)
greyhathacker.net
Bypassing Windows ASLR using "skype4COM" protocol handler
http://www.greyhathacker.net/?p=641
1 comments
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.
Given the smorgasbord of obfuscation nonsense in Skype release binaries, I would not be at all surprised if the snake oil wouldn't play nice with ASLR.
Just curious, how does ASLR make debugging painful for you?
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.
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.
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.
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
[0]: https://www.gnu.org/software/gdb/news/reversible.html
I've never heard of DMTCP or FReD. It sounds interesting. Have you thought of submitting it to HN?
Yes, data breakpoints was mainly what I was thinking of. But I was thinking of assembly language breakpoints as well (Visual Studio doesn't store the addresses symbolically, or didn't seem to when I was trying it) - I've often found myself needing these too when trying to narrow down on some really ugly bug or other.
I've needed to do this on literally every single program I've ever worked on, and I've even missed them a few times in C#...
I've needed to do this on literally every single program I've ever worked on, and I've even missed them a few times in C#...
Some tools (e.g. IDA) will just completely corrupt their database trying to relocate to a base different from the one in the image. It also makes for random looking crash reports.
Not as much of a problem if you have debug data.
Not as much of a problem if you have debug data.