OT: Re: executable obfuscator?
OT: Re: executable obfuscator?
- Subject: OT: Re: executable obfuscator?
- From: "Andy O'Meara" <email@hidden>
- Date: Mon, 11 Dec 2006 13:39:23 -0500
That's a great article, Mike -- thanks for sharing that. Our data
definitely checks with that.
I forgot to share one of the biggest methods that's helped us
completely shutdown this 'casual piracy'. We have two dists: the
free trial version of our software and the paid version. A user can
only get their hands on a paid version of our software by paying
money and getting a license code issued. The process goes like this,
and I recommend it to all shareware devs that make end-user software:
1) Users visit our site and download the free trial version of our
software. The free trial version is a *different* build than the
paid version (complete with #if's in the code), so there's absolutely
nothing to hack or crack -- the paid-only features just aren't there.
2) If a user likes the software, they follow one of the links in the
free trial version to our site and pay for it on our site.
3) When a user pays, they're issued a license code (which is really
just their name and the current date encrypted along with a
checksum). This license code is added to our db.
4) The user enters their license code into our download page so they
can download their asset. This system lets us easily deny access to
compromised license codes and also lets accumulate tons of data (e.g.
how often pirated codes are attempted, how often users download, and
who's active). So even if a keygen was ever made, generated license
codes would be not be allowed access to the assets (b/c they're not
in our db). Our back-end automatically shuts off a license code if
it's been accessed more than a certain number of times in a given
time period.
5) The user downloads their asset and must enter their license code
upon installation.
6) Each time our software starts, the splash screen shows their name
(retrieved from the license code) and says, "Licensed to: John Doe".
This deters users from passing their license code to anyone else.
This scheme also gives users the freedom to backup their license code
and their asset for subsequent installation.
Basically, the only way users are able to pirate with the above
system in place is to distribute the paid asset with a valid license
code (and there's not much you can do about that). But, we do have a
passive blacklist that gets updated if/when the software checks for
updates, so even p2p-style piracy is partially curbed. This is all
in theory b/c the last version of our software that we saw in the p2p
wild is almost two years old (which is before we put in passive
blacklisting).
Is the back-end infrastructure required to pull this off a chunk of
work? Of course, but the data you get out of it (piracy and non-
piracy related) is very valuable. We're able to better track
traffic, user behavior, user response to sales and special offers,
and offer better customer support. Also, if $BLUE_CHIP_COMPANY ever
knocks on your door to talk about your software, you have a lot of
stats to leverage. Well, we can all dream, can't we?? :^)
The OT gods are probably about to strike me down so I'll give it a
rest for now...
On Dec 11, 2006, at 12:07 PM, Mike Blaguszewski wrote:
I don't think you need to go so far as to encrypt the
whole .strings file. There's probably only a few strings that are
directly tied to your anti-piracy code, and for these you can either:
1. Load them ahead of time and cache them someplace
2. Store the literal string encrypted somewhere, decrypt it a
runtime, and then pass it to NSLocalizedString() or the Carbon
equivalent. This means genstrings won't handle it, but that only
impacts you, not the localizers.
3. When possible, keep the strings in nibs (though this may be more
susceptible to runtime analysis).
Also remember that we're talking obfuscation, not real encryption.
XOR or similar is probably fine.
Finally, though it's a bit off-topic for xcode-users, I did want to
mention that one of my coworkers has written a very good essay on
shareware piracy:
"The Plain Truth About Piracy"
<http://www.ambrosiasw.com/news/old_newsletter.php?id=34059>
An excerpt:
And for the last 2 days, starting right after we posted the latest
update to Snapz Pro X, our server has been very busy. Out of the
194 different hosts that tried to renew a license code, 107 of
them sent in pirated codes. Incredibly, more than 50% of the
people installing the update are entering one or both of the
pirated codes we've known about for months. Some of these people
even tried several different variants on the names when the server
refused them access ("maybe I misspelled it"), and one guy got so
frustrated he pounded the Renew button over and over every 4
seconds ("WHY click IS click THIS click NOT click WORKING???")
until our server blacklisted him for flooding.
--
Mike Blaguszewski / Cocoa Hacker / Ambrosia Software, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40soundspectrum.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden