by date
Is your asset worth it?
Is your asset worth it?
| Name: | Neo Binedell |  |
|---|---|---|
| Date Posted: | Apr 03, 2006 | |
| Rating: |  3.5 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Neo Binedell |
Blog post
I've been seeing a lot of big talk in the forums about the fact that asset
protection is futile, etc, as crackers can just do this or that. Usually followed
by some example that the poster probably thinks makes him look like a
l33t cracker.
Look everyone knows its possible to steal assets by ripping from mem,
cracking, etc. What you should be concerned with is what is probable.
You have to choose a level of protection that falls on the appropriate point
on the curve of diminishing returns.
For example one of the simplest things you can do is add a few bytes at the
beginning of image files and just gunk those bytes before reading the stream
with the image libs. Most graphics apps will look at the header stored at the
beginning of a file and if the signature does not match a known header it will
think it is corrupt.
This is sufficient for a large part of your audience as they will try and open the
file and fail and not bother to go further.
Other apps however will scan the whole file looking for a known header and thus the
start of the stream, so if youre concerned about that you add simple encryption
like XOR or what not.
As soon as you get to that level youre moving into an higher level of expertise
required to view the assets, i.e. dev guys. They will have to make a commitment
to crack that asset (which is not THAT much work) but you have to weigh that
against the gains they perceive from having to actually do it.
Finding an unencrypted password in the exe is not that hard, you just dump the string
table and look for it. So if thats an issue for you then you mask or build the password,
(or a ton of other solutions).
Even having the password is not enough as you would have to know which algo was
used, what kind of salting and with what values, etc, then implement that either by using
libraries available or writing your own.
So the law of diminishing returns apply both to you the dev (as you have to do more
and more work to thwart a smaller and smaller probability set) and the cracker/thief
who will have to do the same but based on his perception of value.
For you it is your assets and for a limited product range and so more valuable where
as for the cracker it is a miniscule percentage of assets out there and so of lower value.
Obviously you have to weight this with things like popularity, etc but what asset could
be that valuable; surely you're not storing cc numbers? right?
So if you are going to encrypt at least do it with something like twofish or aes with
custom stream code and salting, etc instead of standard zip as those could just be dumped
out again with publically available zip readers. Encrypt per file and THEN add to zip file system, so
when reading you would stream the asset from the archive, unencrypting as you read it.
~neo
protection is futile, etc, as crackers can just do this or that. Usually followed
by some example that the poster probably thinks makes him look like a
l33t cracker.
Look everyone knows its possible to steal assets by ripping from mem,
cracking, etc. What you should be concerned with is what is probable.
You have to choose a level of protection that falls on the appropriate point
on the curve of diminishing returns.
For example one of the simplest things you can do is add a few bytes at the
beginning of image files and just gunk those bytes before reading the stream
with the image libs. Most graphics apps will look at the header stored at the
beginning of a file and if the signature does not match a known header it will
think it is corrupt.
This is sufficient for a large part of your audience as they will try and open the
file and fail and not bother to go further.
Other apps however will scan the whole file looking for a known header and thus the
start of the stream, so if youre concerned about that you add simple encryption
like XOR or what not.
As soon as you get to that level youre moving into an higher level of expertise
required to view the assets, i.e. dev guys. They will have to make a commitment
to crack that asset (which is not THAT much work) but you have to weigh that
against the gains they perceive from having to actually do it.
Finding an unencrypted password in the exe is not that hard, you just dump the string
table and look for it. So if thats an issue for you then you mask or build the password,
(or a ton of other solutions).
Even having the password is not enough as you would have to know which algo was
used, what kind of salting and with what values, etc, then implement that either by using
libraries available or writing your own.
So the law of diminishing returns apply both to you the dev (as you have to do more
and more work to thwart a smaller and smaller probability set) and the cracker/thief
who will have to do the same but based on his perception of value.
For you it is your assets and for a limited product range and so more valuable where
as for the cracker it is a miniscule percentage of assets out there and so of lower value.
Obviously you have to weight this with things like popularity, etc but what asset could
be that valuable; surely you're not storing cc numbers? right?
So if you are going to encrypt at least do it with something like twofish or aes with
custom stream code and salting, etc instead of standard zip as those could just be dumped
out again with publically available zip readers. Encrypt per file and THEN add to zip file system, so
when reading you would stream the asset from the archive, unencrypting as you read it.
~neo
Recent Blog Posts
| List: | 03/05/08 - Iso-phagus 11/12/07 - Theora Video Seek, Loop And Callback Support 06/17/07 - FX Composer 2 - Public Beta Released 04/27/07 - TGB Isometric Add-On Pack - Part 6: nxAnimator! 02/20/07 - TGB Isometric Add-On Pack - Part 5 11/23/06 - TGB Isometric Add-On Pack - Part 4 08/16/06 - TGB Isometric Add-On Pack - Part 3 06/14/06 - TGB Isometric Add-On Pack - Part 2 - Cont. |
|---|
Submit your own resources!| Harold "LabRat" Brown (Apr 03, 2006 at 20:10 GMT) |
glintercept.nutty.org/
ogle.eyebeamresearch.org/
Hell... Tribes used a custom graphics format... and it didn't stop us from writing extractors and converters to get to the images (I spent well over 2 months with a Hex Editor reverse engineering the .VOL format, the .PBMP format, etc.)
Edited on Apr 03, 2006 20:15 GMT
| Neo Binedell (Apr 03, 2006 at 20:18 GMT) |
Any dev guy worth his salt should be able to lift assets from in memory at runtime,
OGL or no OGL, so I take it you didn't get what i was saying at all...
~neo
| Phil Carlisle (Apr 03, 2006 at 20:26 GMT) |
Frankly, just putting assets into a zipfile which has a password is about as cagey as I would care to get.
| Neo Binedell (Apr 03, 2006 at 20:30 GMT) |
~neo
| Ben Garney (Apr 03, 2006 at 21:06 GMT) |
Proprietary hardware platforms are good for this sort of thing, too.
| Allyn "Mr_Bloodworth" Mcelrath (Apr 03, 2006 at 22:19 GMT) |
i persionaly would like a way to deter the avrage users... am i going to make a supper secure living ...thingy to deter the L3et? nope...
| Jason Swearingen (Apr 03, 2006 at 23:11 GMT) |
It is a very interesting dillema, and generally speaking, you shouldnt bother trying a 'roll your own' method. spend the $300 for a nice anti-hacking tool, and call that good enough. if you are working on an online game (where you charge money or it is popular) then additional steps should be taken so the 1% hackers dont spoil the game for everyone else... but otherwise, dont worry about it right. It would actually be AWESOME for you if someone steals your stuff.. cuz then you can have a bling-bling lawsuit on your hands.
| Ben Curley (Apr 04, 2006 at 22:43 GMT) |
Do enough to stop casual dabblers and no more, IMHO it is wasted development time that could be put to better use.
* Edited for my abysmal spelling! *
Edited on Apr 04, 2006 23:20 GMT
| Michael Woerister (May 25, 2006 at 18:36 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
