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?

---

[Back to counter intelligence] ~ [Back to part one] ~ [Forward to part three]

---

homepage links anonymity +ORC reality cracking antismut
how to search academy database tools cocktailssearch_formsmail_fravia