This strange tweet got >25k retweets. The author sounds confident, and he uses lots of hex and jargon. There are red flags though... like what's up with the DEI stuff, and who says "stack trace dump"? Let's take a closer look... 🧵1/n
250
3,134
495
15,649
This is actually a screenshot of !analyze -v output, I think the author conflated "stack trace" and "minidump". Regardless, he only looks at the decoded exception record and concludes "it was a NULL pointer"...? 🤔 2/n
5
42
2,081
It is a plausible explanation, 0x9c is not NULL, but dereferencing near-NULL addresses can have the same root cause. He explains that the code was reading a field at offset 156 from a NULL object pointer. 3/n

Jul 20, 2024 · 8:40 PM UTC

8
30
1
1,573
Well, except... we can see in his screenshot that MSVC generated mov r9d, [r8]? That's really odd... I spend half my life looking at MSVC output, and I would expect to see mov r9d, [r8+0x9c], so what's up with that? 4/n
8
33
7
1,686
Maybe I'm wrong, let's test it in godbolt godbolt.org/z/sdz4PGxxo. Nope, the code doesn't match! The code is either more complicated, or his hypothesis is incorrect. There is a way to check, he could type `u` (unassemble) into kd and examine the surrounding code. 5/n
5
39
1
1,659
He didn't, but we still can! His version of the faulting module has the bytes 45 8b 08 at csagent+0xe35a1, I found that version in VT, and had a look. In fact, there *is* a NULL check (test r8, r8; jz) immediately before the dereference, so his theory is provably *wrong* 🛑 6/n
9
102
29
2,352
This code is reading pointers from a table in a loop, and some are invalid. Perhaps an error parsing a configuration file left some entries uninitialized, and one just happened to be 0x9c? It's just a theory, but at least mine fits the facts😆 7/n
12
43
6
1,825
Here is the same crash seen by Patrick, except he saw the entry 0xffff9c8e00000008a, nowhere near NULL! If this is uninitialized data, perhaps it was okay during testing and that's why CS didn't catch it 🤷‍♂️ 8/n
Patrick Wardle
 @patrickwardle
19 Jul 2024
I don't do Windows but here are some (initial) details about why the CrowdStrike's CSAgent.sys crashed Faulting inst: mov r9d, [r8] R8: unmapped address ...taken from an array of pointers (held in RAX), index RDX (0x14 * 0x8) holds the invalid memory address @_JohnHammond
11
90
8
2,030
It's amusing to me that Patrick (who actually knows what he's doing) realizes this is complicated, so hedged his analysis with "(initial) details"... but this guy just rocks up with "I'm a professional!!" and gets 25k retweets 😆 9/9
87
198
26
5,517
Replying to @taviso
This was my answer to him for this exact point. He doesn't seem like an expert
Marouane Lamharzi Alaoui
 @marouane53
19 Jul 2024
Replying to @Perpetualmaniac
In 'obj->a is 0 + 4', adding to a null pointer is undefined behavior, not guaranteed to yield 4. The dump shows an attempt to read from 0x9c, not 0x4. The core issue is undefined behavior from dereferencing NULL. We should always check for null before dereferencing to avoid this and potential security risks.
1
Replying to @taviso
Why does dereferencing mear-NULL addresses can have the same root cause?
Replying to @taviso
For someone not current and trying to catch back up on this stuff (i.e. me): what is a near-NULL address?
Replying to @taviso
Also, the address of obj->a wouldn’t offset + 4, it’d be offset + 0.
Replying to @taviso
"it will cannot read" ?
Replying to @taviso
guys why do you stuck in pre c++11? there is nullptr in c++ now
Load more