The case of a program that crashed on its first instruction(devblogs.microsoft.com) |
The case of a program that crashed on its first instruction(devblogs.microsoft.com) |
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";
}Can even make it half the size with an instruction that is invalid in 64bit mode, maybe such as INTO
"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?
Then I read one Raymond's investigations like this and realise I'm still not that good.
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 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.
"So at least it’s nice that this rogue code was compiled with stack buffer overflow protection. Can’t be too careful."
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."
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.
:root > body {
visibility: visible;
opacity: 1;
}