45 replies to this topic

[alphadog]

quadisys, on 19 October 2012 - 04:08 AM, said:

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.

[quadisys]

Reedbeta, on 19 October 2012 - 05:03 AM, said:

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?

[quadisys]

Stainless, on 19 October 2012 - 08:43 AM, said:

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.

[quadisys]

TheNut, on 19 October 2012 - 10:43 AM, said:

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.

[quadisys]

alphadog, on 19 October 2012 - 02:06 PM, said:

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.

[Reedbeta]

quadisys, on 19 October 2012 - 10:43 PM, said:

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.

[Stainless]

quadisys, on 19 October 2012 - 10:47 PM, said:

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.

Quote

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.

[quadisys]

Stainless, on 20 October 2012 - 03:02 PM, said:

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?

[quadisys]

Reedbeta, on 19 October 2012 - 11:29 PM, said:

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.

[Reedbeta]

quadisys, on 21 October 2012 - 11:17 PM, said:

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.

[quadisys]

Reedbeta, on 22 October 2012 - 04:45 AM, said:

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.

[Stainless]

quadisys, on 21 October 2012 - 05:27 AM, said:

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.

[quadisys]

Stainless, on 23 October 2012 - 08:42 AM, said:

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

Quote

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

[Stainless]

quadisys, on 23 October 2012 - 06:28 PM, said:

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.

Quote

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

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.

[}:+()___ (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.

[Sol_HSA]

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.

[Stainless]

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.

[quadisys]

}:+()___ (Smile), on 24 October 2012 - 09:06 AM, said:

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.

[quadisys]

Quote

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! ;-)

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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

Quote

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.

[quadisys]

Stainless, on 23 October 2012 - 11:32 PM, said:

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.

Quote

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.