What prevents that tedium from being automated?

Denuvo is designed to be an extreme pain to work with in a debugger or disassembler. Every game is its own unique maze full of dead ends, fake exits, and an ever-shifting array of clever tricks to detect when the binary is being debugged or disassembled, which quietly rearrange the maze to have no solution at all.

It's extremely tedious for a human, and the pay-off is relatively low, as hinted by the parent (what recent DRMed games are even any good?). I do wonder whether anyone has tried setting a well trained AI on the problem though.

> I do wonder whether anyone has tried setting a well trained AI on the problem though.

That was exactly my thought, if it is just brute force understanding debugging/assembly code a LLM could help.

Only one way to find out!

The reasons a set of heuristics and static code analysis can't do it is because the team developing it is constantly hard at work making Denuvo more difficult and annoying and significantly different every release. You may be able to automate version X of Denuvo after having cracked 5 games using that version, but version X+1 will be significantly different (but in a way that didn't require much work on Denuvo's end to change). The only way to fully automate it would be to have access to their source code, or be a literal super genius.

I'm not an expert on it but my understand is that one part is basically have a VM with custom opcodes, and every opcode is randomized and the set of opcodes used is a subset of a larger pool. Then the code running in the VM is autogenerated from normal code using these confusing and randomly selected made up opcodes. And that is only 1 piece.