45 replies to this topic

[quadisys]

Hello everyone,

I work for a company called Quadisys, we're a startup. What we have basically is a new kind of copy protection technology.

I read a blog where an indie developer claims that 95% of copies of his game were stolen/pirated! I guess we can help you with that. We will be happy to help you and to spread our technology.

Now you probably ask how come we have something different, there's been tens of companies which claimed the same, right?

I'm not sure if it makes sense to post all technical details on how it works, so only briefly.

Basic features:
- Windows only, both 32-bit and 64-bit
- no java, .net, flash, web stuff
- one time internet activation (user enters a serial number, receives protected file(s) from our server)
- we don't need your source code, only the final build (exe, dll, ...)
- if somebody breaks the protection, all the other (present and future) products wont get automatically crackable! It's something as AES/RSA and similar stuff -- if you break one password with brute force, it doesn't mean you can read everyone's emails
- one dialog on your side, server running on our side (scalable, ready for thousands of activations per minute)

Would something like this be interesting for you? As we are looking for references (and real world usage), we'd do it completely for free, servers, customer support -- everything paid by us.

[Reedbeta]

What prevents crackers from redistributing the full game after legitimately activating one copy and downloading the protected files?

[quadisys]

What prevents crackers from redistributing the full game after legitimately activating one copy and downloading the protected files? Let me explain.

Typical protection is just kind of wrapper. You remove the wrapper, you've got a clean, spreadable copy which can be used by anyone. So what are current 'protectors' trying to achieve is to hide this check, this comparison, to obfuscate it as someone has mentioned. But as soon as you find it (it can take hours, weeks, even months, take a look at Starforce for example -- 424 days), the product is finished and in mercy of legal (voluntary) buyers. Apropo Starforce... there's then another element and that's the way how the protection abuses your system... you can read it on wikipedia, what exactly it does, don't know about you but for me it was really scary reading.

These were the starting points for us, the things we wanted to avoid. So... what we have come with?

0. Publisher uploads (clean, unprotected) files he wishes to protect (it might be one .dll, it might be two .exe's + 10 .dlls ...) to our server
- this is of course secure, agreement-based operation, nothing for public

1. Every publisher gets a loader which he executes as the last step in his installation process
- this loader does a hardware check of your computer (looking for unique elements -- serial numbers, IDs, names, ...)
- it sends this information, along with the entered serial key to our server
- as you can see, nothing confident is sent (you can mangle the hw info but then you'll receive a file for another computer registered on your serial key)
- our response will be a file (files) tight to your computer hardware, i.e. it will run on your computer but not on your friend's one
- again, as you see, nothing hackable in this process

2. Customer runs this executable(s), if hardware matches, ok, if not, an error appears

This is how it works from user point of view. Now typical Q&A:

Q: what if I change my HW?
A: you, as publisher, can choose what hardware you expect / allow your customers to change. Plus, how many reactivations do you allow. So in practice: I think my customers are gamers, so I allow them to change video card (video card wont be included in that hardware collect operation) plus since they are crazy upgraders so I allow them to change hdd/mother board/etc three times. That also implies, that you can give your serial number to your 3 friends (or family members or computers in your weekend house), if you are sure you'll never change your hardware, yes, it's ok, I as publisher agree with it. (it's up to me to change these numbers). Plus bear in mind the number of concurrent (already activated) users are always in full control of the publisher -- thanks to the serial key + activation + database on our server.

Q: For every (re)activation I need an internet connection?
A: Yes, you do. You can alternatively sign up in an internet cafe or at your friend's place and download the file there (we'll provide web activation, too -- you bring your hw info file on an usb stick and we'll give you the protected files for your computer)

Q: What about updates?
A: You can upload the update in the same way as in the step 0, i.e. the next time user runs the activation process, new files will be downloaded. No trouble at all.

Q: OK, so how come it's uncrackable?
A: First, we do not claim it's unbreakable. We are only saying we can hold your game long enough on the game market to make some money back. We can debate how effective it is but bear in mind -- if today only 1 player of 20 pays for the product, improvement to 2 of 20 means double revenue!

Q: Cool cool, so how does it work then?
A: As I said, it's similar to cryptography. We inject your executable(s) on random places with thousands of 'crypto points'. There's huge technological background (ring0 stuff, drivers, protected memory etc) but in the nutshell it just asks about your HDD s/n, combines it with some data in the executable and generate some new code on some random place. This 'crypto points' are indistinguishable from regular code so the only way how to recognize them is to debug the app, check the result in memory, store it, patch it and.. move to another one. In a way it's similar to a series of ciphered blocks -- you can eventually crack them with brute force and combine into one but it takes time.

Q: TL;DR. What's the point?
A: The point is that if there's 6000 of these 'crypto points', you have to remove one after each another, you can't automatize it and you can't apply knowledge of one cracked product to another (because each copy is unique, each product has different code, i.e. this 'instruction mixing' happens always differently). So eventually, every game gets cracked but it will happen only after huge dedication from cracker's side and after the main sales are done (typical AAA game makes money in the first 3 weeks)

Super TL;DR version: no permanent Internet access, invisible to user, broad field of options for publisher.

I'm sorry for such a long post I just want to be sure you'll get the idea. Feel free to ask, if you haven't understood something.

[Reedbeta]

OK, so (to summarize what you said) the executable the user receives is "signed", so to speak, with their hardware signature, which is repeatedly checked while the game is running by these "crypto points".

I'm a little leery of your software injecting random "crypto points" into my executable because games do need to run in real-time, and doing kernel mode switches and querying HW drivers and suchlike sounds like it could easily cause a perceptible performance issue if it landed in the wrong place. There would need to be some kind of control on this to ensure no ill performance effects.

And I don't know if I would be *that* confident that crackers won't be able to automate detecting and removing the crypto points.

Beyond that, the idea seems reasonably sound from a once-over. Although my personal opinion is that the best way to fight piracy is to make an excellent game that people will be happy to pay for, price it appropriately (or allow users to choose the price), make it as easy as possible to pay (even internationally), and generally don't be a dick to your customers.

[quadisys]

Reedbeta, on 17 October 2012 - 04:29 AM, said:

OK, so (to summarize what you said) the executable the user receives is "signed", so to speak, with their hardware signature, which is repeatedly checked while the game is running by these "crypto points".

Good summary.

Quote

I'm a little leery of your software injecting random "crypto points" into my executable because games do need to run in real-time, and doing kernel mode switches and querying HW drivers and suchlike sounds like it could easily cause a perceptible performance issue if it landed in the wrong place. There would need to be some kind of control on this to ensure no ill performance effects.

Yes it would and we have done it! Of course we count with this possibility / scenario. We allow to enter you a list of functions and/or offset ranges of your binary which should stay 'clean'.

Quote

And I don't know if I would be *that* confident that crackers won't be able to automate detecting and removing the crypto points.

Unlike the others who'd spent years developing techniques for obfuscation and stealth stuff, we've spent years developing exactly this. So we are pretty confident Plus we had this technology checked by people from cracking scene. Of course, many things can go wrong but ... there's only one way to find out

Quote

don't be a dick to your customers.

Believe or not but that's one of the key features We really tried to find the best balance between security, future usage and annoyance of users.

[TheNut]

There was a game that worked similar to this. I think it was the X-series. I don't remember the exact details of it, but I recall one of the crackers discussing the random check points in the exe. At first he fixed the first one, only to find out later there was another, and another. And if memory serves me, rather than fix all checkpoints, he just altered the actual check function and voila. I'm not sure how long this process was, but I often wonder. Is cracking a game proportional to the sophistication of its DRM, or is it proportional to the dedication and experience of the cracker?

I don't have concrete statistics to prove whether or not piracy / anti-piracy has any effect on sales. It seems mostly anecdotal. You'd have to release the game twice in two different realities to see the net effect. The big question of course, is the DRM transparent? For most gamers, they would turn a blind eye so long as the process doesn't interfere with their gaming experience. For some, any DRM is an automatic "do not purchase" flag. Things like sending personal information, online activation checks, and limited installs are usually widely contested amongst anti-drm activists. Most still put up with it as the cost of PC gaming, but it's negative attention that I would imagine no start-up company would want to have. Any failure during the initial release could spell instant doom for the company. DRM server crashes, high demand loads, or simply having an unlucky day. I've seen it happen, even amongst large companies.

The other thing I would bring up is, how do you expect to compete against a more tested, widely used, and successful DRM provider like Steam? Steam, which also provides you a market to sell your game, community features, and an SDK for integrating bonus features such as achievements and cloud support. I would say in this day and age, it would be very risky to use an unproven 3rd party DRM technology over a proven one. To many games, even from well respected companies, have fallen victim to untested DRM that backfired negatively on the company.

[alphadog]

I agree with Reedbeta. My biggest fear reading the exchange is the automated injection in random places with thousands of 'crypto points'. Now, assuming the game studio has decent Q&A, one should be able to guesstimate the impact of this in performance (except for the fact that there's millions of cofigs out there) or in stability (see previous parens). Of course, if I find issues, I then limit "where" and "how much", and now my software becomes much more crackable, thus making the entire effort useless (and costly).

There's nothing I'd hate more than getting more sales from DRM, then pissing it away on higher support costs.

Seems like the weak point is your executable. What's to prevent me hacking your executable to always return a positive match? Or, impersonate your server?

BTW, what's unique about your solution? Seems like that's how some popular DRM systems work anyways....

[Kenneth Gorking]

quadisys, on 17 October 2012 - 04:12 AM, said:

(because each copy is unique, each product has different code, i.e. this 'instruction mixing' happens always differently)

This might be a problem. My first thought to cracking this, would be to get a hold of a couple of different executeables that you have modified, and do a simple diff on them. This would reveal all the crypto-points, and I could then write a tool to reconstruct a clean executeable from this. If that's unfeasable, then I could modify the points to always succeed.

Another posibility would be to hack into your servers, and just download all the clean executeables . They should be encrypted, but some of them might be decrypted in a cache somewhere...

Yet another posibility would be to register from a VM, and then have everybody just run the exe in the same VM.

[quadisys]

TheNut, on 17 October 2012 - 11:29 AM, said:

There was a game that worked similar to this. I think it was the X-series. I don't remember the exact details of it, but I recall one of the crackers discussing the random check points in the exe. At first he fixed the first one, only to find out later there was another, and another. And if memory serves me, rather than fix all checkpoints, he just altered the actual check function and voila.

In that case, we are one step ahead, as we use the 'whole package' everytime. In practice, you'd need to alter every routine, every check and that's exactly what I'm talking about here. Boring, lengthy and not fun at all.

Quote

I'm not sure how long this process was, but I often wonder. Is cracking a game proportional to the sophistication of its DRM, or is it proportional to the dedication and experience of the cracker?

I'm 100% confident it's the latter. Our technology can stand 5, 10, 50 crackers who are simultaneously trying to crack it but in no way we can't stand fight against 1000 of them (6000 crypto points, that's 6 per 1 person, done in a hour). Fortunately, that's only a theoretical number, I'm even not sure if there's like 1000 crackers out there

Quote

course, is the DRM transparent? For most gamers, they would turn a blind eye so long as the process doesn't interfere with their gaming experience.

That's our target audience. You are right, some people will never ever buy a DRM protected product and some are afraid of the technical issues. Fortunately, the protection process is not so time critical and it's one time only. So it might happen that you'll have to wait let's say 5 minutes to get your protected binary but no crashes at all. It's just about parallelization and queuing.

Quote

The other thing I would bring up is, how do you expect to compete against a more tested, widely used, and successful DRM provider like Steam?

I'm glad you asked this. Believe or not but there's a not so small group of people whohate Steam, even if it offers so many features. Instant Internet access, nearly full control of what you have installed and why and for how long, this kind of Big Brother stuff. I doesn't come from my head, I've got it from another gamedev forum. Steam excluded, there's no such thing as "more tested, widely used and successful DRM provider" for video games (nor software in general).

[quadisys]

Kenneth Gorking, on 17 October 2012 - 02:45 PM, said:

This might be a problem. My first thought to cracking this, would be to get a hold of a couple of different executeables that you have modified, and do a simple diff on them. This would reveal all the crypto-points, and I could then write a tool to reconstruct a clean executeable from this. If that's unfeasable, then I could modify the points to always succeed.

1. If you have one message ciphered by AES using 3 different keys, can you reconstruct the original message only by using diffs? No, you can't. Remember, nobody knows how the original looks like.
2. You could. Each of them. That's the point.

Quote

Another posibility would be to hack into your servers, and just download all the clean executeables . They should be encrypted, but some of them might be decrypted in a cache somewhere...

True. But this is a completely different problem. Remember, there's no download link anywhere. It's hidden behind firewalls, separate networks etc. It's like you are saying "I can hack into a bank because I've got Internet banking there".

Quote

Yet another posibility would be to register from a VM, and then have everybody just run the exe in the same VM.

We control instruction timing. And before you write that you can remove it, think again, it's part of every crypto point, so your only chance is again to debug and remove each of them

[quadisys]

alphadog, on 17 October 2012 - 02:12 PM, said:

I agree with Reedbeta. My biggest fear reading the exchange is the automated injection in random places with thousands of 'crypto points'. Now, assuming the game studio has decent Q&A, one should be able to guesstimate the impact of this in performance (except for the fact that there's millions of cofigs out there) or in stability (see previous parens). Of course, if I find issues, I then limit "where" and "how much", and now my software becomes much more crackable, thus making the entire effort useless (and costly).

See my answer for him above. Publisher can give us information what parts of code are time critical and we will avoid them.

Quote

Seems like the weak point is your executable. What's to prevent me hacking your executable to always return a positive match? Or, impersonate your server?

I only repeat: nothing prevents you to do that and crackers will do that. The point is that you need to do it for every frakking crypto point => it will take you quite some time. Impersonating server: yeah and what would you return as the result? Ciphering is done on our server, you either receive a binary for your computer or ... or what? There's no "download clean copy now" button.

Quote

BTW, what's unique about your solution? Seems like that's how some popular DRM systems work anyways....

See above. We can reuse our technology many times, after each crack. The crack will happen, eventually, we have no problem to admit it. The point is that if we protect another version (1.01, the next game, whatever), you'll have to start again. What DRM features this?

[Kenneth Gorking]

quadisys, on 18 October 2012 - 03:59 AM, said:

1. If you have one message ciphered by AES using 3 different keys, can you reconstruct the original message only by using diffs? No, you can't. Remember, nobody knows how the original looks like.
2. You could. Each of them. That's the point.

My idea may not make alot of sense, but I am just going on what info you have provided so far.
You said that you inject your crypto-points (CP) into the original executeable at random positions. This would mean that two executeables is unlikely to have any CP located at the same position in the file, correct? If this is so, in one exe where there will be a CP, in another exe there will just be the original code.

I could use this knowledge (assuming it is corect) to simultaneously run through 3-or-more executeables, and as long as there is no difference between the files, I dump it to the new file. When a difference is encountered, I would dump the contents of either of the 2 files that are equal, and skip over the content that is modified. I would just repeat this until the end is reached, which should result in a exe stripped of CPs.

Oh, and if you are saying that all the executeable code is encrypted, that point is moot. The file still has to be decrypted before it can be executed, and that decryption code probably exist locally in the file, which makes it easy to crack.

quadisys, on 18 October 2012 - 03:59 AM, said:

True. But this is a completely different problem. Remember, there's no download link anywhere. It's hidden behind firewalls, separate networks etc. It's like you are saying "I can hack into a bank because I've got Internet banking there".

It is a different problem, but one you shouldn't ignore. There are other ways to get to your servers, without needing a direct download link.
If it was me that where to do the hacking, I would start by penetrating your email servers (@quadisys.com), and start looking for emails containing info on your servers containing the clean files. Maybe an IP address, or even some admin login info. People are sometimes careless with these things.

quadisys, on 18 October 2012 - 03:59 AM, said:

We control instruction timing. And before you write that you can remove it, think again, it's part of every crypto point, so your only chance is again to debug and remove each of them

What do you mean by 'We control instruction timing'? I also wouldn't need to remove anything. By registering my program from within a virtual machine, anyone else can run it, as long as their virtual machine is configured like the one used to do the initial registration. It is fairly cumbersome to fire up a VM everytime to use the program, but it is possible.

[quadisys]

Kenneth Gorking, on 18 October 2012 - 05:25 AM, said:

My idea may not make alot of sense, but I am just going on what info you have provided so far.
You said that you inject your crypto-points (CP) into the original executeable at random positions. This would mean that two executeables is unlikely to have any CP located at the same position in the file, correct? If this is so, in one exe where there will be a CP, in another exe there will just be the original code.

That's good thinking, sir! But it has two problems:
1. You don't know which code is original and which is ours, you only see differences
2. Differences are 100%. Whole binary is mixed, moved etc. Only parts which are instructed to remain as-is will remain at the same position. This is our know how, actually.

Quote

Oh, and if you are saying that all the executeable code is encrypted, that point is moot. The file still has to be decrypted before it can be executed, and that decryption code probably exist locally in the file, which makes it easy to crack.

Yes and no. It's part of the code, sure. But the point isn't that you can't crack it but the point is that you have to crack it for every one of them. Every CP in the binary, step by step. Six thousands of them.

Quote

If it was me that where to do the hacking, I would start by penetrating your email servers (@quadisys.com), and start looking for emails containing info on your servers containing the clean files. Maybe an IP address, or even some admin login info. People are sometimes careless with these things.

They are. And as we are by no means security experts, we let this in hands of more capable people. We focus on piracy, they focus on network security. Fair deal

Quote

What do you mean by 'We control instruction timing'? I also wouldn't need to remove anything. By registering my program from within a virtual machine, anyone else can run it, as long as their virtual machine is configured like the one used to do the initial registration. It is fairly cumbersome to fire up a VM everytime to use the program, but it is possible.

I mean that a part of our protection is measuring how long driver responses are. Meaning if you run the app in a VM, the responses will differ (as emulated instructions are always different than the real thing). So we can say that's something is not quite right and exit. You can remove it but again, you have to remove it for every CP of 6000.

[Stainless]

I used to work for a company called freeloader, they bought publishing rites to old games and gave them away for free making their money from advertising.

Normally we were just given a copy of the game straight off the shelf of some games shop.

It was my job to remove the copy protection, get the game to run from hard disk, inject our code into the message loop, and split the game into several downloadable modules (typically 10)

Removing the copy protection took anything from 5 minutes to 5 days. I never failed to remove the copy protection.

The problem with all copy protection schemes is that the games have to run. It is trivial to create a protection scheme that would take a monumental effort to break, but the game would be unplayable as the frame time used to handle the copy protection would leave nothing for the game.

This is the fundamental problem, it's like network security. To create a 100% protected machine is trivial. Just put your machine in a Faraday cage and never turn it on. 100% secure, and 100% useless as a computer.

I often had to handle encrypted executables, it was trivial as all I had to was wait till the game was loaded and take a snapshot of memory. I could then load this snapshot instead of the original encrypted exe.

The games that were difficult to break used the stack to build the protection code. The game would call a subroutine to say load a texture, the code left a couple of bytes of machine code on the stack, then you call a routine to do something else and it leaves a few more, until the protection code exists as a block of memory on the stack. Then you trick the machine into running this code.

Unfortunately that stage was easy to detect and remove. All that hard work and clever coding removed with a few key strokes.

The best copy protection?

Make the game SO good that everyone wants an original.

[quadisys]

Stainless, on 18 October 2012 - 08:52 AM, said:

I often had to handle encrypted executables, it was trivial as all I had to was wait till the game was loaded and take a snapshot of memory. I could then load this snapshot instead of the original encrypted exe.

This is a very common argument. But bear in mind this decryption doesn't happen at once. It happens only when needed, when we reach the part of executable. So you can make a snapshot but in the end you realize you need 6000 memory snapshots to compare. And yes, we're fine with that. Eventually, after few months, you'll break it, fair enough. Then we will release version 1.01 with different 'crypto points', with different instruction mixing and you can start again. That's our deal.

Quote

Make the game SO good that everyone wants an original.

Hm. And what happens if this SO GOOD game gets cracked next day after its release? I don't know in what country you live in but in mine, if something is SO GOOD and it's available for free, people take it for free.

[Reedbeta]

quadisys, on 18 October 2012 - 10:17 PM, said:

But bear in mind this decryption doesn't happen at once. It happens only when needed, when we reach the part of executable.

Yikes! Another cause for performance concerns! This whole process now seems a lot less easy for the developer than you made it sound in your first post...

[quadisys]

Reedbeta, on 18 October 2012 - 11:25 PM, said:

Yikes! Another cause for performance concerns! This whole process now seems a lot less easy for the developer than you made it sound in your first post...

Why do you think so? If you, as the developer, have parts of code which are time critical, you'd send us a list of functions / offset ranges we should avoid touching and ... and that's it. No performance concerns anymore.

[Reedbeta]

Trouble is, in a video game the majority of the code is time-critical! I don't really want to be doing more than one of these checks per frame at most. But that doesn't leave much elsewhere to fit in several thousand crypto points. It just seems like a recipe for problems. Who knows, you could end up cramming 500 of them into your level-loading code, or something, which would probably then make for really slow loading.

[Stainless]

Quote

Then we will release version 1.01 with different 'crypto points', with different instruction mixing and you can start again. That's our deal.

What is the point of that ?

Once the game has been hacked, it will be released. Re-encrypting the game serves no purpose.

Games can use all sort of techniques to boost sales. Having a UID in all copies that has to be registered with a server for example.
These techniques often end up annoying end users and retailers. No second hand games etc.

For me, protecting against the kid in his bedroom with a hex editor is not a priority, the people I really do worry about are the organised crime guys who can copy the CD/DVD and send the image to thousands of distributors.

Luckily they spend most of their time targeting films.

[TheNut]

quadisys said:

Hm. And what happens if this SO GOOD game gets cracked next day after its release? I don't know in what country you live in but in mine, if something is SO GOOD and it's available for free, people take it for free.

Heh, can you honestly say an entire population is that corrupt? I know there are thieves out there, but I don't think the majority of our species is malevolent. There are a couple games that have been released DRM free and have been very successful. Torchlight, Sins of a Solar Empire, World of Goo. Runic announced that Torchlight sold over 1,000,000 copies. Sins of a Solar Empire also attained numbers around that area. That's pretty good for a DRM free game and small enough to fit on a CD. Then there are games with lightweight DRM such as Fallout 3 that have also proven successful.

As Reed and Stainless said, build something good and keep a good relationship with your user base. The more corporate, the more isolated you become, the more people will want to rebel against you. Just look at Ubisoft. They have a lot of talented developers and studios, but their DRM policies have put a bounty on their heads. Be reasonable, be respectful, and most importantly, heh, don't label people as untrustworthy and evil.