Securing Software

Hey Crypto Gurus,
I've been working on some new software for Windows 7.  I've always, 
prior to now, given my software away.  I've decided that I want to start 
charging $0.99 for my new software.  I'm debating on how to implement 
this...
I was thinking of doing a shareware type model, free to try for 30 days, 
then you must buy.  My problem is that I'm not sure the best way to:
A) Enforce the trial period...  Is this usually done in the registry?  
Couldn't I just "fudge" the date if I didn't want to pay...  Should the 
date of install be encrypted somehow to prevent tampering?  If the data 
got "munged" by the user, it would become unenforceable...
B) How to implement the registration keys...  This I'm not sure the best 
way to do either...  I DO NOT want my software phoning home, so I need 
an algorithm that will be able to process a name and data and then 
verify a registry key...  But how?  I was thinking some kind of private-
public key system...  I'm really not sure.  I want the registration to 
be tied ideally to your name and email address...  At least if some 
asshole makes it available he'll get a buttload of spam...
I know this is essentially a crypto question, so I'm hoping you guys 
might have some good thoughts...  I can do the programming, I'm just not 
sure the best way to implement my desires =)
The code is all assembler, thanks to Steve's influence; I would have no 
problem developing my own libraries to implement whatever clever 
thoughts you guys have.
Thanks in advance,
-- 
Jake
    http://www.nymtec.com
0
Jacob
5/12/2010 7:45:27 PM
📁 grc.techtalk.cryptography
📃 876 articles.
⭐ 0 followers.

💬 10 Replies
👁️‍🗨️ 1094 Views


On 05/12/2010 01:45 PM, Jacob Janzen wrote:
>
> Hey Crypto Gurus,
>
> I've been working on some new software for Windows 7.  I've always,
> prior to now, given my software away.  I've decided that I want to start
> charging $0.99 for my new software.  I'm debating on how to implement
> this...
I like your price :)
>
> I was thinking of doing a shareware type model, free to try for 30 days,
> then you must buy.  My problem is that I'm not sure the best way to:
>
I like the way Steve does it, make them pay to get the software, then if 
they don't like it they get their money back.
> A) Enforce the trial period...  Is this usually done in the registry?
> Couldn't I just "fudge" the date if I didn't want to pay...  Should the
> date of install be encrypted somehow to prevent tampering?  If the data
> got "munged" by the user, it would become unenforceable...
You could encrypt the date with a private key, then destroy the private 
key, and decrypt the date with the public key to check if the trial has 
expired. That would work, but it would be easy for someone to replace 
the public key with their own public key and create a fake date with 
their own private key.
>
> B) How to implement the registration keys...  This I'm not sure the best
> way to do either...  I DO NOT want my software phoning home, so I need
> an algorithm that will be able to process a name and data and then
> verify a registry key...  But how?  I was thinking some kind of private-
> public key system...  I'm really not sure.  I want the registration to
> be tied ideally to your name and email address...  At least if some
> asshole makes it available he'll get a buttload of spam...
>
You're right, the best way to do this would be to have a server encrypt 
their name and email address with a private key when the software is 
purchased, the ciphertext of this encryption would be the registration 
key. Then, your software would have the public key, would try to decrypt 
the ciphertext, and if it matches, you know that it is a valid license. 
The problems with this are that someone could change the public key in 
the software to a public key matching his own private key. Also, one 
name/email/key combination would be able to be used an infinite number 
of times. I can't see a way of preventing that unless your software 
phones home.
> I know this is essentially a crypto question, so I'm hoping you guys
> might have some good thoughts...  I can do the programming, I'm just not
> sure the best way to implement my desires =)
>
> The code is all assembler, thanks to Steve's influence; I would have no
> problem developing my own libraries to implement whatever clever
> thoughts you guys have.
>
> Thanks in advance,
>
Protecting software from piracy IS impossible. No matter what you do, 
someone skilled at reverse engineering and assembly programming will be 
able to crack your application. That's why I like Steve's system the 
best, it avoids the hassle of software registration, and he still makes 
money off of it. I'm not saying don't make shareware, if your software 
isn't that valuable ($0.99 isn't) crackers won't see a point in doing 
all the reverse engineering work required to crack it.
0
FireXware
5/12/2010 9:56:06 PM
On 05/12/2010 03:56 PM, FireXware wrote:
>
> Protecting software from piracy IS impossible. No matter what you do,
> someone skilled at reverse engineering and assembly programming will be
> able to crack your application.
I've been thinking about this, and I think it would be a good idea to 
make a system for doing exactly what you want to do. It would be 
something that a lot of developers would use and even pay for. It 
wouldn't be possible to make it completely secure, but it would be 
possible with a bit of work to make a 'worst case scenario' for 
crackers. If it's well designed with cryptography backing up it's 
security I can see it being hard to circumvent. I'm thinking something 
along the lines of phoning home then hardware locking once it's activated.
0
FireXware
5/13/2010 4:19:25 AM
On 12/05/2010 20:45, Jacob Janzen wrote:
>
> Hey Crypto Gurus,
>
> I've been working on some new software for Windows 7.  I've always,
> prior to now, given my software away.  I've decided that I want to start
> charging $0.99 for my new software.  I'm debating on how to implement
> this...
>
> I was thinking of doing a shareware type model, free to try for 30 days,
> then you must buy.  My problem is that I'm not sure the best way to:
>
> A) Enforce the trial period...  Is this usually done in the registry?
> Couldn't I just "fudge" the date if I didn't want to pay...  Should the
> date of install be encrypted somehow to prevent tampering?  If the data
> got "munged" by the user, it would become unenforceable...
Protect the date, but do it in a fairly crude manner - it isn't really 
an issue. any hacker skilled enough to reverse engineer even a simple 
sequentially-increasing xor would just nop out the test. also include a 
hard cut-off date in the binary, set (for example) one year in the 
future, beyond which a trial tells you to go find a newer one.
> B) How to implement the registration keys...  This I'm not sure the best
> way to do either...  I DO NOT want my software phoning home, so I need
> an algorithm that will be able to process a name and data and then
> verify a registry key...  But how?  I was thinking some kind of private-
> public key system...  I'm really not sure.  I want the registration to
> be tied ideally to your name and email address...  At least if some
> asshole makes it available he'll get a buttload of spam...
Depends on if you are concerned about reverse engineering - which for $1 
you probably aren't going to get many attackers.
simple solution is just to append a fixed string (name and version of 
the binary?) to the email address of the user, hash it, then use a 
mapping to a printable ascii set (usually 64 entries, so you encode the 
hash 6 bits at a time)
if the binary is small enough, just email them a (fully working) one 
when they register; embedding their email address at fixed offsets in 
the code (and adding code in the binary to check those against a hash at 
a further location) will keep them honest.
This is my preferred form of DRM btw - an invisible watermark with the 
email address (or better yet, CC details) of the buyer. No effect no 
playback, but they are *not* going to want to post it on pirate bay :)
> I know this is essentially a crypto question, so I'm hoping you guys
> might have some good thoughts...  I can do the programming, I'm just not
> sure the best way to implement my desires =)
for $1, there is no point putting too much effort into it. for $100 or 
$1K, you could, but effort is proportionate to reward and no hacker is 
going to bother cracking your protection for $1.
> The code is all assembler, thanks to Steve's influence; I would have no
> problem developing my own libraries to implement whatever clever
> thoughts you guys have.
0
Dave
5/13/2010 9:17:23 AM
In article <hsfuk3$2f5r$1@news.grc.com>, no@no.com says...
> 
> On 05/12/2010 03:56 PM, FireXware wrote:
> 
> >
> > Protecting software from piracy IS impossible. No matter what you do,
> > someone skilled at reverse engineering and assembly programming will be
> > able to crack your application.
> 
> I've been thinking about this, and I think it would be a good idea to 
> make a system for doing exactly what you want to do. It would be 
> something that a lot of developers would use and even pay for. It 
> wouldn't be possible to make it completely secure, but it would be 
> possible with a bit of work to make a 'worst case scenario' for 
> crackers. If it's well designed with cryptography backing up it's 
> security I can see it being hard to circumvent. I'm thinking something 
> along the lines of phoning home then hardware locking once it's activated.
Interesting idea.
I could certainly do that...  In fact, I think I will =P
I'm going to start designing this, and come up with an implementation 
document, perhaps you wouldn't mind taking a look when I have it done?
Thanks!
-- 
Jake
    http://www.nymtec.com
0
Jacob
5/13/2010 3:57:32 PM
In article <hsgg2o$2sqc$1@news.grc.com>, DaveHowe@Undesclosed.xxx 
says...
> 
> On 12/05/2010 20:45, Jacob Janzen wrote:
> >
> > Hey Crypto Gurus,
> >
> > I've been working on some new software for Windows 7.  I've always,
> > prior to now, given my software away.  I've decided that I want to start
> > charging $0.99 for my new software.  I'm debating on how to implement
> > this...
> >
> > I was thinking of doing a shareware type model, free to try for 30 days,
> > then you must buy.  My problem is that I'm not sure the best way to:
> >
> > A) Enforce the trial period...  Is this usually done in the registry?
> > Couldn't I just "fudge" the date if I didn't want to pay...  Should the
> > date of install be encrypted somehow to prevent tampering?  If the data
> > got "munged" by the user, it would become unenforceable...
> 
> Protect the date, but do it in a fairly crude manner - it isn't really 
> an issue. any hacker skilled enough to reverse engineer even a simple 
> sequentially-increasing xor would just nop out the test. also include a 
> hard cut-off date in the binary, set (for example) one year in the 
> future, beyond which a trial tells you to go find a newer one.
Sounds reasonable.
> 
> > B) How to implement the registration keys...  This I'm not sure the best
> > way to do either...  I DO NOT want my software phoning home, so I need
> > an algorithm that will be able to process a name and data and then
> > verify a registry key...  But how?  I was thinking some kind of private-
> > public key system...  I'm really not sure.  I want the registration to
> > be tied ideally to your name and email address...  At least if some
> > asshole makes it available he'll get a buttload of spam...
> 
> Depends on if you are concerned about reverse engineering - which for $1 
> you probably aren't going to get many attackers.
> 
> simple solution is just to append a fixed string (name and version of 
> the binary?) to the email address of the user, hash it, then use a 
> mapping to a printable ascii set (usually 64 entries, so you encode the 
> hash 6 bits at a time)
> 
> if the binary is small enough, just email them a (fully working) one 
> when they register; embedding their email address at fixed offsets in 
> the code (and adding code in the binary to check those against a hash at 
> a further location) will keep them honest.
> 
> This is my preferred form of DRM btw - an invisible watermark with the 
> email address (or better yet, CC details) of the buyer. No effect no 
> playback, but they are *not* going to want to post it on pirate bay :)
> 
I really like that idea!  Only catch is, do you think people will flip 
when they see that I've included their credit card details?  I can do it 
all "automagically" in php when I get the return from PayPal, so I'll 
never see or store it...  Perhaps it would suffice to let the user know 
beforehand?
> > I know this is essentially a crypto question, so I'm hoping you guys
> > might have some good thoughts...  I can do the programming, I'm just not
> > sure the best way to implement my desires =)
> 
> for $1, there is no point putting too much effort into it. for $100 or 
> $1K, you could, but effort is proportionate to reward and no hacker is 
> going to bother cracking your protection for $1.
> 
Very true...  I'm just trying to cover the costs to distribute the 
software, it's not like I'll be making any real money, considering all 
the hours I've put into the project.
> > The code is all assembler, thanks to Steve's influence; I would have no
> > problem developing my own libraries to implement whatever clever
> > thoughts you guys have.
Thanks for your comments!

-- 
Jake
    http://www.nymtec.com
0
Jacob
5/13/2010 4:01:42 PM
On 05/13/2010 03:17 AM, Dave Howe wrote:
> On 12/05/2010 20:45, Jacob Janzen wrote:
>>
>> Hey Crypto Gurus,
>>
>> I've been working on some new software for Windows 7. I've always,
>> prior to now, given my software away. I've decided that I want to start
>> charging $0.99 for my new software. I'm debating on how to implement
>> this...
>>
>> I was thinking of doing a shareware type model, free to try for 30 days,
>> then you must buy. My problem is that I'm not sure the best way to:
>>
>> A) Enforce the trial period... Is this usually done in the registry?
>> Couldn't I just "fudge" the date if I didn't want to pay... Should the
>> date of install be encrypted somehow to prevent tampering? If the data
>> got "munged" by the user, it would become unenforceable...
>
> Protect the date, but do it in a fairly crude manner - it isn't really
> an issue. any hacker skilled enough to reverse engineer even a simple
> sequentially-increasing xor would just nop out the test. also include a
> hard cut-off date in the binary, set (for example) one year in the
> future, beyond which a trial tells you to go find a newer one.
That's true but if you really wanted to you could encrypt the binary its 
self, only decrypt it if the registration key and date are correct, and 
use RunPE to run the exe. That would be possible but RunPE but then 
antiviruses would detect it as a crypter.
>
>> B) How to implement the registration keys... This I'm not sure the best
>> way to do either... I DO NOT want my software phoning home, so I need
>> an algorithm that will be able to process a name and data and then
>> verify a registry key... But how? I was thinking some kind of private-
>> public key system... I'm really not sure. I want the registration to
>> be tied ideally to your name and email address... At least if some
>> asshole makes it available he'll get a buttload of spam...
>
> Depends on if you are concerned about reverse engineering - which for $1
> you probably aren't going to get many attackers.
>
> simple solution is just to append a fixed string (name and version of
> the binary?) to the email address of the user, hash it, then use a
> mapping to a printable ascii set (usually 64 entries, so you encode the
> hash 6 bits at a time)
Then the cracker could easily make a keygen.He would just have to make 
another application that takes the username and email address and hashes 
it with the same algorithm. Public/Private keys is overkill but then 
they would at least have to modify the binary to make it work.
>
> if the binary is small enough, just email them a (fully working) one
> when they register; embedding their email address at fixed offsets in
> the code (and adding code in the binary to check those against a hash at
> a further location) will keep them honest.
>
> This is my preferred form of DRM btw - an invisible watermark with the
> email address (or better yet, CC details) of the buyer. No effect no
> playback, but they are *not* going to want to post it on pirate bay :)
I wouldn't say that's going to stop them, because they could just buy it 
with fake information. Personally, I wouldn't use something that had my 
credit card number in it. They could use a stolen credit card, or change 
their own credit card after buying it. We should be trying to deter them 
from being able to crack it, not deter them from spreading the crack.
>
>> I know this is essentially a crypto question, so I'm hoping you guys
>> might have some good thoughts... I can do the programming, I'm just not
>> sure the best way to implement my desires =)
>
> for $1, there is no point putting too much effort into it. for $100 or
> $1K, you could, but effort is proportionate to reward and no hacker is
> going to bother cracking your protection for $1.
>
>> The code is all assembler, thanks to Steve's influence; I would have no
>> problem developing my own libraries to implement whatever clever
>> thoughts you guys have.
0
FireXware
5/13/2010 6:51:17 PM
On 13/05/2010 17:01, Jacob Janzen wrote:
> I really like that idea!  Only catch is, do you think people will flip
> when they see that I've included their credit card details?  I can do it
> all "automagically" in php when I get the return from PayPal, so I'll
> never see or store it...  Perhaps it would suffice to let the user know
> beforehand?
I would steer clear of including CC details, unless redacted - you are 
opening yourself to a world of hurt from banking law. If you can get the 
user's name and registered address from the CC data (some merchants 
provide this, to verify delivery is to the registered address) and embed 
that, then you will get all the deterrent effects without opening up the 
can of worms that is storing a user's CC without permission.
The problem with including the email address is that 99% of users 
(legitimate or not) will use some sort of freemail anyhow. Glod knows I 
use GMail for everything now, and generating a throwaway would not even 
be a roadbump.
0
Dave
5/17/2010 3:37:27 PM
On 13/05/2010 19:51, FireXware wrote:
> That's true but if you really wanted to you could encrypt the binary its
> self, only decrypt it if the registration key and date are correct, and
> use RunPE to run the exe. That would be possible but RunPE but then
> antiviruses would detect it as a crypter.
Problem there is the shareware model - if you allow 30 days trial, a 
hacker will just make that an infinite trial and use your existing 
mechanism to decrypt from there.
>> simple solution is just to append a fixed string (name and version of
>> the binary?) to the email address of the user, hash it, then use a
>> mapping to a printable ascii set (usually 64 entries, so you encode the
>> hash 6 bits at a time)
> Then the cracker could easily make a keygen.He would just have to make
> another application that takes the username and email address and hashes
> it with the same algorithm. Public/Private keys is overkill but then
> they would at least have to modify the binary to make it work.
Indeed so; however, anyone who can reverse engineer the hash could 
trivially invert the final test (so only a valid key will *not* be 
accepted) and ditto a pki test. Anything that can be defeated with a 
*one byte* patchout is not going to be worth faking up a keygen for.
> I wouldn't say that's going to stop them, because they could just buy it
> with fake information. Personally, I wouldn't use something that had my
> credit card number in it. They could use a stolen credit card, or change
> their own credit card after buying it. We should be trying to deter them
> from being able to crack it, not deter them from spreading the crack.
Its not going to happen, seriously. always bear in mind that protection 
is to keep mostly honest people honest, not lock out skilled attackers.
as a rule of thumb - for each man-day you spend implementing *effective* 
software protection (and you will be surprised at how few hours actually 
add to the protection) you will add one *hour* to the time a skilled 
hacker will take to crack and/or keygen the app. However, if it is cheap 
enough, and especially given the current situation (where most keygens 
are trojaned, either at source or via silkrope when being redistributed 
via edonkey2k/piratebay) most users will cough up for a legitimate copy. 
The ones they tend to risk keygens for tend to be big ticket packages 
like CS3.

0
Dave
5/18/2010 8:01:59 AM
In article <hsrnrc$i86$1@news.grc.com>, DaveHowe@Undesclosed.xxx says...
> 
> On 13/05/2010 17:01, Jacob Janzen wrote:
> > I really like that idea!  Only catch is, do you think people will flip
> > when they see that I've included their credit card details?  I can do it
> > all "automagically" in php when I get the return from PayPal, so I'll
> > never see or store it...  Perhaps it would suffice to let the user know
> > beforehand?
> 
> I would steer clear of including CC details, unless redacted - you are 
> opening yourself to a world of hurt from banking law. If you can get the 
> user's name and registered address from the CC data (some merchants 
> provide this, to verify delivery is to the registered address) and embed 
> that, then you will get all the deterrent effects without opening up the 
> can of worms that is storing a user's CC without permission.
> 
I would never include any of the actual CC details other than perhaps 
With card ending 'XXXX'...
Never the number/security code/expiration, just the address.
> The problem with including the email address is that 99% of users 
> (legitimate or not) will use some sort of freemail anyhow. Glod knows I 
> use GMail for everything now, and generating a throwaway would not even 
> be a roadbump.
Good point, thanks.

-- 
Jake
    http://www.nymtec.com
0
Jacob
5/19/2010 5:42:03 PM
On 05/19/2010 11:42 AM, Jacob Janzen wrote:
> In article<hsrnrc$i86$1@news.grc.com>, DaveHowe@Undesclosed.xxx says...
>>
>> On 13/05/2010 17:01, Jacob Janzen wrote:
>>> I really like that idea!  Only catch is, do you think people will flip
>>> when they see that I've included their credit card details?  I can do it
>>> all "automagically" in php when I get the return from PayPal, so I'll
>>> never see or store it...  Perhaps it would suffice to let the user know
>>> beforehand?
>>
>> I would steer clear of including CC details, unless redacted - you are
>> opening yourself to a world of hurt from banking law. If you can get the
>> user's name and registered address from the CC data (some merchants
>> provide this, to verify delivery is to the registered address) and embed
>> that, then you will get all the deterrent effects without opening up the
>> can of worms that is storing a user's CC without permission.
>>
>
> I would never include any of the actual CC details other than perhaps
> With card ending 'XXXX'...
>
> Never the number/security code/expiration, just the address.
Another way to make sure they can't share it is to use a hardware id to 
create the encryption key. The hardware id can be generated from hard 
drive serial numbers etc.. I beleive that windowsblinds uses hardware 
ids but im not sure. The only problem with that is if they ever changed 
hardware they would have to re-download or maybe just enter their 
license info and it will re-encrypt with the new hardware ID.
>
>> The problem with including the email address is that 99% of users
>> (legitimate or not) will use some sort of freemail anyhow. Glod knows I
>> use GMail for everything now, and generating a throwaway would not even
>> be a roadbump.
>
> Good point, thanks.
>
>

0
FireXware
5/20/2010 12:06:51 AM
Reply: