Making my program have a 15 day trial, any ideas?

Hello,

What is a good way to make my program run for a 15 day trial? Anybody have any good non 'hackable' ideas?
Thank you!
Stilekid007 :wave:

sure. You can save it to the registry, but you have to encrypt it. Find the date ,and save that to the registry. Minus one everyday.

Also, to make it so they cant mess with the registry..if it isnt a real date (the registry entry) make the program not work.

If you need an example ill make one : )

Hey,

I am not really registry savey - how would I encrypt it?

Maybe a simple example would help me ;) lol

Thank you so much! :thumb:
Stilekid007

one problem with this method is that the user can always change the system date to fool your program.

A couple of suggestions to try to fix this are:
1. each time the program is run, write the current date and time to the registry. Have program check before doing this to see if current date and time are before last time you updated this value. If so then expire program.
2. To get real date don't rely on local system date, but go out to internet time server to get real date.
3. Keep running count of total number of minutes program has actually run. Once this value exceeds 15 days then expire program.

Yes I was wondering about the whole roll back the date time. So 2mix, can I intergrade the internet time method with the sample program you make?

Thank you both of you!
Stilekid007

That's only good if the user is actualy connected to the internet everytime the application starts up.... not always a reliable assumption.... unfortunately I don't have any solutions to offer up myself.....

Tg

Yea I suppose your right. So with that in mind I guess the best way is to make it each time the program is run, write the current date and time to the registry. Have program check before doing this to see if current date and time are before last time you updated this value. If so then expire program.

I think this should do it.

In a form:

VB Code:

Option Explicit
 
Private Sub Form_Load()
Dim getdate As String
Dim getsett As String
getsett = RC4ED(GetSetting(App.EXEName, "Settings", "Username"), "TYPE PASSWORD HERE")
    Select Case Val(getsett)
        Case 0
            SaveSetting App.EXEName, "Settings", "Username", RC4ED(Date, "TYPE PASSWORD HERE")
        Case Is > 0
            getdate = DateDiff("d", getsett, Date)
                If getdate = 15 Then 'And getsett <> Date Then
                    MsgBox "Trial over, hope you enjoyed it!"
                    Unload Me
                Else
                    MsgBox (15 - getdate & " Days Left")
                End If
        Case Is < 0
            MsgBox "ERROR! - You have messed with registry!", vbExclamation
    End Select
End Sub

In a module:

VB Code:

Option Explicit
 
Function RC4ED(InString As String, password As String) As String
 
    Dim S(0 To 255) As Integer
    Dim K(0 To 255) As Integer
    Dim I As Integer, j As Integer, tmp As Integer
    Dim t As Integer
    Dim outstring As String
 
 
    For tmp = 0 To 255
        S(tmp) = tmp
        K(tmp) = Asc(Mid(password, 1 + (tmp Mod Len(password)), 1))
    Next
 
 
    For I = 0 To 255
        j = (j + S(I) + K(I)) Mod 256
        Swap S(I), S(j)
    Next
 
    I = 0
    j = 0
    outstring = ""
 
 
    For tmp = 1 To Len(InString)
        I = (I + 1) Mod 256
        j = (j + S(I)) Mod 256
        Swap S(I), S(j)
        t = (S(I) + S(j)) Mod 256
        outstring = outstring & Chr((mXor(S(t), Asc(Mid(InString, tmp, 1)))))
    Next
 
    RC4ED = outstring
End Function
 
 
Function mXor(I As Integer, j As Integer) As Integer
 
 
    If I = j Then
        mXor = j
    Else
        mXor = I Xor j
    End If
 
End Function
 
 
Sub Swap(ByRef a As Integer, ByRef b As Integer)
 
    Dim t As Integer
    t = a
    a = b
    b = t
End Sub

i hope i did it all right
;)

mmhmm! Well it looks complicated! ;) lol Thank you for taking the time to write it all! I really appreciate your time and help! There is one problem here though. When the time goes PAST 15 days (by editing the system date to July 29 instead of June 29th.) It just gives me a msgbox -15 days left. Also if I set the date to yesterday it tells me I hae 16 days left. And if I was a user I would just be able to set the date to June 30th and have 14 days everyday that I switch it back to June 30th. Also it never gave me the trial over msgbox.

Do you know how to fix any of that? lol
Sorry if I am to dumb to see somthing that I am doing that is making it not work ;) :P
Stilekid007

well, for negatives i thought this would catch them:
Case Is < 0
MsgBox "ERROR! - You have messed with registry!", vbExclamation

There really is no way to fix any of that other stuff, because the user will always be able to change it. Thats why 15 day subscriptions normally stay on my system for months.(non - internet programs) but if really need it to be so they cant mess with anything - you need to have an internet server with the time on it and match......

agh im confusing myself!

actually, to fix that -15 do this:

VB Code:

If getdate = 15 Then 'And getsett <> Date Then
                    MsgBox "Trial over, hope you enjoyed it!"
                    Unload Me
                Else
                         If (15-getdate) > 0 then
                    MsgBox (15 - getdate & " Days Left")
                         Else
                    MsgBox "Trial over, hope you enjoyed it!"
                    Unload Me
                        end if
                End If

Hello,

Ok, Thank you for the rest of that code! I will rate you for your time! I do have another qeustion though. How would I get the program to get the date ONLY the first time the program starts and the add 15 days to that then save it to the registry?

Thank you again All!!
Stilekid007

Hey everyone! Ok, I made a program that works for a 15 day trial! I like it alot.

The user cannot role back the time.
The user cannot tamper with the time or anything like that.
The user cannot use it past 15 days ;)

I don't think it is completly hack proof. I used your encryption method for my registry settings so that the user can't see the registry settings.

So it works nicely and it is very simple.

But if the user just deletes the whole registry key for my program it will be like the trial never existed and it will start the trial over. So I have to make it so that the user cannot delete the registry key. I have to put some restrictions on it.

But I will make a new thread for that.

2emix I tried to rate you but it said I have to spread my reputation before giving you more. So I will come back to this thread once I spread alot to other people;) lol

Thank you all and have a great day!
Stilekid007 :wave:
P.S. I will post my program once I square away the registry security issue ;)

Quote:

---

Originally Posted by stilekid007

But if the user just deletes the whole registry key for my program it will be like the trial never existed and it will start the trial over. So I have to make it so that the user cannot delete the registry key. I have to put some restrictions on it.

---

You could make it so the 1st time the program is run it alters a flag value within the exe (or a DLL used by the exe), and subsequently checks that. Make it a constant and then you can get the byte offset using a hex editor. You might want to make it a long string of one character or something to start off with, so that you can find it in the editor. Then just do a simple write op the change the value, the next time the program is run the change will indicate it has been run before.

In addition to that you could have multiple keys hidden in the registry, so if any one of them is tampered with the trial expires. You could make it so that the flag value is re-written again when the trial expires also, so that any attempts to restore the demo state will be overcome.

Hope that gives you some ideas :)

Wow - yea that helps alot man! That gives me a few ideas! I will have to expirement and let you know the outcome!
Thank you for your suggestions!
Stilekid007

Quote:

---

Originally Posted by penagate

You could make it so the 1st time the program is run it alters a flag value within the exe (or a DLL used by the exe), and subsequently checks that. Make it a constant and then you can get the byte offset using a hex editor. You might want to make it a long string of one character or something to start off with, so that you can find it in the editor. Then just do a simple write op the change the value, the next time the program is run the change will indicate it has been run before.

---

Hey Penagate, You said above to have my program alter a flag the first time it runs and subsequently check that. And you say to use a hex editor.

I have no idea what that paragraph above means. Could you explain or if you find yourself 'board' lol make some example or instructions. I don't even know what hex is so I am pretty bad lol

Thank you for all your help!
Stilekid007

This won't prevent the user from deleting the registry and just reinstalling the program.

Quote:

---

Originally Posted by moeur

This won't prevent the user from deleting the registry and just reinstalling the program.

---

Another idea. As well as the registry stuff why not create a little file in the system32 folder with one of those meaningless names that makes you think it's probably some vital little bit of windows- write a few bytes to it and leave it there. Then when they delete registry keys they'll probably miss it, but your program can check for its existence and terminate if it's there.

Yea that would help make it better too. I was kind of looking for a fool proof method. I guess there really isn't one out there. So I guess I could combine alot of these schemes together to make it hard to crack.

Quote:

---

Originally Posted by stilekid007

Hey Penagate, You said above to have my program alter a flag the first time it runs and subsequently check that. And you say to use a hex editor.

I have no idea what that paragraph above means. Could you explain or if you find yourself 'board' lol make some example or instructions. I don't even know what hex is so I am pretty bad lol

---

Hex (hexadecimal) is just a represention of numbers. It goes from 0 to F instead of 0 to 9, so it uses less space (150 in decimal = 96 in hex, FF in hex = 255 in decimal, etc.) Basically a hex editor just displays a file in hex view. They are typically used for editing files such as exes, at byte level. If you search on download.com I believe there are several good freeware hex editors, unfortunately I seem to have an expired shareware one but I'm sure there are free ones ;)

Now the flag edit, works like this: Say you hard-code a constant into your app (in a module):

VB Code:

Public Const FLAGVALUE As String = "%%%%%%%%%"

Now when you open the exe file up in a hex editor and scroll through a bit, you should fine the string "%%%%%%%%%". Click at the start of that string and it will tell you the byte offset of the constant, i.e. where it is located within the file. You then take that number and hard-code into another exe that modifies the original one using a Write or Print command (I've forgotten how you do that bit actually :eek:)

Quote:

---

Originally Posted by stilekid007

Hello,

What is a good way to make my program run for a 15 day trial? Anybody have any good non 'hackable' ideas?
Thank you!
Stilekid007 :wave:

---

Does your program require the use of a database? If so, what kind?

A good idea for this would be to not use the GetSetting & SaveSetting methods, they just use...

HKEY_CURRENT_USER\Software\VB and VBA Program Settings

...which could be quite easy to locate and manipulate.

Instead, you could write to some hidden location, not easily found....the registry is a big place! ;)

Something like...

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\GUID (you could create a GUID for your app).

Any user browsing the registry won't see you Executable name then, just a load of meaningless numbers...! The amount of entries in the Classes key root also adds a layer of complexity.

The only reservation I have on using the registry is running into a company that might be interested in the program but, as a company standard, has a lock down registry policy in effect for all of the machines they roll out to employees. As a commerical developer, I can assure you that this is becoming more and more prevalent.

Quote:

---

Originally Posted by Hack

The only reservation I have on using the registry is running into a company that might be interested in the program but, as a company standard, has a lock down registry policy in effect for all of the machines they roll out to employees. As a commerical developer, I can assure you that this is becoming more and more prevalent.

---

True - most of our network is served by a Citrix farm of about 20 servers, they're all locked down, we can't even register DLL's unless you are signed on as a local or domain admin.

However, if a company was interested in your product, I think it would be a fair assumtion to say that someone from the companies support department could sign on as admin and perform the install for you.

Yea it would probablly just tell the user somthing like "registry restrictions present please olgin as an admin"???? I don't know though. But I am thinking I am going to have to hide it deep in the registry somewhere (Like in a GUID)

I am still working on different types of trial programs and one of em will be with a GUID;)

Stilekid007

What is a GUID?

Quote:

---

Originally Posted by penagate

What is a GUID?

---

Globally Unique IDentifier, like used by ClassID's...

{0BA686AF-F7D3-101A-993E-0000C0EF6F5E}

Cheers :)

Quote:

---

Originally Posted by Dylan Morley

True - most of our network is served by a Citrix farm of about 20 servers, they're all locked down, we can't even register DLL's unless you are signed on as a local or domain admin.

---

We have been partially getting around this restriction by taking out application settings and user preference settings from the registry and writing them to backend DB tables (all of our products ship with SQL Server). Well still, however, need local admin support for registering/installing our .Dlls and .OCXs.

MartinLiss produced a registration program
http://www.vbforums.com/showthread.php?t=232146

That might be worth looking at

how far do you want to go with security?

all of which i've read here still is kinda basic, and easily 'beatable' :)

LOL, Wildcat - yea I know these are all very beatable that is why I don't like any of the ideas as much as what I was hoping to find. I was hoping to find some kind of unbeatable scheme. Do you know of something really good?


agMorgan - Thank you for that link from Martin. I have already intergrated his program into my program. But I am looking for something that will let the user have a trial. His prgram is only for registering and it works nicely ;)

Thank you!
Stilekid007

well... ive not read everyone's post above... but wud just like to add.... instead of saving it with SaveSetting to HKEY_CURRENT_USER\Software\VB and VBA Program Settings select some other location where it cannot be found or make a txt file.. into a location which very few people dig like the system32 folder and save it there...

this is just a non-hackable idea.. moreover the message where it says... invalid registration key... remember to encrypt it to prevent it from being visible in a hex editor. so no1 can reverse it.. and crack your program easily..

you cannot completely prepare a time trial.. 95% time trials, shareware , nagscreens have been cracked... so a small vb program wud not be a big deal for every day programmers.

Rate me if you found me useful.

Does your application come with a database?

If so, I can tell you how to make a demo copy of your program that should satisfy both you and your potential customers.

Well I can use the excellent tools FileMon and Regmon to watch an exe I load and see exactly which files and registry keys it accesses/creates. Keep that in mind ;)

Quote:

---

Originally Posted by Hack

Does your application come with a database?

If so, I can tell you how to make a demo copy of your program that should satisfy both you and your potential customers.

---

Uhh - what do you mean by database?

Sorry I don't understand everything lol ;)
Stielkid007

Quote:

---

Originally Posted by penagate

Well I can use the excellent tools FileMon and Regmon to watch an exe I load and see exactly which files and registry keys it accesses/creates. Keep that in mind ;)

---

I know thats what I am worried about. I am still trying to figure something out that just can't be hacked - maybe there isn't anything of the sort. I mean hiding it good enough in system32 folder and in the registry but like you said that is still not un beatable.

So I guess I will just keep thinking and looking. ;)

Stilekid007 :D

Quote:

---

Originally Posted by stilekid007

Uhh - what do you mean by database?

Sorry I don't understand everything lol ;)
Stielkid007

---

A database. You know, like MS Acces, MS SQL Server, Oracle, SyBase that sort of thing.

What does your application do?

Quote:

---

Originally Posted by Hack

A database. You know, like MS Acces, MS SQL Server, Oracle, SyBase that sort of thing.

What does your application do?

---

Oh I see - No, it doesn't use any database. My program does alot of different calculations and stuff its actually a very big program. This program that I just made is more or less pretty much my first program - I made a few others but never 'completed' them and they wern'y very good. But I wouldn't really need to use this trial program for this one but for my other programs that I plan on making and maybe even this one. But no it does not contain a database. Sorry.

Truth of the matter is, you're going to find it very difficult to make your program completely uncrackable. A quick search of the web will result in hundreds of sites hosting cracked software from all sorts of professional companies.....At home, I work with a lot of audio software like Cubase SX, they've all gone back to USB dongles.....I hate them, but the developers at Steinberg couldn't think of a better way!

All you can do is make it difficult for your every day user \ amateur to get around your setup. Anyone with a decent set of cracking tools & knowledge of assembly can see exactly whats going on once your executable starts running.

That's completely correct. It is up to the OS to ensure people cannot do that, and Windows does nothing to prevent people from examining the intricacies of applications. However hard you try, if someone tries hard enough they will crack it.

Quote:

---

Originally Posted by Dylan Morley

Truth of the matter is, you're going to find it very difficult to make your program completely uncrackable. A quick search of the web will result in hundreds of sites hosting cracked software from all sorts of professional companies.....At home, I work with a lot of audio software like Cubase SX, they've all gone back to USB dongles.....I hate them, but the developers at Steinberg couldn't think of a better way!

---

How about this. It's a bit restrictive, but is it uncrackable?:
When you launch your installer it has to connect to the internet to register the demo (or it terminates). It then writes a record to a database on a remote server, which contains a unique identifier of the machine (say the windows serial number) and the date of registration. The app can then only run if it can locate its record in the database (by connecting to the remote server) and confirm the date.

Quote:

---

Originally Posted by anguswalker

How about this. It's a bit restrictive, but is it uncrackable?:
When you launch your installer it has to connect to the internet to register the demo (or it terminates). It then writes a record to a database on a remote server, which contains a unique identifier of the machine (say the windows serial number) and the date of registration. The app can then only run if it can locate its record in the database (by connecting to the remote server) and confirm the date.

---

Could use a packet sniffer to get the response from the server and then fake it in the future, or find a check for that response in the app and zero it.

This needs a web link though which in some circumstances wold be restrictive.

The best idea I saw in the forums once was to switch the app to demo mode if the registry authorisation was compromised. This gives the user unlimited evaluation time but they will only really be able to use the prog when it is properly licenced to the machine.

When they try to copy the ap to another machine - no problem - it kicks back in to demo mode on the new machine because you key the registry activation code to the machine.

Yea another thing I could do is just make my program and then make a seperate evaluation with restrictions on it.
Ecample:
Have some of the command buttons disabled until the registration code is entered into the textbox, and have other things disabled but still have it so they can get the idea.

It would work anyway and wouldn't be hackable. (I don't think?) lol :D

I used to sell a program on Prodigy & Compuserve (how old??). Anyway, once a month I would recompile it with an expiration date that was 60 days in the future. Of course, all the user had to do was change their system date. You just have to make it enough of a nuisance that they will just pay the registreatiuon fee (in my case $15) and get a "full" version with out the cripple code. Just like locks on your door. If someone wants in bad enough, they will get in. The locks keep the honest and borderline people at bay.

I'm making a avi movie to send to let them decide if they want it. They have to buy it to use it at all. That way, I hope to eliminate pirate copies.

Another idea. This is completely theoretical as I'm not a programmer and wouldn't know how to do it, but it seems reasonable:
When you get a request for the programme you send an installer which is conditionally compiled to hardcode in the date of compilation. The installer checks with its date of compilation and will not install say more than 10 days after its own compilation. The app is then similarly conditionally compiled to include its date of compilation and will only run for a set number of days after. Would that work?
The app might also have to create and check against registry keys to avoid the user changing the system date, but to be honest if someone had to change the system date every time to use the app they'd soon get fed up, wouldn't they?

Quote:

---

Originally Posted by dglienna

I'm making a avi movie to send to let them decide if they want it. They have to buy it to use it at all. That way, I hope to eliminate pirate copies.

---

Even if people purchase the app, whats to stop them from redistributing the app to their friends, and their friends to their friends? before you know it, youll have a billion illegal copies out there ;)

Another suggestion:
Instead of limiting the amount of time the app can run (eg 15 days), which as you can tell can be 'tricked'.
Publish 'trial' versions that are limited/crippled in some way. Then if the user wants all the functions/features of the app they need to purchase (the full edition).




Bruce.

Quote:

---

Originally Posted by BrailleSchool

Even if people purchase the app, whats to stop them from redistributing the app to their friends, and their friends to their friends? before you know it, youll have a billion illegal copies out there ;)

---

An emailed registration code tied to their machine :)

Quote:

---

Originally Posted by penagate

Could use a packet sniffer to get the response from the server and then fake it in the future, or find a check for that response in the app and zero it.

---

packet sniffing? naaaaaaaaa easier to just reset the check :)

few suggestions here.

1. i wouldn't recommend anything related to dates. i would, instead, limit the 'use' of it: you can start it up 50 times, for ex.

2. do not give any 'pointers' to crackers: do not have a message box stating 'hey, program unregistered!' or things like that. instead, disable buttons or hide the main screen, showing another one with this information on it.

3. cripple your messages: a text containing 'program expired' is the best way for a cracker to identify in your lines of code which part is to target.

4. cross-check multiple keys in the registry, and save some into common key locations: a key like 'My program/Key' is easily findeable and resettable.

5. pack your program: ASPack.

6. add CRC checks on file, i posted something for this here.

7. fake registration routines, it makes crackers a living hell to trace them down (i.e. put some complicated computation routines that have no scope at all).

8. do not compute your serial and compare to it directly. devide it into pieces. otherwise, a correct serial will be easily visible in memory.

9. if you feel like entering in your code with a disassembler, use a simple technique (my post here) to protect against 'live memory' patching.

10. add anti-softice tricks (even though a basic cracker can beat these in 22 seconds).

have fun :)

cheers,

wc.

Wildcat, can you expand on number 9. What is anti-softice?

Quote:

---

Originally Posted by David.Poundall

Wildcat, can you expand on number 9. What is anti-softice?

---

softice is a debugger, one of the main tools used by crackers to unprotect software.

it is possible to know if this tool is running in the windows environment, though letting the program defend itself. however, again, afaik these anti-softice tricks are mostly easily beateable.

for some code on anti-softice tricks you can check on Planet Source Code (site is down right now, can't give you a direct link). do not expect too much out of these. you can easily google around to find the most common softice methods and build your own trying to improve them.

Thanks for that Wildcat

you're welcome!

Hey Wildcat. I appreciate all the 10 points you gave - very helpull!

Thanks buddy! :thumb:

Stilekid007 :wave:

Quote:

---

Originally Posted by stilekid007

Hey Wildcat. I appreciate all the 10 points you gave - very helpull!

Thanks buddy! :thumb:

Stilekid007 :wave:

---

you're most welcome. if you need help on implementation do not hesitate.

cheers,

wc.