[HN Gopher] The case of a program that crashed on its first inst...
___________________________________________________________________
The case of a program that crashed on its first instruction
Author : zdimension
Score : 90 points
Date : 2024-11-08 17:43 UTC (5 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| xen0 wrote:
| 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.
| Const-me wrote:
| 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
| nanoxide wrote:
| 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).
| jesse__ wrote:
| I just went through the exact same thought process reading
| this.
| saagarjha wrote:
| 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.
| pdonis wrote:
| 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."
| xen0 wrote:
| Wouldn't want your root kit to introduce an unwanted security
| vulnerability.
| tzs wrote:
| 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.
| lieks wrote:
| /* 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";
| }
| wizzwizz4 wrote:
| If it's not loading, add the following CSS: :root
| > body { visibility: visible; opacity: 1; }
| jandrese wrote:
| 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.
| JSDevOps wrote:
| Wow
| interroboink wrote:
| 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."
___________________________________________________________________
(page generated 2024-11-08 23:01 UTC)