Well, this is a long email-exchange between game-programmers. Top game programmers' protection techniques are interesting because these guys are under very sophisticated attacks from the 'real piracy' industry: i.e. those guys that BURN hundreds (thousands?) of pirated CD-ROMs with the latest "hit" in order to steal money. Whole industries are active in this sense in Asia and Eastern Europe. This activity is not only stealing, it is a "commercial" attitude that we not only DO NOT condone, but that we are ready to counter together with these same protectors if needs be, for instance delivering our own thoughts on these protection schemes.
On the other hand, these same attacks seem to push these protectors to an higher degree of resourceful inventive: unfortunately their main problem is identifying leaks when they send CD-ROMs to the magazines for testing, yet part of the schemes that they propose could bear interesting fruits in the future for all forms of software protection, CD-ROM based or NOT CD-ROM based. That's the reason I have decided to publish this.
As you will read, there are quite a lot of sound protecting ideas in here, and I can only praise the idea of sticking the key "in the INDEX STRUCTURE of the data, somewhere that takes quite a while to figure out how to transform without breaking everything. Yes! Yes! This is the way of the future for all kinds of protections, and it is, IMO, the only strategy that will work. Once more: "The cracker *has* to solve the structure of your data file to break the protection scheme. No other choice. Has to understand what's a float value, what's an index, etc. And you could make it take a very long time for him to do that. And exactly that will mark the difference between lam-o-crackers and real reversers: real reversers will enjoy this kind of protection! Of course we will reverse these schemes, yet it shall -let's hope- take some time (like it should be when solving any good puzzle) and this delay will serve this kind of protectors well, since by the time we have cracked their games' protections, the commercial products themselves will already be "oldies". So what? Who cares? Man, I'm myself at this very moment cracking in the background a very old DOS game just for the fun of it! Who cares if the target is the last frizzy-dizzy flop of tomorrow? It's the amount of intelligence that has been put into the protection scheme that counts :-)
Let's hope that Brandon and Russ will soon implement some of their smart and inventive projects!

Re: The Economics of Piracy
message  Author: Brandon Van Every 
Email:vanevery@blarg.net
Date:1998/09/17
Forums:comp.games.development.industry 
------------------------------------------------------------------------


Brian Upton wrote in message <6TRQ4F$f98$1@news0-alterdial.uu.net>...
>
>My sympathies.  Rainbow Six leaked the week it went to press.  We were
>*not* amused.  I don't think the pirates realize how much work goes
>into a game, and how much ownership you feel for something you've
>built yourself.  Particularly galling were online "reviews" that
>dinged the product for flaws that didn't exist in the final version.


I think that settles the whole pre-release piracy-as-marketing question
right there!  You don't want them reviewing your betas.  Too risky even if
you think your game concept is so good it'll carry the day.

>Right now we're working on a version control system to uniquely tag
>every CD that leaves the building. That way at least we'll be able to
>track where the leak came from.


How can that help?  If pirates get wise that you're doing this, then 
they'll just erase the identifying information.  It's 
only if they don't realize that there's identifying information, that 
it would stay put from copy to copy.  What you suggest is 
yet-another-way to curb the problem, it doesn't stop the problem.

Also the piracy community is huge and some of it highly organized.   ;flattening :-) yet we
Check out http://www.fravia.org if you doubt.  The minute someone    ;have nothing to do with 
gets busted the 1st time on this "identifying information" stuff,    ;the 'piracy community'
the word is going to travel very fast and then the reverse engineers 
will work on methods to erase your identifying information.   	     ;true, yet you could at
					   			     ;least track the leak
									
Actually I have to admit, I find the struggle of piracy vs. 
anti-piracy to be more glamourous than the old virus vs. anti-virus 
struggle.  The former were assholes that made people's lives 
miserable, the latter were creeps with the sense of humor of the 
National Security Administration.  At least with piracy, it's somewhat 
like Monopoly money in a lot of instances, even if there are real 
dollars in there too.  Example of glamour: cracking someone's network 
site is generally considered rude-to-criminal behavior, depending on 
what you do once you get in.  But if you crack a pirate's warez 
site??!?  :-)  I think it would be a fun way to train one's cracking 	;I agree completely
skills, because you wouldn't have to feel any sympathy for the 		;would add commercial 
victims, and they wouldn't want to take you to court because of 	;porn-sites as well.
what you know about them.						;Hey!, there's no court
									;for web-sites busting
									;it's a free game!
A final comment, now that you know the true nature of my diabolical 
mind :-)
I sympathize (can't empathize, it hasn't happened to me yet) with game
developers whose work was ripped off.  But think back to when you were a
kid.  Did you have any warez?  Did you have a special disk that would just
copy anything?  If you did, well then just because you're an adult 
now you can't judge the kids too harshly.  And if you were never like that 
as a kid, all I can tell you is you missed out on a Rite De Passage that 
a lot of others of us have fond rememberances of.  Like toilet papering 
someone's house, going on a panty raid, or getting laid your first   ;well its' still like
time.								     ;getting laid even when
							             ;you do it as an adult :-)

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?

 
Re: The Economics of Piracy
message  Author: Nathan Mates 
Email:nathan@visi.com
Date:1998/09/17
Forums:comp.games.development.industry 
------------------------------------------------------------------------

In article <36018D8E.0@news.blarg.net>,
Brandon Van Every  wrote:
>>Right now we're working on a version control system to uniquely tag
>>every CD that leaves the building.  That way at least we'll be able to
>>track where the leak came from.

>How can that help?  If pirates get wise that you're doing this, then they'll
>just erase the identifying information.  It's only if they don't realize
>that there's identifying information, that it would stay put from copy to
>copy.  What you suggest is yet-another-way to curb the problem, it doesn't
>stop the problem.

   Level 1: a visible "BETA, NOT FOR RELEASE" stamp on an opening or
closing screen with a tag id# ("burn #75").

   Level 2: a different binary on every version released. If you're
doing no more than one burn per day, this is pretty trivial, as the
code *will* change daily during a project. Keep around every binary
you ever shipped out, and when something is stolen, match that binary
to your archived copies-- say the 9/17/98 build of beta test candidate
#8. If someone's able to mix and match functions out of >1 binary on
the fly, then they really should be working for you.

   Level 3: some datastreams in each binary that are randomized. 
All you need is a app_cuid.cpp which has a const unsigned char
appid1={0xde, 0xad, 0xbe, 0xef....}  or the like. Have a 
few of these things in the code, and change only one at a time (like 
an odometer or the like) and most people wouldn't know that data       ;a very clever idea
from the rest of your binary.

   Level 4: any ideas?

   Crooks won't know what method(s) you used until possibly *after* a
source is pinpointed and terminated. If you've only got a few possible
leak sources, then you might be able to get around many major leaks
for a project or two.

Nathan Mates
--

# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places? -R.A. Heinlein

Re: The Economics of Piracy
Author: Brandon Van Every
Email:vanevery@blarg.net
Date:1998/09/17
Forums:comp.games.development.industry 
------------------------------------------------------------------------

Nathan Mates wrote in message <1MGM1.454$Ge.1031913@ptah.visi.com>...
>
>   Level 1: a visible "BETA, NOT FOR RELEASE" stamp on an opening or
>closing screen with a tag id# ("burn #75").


Since the only purpose of this message is to intimidate, it should say
"BETA, NOT FOR RELEASE. Burn #75 issued to James Cameron of Industrial Death
And Mayhem on August 16, 1998."  Because you *are* going to release only 1
disk per person per company, right?

Hmm, what if some disgruntled worker at Industrial Death And Mayhem doesn't
like James Cameron, or his movie Titanic?  She steals the CD, burns a copy,
then sends it to some piracy ring for processing.  She quits the company,
nobody ever figures out her role.  James Cameron is screwed.  It places a
grave responsibility on him to guard the data, that's for sure!

>   Level 2: a different binary on every version released. If you're
>doing no more than one burn per day, this is pretty trivial, as the
>code *will* change daily during a project. Keep around every binary
>you ever shipped out, and when something is stolen, match that binary
>to your archived copies-- say the 9/17/98 build of beta test candidate
>#8. If someone's able to mix and match functions out of >1 binary on
>the fly, then they really should be working for you.


This works if you send 1 version per person per company, you're not sending
out many versions, and you're sending out versions on very different builds.
If  (N) builds are substantially similar, then a cracker could
hack/obfuscate your code, the obfuscated code will look substantially
similar to (N) different versions of code in your archive, and you won't
know which of (N) people to blame.  And of course if you send out more
versions, you increase (N) and there are more suspects.

For what purposes do you typically release CDs?  Why do these things need to
go out of the building, to let lotsa publishers know your current progress?
I see a problem in that you'll typically want to send out many of the same
CDs to different companies at the same time.  Like a Release Candidate.  If
you do this, then you've violated the uniqueness of the CDs.  And it doesn't
help to send a CD that's 99.9% the same and just change a variable.
Crackers can bust that sort of thing easily, and you won't know who to
blame.

If you're just sending CDs to your 1 publisher to keep them appraised of
your situation, then why isn't it their responsibility when *any* of the CDs
turn up pirated?

>   Level 3: some datastreams in each binary that are randomized. All
>you need is a app_cuid.cpp which has a const unsigned char
>appid1={0xde, 0xad, 0xbe, 0xef....}  or the like. Have a few of these
>things in the code, and change only one at a time (like an odometer or
>the like) and most people wouldn't know that data from the rest of
>your binary.


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.  But only as good as preventing someone from taking an unmarked
CD outside the building anyways.

Problem: let's say your secret data is a special triangle in your 3D  ;a very clever idea!
dataset.  You slightly change the value of the vertices at 
every release, and you scramble the datasets between each release enough 
so that no easy comparisons can be made, i.e. the triangle will never stick 
out like a sore thumb.  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   ;need a dedicated C
random amount.  Hey presto, your program still works!  Oh no! the      ;script for that... few
magic key is gone.						       ;reversers would do it.

Same basic drill as [2] above.  First the cracker has to figure out your
spaghetti, i.e. the program structure or data structures of your binary.
Then he has to devise an automated way to transform everything into a
slightly different usable value.  Crackerz are very good at the 1st    
stage already.  It's this new "transformation" stage which will be     ;correct, we need new
a challenge for them for awhile.  But given enough time, they'll come  ;automated scripts for
up with some methods.						       ;this kind of detection.

>   Level 4: any ideas?
>
>   Crooks won't know what method(s) you used until possibly *after* a
>source is pinpointed and terminated. If you've only got a few possible
>leak sources, then you might be able to get around many major leaks
>for a project or two.

Who are the usual sources of pre-release leaks, typically?


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?

Re: The Economics of Piracy
message  Author: Russ Williams 
Email:russ@algorithm.demon.co.uk
Date:1998/09/18
Forums:comp.games.development.industry view
------------------------------------------------------------------------

Brandon Van Every  wrote:
>Nathan Mates wrote:
[...]
>>   Level 3: some datastreams in each binary that
>>are randomized. All you need is a app_cuid.cpp which
>>has a const unsigned char appid1={0xde, 0xad, 0xbe,
>>0xef....}  or the like. Have a few of these things in the
>>code, and change only one at a time (like an odometer
>>or the like) and most people wouldn't know that data
>>from the rest of your binary.
>
>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.

[...]
>Problem: let's say your secret data is a special triangle
>in your 3D dataset.  You slightly change the value of the
>vertices at every release, and you scramble the
>datasets between each release enough so that no
>easy comparisons can be made, i.e. the triangle will
>never stick out like a sore thumb.

Very good plan. I doubt anyone would ever notice that
until it's too late.

>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. A simple CD check 
to fool the crackers into thinking they've found it and the  ;correct. They are getting
key hidden in the models/textures is likely to go	     ;at it. Let's prepare for
undetected. Steganography is perfect for anti-piracy         ;routined DOUBLE checking:
measures unless the pirates can get n versions of the	     ;maybe some of the next stupid
distribution - even then, they'd really have to be looking   ;protections will not be so
to detect 1k of differences on a full CD.  		     ;stupid after all (let's hope
							     ;they will not :-)
Of course, this is only going to work if the leak comes
from a magazine or publisher.

---
Russ

---

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

---

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