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. You'll get better revenues. 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)
In case of questions / interest you can write me at miroslav.kropacek@quadisys.com or post your questions here.
Is software piracy a problem for you?
I'm not sure if it makes sense to post all technical details on how it works.
Please do, I would love to have a look at this new technology, particularly if it uses cryptography (which is seldom used in current DRM for good reason) since that's one of my fields of interest.
Providing more details will also make you look like a more serious provider.
As it is now, my first question would be "one-time activation, how is that supposed to work?". Or, worded differently, user activates online and downloads the protected files, what prevents him from copying those (... and still allows him to upgrade his PC later).
Another question would be what "something like AES/RSA and similar stuff" is supposed to mean exactly. If this is "something like AES/RSA" then the claim that someone breaking a key is not a problem is a quite... brave statement.
As it is now, my first question would be "one-time activation, how is that supposed to work?". Or, worded differently, user activates online and downloads the protected files, what prevents him from copying those (... and still allows him to upgrade his PC later).
Another question would be what "something like AES/RSA and similar stuff" is supposed to mean exactly. If this is "something like AES/RSA" then the claim that someone breaking a key is not a problem is a quite... brave statement.
I've done extensive experimentation with software licensing security in my home office "laboratory" (which consists of a PC, cup of coffee, pack of smokes and an assembly-level debugger...OlyDbg). And I've found that about 90% of software is trivial to crack, including my own. So my first thought is what makes this solution you have better than the other 90%?
Most developers take a very naive approach to their licensing authentication (pseudo-code):
[source lang="csharp"]
void main()
{
var key = Environment.GetKey(ActiveUser);
bool result = server.AuthenticateLicense(key);
if (result)
LetProgramRun();
else
MessageBox.Show("Invalid license key!");
}
[/source]
What this boils down to in assembly language all hinges on a couple instructions (pseudo-assembly language):
MOV EAX, [result]
CMP EAX, 0x0001
JNE [bad_key]
JMP [success]
It's a total walk in the park to crack this. The easiest way is just to overwrite JNE with a NOP, so the code always falls through to "success". Alternatively, one could just change the JNE op to jump to the address of the success proc. That way an invalid license code becomes a valid license code. There are many different variations of this, and its always tackled a bit differently because compilers and assemblers output different instructions. But the point is that the overwhelming majority of license protection schemes are utterly useless against anyone with even the slightest notion of how machine code works. A lot of developers recognize this problem and try to complicate and/or obfuscate the code to make it difficult to find and interpret, but it still boils down to the same thing; give or take a few instructions.
So what makes your license protection solution more robust and secure than the "conventional" approach most developers take?
Also, I think the whole anti-piracy thing has gone much too far. The fact is that people who aren't going to buy your game simply aren't going to buy your game. Maybe they simply don't have the money...they have to pay for their Ramen noodles and can't afford it. Or maybe they just don't want to pay. We can't force them to pay. So license/copy protection is NOT going to increase revenues. All it can do (in theory) is reduce the number of people who play your game by reducing the number of illegal copies. Honest people are going to buy the game if they can afford it and the game is worth the price being asked. I feel that the best "security" is to make the game/software difficult to pirate (it's impossible to make it impossible) or run without a license, price it properly and make it accessible to the public.
On a few occasions I've actually had to run pirated versions of software I PAID FOR because their security wouldn't even let me run the damn software with a valid license key I'd just purchased. That really ticks me off. Disservices like Steam from Valve Corporation are a prime example. Over-doing it on security is almost a way to ensure people are going to pirate your game because they will have trouble running it, have to crack it and then they'll share the crack/patch with friends (and then all over the web). Also, when you try to make an "unbeatable" security system you're going to attract people who want to crack your software just to prove a point. And they'll be sure to share their solution all over the internet as well. So I really feel like the best approach to security is a very modest approach... Just my two cents. :-)
Regards,
--ATC--
Most developers take a very naive approach to their licensing authentication (pseudo-code):
[source lang="csharp"]
void main()
{
var key = Environment.GetKey(ActiveUser);
bool result = server.AuthenticateLicense(key);
if (result)
LetProgramRun();
else
MessageBox.Show("Invalid license key!");
}
[/source]
What this boils down to in assembly language all hinges on a couple instructions (pseudo-assembly language):
MOV EAX, [result]
CMP EAX, 0x0001
JNE [bad_key]
JMP [success]
It's a total walk in the park to crack this. The easiest way is just to overwrite JNE with a NOP, so the code always falls through to "success". Alternatively, one could just change the JNE op to jump to the address of the success proc. That way an invalid license code becomes a valid license code. There are many different variations of this, and its always tackled a bit differently because compilers and assemblers output different instructions. But the point is that the overwhelming majority of license protection schemes are utterly useless against anyone with even the slightest notion of how machine code works. A lot of developers recognize this problem and try to complicate and/or obfuscate the code to make it difficult to find and interpret, but it still boils down to the same thing; give or take a few instructions.
So what makes your license protection solution more robust and secure than the "conventional" approach most developers take?
Also, I think the whole anti-piracy thing has gone much too far. The fact is that people who aren't going to buy your game simply aren't going to buy your game. Maybe they simply don't have the money...they have to pay for their Ramen noodles and can't afford it. Or maybe they just don't want to pay. We can't force them to pay. So license/copy protection is NOT going to increase revenues. All it can do (in theory) is reduce the number of people who play your game by reducing the number of illegal copies. Honest people are going to buy the game if they can afford it and the game is worth the price being asked. I feel that the best "security" is to make the game/software difficult to pirate (it's impossible to make it impossible) or run without a license, price it properly and make it accessible to the public.
On a few occasions I've actually had to run pirated versions of software I PAID FOR because their security wouldn't even let me run the damn software with a valid license key I'd just purchased. That really ticks me off. Disservices like Steam from Valve Corporation are a prime example. Over-doing it on security is almost a way to ensure people are going to pirate your game because they will have trouble running it, have to crack it and then they'll share the crack/patch with friends (and then all over the web). Also, when you try to make an "unbeatable" security system you're going to attract people who want to crack your software just to prove a point. And they'll be sure to share their solution all over the internet as well. So I really feel like the best approach to security is a very modest approach... Just my two cents. :-)
Regards,
--ATC--
@ATC: In your opinion, you feel like Steam overdoes security?
I haven't had any problem DRM-wise with them (the constant patching can get annoying though).
I haven't had any problem DRM-wise with them (the constant patching can get annoying though).
One possible solution would be to move your game logic onto the server and use the client only as display/renderer..
Everything else is hackable.
If you e.g decide to use a server for authentification, one could #1 (as atc stated) change the authentification codeblock in your executable, #2 change the server data so that it connects to a custom server, .... use your imagination
Authentificating on a server would be a cake by using asymmetric encryption:
the key you have produces encrypted (login) data that can only be decrypted by the server and vice versa...
Hacking this is also possible but that should not be your concern since it would require setting up keyloggers and thats the user's fault.
Everything else is hackable.
If you e.g decide to use a server for authentification, one could #1 (as atc stated) change the authentification codeblock in your executable, #2 change the server data so that it connects to a custom server, .... use your imagination
Authentificating on a server would be a cake by using asymmetric encryption:
the key you have produces encrypted (login) data that can only be decrypted by the server and vice versa...
Hacking this is also possible but that should not be your concern since it would require setting up keyloggers and thats the user's fault.
@ATC: In your opinion, you feel like Steam overdoes security?
I haven't had any problem DRM-wise with them (the constant patching can get annoying though).
Definitely. I hate Steam with a passion. Steam is a complete and total deception; and if you ask me, an insult to gamers. It's passed off as a "service" for gamers to "help keep your games updated and all in one place". But Steam is actually a DRM platform about nothing other than control; controlling the use of the software you've paid for and which you should, by all rights, "own" (be able to personally use/consume as you please on your own machine). But not so with Steam. Steam owns your games, and they're just letting you play it in return for the money you've spent. At any time, technically, they could bar you from playing any (or all) of the games you've paid for. And if Valve Corporation were to ever go under, despite what they say, I seriously doubt you'd ever be able to play your games again. And don't tell me Valve can't go under... I remember people saying that about quite a few corporations and losing a lot of money... *cough* Bear-Sterns! *cough* :-) Some people have bought hundreds or even thousands of dollars worth of games and content through Steam, so that could be a significant loss...
So Valve claims Steam is to help keep your games up-to-date and all in one place... but I say bologna... Any self-respecting software company provides a simple and easy way for users to update their software. And Windows, for instance, also has the Games Manager that makes it easy to keep your games updated and all in one place. You also have freedom in deciding when you play, if/when you update, where you install things, etc. Not so with Steam. Steam decides when your games are updated, and you cannot play until Steam is satisfied. Steam also decides when you play. If Steam has an error, can't connect to the internet or just wants to be a prick you may not be able to play your game for days, weeks, ...? It's happened to me too many times.
Every time I buy a game I look on the back to see if it says "Steam Activation Required". If it requires Steam I will most often put it right back on the shelf, unless it's a very good game like Skyrim or IL-2 Cliffs of Dover that I cannot live without...in which case I just have to suffer the Steam Disservice. And every time I'm forced to compromise and buy a Steam-based game I always use more swear words than a pirate crew on a three month voyage. 99% of the time I install the game just fine then Steam starts "updating" and it's not until 1-3 days later that I actually get to play the game. That always makes me furious with not only Valve but the developers of the game for choosing a Steam-only setup. On a regular basis I get kicked in the teeth and infuriated by Steam when I want to play the games I've paid for. It often fails to load, behaves erratically, gets hung up on updates or takes forever to complete an update, etc... Even when I keep it in offline mode it STILL finds ways to screw me over and make me mad. One thing it does sometimes in offline mode, when I try to launch a game or Steam itself, is say it had an error logging into my Steam account. WTF? I'm in offline mode! Things like this are just constantly driving me crazy... when I lived out in the country I thought these problems were the result of my lousy, slow satellite internet connection. But now I'm living in the city on a T-1 connection and it's almost just as bad...
Steam is also, imho, a piece of "junkware"... It's slow, bloated, over-engineered, unreliable, the list goes on and on... It also doesn't conform to standards for the operating systems it runs on (e.g., Windows, Mac..), even down to it's UI. It's so bad I feel like we should bring all the Steam programmers before the Council of Programming Elders and have them punished by dragonfire, haha! :-)
I literally beg all software developers to NOT make their games Steam-only. Some people like Steam, and that is fine. You can make your game available on Steam for those who want it. But offer a non-Steam version of the game, for the love of God lol...
Regards,
--ATC--
One possible solution would be to move your game logic onto the server and use the client only as display/renderer..
Everything else is hackable.
If you e.g decide to use a server for authentification, one could #1 (as atc stated) change the authentification codeblock in your executable, #2 change the server data so that it connects to a custom server, .... use your imagination
Authentificating on a server would be a cake by using asymmetric encryption:
the key you have produces encrypted (login) data that can only be decrypted by the server and vice versa...
Hacking this is also possible but that should not be your concern since it would require setting up keyloggers and thats the user's fault.
That could work, but introduces a whole new host of problems. For one, people without internet connection cannot play your game. You're probably thinking, "Dude, everyone has internet these days!", and to some extent that is true. But not everyone. And we all travel... what if I'm on a road trip or long flight and want to play my games, but I can't because I don't have internet connection? Games that require internet connection drive me insane. Just recently, we lost our beloved T-1 connection during Hurricane Isaac. I couldn't play ANY of my favorite games because of Steam... it wouldn't even start in offline mode because I didn't have internet (go figure, makes no sense...). Requiring internet connection to play a game (unless it's a multiplayer-only game) is bad design...
Author
OK guys, you want technical details, here they are. First I want to say that I 100% agree with ATC and his analysis of typical solutions as well as with samoth about RSA/AES. Because ... that's the point exactly! Let me explain.
Typical protection is exactly as ATC says... it's 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 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)
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.
Typical protection is exactly as ATC says... it's 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 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)
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.
If only the crypto points are scrambled: Couldn't a group of crackers each pool their executables, and then compare the executables to find the crypto points which could then be removed?
If the entire binary is scrambled: Wouldn't this effect the performance of carefully balanced tight inner loops? Is there a way to specify, for performance-sensitive areas of code, not to scramble that portion?
Does your method require an internet connection for ever playing session, or just for install/activation? If only for activation, how do you detect concurrent users?
If the entire binary is scrambled: Wouldn't this effect the performance of carefully balanced tight inner loops? Is there a way to specify, for performance-sensitive areas of code, not to scramble that portion?
Does your method require an internet connection for ever playing session, or just for install/activation? If only for activation, how do you detect concurrent users?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
