[Back to counter intelligence] ~ [Back to part one] ~ [Forward to part three]
Re: The Economics of Piracy Author: Brandon Van Every Email: vanevery@blarg.net Date: 1998/09/18 Forums: comp.games.development.industry Russ Williams wrote in message <6tti6k$ktr$5@flex.london.pipex.net>... >> >>And I take it you never ever release the identifier program >>app_cuid.exe outside of the building. Your own >>in-building security has to be pretty good, then. > >Surely it's the personal security of the person in charge >of the checks? They can keep it strongly encrypted and >only dig it out when they find a new warez copy of the >program to examine. No, the engineers whose work depends on the data file must be in the loop too. Without being in the know, they might inadvertently make a version whose app_cuid.exe is invalid. This could be 1 engineer or 100 engineers, depending on how judiciously you choose your data file. It is, quite literally, a data hiding issue! :-) >>A clever cracker thinkz you might have embedded a >>key in your program somewherez, he thinkz itz in >>your 3D datasetz. So he perturbs every single point >>of data in your dataset by a small random amount. >>Hey presto, your program still works! Oh no! the >>magic key is gone. > >Assuming they know it's there. No, they don't have to know it's there. They only have to know that developers do this sort of thing with data structures, and that transforming the entire data structure into something else slightly different is a good idea. They could be completely wrong, there might be no embedded ID in the data structures whatsoever. They could waste a lot of labor on it, thinking they need to understand all the data structures and then transform them. But then again, lotsa people reverse engineer the data structures just to build new game levels and such. The goal is to erase all identifying marks. They can do this by transforming all data, and by turning the program code into a pile of spaghetti. Any cracker with a background in compiler technology and sufficient determination could perfect the program code transformations in about 6 months to 1 year. To be sure, that requires someone with a considerable amount of skill and interest in the problem. There are very few people in the world with that kind of theoretical research interest, unfortunately Fravia at http://www.fravia.org is <-- flattening, isn't it? :-) exactly such a person and there may be others. He sees the mission of cracker-dom as extending various branches of computer science that academia or industry won't explore. And actually, he's got a good point in an "American Civil Liberties Union defending the Nazis" sort of way. It would be very damaging <-- why nazis? Reversers are to someone like Microsoft if you could simply fix what's wrong <-- universal, anti-racist, with their system and/or extend it arbitrarily. Might actually <-- and clever... nothing to bring the computer industry to a new level of quality or <-- do with nazionalists... price/performance or something. <-- quite the contrary, if <-- you ask me :-) Transforming the data structures is more "artistic." It's application-specific and requires someone to reverse-engineer the structures. So you'd want to put your key in a really convoluted data structure that takes a long time to figure out, and that is also critical to your program's operation. Because if it wasn't critical, the crackerz just might try throwing out any convoluted file they come across. Of course, the security is only as good as your engineering team's willingness to make their critical data structures convoluted. Cheers, 3d graphics optimization jock Brandon Van Every Seattle, WA ----------------------------------------------------------------------- If we are all Gods and we have thrown our toys the mortals away and we are Immortal What shall we do and we cannot die to entertain ourselves?
russ@algorithm.demon.co.uk Date: 1998/09/19 Forums: comp.games.development.programming.algorithms Brandon Van Every wrote: >Russ Williams wrote: [...] >>Unless the lead programmer says "I'll burn all the CDRs". >>Then (s)he can place the keys and burn the discs. No-one >>else needs to be in the loop. > >Ok, the lead programmer has to be aware of all the changes >in data files that he/she might wish to utilize for the keys. >Also, the lead programmer has to verify this info every time >a new disk is cut. Whether this is expeditious depends on >how frequently you release new disks. Well, it's only likely to be useful when sending discs to publishers or, more likely, magazines. >Small problem: what if the lead programmer screws it up? >Shouldn't we have some QA on the piracy prevention >method? Well, if you do the security on every single disc, then the QA would be done on the protected game - if it goes wrong, the testers will bitch about it... >>>No, they don't have to know it's there. They only have to >>>know that developers do this sort of thing with data >>>structures, and that transforming the entire data structure >>>into something else slightly different is a good idea. >> >>Yeah, but that involves a *lot* of work. > >Maybe not as much as you think. It depends on how >convoluted the files are. If engineers design the files knowing >how they should make it harder for crackerz, then they have >a better chance of thwarting them. But if they just assume >that the scheme is going to work, then maybe their data files >are really easy to deduce and transform. Which is why we're >having this discussion: to educate the engineers on what >safeguards would/wouldn't be good. OK. Fair point. Something like using the least significant bits of each byte in a BMP body would be bad because it could be wiped out trivially once detected. OTOH, a 4Hz carrier wave modulated into a sound would be more difficult - small pertubations (ie: noise) are high frequency, so a simple FFT would seperate them out. >>>They could be completely wrong, there might be no >>>embedded ID in the data structures whatsoever. >> >>Which is why they probably won't look. > >It's not a matter of statistics! It's a matter of exactly ONE >determined cracker being out there who'z willing to look. >If that ONE cracker gets through the puzzle, then hiz/her >work goez to all the other sitez. >Look very closely at http://www.fravia.org <---- flattening, isn't it? :-) Seen it. >if you doubt the resolve of certain ringz of crackerz. Some >of them are as fanatic as a Linux hacker who wants >to wipe Microsoft off the face of the earth. Yup. But how many of them are in it for the "0-day warez" aspect? IMO, most of the fanatics are more likely to spend a couple of months cracking it and then write up a nice essay on the experience to share with their peers. >The *statistical* part comes from how many disks you >release to the world. The odds of the extremely determined >cracker getting ahold of 1, or 2, of them. Yup. The way I'd counter that is to provide codes grouped on 3 sources. That way you need nC3 keys, but a disc from <=3 sources will have a piece of the data that's identical in all 3 versions and identifies which 3 leaked. If only 2 leak, then there will be many more keys to identify which 2. Obviously, this is trivially expandable to any number in a group (in case you think 42 discs will go walkabout). >>>They could waste a lot of labor on it, thinking they need to >>>understand all the data structures and then transform them. >>>But then again, lotsa people reverse engineer the data >>>structures just to build new game levels and such. >> >>But usually games don't have sufficient error checking - it's >>only necessary if the game is supposed to be expandable. >>A slight change in the data is likely to screw something up. > >Well then you'd like to design your game to have a >crack-test-crack cycle that takes a long time. For instance, >make the key hidden about 1/4 the way through the game, >and make it necessary to get through that part of the game >to reach the end of the game. This is a long enough >turnaround time that verifying whether your transformative >crack worked would be verrrrry tedious. Not to mention the fact that, if they fail halfway through the crack and distribute anyway, the warez version would make a nice demo. 25% of the final game would be enough for people to decide if they want the rest or not. >This strategy doesn't work very well for level-based games. >Works great for adventure games. It could work for levels if you use lots and lots of strong encryption and chain levels together (ie: the key for level n is in the data for level n-1) and alter things after some number of levels. They'd crack the first dozen levels, say, figure it's working, but have missed that the encryption method changes for level 13.. >>IMHO, the best solution would be three-fold: >>i) A CD check. Something lame like the volume >>ii) Encrypted data - but using a different key for each >> disc. > >If the data is needed for program operation, then the >data must be decrypted by the program at some point. Of course. >Ergo, the decryption method is contained in the program >and can be easily found. Indeed - it's supposed to be. If they leave the encryption in (just removing the CD check intertwined with it), the decode key will identify the leak. If they remove the routine and expand/decrypt the data, they may think they're done and miss #3. Sleight of hand. [...] >>iii) A couple of hidden keys in the raw data, eg: the >> luminance channel of textures, or modulated on >> an infrasound carrier into samples. > >No, you don't want it in the raw data. The raw data is easy >to perturb randomly and still get basically the same data. That depends how you place it. Ultra low frequency components across the whole dataset would be much more difficult to remove. Imagine a sample with a 4Hz sine wave mixed in - it would be undetectable by ear and noise wouldn't remove it. A simple FFT of the whole sample would reveal that note, and you could mix different frequencies in (ie: 4.0Hz, 4.1Hz, 4.2Hz) to allow for ECC-style identification of the leak(s). >You want to stick your key in the INDEX STRUCTURE >of the data. Too obvious. >Somewhere that takes quite a while to figure out how >to transform without breaking everything. But, as you've said, there are crackers willing to spend any amount of time doing the grunt work.. >>The question is: how many would look for and find #3? > >To reiterate, you don't FIND the key. You eradicate >everything, including the key. It's not always that simple. Unless the crackers are going to rip out every image, every sample, every piece of data from the game then they're not going to be 100% effective. [...] >Incidentally, if you're willing to burn your CDs one at a time, >then you could use the same data transformation methods >to encode the unique identity of a file. Rather than sticking >a unique ID on each disk somewhere within the file, and >running the risk of 2 files being compared, you make the data >file on *every* CD unique. That was the idea of #2 above - a compressed and encrypted data set can't be compared meaningfully if they encryption key changes between builds. You need to spend ages decompressing before you can compare. I hadn't thought of altering file positions, but that's another subtle method. --- Russ
Author: Brandon Van Every Email: vanevery@blarg.net Date: 1998/09/18 Forums: comp.games.development.programming.algorithms Russ Williams wrote in message <906161319.29079.0.nnrp- >> >>No, the engineers whose work depends on the data file >>must be in the loop too. Without being in the know, they >>might inadvertently make a version whose app_cuid.exe >>is invalid. This could be 1 engineer or 100 engineers, >>depending on how judiciously you choose your data file. >>It is, quite literally, a data hiding issue! :-) > >Unless the lead programmer says "I'll burn all the CDRs". >Then (s)he can place the keys and burn the discs. No-one >else needs to be in the loop. Ok, the lead programmer has to be aware of all the changes in data files that he/she might wish to utilize for the keys. Also, the lead programmer has to verify this info every time a new disk is cut. Whether this is expeditious depends on how frequently you release new disks. Small problem: what if the lead programmer screws it up? Shouldn't we have some QA on the piracy prevention method? >>No, they don't have to know it's there. They only have to >>know that developers do this sort of thing with data >>structures, and that transforming the entire data structure >>into something else slightly different is a good idea. > >Yeah, but that involves a *lot* of work. Maybe not as much as you think. It depends on how convoluted the files are. If engineers design the files knowing how they should make it harder for crackerz, then they have a better chance of thwarting them. But if they just assume that the scheme is going to work, then maybe their data files are really easy to deduce and transform. Which is why we're having this discussion: to educate the engineers on what safeguards would/wouldn't be good. >>They could be completely wrong, there might be no >>embedded ID in the data structures whatsoever. > >Which is why they probably won't look. It's not a matter of statistics! It's a matter of exactly ONE determined cracker being out there who'z willing to look. If that ONE cracker gets through the puzzle, then hiz/her work goez to all the other sitez. Look very closely at http://www.fravia.org if you doubt the resolve of certain ringz of crackerz. Some of them are as fanatic as a Linux hacker who wants to wipe Microsoft off the face of the earth. The *statistical* part comes from how many disks you release to the world. The odds of the extremely determined cracker getting ahold of 1, or 2, of them. >>They could waste a lot of labor on it, thinking they need to >>understand all the data structures and then transform them. >>But then again, lotsa people reverse engineer the data >>structures just to build new game levels and such. > >But usually games don't have sufficient error checking - it's >only necessary if the game is supposed to be expandable. >A slight change in the data is likely to screw something up. Well then you'd like to design your game to have a crack-test-crack cycle that takes a long time. For instance, make the key hidden about 1/4 the way through the game, and make it necessary to get through that part of the game to reach the end of the game. This is a long enough turnaround time that verifying whether your transformative crack worked would be verrrrry tedious. This strategy doesn't work very well for level-based games. Works great for adventure games. >IMHO, the best solution would be three-fold: >i) A CD check. Something lame like the volume >ii) Encrypted data - but using a different key for each > disc. If the data is needed for program operation, then the data must be decrypted by the program at some point. Ergo, the decryption method is contained in the program and can be easily found. If the data is not needed for program operation, then it can be easily erased. The best identifying mark is a hidden mark, not an encrypted mark. >iii) A couple of hidden keys in the raw data, eg: the > luminance channel of textures, or modulated on > an infrasound carrier into samples. No, you don't want it in the raw data. The raw data is easy to perturb randomly and still get basically the same data. You want to stick your key in the INDEX STRUCTURE of the data. Somewhere that takes ;very clever and correct! quite a while to figure out how to transform without breaking everything. >The question is: how many would look for and find #3? To reiterate, you don't FIND the key. You eradicate everything, including the key. >And how well would they do at eradicating the key? http://www.fravia.org . Turn the webpage, you're bound to ;more compliments :-) learn something. There are lame-o crackerz who want free software, and then there are super-crackerz who enjoy busting cryptograms. Incidentally, if you're willing to burn your CDs one at a time, then you could use the same data transformation methods to encode the unique identity of a file. Rather than sticking a unique ID on each disk somewhere within the file, and running the risk of 2 files being compared, you make the data file on *every* CD unique. Perturb all the data points and rearrange all the file indices using some randomization scheme, do this uniquely for each CD you let out the door. Now when 2 CDs fall into a cracker'z hands, he compares them, and the comparison yields complete junk! It's not 99% the same with 1% different, thereby tipping him off. Instead it's 100% different. And it doesn't matter if he getz 100 different CDs, each CD's data file is unique and has someone you can sue attached to it! He can replace files all day long, there's always going to be 1 out of 100 possible people that's going to get sued. The cracker *has* to solve the structure of your data file to break ;yeah, that's the this scheme. No other choice. Has to understand what's a float value, ;true and worth what's an index, etc. And you could make it take a very long time for ;trying point! him to do that. Thing to watch out for: the way in which you perturb your data file could tip off the cracker as to what kind of data she'z looking at. Floats might all have lotsa bits in the low-end values, index ints ;Yes! might all fall within a certain range, etc. But still, with awareness of this possibility, there's probably a way to scramble it up really ;and to unscramble it well in an automated fashion. ;up really well in an ;automated fashion :-) Cheers, 3d graphics optimization jock Brandon Van Every Seattle, WA ----------------------------------------------------------------------- If we are all Gods and we have thrown our toys the mortals away and we are Immortal What shall we do and we cannot die to entertain ourselves?