45 replies to this topic

[quadisys]

Stainless, on 24 October 2012 - 10:05 AM, said:

Your random number generator, there are no real random number generators in software, so if the algorithm is known (or can be derived) that is a potential weak point

The random generator has really only a minor role in whole process. It's not about ciphering based on that or whatever else.

Quote

Anything sent over a network is public, if the data packets are captured and recorded for a valid game, will that give enough data for an attack?

There are two things sent over network: your hardware info (to our server) and the final executable (back to you). Both of these are public. You can hack the hardware info file (and to "lock" it for another hardware under your s/n) but what's the point? Our website will allow you to do the same, no need to hack the hwinfo format at all.

Quote

Honestly if you want this technology to be treated seriously, I would set up some form of peer review and let people try it out.

One step at time There will be a public crack challenge, everybody is invited, I'll post about it here too, don't worry.

[Sol_HSA]

quadisys, on 25 October 2012 - 06:51 PM, said:

Hey, that's pretty cool idea! It's public, it's reliable, a perfect test case. We'll do some tests and publish it on our website ASAP.

I don't think you've mentioned an url at any point. Googling for quadisys gets some unrelated company.

[quadisys]

Sol_HSA, on 26 October 2012 - 05:45 AM, said:

I don't think you've mentioned an url at any point. Googling for quadisys gets some unrelated company.

You're right, I didn't. It's that we are now in Silicon Valley and have a lot of stuff to do so it takes time. I'll post all details once it's done. Actually, what are doing here is to collect people's opinion, be it positive or negative ones, to make our message as clear as possible.

[Sol_HSA]

quadisys, on 27 October 2012 - 04:33 AM, said:

You're right, I didn't. It's that we are now in Silicon Valley and have a lot of stuff to do so it takes time. I'll post all details once it's done. Actually, what are doing here is to collect people's opinion, be it positive or negative ones, to make our message as clear as possible.

In that regard, Devmaster delivers =)

[Kenneth Gorking]

So... Any ETA on those demos? I would like at least 3 versions of the same .exe, for proper testing and/or cracking attempts

[JarkkoL]

While ago I had an idea for DRM system where the code would be instrument by the developer with a simple DRM macro (in non-highly performance critical places). This macro would add some self-contained encrypted DRM check (i.e. no API or function calls cracker could circumvent) which essentially gets your CPUID and uses that to generate a unique check value for that DRM macro instance (e.g. by using __LINE__ as a key within the macro). Each instance of the DRM check code is decrypted in fly every time it's executed so there's no decrypted version of the game in memory that cracker could capture. The decryption code is very tiny so it's not easy to locate it in code and this code can also vary per DRM check instance. The decryption is also written in C++ so generated op codes for decryption can vary significantly per DRM check instance as it's embedded to the surrounding code. The DRM check code decryption and DRM check itself are also fast so it's not really a performance issue as long as you don't instrument std::vector::operator[] equivalent function or something like that. You could essentially do hundreds of DRM checks per frame if you wanted without notable performance impact, though these checks should be distributed more along the line of game progression and different branches of logic to make it more difficult to bump into them. They can also be non-deterministic (e.g. per CPUID) making it more difficult to find them all.

User would need to register the application with a DRM server only once which returns bunch of DRM check values (one for each instance of the DRM macro) for user's CPUID. These check values are then injected into the exe by the registration app and those values are used by the DRM macros. The DRM check values reside in static store, so cracker can't find the DRM code locations simply by checking where the codes were injected. The DRM code encryption further hides any op codes (e.g. CPUID) or memory addresses cracker could search in memory to find the check locations, so all the DRM checks would need to be removed individually by playing the game and hitting each one. These macros would make it very easy to litter the code with thousands of DRM checks all over the code base making the removal very taunting and time consuming task.

I did some prototyping long ago for the DRM code decrypting. This can be done completely in C++ and was pretty easy to do, so it doesn't require any magic asm tricks or anything like that. This DRM system essentially relies that you can't easily find the DRM checks in binary distributable/memory of the app and that CPUID read can't be circumvented.

You can register the game say 10 times with your password before having to contact support. So if you update your PC's CPU it should be ok. Of course you could register the app for your friend's PC, but the idea is just to prevent mass distribution of a pirated exe.

So what do you think? Any obvious loopholes? Since this is just client side DRM you would of course still need figure out how to make things secure in server side that someone doesn't steal the DRM check value generator.


Cheers, Jarkko