Re: Protecting Software w/ Software License -- a modest
Re: Protecting Software w/ Software License -- a modest
- Subject: Re: Protecting Software w/ Software License -- a modest
- From: Kirk Kerekes <email@hidden>
- Date: Wed, 19 Jun 2002 12:13:50 -0500
Am Mittwoch den, 19. Juni 2002, um 01:36, schrieb Kirk Kerekes:
File sharing systems like LimeWire that will download a file via
multiple parallel streams from different sources are just about
guaranteed to download unusable kracker-krap when multiple differing
version of the same file appear to be identical.
Umm. They are starting to use file hashes to uniquely identify files.
That will probably break this part of your scheme since the crackers may
publish hashes for working versions on their web sites.
Could be ... but that just increases the hassle-factor of using stolen
software. You have to know the website, you have to go there, you have to
have a hash-verifier of some kind that uses the correct algorithm.
And you can't verify that you are looking at a "good" copy without
downloading it.
-- and, of course, any attempt to distribute the hash inside the
distribution is corruptable (because the hash has to be external to the
hashed part of the distribution).
And even if the file-sharing services adopt a scheme which recognizes a
file-item with a hash in the filename, and actually verifies the item
against the hash, (which would be an interesting and difficult trick, given
that the recent file-sharing services do not store the file -- just arrange
for its transmission between users) the would-be thief still has to verify
the hash against some sort of master-list from an unverifiable (anonymous)
source... and of course, it is entirely possible that the "source" could
be poisoned also. Hassle, confusion, uncertainty.
Implicit in this scheme is the creation of fake krackers, and the
impersonation of real ones, including the creation of poisoned kracker
websites, and the posting of poisoned serial-numbers to appropriate
newsgroups, using the "names" of "trusted" krack-posters. Habitues of
kracker newsgroups tend to post via anonymizing methods, which makes them
highly vulnerable to having their identities hijacked.
Once again -- using the tools of the thief (anonymity and zero-cost
distribution) against them.
Confusion and uncertainty (among would-be thieves) is the goal, and they
are fairly easy to encourage, the increase of entropy being the natural
order of things.
All of this works to lower the perceived value of a stolen serial-number.
And I don't think, bad serial numbers will get into collections like
"surfer's serials".
If the software uses a delayed response to a "pirate" serial number
(requiring a random number of starts and/or a random interval of use before
reacting) they likely will end up on that list via "legit" means. Random
delayed response makes testing uncertain, once again decreasing the
perceived value of the stolen serial#.
And "Surfer's Serials" appears to be totally unprotected -- easily poisoned.
The actual data is stored uncompressed, unencrypted and unhashed.
It appears that the reader makes no attempt to verify the validity of the
data file. (I just altered a copy of SS and viewed it without difficulty in
the Jan-02 OSX version of the distributed reader).
And while it would be comparatively trivial to add hashing to to the
various permutations of the SS app, that is subject to the same
value-diluting limitations mentioned above. And it puts the krackers on
the defensive for a change. Let _them_ fight the tech-war for a while!
And if a rumor happened to start that there was a "trick" version of SS out
there that reported user information to a mysterious central server when
the SS app was run... or that there was a version of SS that was infected
with a new virus...
My core point is that the krackers are _vulnerable_, primarily due to their
anonymity. Legit developers distribute software via verifiable and trusted
channels, while krackers cannot.
We can use that fact.
But then again - just try it anyway. :)
bye. Andreas.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.