Where do programs store the check against Volume ID (HWID, Volume Serial, etc.)?

[binarylaw]

Where do programs store the check against Volume ID (HWID, Volume Serial, etc.)?


A software trial I'm trying to reset doesn't appear to store the trial data via file OR registry, unless it's somehow using methods to hide the writes (file + registry) from Process Monitor. It also isn't storing it anywhere via network. A complete uninstall + reinstall still detects that a trial already occurred.

I do know, however, that by changing the hard drive's volume ID (HWID, volume serial) it suddenly resets the trial when installing (after uninstalling), as the software sees it as a new computer.

So the software is storing the initial volume ID/serial somewhere... any idea where it might be stored? Or how I could locate where it's storing it (and how it's doing this)? I'm asking more for reference rather than just getting the software to work.

[chessgod101]

I've seen some cases where a trial software relied on the date that its application specific files and/or directories were created as a means to verify the trial period. They simply called GetFileTime to check this.

[ionioni]

could be stored in many ways, as ADS of some file/dir, in registry, even at sector level, to name a few... ProcMon might be even catching the thing and not be that obvious, since many times we are biased in our search.
post a link to the software?

[binarylaw]

Originally Posted by chessgod101

I've seen some cases where a trial software relied on the date that its application specific files and/or directories were created as a means to verify the trial period. They simply called GetFileTime to check this.

But the software would still need to record/log the reference timestamp somewhere, either disk or registry, right?

Originally Posted by ionioni

could be stored in many ways, as ADS of some file/dir, in registry, even at sector level, to name a few... ProcMon might be even catching the thing and not be that obvious, since many times we are biased in our search.
post a link to the software?

Ah, that would make sense. What would be a way to detect if this is happening... using something like an API monitor to watch all the API calls it uses, watching for particular ones that have anything to do with writes?

Here's the link:

https://href.li/?http://download.jgsoft.com/acetext/SetupAceTextDemo.exe

[chessgod101]

Originally Posted by binarylaw

But the software would still need to record/log the reference timestamp somewhere, either disk or registry, right?

No. The directory/file creation time is the timestamp since these values don't typically change unless the file or directory is deleted and/or recreated. This information is stored on the disk and is retrieved by the system with this call. It could simply compare that to the current system time to see if it is within the trial days. Though this is a probably a little impractical, I have seen this method used in a program in the past. GetSystemTime or GetLocalTime could be some useful APIs for you to track this type of check.

Please note that I haven't actually analyzed your target application. This is all speculative and is one trick which I have encountered that is hidden from ProcMon.

[binarylaw]

Originally Posted by chessgod101

No. The directory/file creation time is the timestamp since these values don't typically change unless the file or directory is deleted and/or recreated. This information is stored on the disk and is retrieved by the system with this call. It could simply compare that to the current system time to see if it is within the trial days. Though this is a probably a little impractical, I have seen this method used in a program in the past. GetSystemTime or GetLocalTime could be some useful APIs for you to track this type of check.

Please note that I haven't actually analyzed your target application. This is all speculative and is one trick which I have encountered that is hidden from ProcMon.

Ah, that makes sense. And it seems you may be right: in its registry settings is a key called "Demo", with values "Date", "Days", and "Msg". Changing these doesn't change anything, however. But maybe like you say, it's just looking at a timestamp and judging the days beyond that, and anything it puts in the registry is merely for reference, not as a variable it checks against.

Theoretically, if that's the case, then if I were to change all the timestamps of its own files/folders, this would bypass the trial limitation, right? Assuming there's no registry trial-finished flag that it's written.

Lastly, when I change the drive's volume ID, the software suddenly starts as if it's a fresh trial. So somehow it's logging somewhere what the current volume ID is. I'm wondering if I can find where it's storing that information. Any thoughts?

[ionioni]

[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"Integration"=dword:xxxxyyyy

xxxx = usage days (different consecutive days)
yyyy = install date (days since 1900)
"Integration"=dword:0015a99b = 21 days, installed on 15 nov. 2018

didn't stay on it too much, so other things might be there

[DavidXanatos]

I find it strange that the trail period locally depends on the HWID.
I mean if I save a date some ware some how and than find it I use it.
I wouldn't assume any legit trail case where a customer would have a machine with the date set but a changed HWID.

Are you sure the tool is not communicating over the internet with its mothership and checking with them if for this machien with this HWID the trail period is not expired?

[mr.exodia]

Check GetVolumeInformationW

[binarylaw]

Originally Posted by ionioni

[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"Integration"=dword:xxxxyyyy

xxxx = usage days (different consecutive days)
yyyy = install date (days since 1900)
"Integration"=dword:0015a99b = 21 days, installed on 15 nov. 2018

didn't stay on it too much, so other things might be there

Very interesting, thanks! Can I ask how you figured that out? Like what tools you used and methodology. I can see it now in Process Monitor (in hindsight), but I wouldn't have seen or realized that on my own, or known how to figure out that it was calculating anything based off that.

Originally Posted by DavidXanatos

I find it strange that the trail period locally depends on the HWID.
I mean if I save a date some ware some how and than find it I use it.
I wouldn't assume any legit trail case where a customer would have a machine with the date set but a changed HWID.

Are you sure the tool is not communicating over the internet with its mothership and checking with them if for this machien with this HWID the trail period is not expired?

All I know is that when I changed the volume ID of the drive, on next launch or install of AceText, it suddenly sees it as a new machine. I agree with you though, but I can't find where it saves the volume ID. It must save it somehow somewhere to be able to know when there's suddenly a new volume ID.

As for the internet, I'm positive. I've had it's network comms completely locked out, and even run it in a networkless VM too. Your thought makes sense though, I would think the same thing myself.

Originally Posted by mr.exodia

Check GetVolumeInformationW

Thanks. Are you suggesting this generally (it being the API to get such information), or have you analyzed this program specifically to see that it does this?

I'm stuck trying to figure this out with my limited ability. I can see that it requests volume information in Process Monitor and API Monitor, but I don't know where to go from there, like finding out where it's storing the registration information.

If you can recommend any tools in particular necessary for this process or tutorials, I'd appreciate it. I probably have the tools already, I'm just not well versed in what to do next to go deeper on something like this.