7 replies to this topic

[Idov]

Hi!
Suppose you write a program that has a trial period, which gives the user full functionality but only for 1-2 weeks.
You also wouldn't like people to use the trial period several times by removing values from your keys in the registry so you decide to hide them.
The only problem with it is that in order to hide your key in the registry you have to give your process administrators privileges, so the user will have to start it as administrator.
I know hackers can track down the keys in the registry i'm accessing and delete them anyway,
but I'm guessing that the typical user is:
1. Honest.
2. Too lazy to try to hack my process.
3. Is not a hacker.

My question is:
would you as users be bothered by this request - run as administrator?
(My typical user is a software developer)
Can you suggest another way to do it?

thanks

[Ashaman73]

My question is:
would you as users be bothered by this request - run as administrator?
(My typical user is a software developer)
Can you suggest another way to do it?

In this case you're punishing the honest customer, who will download a cracked version which doesn't need a req. entry.

Btw. some developers do not get admin rights on the workstation

Edited by Ashaman73, 30 May 2012 - 06:54 AM.

[Dawoodoz]

Try not to use the registry more than needed since it makes it harder for people to keep their computer safe if everyone ask for full permission by default.

A demo version with size restrictions is harder to bypass.

[Bacterius]

FWIW, registry activity can be monitored, even with legit Windows API's - any hacker worth his salt will simply observe where your program is reading/writing the registry.

but I'm guessing that the typical user is:
1. Honest.
2. Too lazy to try to hack my process.
3. Is not a hacker.

Based on this assumption, hiding registry keys is not necessary. Note this doesn't make it invalid - this is a perfectly acceptable threat model. In general, it's not worth the effort to implement strong security measures in such an application - you only roll out the big boys like DRM/etc if you have a reason to do so (e.g. legally compelled to do so, or a significant part of your revenue is being lost to users downloading cracked versions, or you can guarantee security by providing an authenticated paid service, etc...).

Let's face it - whether you want to or not, if your app is at least a little bit popular, somebody out there will crack it and upload the cracked version, no matter how hardcore your security system is. A more efficient strategy is in general, to encourage users to actually purchase the software; this means polishing it to the best of your ability. In general, if people are really satisfied with a product that they often use, they will eventually purchase it (you can add a discreet nag screen to ensure this happens). Of course, you'll always have "that guy" who swears only by piracy and will never give you a penny for your work, but (hopefully) these people make up a negligible fraction of your userbase.

[FrostyBacon]

First of all: You can write to the registy without admin privileges, but not to all places. For instance writing somewhere below the key HKEY_CURRENT_USER is perfectly fine, while HKEY_LOCAL_MACHINE is off limits. This is similar to writing files. A user process has read-only acces to %PROGRAMFILES% but can write to %APPDATA%.

Regarding your trial protection:
One commercial software protection I know stores it's license information in three distinct places. If only one or two of those locations are wiped the information is restored to all three at the next launch. These places are:
- a registry key under HKEY_CURRENT_USER (the "official" location)
- a file in the temp folder
- one or more fake CLSID entrys below HKEY_CLASSES_ROOT (needs admin)

The CLSIDs are not written if the user does not have the neccesary privileges. In my opinion this is the right thing to do: don't bother the user, just skip it.

Another thing I have seen some protections do is hide information in NTFS Alternate Data Streams (http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29). This is something I would definitely do if I was you.

That being said, I wouldn't use to much sleep over this matter. Store your trial information in multiple places, perform self healing as described above and move on.

[Idov]

Another thing I have seen some protections do is hide information in NTFS Alternate Data Streams (http://en.wikipedia....reams_.28ADS.29). This is something I would definitely do if I was you.

Hmmm... But it can make antiviruses think my program is a virus, can't it?

[FrostyBacon]

Hmmm... But it can make antiviruses think my program is a virus, can't it?

I don't know any antivirus packages that would do that. It's not like ADS is only used for harmful or sneaky stuff, for instance Windows uses ADS to tag files that you downloaded from the internet. Thats where those "This file was downloaded from the internet" dialogs are coming from.

[orizvi]

Personally - I'd say stay away from the registry. Use it only if absolutely nothing else will work.

As an alternate suggestion - you could potentially use NTFS ADS to store license data on your main executable. Its hidden from view and even most developers wouldn't know to check there. You can also design around users rolling back their computer clocks to trick your date checks. Overall - its a much nicer solution in my opinion, and it keeps your application contained entirely within its directory which I think is always an excellent idea.