3 ms·
Some critique from a seasoned kernel exploiter https://twitter.com/d_olex/status/1544008208641306624 https://twitter.com/d_olex/status/1544008208641306624: "Yo
by brasenose 4y ago
Some critique from a seasoned kernel exploiter https://twitter.com/d_olex/status/1544008208641306624 https://twitter.com/d_olex/status/1544008208641306624:
"You have at least two race condition bugs in your code: manual traverse of ActiveProcessLinks without locking the list, and same issue with process objects you're working with. Correct approach: use appropriate kernel functions to reference needed _EPROCESS in error safe way."
And https://twitter.com/d_olex/status/1544013068388433920 https://twitter.com/d_olex/status/1544013068388433920:
"Seriously, never ever touch nt!PsActiveProcessHead list with your own code, nt!ZwQuerySystemInformation() with SystemProcessInformation info class can do it for you without any risks to catch BSoD ... and if you want direct _EPROCESS pointer for your fuckery -- it's better to obtain it with nt!PsLookupProcessByProcessId() and free it with nt!ObDereferenceObject() call at the end."
- _8j50 4y agoHaha, the guy is writing shellcode not production software. Some of the criticism is good but malware developers hardly care about the proper way of doing things or race conditions.
- charles_kaw 4y ago>malware developers hardly care about the proper way of doing things or race conditions Yes they do, they absolutely do - especially at this level. An easy way to get caught is to show up in a crashdump that automated software flags.
- _8j50 4y agoFair point, you're right that makes sense.