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
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 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
>>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
>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.
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.
>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%
>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
I hadn’t thought of altering file positions, but that’s
another subtle method.