Is software piracy a problem for you?

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 17, 2012 at 02:52

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.

45 Replies

Please log in or register to post a reply.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Oct 17, 2012 at 04:07

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

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 17, 2012 at 04:12

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?

  1. 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
  2. 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
  3. 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.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Oct 17, 2012 at 04:29

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. :)

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 17, 2012 at 04:53

@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”.

Good summary.

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’.

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 :)

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.

6837d514b487de395be51432d9cdd078
0
TheNut 179 Oct 17, 2012 at 11:29

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.

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 Oct 17, 2012 at 14:12

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….

46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Oct 17, 2012 at 14:45

@quadisys

(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 :P. 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.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 18, 2012 at 03:52

@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.

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.

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 :)

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.

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).

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 18, 2012 at 03:59

@Kenneth Gorking

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. :)

Another posibility would be to hack into your servers, and just download all the clean executeables :P. 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”.

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 :)

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 18, 2012 at 04:05

@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).

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

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.

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?

46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Oct 18, 2012 at 05:25

@quadisys

  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

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

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.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 18, 2012 at 07:29

@Kenneth Gorking

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.

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.

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 :)

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.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 18, 2012 at 08:52

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.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 18, 2012 at 22:17

@Stainless

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.

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.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Oct 18, 2012 at 23:25

@quadisys

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…

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 19, 2012 at 04:08

@Reedbeta

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.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Oct 19, 2012 at 05:03

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. :)

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 19, 2012 at 08:43

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.

6837d514b487de395be51432d9cdd078
0
TheNut 179 Oct 19, 2012 at 10:43

@quadisys

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.

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 Oct 19, 2012 at 14:06

@quadisys

you’d send us a list of functions / offset ranges we should avoid touching and … and that’s it. No performance concerns anymore.

Man, you set yourself up for some serious review! :) Personally, I don’t think there’s much revoluitonary to what you are doing compared to some of the big players. Lots of them actually bury random code into executables. There may be a minor tweak that I am not familiar enough with your product wrt to online checks, but I beleive that happens already.

However, one concern is the above quote. So, anytime I want to update my exe to have a new set of “over 9000” crypto points, I have to ask you? So, you could become the bottleneck if your product is a runaway success and I can’t get your time? Stainless is partly right too. Once a version is hacked, what’s the point of redistributing the checkpoints? Only a patched version, that is worth updating to, would be worth re-randomizing checks.

As for the business case for DRM, I think everyone goes to extremes of logic to make their case. Without DRM, you will get a hit on sales, period. Some say every downloader is a potential buyer, others say none. The truth is in between and no one can ever know what that average ratio is. You’d have to release a game DRM-free, wipe collective memories, and redo the release with DRM to know! The point is, unless negligeably low, that is lost sales. It’s up to each studio to determine what they think and go accordingly. That’s the thrill of business decisions.

I also don’t think mild DRM and “Build something good” are mutually exclusive.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 19, 2012 at 22:43

@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. :)

That’s a fair question, no doubt. I can only speak from our experiences: we tried to protect time critical apps like UPX, zip, rar, … and measure differences. Packing and depacking time decreased by 5-8%, heavily depending on source archive. No that bad, is it?

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 19, 2012 at 22:47

@Stainless

What is the point of that ? Once the game has been hacked, it will be released. Re-encrypting the game serves no purpose.

The point of that is the fact that gamers who’ve chosen to download the cracked version will be stuck with old version for another 10 months (for example). While their friends who legally bought the game can use new features etc.

And the bottom line is that if a publisher A’s game gets cracked, publisher B’s game wont be affected. You can’t tell this about any other software protection mechanism.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 19, 2012 at 22:52

@TheNut

Heh, can you honestly say an entire population is that corrupt?

You’re from western part of globe, aren’t you ;-) You know, I live in Slovakia. Here (and more to the east), piracy goes as low as 90%. Yeah, that’s right. While in the US the rate is about 20%, here - every kid and/or teen in every class has the newest video games, the newest Photoshop (for removing the red eyes, of course!) etc. That’s what we are about to change.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 19, 2012 at 22:57

@alphadog

However, one concern is the above quote. So, anytime I want to update my exe to have a new set of “over 9000” crypto points, I have to ask you? So, you could become the bottleneck if your product is a runaway success and I can’t get your time? Stainless is partly right too. Once a version is hacked, what’s the point of redistributing the checkpoints? Only a patched version, that is worth updating to, would be worth re-randomizing checks.

I have good news for you - YOU are the manager of your software. You don’t need to wait for us for anything. You sign up at our website, upload files to protect, download our loader and … that’s pretty much it. Wanna do an update? Sign in again, change 1-2 files, download a new loader, distribute. No steps from our side at all.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Oct 19, 2012 at 23:29

@quadisys

That’s a fair question, no doubt. I can only speak from our experiences: we tried to protect time critical apps like UPX, zip, rar, … and measure differences. Packing and depacking time decreased by 5-8%, heavily depending on source archive. No that bad, is it?

If your algorithm adds 5-8% to my frame time, I would consider that unacceptable for a real-time game. That amount of time could easily make the difference between hitting and missing my target framerate. There’s a lot of stuff I’d rather spend 5% of a frame on than DRM. That amount of loss might be acceptable for a zip app (which really isn’t “time-critical” BTW), but definitely not for a game trying to render a 3D world at 60 fps.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 20, 2012 at 15:02

@quadisys

The point of that is the fact that gamers who’ve chosen to download the cracked version will be stuck with old version for another 10 months (for example). While their friends who legally bought the game can use new features etc.

But that is true for a game that is totally unprotected (code wise) but uses a server to register and validate users. This has been used on other games, I think one of the Final Fantasy games did something similar… not sure.

And the bottom line is that if a publisher A’s game gets cracked, publisher B’s game wont be affected. You can’t tell this about any other software protection mechanism.

That’s not a real advantage if I am publisher A

Also the premise that publisher B’s game won’t be affected is a little weak. When it comes to breaking copy protection it’s techniques that matter, and the technique used to crack game A is probably still valid for game B.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 21, 2012 at 05:27

@Stainless

Also the premise that publisher B’s game won’t be affected is a little weak. When it comes to breaking copy protection it’s techniques that matter, and the technique used to crack game A is probably still valid for game B.

But that’s the point! It is not! It’s like if you decipher a crypted message using brute force. What exactly it gives you as advantage for next messages, crypted using different keys?

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 21, 2012 at 23:17

@Reedbeta

If your algorithm adds 5-8% to my frame time, I would consider that unacceptable for a real-time game. That amount of time could easily make the difference between hitting and missing my target framerate. There’s a lot of stuff I’d rather spend 5% of a frame on than DRM. That amount of loss might be acceptable for a zip app (which really isn’t “time-critical” BTW), but definitely not for a game trying to render a 3D world at 60 fps.

Uhm, you’re right, the words ‘time critical’ do not fit for packers very much. What I wanted to say that we tested many algorithm-based apps and this was the result. As for 60 fps games … I guess you’re familiar with rendering pipe line… 90% of the time critical stuff is done in GPU. CPU reads keyboard, loads stuff, depack textures, handles AI.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Oct 22, 2012 at 04:45

@quadisys

I guess you’re familiar with rendering pipe line… 90% of the time critical stuff is done in GPU. CPU reads keyboard, loads stuff, depack textures, handles AI.

No offense, but I suspect I am somewhat more familiar with the rendering pipeline than you are. :) In a realistic 3D game, the CPU does a lot more work than you suggest. The graphics is not all on the GPU; there is quite a lot of related work on the CPU as well: scene management, animation, visibility culling, sorting, generating command buffers and shader parameters. Then there is physics, networking, and so on. Depending on what you are doing for AI, it is not necessarily cheap either - think pathfinding, NPC visibility raycasts, etc.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 23, 2012 at 03:33

@Reedbeta

No offense, but I suspect I am somewhat more familiar with the rendering pipeline than you are. :) In a realistic 3D game, the CPU does a lot more work than you suggest. The graphics is not all on the GPU; there is quite a lot of related work on the CPU as well: scene management, animation, visibility culling, sorting, generating command buffers and shader parameters. Then there is physics, networking, and so on. Depending on what you are doing for AI, it is not necessarily cheap either - think pathfinding, NPC visibility raycasts, etc.

I’m not going to argue over this, you may be very well right. You know, it’s up to the publisher – if he tries our protection and realize it’s too slow even with the fastest settings, it’s fine, he can fall back to whatever he is using now. We cash you per activated users, not in advance.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 23, 2012 at 08:42

@quadisys

But that’s the point! It is not! It’s like if you decipher a crypted message using brute force. What exactly it gives you as advantage for next messages, crypted using different keys?

Brute force? Who the hell would use brute force?

Whatever algorithm you use for encrypting anything, will have a counter algorithm. History is riddled with examples of the battle to encrypt data and the counter measures used to break the encryption.

The people who get hurt in that battle are the people who assume the data is secure. Arrogance kills.

If your system becomes popular with publishers, and it will be publishers you need to talk to, not developers, then someone will find a way of beating it.

Eventually.

It’s that eventually that gives you a chance, if the period of time between release into the wild and break is long enough you may make some money, but if your techniques have not adapted by that point then you are worse than useless. You are dangerous.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 23, 2012 at 18:28

@Stainless

Brute force? Who the hell would use brute force? Whatever algorithm you use for encrypting anything, will have a counter algorithm. History is riddled with examples of the battle to encrypt data and the counter measures used to break the encryption.

We’re mixing up two things here.

  1. With the cryptology example I wanted to say that there are scenarios when you can know the algorithm, have 3 different ciphered messages and still, you can’t do anything about it. Correct me if I’m wrong but RSA & friends can’t be broken with any ‘counter measure’ except brute force and stolen keys.

  2. Our technology. Here the key = your hardware. And the algorithm = checking of hardware in the thousands of points. So only mean of breaking our technology = remove every point = brute force (manual work, not automated nor outsmarted).

It’s that eventually that gives you a chance, if the period of time between release into the wild and break is long enough you may make some money, but if your techniques have not adapted by that point then you are worse than useless. You are dangerous.

Our techniques are based on randomness, i.e. the adaptation you’re talking about happens for every copy, for every publisher. So our technology is all but useless…

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 23, 2012 at 23:32

@quadisys

Correct me if I’m wrong but RSA & friends can’t be broken with any ‘counter measure’ except brute force and stolen keys.

You are wrong.

RSA encryption is the target of intense study and modern techniques cannot be called anything close to “brute force”

Abderrahmane Nitaj has done some really interesting work in the field , others are more concerned with key management and the fact that processing public keys can reveal common factors and compromise the private key.

It’s like any encryption system, once it goes into the real world, people start working on it, then vulnerabilities show up.

  1. Our technology. Here the key = your hardware. And the algorithm = checking of hardware in the thousands of points. So only mean of breaking our technology = remove every point = brute force (manual work, not automated nor outsmarted). Our techniques are based on randomness, i.e. the adaptation you’re talking about happens for every copy, for every publisher. So our technology is all but useless…

The techniques may look perfect on paper, but they don’t run on paper. The run on a computer. Whatever technique you use, or anybody uses, it WILL be vulnerable to something.

When they designed the GSM phone network they used two encryption systems and made the decision to develop them in secret. Once they become public, they were hacked. By this time it was too late to change the design.

You seem to have it in your head that your system is perfect, it’s not. Nothing ever will be. All you can hope to do is delay the hackers long enough that you have already made your money out of the game by the time they have hacked it.

You say that your technique can be added to thousands of locations in the code, fine so I go out and buy a load of raspberry pi’s and put them together into an array and set that off on the problem. For about $3000 you have a machine capable of a huge number of calculations per second, with some clever code I bet it will be able to do a game in a day.

Stop thinking your system is perfect, start looking at it objectively and then you will have a better idea of what you are up against.

We have all done it, had a brainwave and rushed into something that feels perfect, it never ends up being perfect. Ever.

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Oct 24, 2012 at 09:06

I think, most vulnerable part of such DRM scheme is the process of getting hardware id. Cracker simply hook API functions for getting hardware info or rewrite supplied ring0 driver instead of hunting zillion of crypto points.

3c5be51fdeec526e1f232d6b68cc0954
0
Sol_HSA 119 Oct 24, 2012 at 09:41

Hi, and congrats: you got me signing in after a long time just to participate..

First off, the approach to copy protection seems grounded on a very good point: instead of making cracking “impossible”, make it boring and time-consuming.

Second, you could try “protecting” some tools benchmarkers use - like some 3dmark or some of the games used to benchmark new hardware these days. The results from those would probably soothe (or confirm) some of the concerns from the folk in here.

Third, files are on your servers. Can they handle AAA title launch traffic?

Fourth, if the game gets cracked within N days, will you give the developer full refund?

The primary concern I have is the randomity of the thing - if I have a game project with its million lines of code, and I carefully list functions that shouldn’t get instrumented (which would probably be around \~80% of the whole codebase), it’s still possible I miss something that, when slowed down, causes issues. And since this is a random process, some customers have the issues and others don’t. No amount of testing will conclusively say your solution won’t cause issues for me.

The best copy protection story I’ve read was some console game (dreamcast maybe?) where the game made constant checksums of itself, with the checksum areas overlapping (so they had to recursively change the checksums in the build to find ones that take each other into account).

If some checksum failed, the game didn’t die, but instead removed some keys (or coins or gems or whatever) that you had to collect to advance - so to validate your crack, you had to play the game for hours.

How was it cracked in the end? The crackers found a shortcut.

The game only did a hardware check at load time.The game loaded to memory and patched itself back to the original form once hardware check was passed. In retrospect the developers could have included hardware checks later on, like at the start of each level, to make cracking even harder.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 24, 2012 at 10:05

Both the last posts made good points, other things to consider ….

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

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?

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.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 25, 2012 at 18:31

@}:+()___ (Smile)

I think, most vulnerable part of such DRM scheme is the process of getting hardware id. Cracker simply hook API functions for getting hardware info or rewrite supplied ring0 driver instead of hunting zillion of crypto points.

I’ll surprise you, it is not. First we do not use any APIs and second we do not use any driver for this. Driver only grants ring0 privileges to one control point at time, this control point talks directly to hardware and therefore if you want to remove each checkpoint, you have to debug it manually and that’s what our technology is about. Boring and lengthy debugging, again and again.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 25, 2012 at 18:51

First off, the approach to copy protection seems grounded on a very good point: instead of making cracking “impossible”, make it boring and time-consuming.

Beware, crowd will beat you up for this kind of comments! ;-)

Second, you could try “protecting” some tools benchmarkers use - like some 3dmark or some of the games used to benchmark new hardware these days. The results from those would probably soothe (or confirm) some of the
concerns from the folk in here.

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.

Third, files are on your servers. Can they handle AAA title launch traffic?

By the nature of our protection, we don’t need to do any magic stuff there. It’s more like a reliable file server with multiple downloads. We outsourced this task to one of the best companies in our country to handle this, so in this matter I’m pretty confident.

Fourth, if the game gets cracked within N days, will you give the developer full refund?

As I mentioned somewhere else we charge them per activation. So, in case the game gets cracked, obviously “no one” would be interested in activation on our servers anymore => you wont get charged as well.

The primary concern I have is the randomity of the thing - if I have a game project with its million lines of code, and I carefully list functions that shouldn’t get instrumented (which would probably be around \~80% of the whole codebase), it’s still possible I miss something that, when slowed down, causes issues. And since this is a random process, some customers have the issues and others don’t. No amount of testing will conclusively say your solution won’t cause issues for me.

Actually, we’ll make your make job much easier. Sure, you can tell us that these function are most important / optimized. But if you still don’t feel good about the result, we have a tool (I guess we could spread this tool among publishers) which analyzes the most used / most called code and we can tell you what functions should be avoided or we will do that by ourselves, obviously.

If some checksum failed, the game didn’t die, but instead removed some keys (or coins or gems or whatever) that you had to collect to advance - so to validate your crack, you had to play the game for hours.

We do exactly the same, as those control points are randomly spread, it’s very well possible the last control point gets discovered in the very last level :)

In retrospect the developers could have included hardware checks later on, like at the start of each level, to make cracking even harder.

Sure. We learn from mistakes and although we had no idea about Dreamcast, we figured out that we can’t have one single deep throat else we’re doomed.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 25, 2012 at 19:10

@Stainless

All you can hope to do is delay the hackers long enough that you have already made your money out of the game by the time they have hacked it.

I guess my English is really broken as this is exactly thing I’m trying to repeat here again and again. Our technology is built on this premise.

You say that your technique can be added to thousands of locations in the code, fine so I go out and buy a load of raspberry pi’s and put them together into an array and set that off on the problem. For about $3000 you have a machine capable of a huge number of calculations per second, with some clever code I bet it will be able to do a game in a day.

You still don’t understand. Maybe I should invent a smarter term than the ‘crypto point’ as the point lies completely elsewhere. We don’t say it’s computationally complex. We say that’s there are some control points, which are well hidden for any kind of automation approach and that you, you as a person - pirate, need to find & debug & remove it manually. Every one of them.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 25, 2012 at 19:16

@Stainless

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.

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.

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.

3c5be51fdeec526e1f232d6b68cc0954
0
Sol_HSA 119 Oct 26, 2012 at 05:45

@quadisys

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.

4930d73f28dc16986e5ac59a4d636b97
0
quadisys 101 Oct 27, 2012 at 04:33

@Sol_HSA

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.

3c5be51fdeec526e1f232d6b68cc0954
0
Sol_HSA 119 Oct 27, 2012 at 14:18

@quadisys

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 =)

46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Dec 21, 2012 at 15:59

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

Fe8a5d0ee91f9db7f5b82b8fd4a4e1e6
0
JarkkoL 102 Mar 17, 2013 at 19:41

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