[pieter1976]

The malware looks for processes with with a specific DLL loaded in it and then will replace two specific bytes with other instructions, which essentially trick the process into thinking an important check has been done.

It replaced a JNZ with NOP NOP. The BAE Systems blog post has lots of techincal detail: http://baesystemsai.blogspot.co.uk/2016/04/two-bytes-to-951m...

[masklinn]

> It replaced a JNZ with NOP NOP.

That's some good old-fashioned straightforward DRM cracking right there, I'm getting flashbacks from the 90s.

[kchoudhu]

Would ASLR have helped here? I feel like once they knew where the library was loaded in memory, all hope was lost.

[MichaelGG]

No, they we're already running code on the box with high enough permissions, so they're allowed to inspect processrs and do whatever is necessary. No C-like memory protection stuff matters at that point.

What would have prevented it was not letting them have root in the first place. Perhaps by running with Software Restriction Policies so only a whitelist of binaries can run in the first place.

[nickpsecurity]

Stuff like this is why machines like Burroughs should've dominated in critical applications like banking. Those machines marked code and data as different in memory where CPU wouldnt even execute data words. Also bounds checked pointers and protected stack.

Interesting enough, the successor to Burroughs is being made partly by BAE Systems. See crash-safe.org publication list.