I've looked at past versions of Denuvo. It uses a modified version of VMProtect 3 to virtualize many game functions, and a custom library that's different from VMProtect's for anti-debug, initial game decryptions as well as to implement some SDK features that lets the game check if it has been unpacked (known as "triggers" in older protections).
Before running game code, it will call a DRM library which is specific to the underlying platform, such as Steam or Origin and others.
I don't know why people call Denuvo not DRM, it's as much DRM as all the other protectors that came before it, and it has custom code written for Steam that is used in all Steam games, and the same for Origin games. It seems to me to be a PR stunt.
Besides VMProtect, some versions of Denuvo also have integrity checks, and random chunks of useless code and obfuscation inserted throughout the game code. Compared to the virtualization this is an insignificant problem, especially if you were to see what the obfuscations look like. Standard compiler techniques are sufficient for recovering most of the code, both obfuscation and virtualization.
If Denuvo isn't cracked it isn't because it's special, it's because there are no crackers left that seem to have the skills any more. VMProtect has existed since 2006 and the version used in Denuvo does still look the same as it always has looked. People have cracked and made VMProtect tools many times in the past, although not all the good ones are public.
From what I've seen, both now and in the past, it gets some encryption keys from Steam through a ticket, which serve to function as a temporary license for your PC, this license contains hardware id, expiration date, and possibly a code decryption key.
Despite all the claims people are making about Denuvo not affecting performance, the VM does come with a few orders of magnitude of slowdown:
1) code is compiled from x86 to a virtual machine's instruction set, an x86 instruction will be translated into about between 2 to 50 VM instructions. A VM instruction is 1 to 4 bytes (depending on version of VMProtect, old was 1, new is 4) for fetching the next instruction opcode, and either 0, 1, 2 or 8 bytes for arguments. This will result in new instructions taking a lot more space, possibly between 2 bytes to 600 bytes per original x86 instruction, depending what the instruction is and the used version of the protector, newer ones being bigger.
2) the interpreter for this machine tends to take between 3 to 100 x86 instructions in its un-obfuscated form.
3) the interpreter is obfuscated, usually resulting in a 4-10 times increase in code size, and the code isn't localized in the same space (jumps throughout a 100MB executable will hurt cache) and access to the interpreter's "registers" and memory is done indirectly, again resulting in more sluggish performance.
Given these estimations, even if not perfectly accurate without doing actual statistics, you can expect between 24-50000 times slower code execution for protected instructions, possibly with an average 10000 times slow down. It would be insanity to do this on anything but initialization functions if you don't want your games to be very slow. If that wasn't enough to be bad, there are also threads running in parallel that performs anti-debugging features and they run virtualized code.
I haven't seen any gaps as you mention in protected game code once it's decrypted in memory, there are hundreds of virtualized functions per game, there are a lot of integrity checks in certain functions which are bound to be very slow, but if the developers were clever, they placed them in initialization code only. Some performance loss is unavoidable as certain code seems to be inserted indiscriminately throughout most functions, such as hiding integer constants using rather simple obfuscations, import protection by decrypting import addresses at runtime, and the integrity checks. Some games don't use most of these features, including the game 3DM was complaining about.
If the virtualized code is encrypted with a key, the key should be fixed and contained in the ticket. The size of this key for VMProtect was 64bits. It could be different here, in VMProtect they didn't even encrypt the code, rather the location of the code was encrypted.
While CPU-specific code is possible, in general, x86/x64 is a standard and it just works the same everywhere. CPUID might work differently and there are some far more evil recent features in Intel CPUs, but they aren't used by Denuvo. Exploiting CPU bugs might be possible, but the solution would be to just get all the versions: they can't all fit in the exe, and I haven't even seen any space there for all these versions you're talking about. Nor have I seen online code that does anything but get the time-locked license from Steam. "Encrypted" virtualized functions may exist, but this key should be game-specific and not user-specific.
Even if your idea was somehow feasible, it could be defeated by requesting older or more generic versions, or getting recent versions, and removing their architecture specific tricks as they are bound to be glaringly obvious, as most of Denuvo's code is, once you view it in a disassembler and study it a bit.
Your timing checks idea is feasible and has been done on some platforms like ARM that are more predictable than x86. While feasible in principle, it's incredibly hard to do it reliably and have stable code. It is also not undefeatable at all, it can be dealt with standard compilation and temporary emulations techniques to generate the original code from the modified code. I am doubtful of this technique being used on x86 as all implementations of it are very unreliable and buggy and it's very hard to implement it on x86 without bugs creeping up on you. I would consider your post speculation, unless you provide evidence or proof of your claims.
If you haven't realized it by now, the only real way of defeating Denuvo is with a specialized tool, this tool once written will defeat all current versions, removing it completely. Why doesn't this tool exist? I don't know, maybe sceners retired or lost interest? Maybe no skilled people outside of it? Lack of interest? You want to see it done? Set aside a few months, reverse engineer the protection and write a tool. It's not as hard as you may think, but you might want to cut your teeth on simpler ones first. Having such a tool would grant you better executables that run faster and are more stable.
You don't want to do that? You could take the the approach web groups like 3DM or even scene groups like CPY have and replace the keys in memory while patching the integrity checks in a few hundred places after making some scripts to detect them. This may be more difficult than you think because you will have to take a partial black box approach at studying memory and tracing differences between activated/non-activated versions. It won't be pleasant and it won't give you a better game or the satisfaction of having a better product than the original, it will also make you want to tear your hair out as you trace through the same VM interpreter code each time, duplicated dozens of times.
There is nothing special or new in Denuvo that hasn't been seen in Starforce 3 or 4, Securom 7 or 8, Solidshield and other big name game protections or cheaper commercial application protectors, and it's as much a protection and a DRM as those were, especially as they reuse the DRM code for each game. All you're seeing here is a PR stunt from a re-branded protection company and a not very active cracking scene, compounded by the fact that x64 reverse engineering tools are still young, although they are usable and enough to crack this: people have worked with far less usable tools in the past and have succeeded.
This is a throwaway account, I don't want to be given "gilded" or thanked. Please do your own research people, stop believing in things without sufficient evidence, especially when that evidence can be obtained merely by examining a file that is public. The game code is out there and you can read it as well as everyone else can, learn to reverse engineer and stop reading so many made up stories (SSD killer, processor "unique" code, constantly re-encrypting memory and other myths). The only reason I posted this is that it gets very tiring to read all these unfounded speculations about this protector on the internet, especially since it's a very standard protection in its design.