Prevent Reinstallation 6

[AkutaSame]

I was just wondering if someone could share with me a method (other than putting a simple key into the registry, which can be deleted/removed) to prevent a demo software from being reinstalled.

Ex.
Someone downloads my demo software (hypothetical, the software isn't done) which has a time limit on it set to expire after 15 days. After the expiration, I want to make it so the person can't just uninstall the program and reinstall it for another 15 day trial. I know there are people out there who will even scour the registry for the product and remove all entries.

Is the only solution a hidden registry key with a name and value that have NOTHING to do with the program?

 

[BBaggins]

In my opinion, it is irresponsible for us to go around dropping mystery keys into people's registries that never get cleaned up. Bad idea.

Here's a suggestion. You give the user a key which has the expiration date encrypted into it. On first run you save the key so they don't have to type it in every time. Include a checksum in the key string, so it won't work if it's been modified.

They can reinstall all they want, but unless they can reverse engineer your encryption scheme and manufacture a valid key with a new expiration date, it won't do them any good.

 

[AkutaSame]

BB, have you ever been in an arguement, then 15 minutes later tell yourself, "DAMNIT, I should have said THIS!" Well, that's pretty much what this has turned into. These people probably will never drop registry keys into someone's computer and not clean them up. I want to note something for you here in your statement though.

[clipped]
"They can reinstall all they want, but unless they can reverse engineer your encryption scheme and manufacture a valid key with a new expiration date, it won't do them any good."
[/clipped]

Ok, now this is not efficient. It is possible to use date-encrypted keys for demo software; however, if they purchase the full software? We then have a problem. Are we going to provide a key that allows "no expiration date" to everyone? Most activation keys are keys created using a single algorythm. You would have to hand-check EVERY key that came in if you did it the route you are speaking of. And if we, say, set up a key generation algorythm that uses the date. Ok, that's fine. Now, someone purchases the full software. We now have another key, which would have to be the SAME for everyone in order to bypass the activation (some portion of the key would have to be similar in each of the full version keys in order to bypass the date/time check). Doing as such would end up taking more time to peruse through the keys than it would to just place a file or something onto their computer. (Sorry, the .Net 2003 release in my area was yesterday... I'm still a bit tired from the 3 hr drive, 8 hr release, 3 hr drive back).

You say we shouldn't leave keys in the registry. Go take a look into YOUR registry and see how many old programs that you have since uninstalled still have their data (or trees) in your registry. I'm sure you find plenty.

Akuta Same

 

[CassandraR]

Ramblings.

Start with a key similar to Microsoft's product keys: five groups of five alphanumeric characters.

Use an algorithm to convert the product key to a 125-bit number. This algorithm creates a possible bank of 4.25E+37 keys. (This my company has done.)

Use a second algorithm to limit the number of valid keys to one of 2^21, which amounts to 2,097,152 valid keys. (This my company has done.)

For every valid key from the second algorithm, we have 2.03E+31 invalid keys.

Trying one random key during each second, how long would be reasonable to expect before one finds one of the 2,097,152 valid keys? Something on the order of 6E+31 years?

Use a third algorithm to encode the end date of the trial period (e.g. 30 days) into one of another set of 2,097,152 keys. Enter a key that validates to the second algorithm to replace the third-algorithm time-limited key with a time-unlimited key.

Save the key in at least two places. First, in the registry. Second, in a file "buried" somewhere in the Windows directory subtree. Encrypt both copies of the key. If either key is deleted, then restore it from the other key when the program is run.

Just some ramblings to ponder.

Cassie

 

[ADoozer]

that is a very good suggestion, one worthy of a star!

but bear in mind the Enigma code was unbreakable until a slip up in security.

http://www.bletchleypark.org.uk/

If somethings hard to do, its not worth doing - Homer Simpson
------------------------------------------------------------------------
A General Guide To Excel in VB FAQ222-3383

 

[CassandraR]

ADoozer

Eventually all codes are broken. It is just a matter of how long a code will last before someone breaks it.

40-bit encryption was good. Then broken.
56-bit encryption was better. Then broken.
128-bit encryption was quite strong, but has been broken.

Thanks for the star!

Cassie

 

[KornGeek]

One thing to keep in mind is that security and copy protection schemes aren't meant to be unbreakable, so don't wrack your brain trying to make an unbreakable code.

The goal is to make it so that it is worth it to them to just register the program rather than go through the grief of bypassing your scheme. This is a combination of reasonable pricing and relatively secure copy protection.

I have used the hardware key approach. My customers don't complain too much, and I have the option of allowing limited demo use without a key, and full use with a key. The keys also support limiting a demo to a time period and/or a number of uses. I've found a way to work in a service level also to define which features are unlocked, allowing me to have multiple product levels.

Although the keys have a material cost associated with them, I like the versatility they provide.

 

[CassandraR]

Thanks for the words of wisdom, KornGeek.

Here's a star for you.

Cassie

 

[ADoozer]

ive just been reading about a company called steganos (www.steganos.co.uk)[although i think there site might be down, im having problems connecting]

the odysseus solution

"The concept is to bury the data in another form of document such as an image. only someone who knows where to look will see the data; everyone else just sees a pretty picture"

just thought id mention it...

enjoy!!

If somethings hard to do, its not worth doing - Homer Simpson
------------------------------------------------------------------------
A General Guide To Excel in VB FAQ222-3383

 

[CassandraR]

ADoozer

I like the idea. Suggestion: incorporate an image into a splash form and bury the keys in the image. Who's going to look at the image file for the splash form?

A star for you!

Cassie

 

[strongm]

Just use your favoured web search engine to search on steganography if you want to know (a lot) more about this concept. We've briefly touched on it in this forum before in the dim and distant past, but I can't find the relevant thread

 

[SteveMCSE]

I have an idea that NO ONE here even touched on.
Instead of trying to limit how long they can use the demo program, consider limiting how MUCH they can do with the demo program. Don't allow SAVE or PRINT. Or don't allow them to create a new document. Something that limits the functioning of it so much that they can use it quite well, but not productively. They will have enough fucnctions available to learn the software, but be forced to buy it so that they can use it. Interesting. 30 threads, and no one mentioned it. Hrm. I think that's more fascinating than the topic! LOL JK.

 

[tsh73]

sirskydive:
I think that's called "crippleware".
Then I see such a program I turn blue ;Of course that's personal...

>They will have enough fucnctions available to learn the software, but be forced to buy it so that they can use it.
I'm afraid they will find it of no use at all.
Like, creating complex things for hours - and then find out that you can't even save it!

may be that's why "no one mentioned it"?

 

[tsh73]

sirskydive:
"how much" approach could do, actually.
After some recalling...
I know one example there limiting of functionality seem appropriate.
The program "Tiramisu" - for HDD recovery.
So it _shows_ you that it could recover your data (or that it couldn't) - but it didn't recover until registered.

But one should be very careful limiting functionality... 'cause it could became too annoying even to try.

 

[CCLINT]

>consider limiting how MUCH they can do with the demo program

While for some smaller or simple programs, or games, that may be fine.

But other than that, probably not a good as it hinders being able to present your application to the potential buyer in a manner that they can correctly evaluate it whicj hopefully leads to a (positive) buying decision.

Take tsh73's example:
>So it _shows_ you that it could recover your data (or that it couldn't) - but it didn't recover until registered.

So how does the buyer know that the program actually does recovers the data effectivly and accurately with-out being able to evaluate it completely?

 

[Alt255]

Since Tek-Tips search isn't working well today, here's a rudimentary example of steganography.

(1) Right-click on the image at the bottom of this post and save it to your application path as "MyStego.bmp&quot.
(2) Add a text box and a command button to a form.
(3) Click the button to place a message in the text box.
[tt]
Private Sub Command1_Click()
' Create a random seed from a password
PWD$ = "f3W#1"
For P = 1 To Len(PWD$)
RNDseed& = RNDseed& + (Asc(Mid$(PWD$, P, 1)) * P)
Next
a = Rnd(-1)
Randomize RNDseed&
StartByte& = 1079
f2 = FreeFile
Open App.Path & "\MyStego.bmp" For Binary As #f2
' The length of the text message was stored at
'the 1075th offset. Get the value.
Get #f2, 1075, TextLen&
Gout$ = String$(LOF(f2) - StartByte&, 0)
Get #f2, StartByte&, Gout$
Close #f2
Temp$ = String$(Len(Gout$), 255)
ClearText$ = ""
For Re = 1 To TextLen&
RandPos& = NextRandLoc&(Temp$)
'Get the text from the various "random" locations
' where it was stored in the BMP.
ClearText$ = ClearText$ & Mid$(Gout$, RandPos&, 1)
'Mark that location in Temp$ as having been read once.
Mid$(Temp$, RandPos&, 1) = Chr$(1)
Next
Text1.Text = ClearText$
End Sub

Private Function NextRandLoc&(Temp$)
' This just distributes the message
' "randomly" though a string of the right size.
Written = False
TempLen& = Len(Temp$)
Do While Not Written
' Try to find an unused random location
' five times. If that fails, use the
' next available location.
For Rep& = 1 To 5 'try 5 times
RandPos& = Fix(TempLen& * Rnd + 1)
If Mid$(Temp$, RandPos&, 1) = Chr$(255) Then
Written = True
Exit For
End If
Next
If Written = True Then Exit Do
RandPos& = InStr(RandPos&, Temp$, Chr$(255))
If RandPos& < 1 Then
RandPos& = InStr(1, Temp$, Chr$(255))
If RandPos& > 0 Then
Written = True
Exit Do
End If
End If
Loop
Mid$(Temp$, RandPos&, 1) = Chr$(1)
NextRandLoc& = RandPos&
End Function
[/tt]

This is really simplistic and you can probably find much better ways to do it... still, it demonstrates the basic concepts. Create a randomizing seed from a password and use it to scramble a message and mix it into a graphic. Use the same password to reverse the process and retrieve the message (in this case I suppose that would be your installation key).

I only included code for reading the &quot;encrypted&quot; text. It shouldn't be huge undertaking to modify the code to allow writes.

​

Suffice it to say that adding disk drives and a disk operating system to a personal microcomputer is guaranteed to increase its power dramatically.
CP/M and the Personal Computer

 

[ADoozer]

Bravo... And a star!!

If somethings hard to do, its not worth doing - Homer Simpson
------------------------------------------------------------------------
A General Guide To Excel in VB FAQ222-3383
File Formats Galore @

http://www.wotsit.org

 

[TheVampire]

Alt255,

You have good taste in music!

Robert

 

[ADoozer]

this is a link to my new thread that people might find informative (especially johnwms link)

thread222-538092

If somethings hard to do, its not worth doing - Homer Simpson
------------------------------------------------------------------------
A General Guide To Excel in VB FAQ222-3383
File Formats Galore @

http://www.wotsit.org

 

[KornGeek]

Since we've touched on methods of implementing a demo, let me share another one. I'm releasing some software where it's primary use is in maintaining transaction history over time. What we are planning to do for the demo mode is to allow nearly full functionality for the first week (with only one minor restriction).

When the program starts up, it will check the transaction history, and if any transactions are older than a week, it will not allow the user to enter. Of course, the user can adjust their clock, re-install, etc. to their heart's content. Doing so will mess up or remove the transaction log and keep the software from being used effectively.

When they buy a license, they get a dongle (I still love saying that word) which allows them to bypass the transaction log check.

This scheme obviously won't work for many applications, but it's something to consider for when it will.

 

[chelseatech]

Hi everyone,

What a fascinating thread, and one that relates to the problem I'm trying to solve.

I don't want a hardware solution. Dongle's are evil, archaic and incompetent (How many machines have parallel or serial ports any more). Besides, I want to sell thousands of copies of my utility, and don't want to have to ship anything physical around the world to my customers.

So I want a software solution to make life difficult for anyone trying to use my software beyond the trial period. I've already got a license file that unlocks the demo features.

The problem I want to solve is where do I hide the file that has the expiry date?

The registry has been suggested, but that can be easily backed up and restored. All users on a Citrix or Terminal server machine get a clean registry each time they start, so their trial period is forever.

I used to hide something in a Windows System folder, but recent network security settings stop users apps from writing files in there.

And other network security settings even stop me from writing to my own app folder. &quot;c:\Program Files\...&quot; is now a no-write area.

I could use the temp folder, but that is cleared out on a regular basis, which again would reset my expiry timer.

I could hard code an expiry date into my install, but that would mean rebuilding and uploading my 30MB install every month. And again, it wouldn't stop a reinstall continuing the trial period.

So where is a good place to hide a file with an expiry date, so the trial version will cease when planned. And to stop someone reinstalling and getting another trial period.

VIP - suggested location must be one that agrees with modern user security settings and also stops all potential users on a Citrix/Terminal Server environment.

Thanks everyone


Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm