Re: OT: Re: executable obfuscator?
Re: OT: Re: executable obfuscator?
- Subject: Re: OT: Re: executable obfuscator?
- From: Brian Mitchell <email@hidden>
- Date: Mon, 11 Dec 2006 14:24:27 -0500
One improvement I might suggest is that when they pay, a link to the
software is created that is watermarked with their license
information. I know one way that's been used in the past on x86 is
making use of instructions encodings that are equivalent but have
different bytes (mod r/m encoding fields come to mind). This lets you
track the leaked executable down to the licensee who leaked it.
On Dec 11, 2006, at 1:39 PM, Andy O'Meara wrote:
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...
_______________________________________________
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