Wow
The case of a program that crashed on its first instruction
11–20 of 20 posts
Re: The case of a program that crashed on its first instruction
#12Sometimes 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.
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.
Re: The case of a program that crashed on its first instruction
#13I 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.
Re: The case of a program that crashed on its first instruction
#14Could 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."
Re: The case of a program that crashed on its first instruction
#15I 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
Re: The case of a program that crashed on its first instruction
#16I 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.
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?
Re: The case of a program that crashed on its first instruction
#17Could 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 artic…
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.
Re: The case of a program that crashed on its first instruction
#18Sometimes 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.
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.
Re: The case of a program that crashed on its first instruction
#19Earlier quoted context omitted.
/* 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
Re: The case of a program that crashed on its first instruction
#20Earlier quoted context omitted.
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 h…
The fun thing about computers being magic is that the magicians are usually more than happy to show you their tricks :)