Metropol

Hi,

I've always been interested in one thing. How do the "wrappers" that set e.g. 30-day limits on the use of software make sure that you haven't just altered the date? As I understand it, the only tools a programmer really has available to them is to note the install date, write it to the registry somewhere, and check it when it's run to make sure you're still within the 30-day period. But many of these programs are rather sophisticated and also ensure you haven't just set back the clock, so I'm intersted to know what's going on 'behind the scenes' to ensure this! I haven't found anything useful in my research.

Also, presumably these wrappers don't write to obvious places in the registry, instead trying to obfuscate their note of the install date (otherwise it could easily be removed) - actually this is the reason I never install 30-day trial software any more, since by definition it is squirrelling things away in my computer... anyway, what sort of methods and places are used to accomplish this? I'm most interested in how it accomplishes this in a Windows environment as that's what I'm most familiar with.

NB: I don't intend to do anything illegal or reverse engineer software - this is only out of curiosity. Rather interesting field if you ask me.

A good way to detect clock changes is to record when the software is launched, as well as when installed. As obviously time can't go backwards, subsequent launches of the software must be after the last time it was run.

A simple way of storing such data is to encrypt it, or use a hashing function, and then just store it in the registry. If it's missing, or corrupt, don't load the software. Data can also be stored in various other files related to the program such as file headers.

I don't know anybody who does this, but it's definately possible, but you could store a unique identifier for the machine in the header of all files it creates, along with an encrypted / hashed version of the last time it was loaded, edited or saved, and then use that also to detect if time has reversed.

Ah, so continuously updating the most recently-run date every time it's run. That doesn't protect software from users who carefully choose dates that are only slightly advanced from the previous one, but it does provide some protection from casual 'date backing'.

I find it unlikely it would write it into the header files of the program itself, because this would make it vulnerable to just being uninstalled and reinstalled. By definition the program must leave something behind.

I think I might try installing then uninstalling some piece of 30 day trial software, running WhatChanged before and after to find out exactly what gets left behind in the registry and file system post-uninstallation. I suspect it will be rather interesting.

some applications, namely the Adobe suite seem to modify part of the boot sector to store their activation information, but there are some creative places you can hide these things.

some clever ways i've seen is to use alternate ntfs data streams and or to hide registry keys by adding entries with null bytes.

i seem to remember many yonks ago when i wanted to extend the life of the shareware paint shop pro i used regedit to export the full registry and a text file before and after installation and compared the differences.

in that case the date information was stored as an innocuous key not anything jasc related - removing it reset the counter.

most software have to record their date information somewhere what you can see and easily reset

i'm sure you know about the sysinternals tools, but if not process monitor will let you see what an application is doing http://technet.microsoft.com/en-gb/sysi ... 96645.aspx

from this you'll easily be able to work out how a specific application is storing it's trial data (unless it is communicating with a kernel mode driver to hide the data somewhere not normally accessible to user mode apps like in the special ntfs meta data files that record bad sectors and other internal file system details)