Bypassing Windows ASLR using "skype4COM" protocol handler

http://www.greyhathacker.net/?p=641

by ColinWright • 13 years ago

57 11 13 years ago

to3m2• 13 years ago

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.

loeg2• 13 years ago

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

barrkel• 13 years ago

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.

revelation2• 13 years ago

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.

revelation2• 13 years ago

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.

Bypassing Windows ASLR using "skype4COM" protocol handler

Related Stories