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