Bypassing Windows ASLR using "skype4COM" protocol handler
greyhathacker.net
Bypassing Windows ASLR using "skype4COM" protocol handler
1–10 of 12 posts
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#2Poor 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.
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#3Poor 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.
Just curious, how does ASLR make debugging painful for you?
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#4Poor 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.
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.
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#5Poor 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.
Just curious, how does ASLR make debugging painful for you?
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.
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#6Earlier quoted context omitted.
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 progra…
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.
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#7Poor 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.
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#8Earlier quoted context omitted.
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 progra…
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#...
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#9Earlier quoted context omitted.
Just curious, how does ASLR make debugging painful for you?
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.
I've rebased addresses in IDA tons of times, and I've never run into any corruption.
Re: Bypassing Windows ASLR using "skype4COM" protocol handler
#10Earlier quoted context omitted.
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.
I've rebased addresses in IDA tons of times, and I've never run into any corruption.
I've never run into corruption directly, but IDA has tanked for me upon exiting debugging where it attempts to re-relocate. Haven't seen that in a number of years, though.