/* Optimize a program.
May perform unsafe optimizations.
May introduce up to 1 bug.
*/
char *optimize(char *program) {
(void) program;
return ".export main\nmain:\n\tub2\n";
}
IMO the main reason Raymond Chen is so good at that, he does that a lot. Unless you work for Microsoft, it’s very unlikely your job requires analyzing thousands of crash dumps of random third-party programs.
I do that very rarely, and I only analyze the dumps of the programs I made. Of course, Raymond is way better than me at that, but I’m fine with it. People pay me to develop software for them; I only debug stuff when I have to.
Maybe not, but I think he does a pretty good job of showing how he is “just” taking logical steps towards understanding what is going on. Some of them probably didn’t pan out and were omitted but most of this debugging work is simply trying to understand more and iteratively zeroing in on the bug.
He has obviously decades of experience, but the basics of debugging with windbg aren't actually that difficult to start with. I remember trying to look into some memory dumps we got from crashes of our application from internal users, and was able to get relevant information pretty quickly just from some basic built-in diagnostic commands I picked up from his and the old NTDebugging blog (which seems to be sadly gone).
Could someone explain to me — it's not actually crashing on its first instruction, I take it?
Why does it appear to be crashing on the first instruction?
Did the malware mess with the main thread's code, so that the first instruction of the main thread was the invalid write instruction?
But then the malware thread must have run first somehow, no? (since that thread is in the same process)
I think I followed the article generally, but I don't understand what actual sequence of events might have taken place that resulted in this report of "crashed on first instruction."
I guessed wrong from the title. I was expecting a C/C++ programmer that tried to stick too much stuff on the stack and crashing immediately on start. That's usually the case when someone asks me why their previously working program doesn't even make it to the first instruction.
I remember someone quipped that every program always has at least one bug left, and every program could be optimized to be smaller.
It follows then that with a sufficiently good optimizer every program can be reduced to a single wrong instruction.
That’s golden!
Can even make it half the size with an instruction that is invalid in 64bit mode, maybe such as INTO
Sometimes I start to feel like I'm pretty good at what I do.
Then I read one Raymond's investigations like this and realise I'm still not that good.
IMO the main reason Raymond Chen is so good at that, he does that a lot. Unless you work for Microsoft, it’s very unlikely your job requires analyzing thousands of crash dumps of random third-party programs.
I do that very rarely, and I only analyze the dumps of the programs I made. Of course, Raymond is way better than me at that, but I’m fine with it. People pay me to develop software for them; I only debug stuff when I have to.
BTW, couple years ago I wrote an article on the topic: http://const.me/articles/windbg/windbg-intro.pdf
Maybe not, but I think he does a pretty good job of showing how he is “just” taking logical steps towards understanding what is going on. Some of them probably didn’t pan out and were omitted but most of this debugging work is simply trying to understand more and iteratively zeroing in on the bug.
He has obviously decades of experience, but the basics of debugging with windbg aren't actually that difficult to start with. I remember trying to look into some memory dumps we got from crashes of our application from internal users, and was able to get relevant information pretty quickly just from some basic built-in diagnostic commands I picked up from his and the old NTDebugging blog (which seems to be sadly gone).
I just went through the exact same thought process reading this.
I love this comment:
"So at least it’s nice that this rogue code was compiled with stack buffer overflow protection. Can’t be too careful."
Wouldn't want your root kit to introduce an unwanted security vulnerability.
Could someone explain to me — it's not actually crashing on its first instruction, I take it?
Why does it appear to be crashing on the first instruction?
Did the malware mess with the main thread's code, so that the first instruction of the main thread was the invalid write instruction?
But then the malware thread must have run first somehow, no? (since that thread is in the same process)
I think I followed the article generally, but I don't understand what actual sequence of events might have taken place that resulted in this report of "crashed on first instruction."
I guessed wrong from the title. I was expecting a C/C++ programmer that tried to stick too much stuff on the stack and crashing immediately on start. That's usually the case when someone asks me why their previously working program doesn't even make it to the first instruction.
Wow
If it's not loading, add the following CSS: