views:

503

answers:

6

where do programs save their secret license or install related information? I notice that often times when you uninstall a program, clear out appdata references, check registries to make sure there is no residue of any relevant information.

If you reinstall the trial program again, it seems to know it was installed before. I'm not looking to find a way to crack trial programs but actually need to implement something similar and cant find any good information on how to do this.

+2  A: 

They save it wherever they can, secret files, secret registry keys. There are commercial products that offer this kind of protection, like asprotect, armadillo, etc.

Nikola Smiljanić
+15  A: 
  • Registry
  • online
  • file in folder Windows with system like name
  • I even seen apps that hacked unused OS variables to store custom data in registry.
  • But the simplest method is to register a handler for a custom unused file type like .sof (if that is there, it was installed before) Edit 1 You have to register the handle to open a known executable on the system, not to your app. Because cleaners will detect if points to a no longer existing app location. As for storing additional params like date of trial expiry you can include them in the path as a param, like: cmd.exe -o 2010-02-09
Pentium10
I would suggest registering something more like `.xxxxxnotusedxxxxx` for the file extension. Whenever I wanna use a `.sof` file I don't want your program screwing it up.
Earlz
@Earlz : When you install something else it'll just update the extension. Pentium is just suggesting checking for it's presence.
Ian
That's quite clever.
Cyclone
There's nothing clever about trashing someone's OS for your own greed.
Longpoke
+5  A: 

I have handled this in two ways. First, in windows apps, I put in an encrypted Registry entry which is not in a standard location so that it is not easily found. This is a good solution if you don't mind people who either a) reformat often which removes all registry entries or b) use your software on a virtual machine which can be quickly reverted to a pre-trial state (and thus your trail can be used again quickly).

The better alternative is to have an online registry component which catches the MAC address of the machine which the trial is loaded on. Whenever the trial is reloaded, the software checks against a web service to see if the MAC address has been seen before. The only way around this is again using a Virtual Machine with the ability to change the MAC address. However, if you have a user that goes to this extreme, they'll use your trial regardless.

Tim C
I like that encrypted registry idea, but isn't the encrytion redundant? If they can't find it they can't remove it. What do you encrypt, the key or the value, and why does it matter?
Steve H.
@Steve H.: You are right it might be redundant to encrypt it but sometimes it gives management a little extra sense of security. They love to have a feeling of security and throwing in a hash instead of a static value just makes them happy (Yep, sometimes I code to the management instead of the user). Generally I just hash the value of the key, taking, for example, the MAC address of the machine and throwing it through an MD5.
Tim C
A: 

Could also try making the file or folder hidden - most users don't know to reveal hidden files and folders. Then you can put it anywhere really. C:/WINDOWS is sometimes a good choice because of that silly window that shows up when you click it for the first time that says "DANGER! DO NOT EDIT ANYTHING IN THIS FOLDER OR YOUR OS WILL MESS UP!" This will hide most anything from the lay man, but let's face the facts, you're not hiding anything from anyone that is active on stack overflow. :)

Steve H.
Putting your crap in C:\Windows is either unethical or just plain stupid.
Longpoke
+1  A: 

Some products will utilize ADS (Alternate Data Streams) and hide the data in various places.

Others will leave behind "rootkits" cough SONY.

Also some will create special registry entries that cannot be delete easily, such as entries with NULLs in the name.

It sometimes depends on how scrupulous the developer is.

adahnert
+1  A: 

Probably the most foolproof way of licensing (when done right) is through something the user physically has - some kind of hardware dongle.

  • very hard to copy/duplicate
  • not dependent on network access
  • tamper-resistant (compared to software)
  • user-friendly (when working correctly)
  • licence count enforcement (can't easily plug 1 dongle into 10 machines at once)

Of course, it has also numerous disadvantages:

  • expensive to produce
  • hard to repair/replace
  • actually requires you to communicate with the dongle in a cryptographically secure way - any kind of if(dongle_ok()) { do_stuff() } is an invitation for crackers to patch that over to if (1) { do_stuff() }...
  • ...which will require special drivers...
  • ...maybe even a special interface (I still have a LPT dongle, but no LPT ports; USB<->LPT sucks)
  • don't even think of hooking it up to a virtual machine (although peripheral support is better in VMs nowadays)
  • support hell (is it connected? is it not broken? is the driver not broken? are the signatures/keys right and unexpired?)
  • fragile, esp. if it sticks out of the computer and/or has destructive anti-tamper mechanisms
  • may break communication with other peripherals (esp. those "pass-through" things were notorious for this)

For most programs, the disadvantages far outweigh the advantages; however, if you're making expensive, complex software (think "production plant control"), your clients are rather cavalier about licensing (in other words, "would buy a single copy (crack it if necessary) and run it on 50 machines if they could get away with it"), and lawsuits are impractical (take too long, you don't have much evidence, uncertain outcome), this may be useful. (I didn't say simple, did I?)

Piskvor
Oh I just love when I have to install some random developer's driver to use his word processor...
Longpoke
@Longpoke: Indeed, the problems here outweigh the benefits for most general-purpose applications. The usability factor is appaling here, but the security still makes this appealing in some areas. (and yes, it's all security *potential*, which is easy to waste - there are HW dongles which provide security on a level of "check that an USB device with ID 12345 is connected"; as with any product)
Piskvor