The Origin of the worlds most powerful DRM revealed!

More powerful than a speeding Core-i5, able to crash a Ryzen 3 in a single launch process; it's not a demo, it's not a plane, it's SuperDRM! Not only will Ubisoft's new creation prevent pirates from taking over this non-pirate verison of Assassin's Creed (for a few days or so) it can also prevent people who did not invest enough money in their rigs from playing the copy they bought! This masterful scheme should ensure that only those truly worthy souls, with a machine capable of creating a virtual machine for the game and the Denuvo DRM software to run on will be able to learn the true Origins of Assassin's Creed. The Inquirer's story also points out that your GPU power does not matter, if your CPU can't handle the completely reasonable request to create and run a VM for the DRM and its sidekick, then your GPU will be stuck waiting on the bus.

"EARLY ADOPTERS of Assassin's Creed Origins are have been quick to moan that the open world game is using excessive CPU resources, and it's thought that Ubisoft's implementation of piracy-thwarting DRM tools is to blame."

So Core i3 CPUs are out in the cold as they don't support VT-d. Some of those i3s cost over 150$. Surely gamers will understand and upgrade their CPUs in order to play the latest game, as opposed to just searching for a free workaround.

They are using VMProtect and the VMProtect software works to protect code by running it on a virtual machine that utilizes a non-standard architecture. So this is a software based VM, like the java VM, only they are using a custom intermediate code so their software VM is running a proprietary intermediate code that gets JIT(Just in time) compiled from the proprietary intermediate code into x86 code, and that's a compute intensive operation. So all that extra translation for DRM is what is stressing the i3s/i5s and Bristol Ridge and older APUs/CPUs from AMD with lower core counts.

If they where using a hardware VM under facility like Xen/KVM/VMware/other Type-One Hypervisor managed OS/VM instance using the full x86/other hardware VM instruction extentions that all modern CPUs have, x86 and ARM/others, then the consumer Nvidia cards would not run as that would require PCIe passthrough and IOMMU enumeration. Nvidia's consumer cards do not play well with PCIe passthrough while AMD cards do, when AMD/MB makers gets the bugs fully worked out and IOMMU Groupings/PCIe passthrough working properly under AGESA. Nvidia only enables PCIe passthrough to a Hypervisor managed OS instance on its professional GPU SKUs.

Xen/KVM/VMware/other Hypervisor based VMs/VM facilities are very efficient relative to any software based simulated ISA/intermediate code based "VMs" that are resource hogs. The hardware VM's make use of the processor's native ISA and the procssor's virtualization instructions that can be used to isolate and run miltiple OS instances, with each OS instance unaware that it's running in a VM along side other OS/instances that are under the management of a Type 1 hypervisor VM facility.

It you set a VM config file setting to make the OS/Driver think that it's running on the hardware's bare metal, and who knows if Nvidia will not close that method/work around up.

Nvidia officially does not support PCIe passthrough on its non Quadro/Professional GPU SKUs and this guide is an intresting read(1) even though the article is old(2014) there are still recent forum posts stating that Nvidia cards can be made to work, just look at the most recent posts in the forum.

One Forum Poster states:

"Finally got my Geforce GTX 670 to work in a VM. The secret is to add this parameter to your VM's *.vmx config file:

hypervisor.cpuid.v0 = "FALSE"

I'm not exactly sure what this does, but it apparently tricks the guest OS into believing it's running on bare metal instead of a VM. This also fools the Nvidia driver into not giving the Error 43 message we all know and love. One odd consequence of this config file parameter is that Task Manager now shows CPU usage permanently at zero percent, nor does it show usages for individual processes. They're all zero. It's also been implied that this setting can introduce a performance penalty, but I'm getting near native performance levels from my GTX 670." (1, see forum post)

This article/guide is an interesting read and I'd expect that this OEM will probably be offering TR based SKUs once Alienware's(Exclusive Agreement for 16 core TR OEM builds) end at the end of 2017 and other OEMs begin offering 16 core TR SKUs based systems. The system in the article is serving up multi-headed gameing to more than one user and the setup information is very useful to know.

One of the reasons why I've said to myself - never ever again will buy Ubis**m software. At this moment in time I don't even remember what old game it was, but I was so infuriated decade or so about some DRM that I banned anything Ubi$oft forever.

Now "South Park Fractured..." was tempting for a while, but this little article strengthened my resolve.

Let the Ubi burn in the Dark Kingdom of Pirated Software.

Probably next Ubis**m DRM will require dual Xeon system just to see the menus...