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.
/* 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";
}That’s golden!
Can even make it half the size with an instruction that is invalid in 64bit mode, maybe such as INTO
And that instruction can be removed too: zero byte ".text" section -> page fault
Once, when a bunch of us were sitting in my office trading debugging[0] war stories, the owner of the company dropped in[1], figured out the convo, and interjected:
"That's nothing; I once wrote a single line of assembly that had 3 bugs."
then left...
[0] we'd gotten to the subject because I was in the midst of using an oscope to decide if my ROM monitor or my libc or both were buggy.
[1] perhaps to discover why all the other offices were vacant?
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
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).
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.
I'm reminded of one of my Maths lecturers.
He argued that most proofs really only involve one insightful step. Really difficult ones might require two.
The rest is just 'turning the wheel'; each step is just doing the only thing you can do. The point of practice is to make those steps obvious; to learn to turn the wheel.
I guess when it comes to looking at core dumps, I don't even know where the wheel is, let alone how to turn it because it's something I have never done. It maintains that air of magic to me.
The fun thing about computers being magic is that the magicians are usually more than happy to show you their tricks :)
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."
You can start a windows process in a paused state, then inject some code in it, pause or destroy the main thread, create your own thread, then unpause the process. The result would look a lot like this.
What you gain from it is another question. The injected code could do its malware thing first, then start the real program?
As the rootkit is on the internet, presumably you could read it. But I'm not going to touch it with a 10 meter pole.
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.
If it's not loading, add the following CSS:
:root > body {
visibility: visible;
opacity: 1;
}Wow