Simple but probably effective. In terms of protecting against regular end users fiddling with the system time I mean.
On a related note I remember many years ago when I was using Windows, and there was a third-party utility to monitor the registry for changes.
I only had the trial version of the utility, but using the utility itself I found that they were storing information in the registry about when the trial would expire. So I was able to use the utility to discover and defeat the trial protection of itself.
So that was cool in and of itself. But I also found that, even though this was in a time before most software would do online checks, many pieces of software were able to know that the trial had expired even if I tried things like setting the clock back or removing registry entries they had created.
Probably some of those pieces of software were doing similar things to the one mentioned in the OP. But it never occurred to me at the time. I’m not even sure I would have thought of this even today if I were to try it.
But these days I use software that’s open source for a lot of things instead, and where I need proprietary software I pay for it instead. If it’s proprietary and not worth the money then it’s not worth using either. Though I am still sad that Adobe switched to a subscription based payment which I ended up not being able to afford and don’t want to sign up for again because of their horrible billing practices. So I am stuck not being able to run Adobe software even though I would have liked to.
In the windows 9x days, software had direct access to hardware without needing any permission.
They could get very creative about where the trial end date could be hidden. They could write it to random blocks of the fat32 partition marked as "free". They could even find unallocated blocks outside of the partition table and write it there.
Or you could write it to the contents of a file without going though the regular file APIs, so it's modification date wouldn't change.
As long as just one copy of the trial end date stays intact, it can simply take the latest one.
You're giving me flashbacks to the bad old days when Opera was the only competent browser for Windows Mobile devices. What made them the bad old days? They only had a trial version, and some time after the paid version didn't come out the date limit on the trial version expired, so thousands of people turned the dates back and sacrificed the entire "organization" category of PDA functionality just to keep using a good browser.
I believe a full version of Opera was eventually released but it took a very long time.
Age of Empires 2 does something similarly tricky for beta/trial versions - when it's check_expiration check fails once, it writes some "hard to find" registry value (Software\X\DT2 to 1 for aok and Software\TC\XPX to 7 for aoc), and then thereafter also fails if this value exists and is the previously written value to prevent you changing your system clock to circumvent that check.
Of course that's all rather silly since a 1 byte change in WinMain also defeats this, but that requires modifying the program ...
> So I was able to use the utility to discover and defeat the trial protection of itself.
This is why I used to feel bad for Hex Rays / IDA Pro. When your product is a disassembler, there's bound to be someone in your target audience capable of cracking your software.
P.S. Don't use a cracked IDA Pro. Checkout Hopper instead. It's reasonably priced and really solid software. Been using it on and off for years.
This bit me once when I was hosting my FPGA design on an NFS server which lost the CMOS battery so it came up with a very weird date. The computer mounting it was fine but the files would get their access time screwed up. And then FlexLM bombed out. So very annoying.
That sounds like the steps I saw to get a free version of the original version of Little Snitch. Simply use Little Snitch to stop Little Snitch from phoning home.
FLEXlm was originally written by just one guy. I think I remember his name -- his initials are M.C. if anyone would like to confirm that I'm recalling correctly. When he sold his stake he got ~$10 million. The software went through many ownership changes. I think this was when it went from Globetrotter to Macrovision. When he got his ~$10 million he gave about $2 million to his current employees as a gift. I thought it was a very honorable thing. He had no legal obligation to do so.
This isn't inside information; it was all published somewhere but it's funny how the web can "forget" things after a couple decades.
EDIT: I found something that at least confirms the name I was remembering, Matt Christiano, and a history[1] of license management that he wrote in 2007.
When I see the word "security" used like this, I wish the person who used it would be honest about whose security they have in mind. (Also, they should be clear about whether they are talking about cyber security, or financial security, or personal security.)
It's like the word "protection" in the terms "copy protection" or "content protection". Those at least make clear that it is not the user who is being protected, but it's still disingenuous to suggest that a file is somehow harmed by being copied. If anything, having more copies of a file only makes it safer.
"Revenue security" is something every startup, YCs included, ought to spend a notable chunk of their time considering. It fits the bill for clearly stating who's protecting, as well as clearly stating what's protected. And it can be easily applied:
"Does having more copies of a file generally improve revenue security?" is probably a solid "no, not generally" with some very interesting exceptions.
I don't use any licensed software with enforcement methods like this, but it looks trivial to defeat.
A string dump of the binary would likely show these directories, and even if they were obfuscated, an strace would reveal them as they probed the file dates.
Yup. It's just a cliché of modern life. You hear it at train stations: "For security reasons, <anything>".
It's the same in medium-size and large companies with "legal". All you need say is "Oh that's required by legal" and no-one applies any rational scrutiny to it because for some reason the "legal" and "security" departments are considered to house minds far superior to those of anyone else.
Back in the days we actually had to use this trick. We knew we had enough licenses but at some point people started complaining that others wouldn't give back shared licenses.
It turned out the server didn't register them in when someone signed off.
So after troubleshooting we ended up doing exactly what this trick is protecting against, setting the server clock to somewhere in the future.
Worked nicely back then.
This was just as I left that place, a few weeks later my college told me they had found the problem: our previous it manager had installed a new instance of the license server on a faster machine. He had not installed the license files (nor documented it anywhere) though so the new server would just say thank you and discard the license token whenever anyone signed out.
FlexLM --- certainly gave me a bit of nostalgia from all the time I spent on it as a cracker few decades ago... I guess it's still found on very expensive/specialist software which hasn't become entirely service/cloud-based.
I think Autodesk still uses it. I vaguely recall running into some trouble with the FlexLM service and Autodesk Inventor when I still worked as a Windows admin/helpdesk monkey.
I expect the purpose of enterprise license management software like this is less to prevent unlicensed use (which is basically impossible) and more to help organizations track their license usage and stay compliant with whatever the terms are.
It's a beautiful comment though, and an interesting scheme that could potentially break relatively easily.
In my experience, the license manager usually goes out to lunch at the most inopportune moment – usually before some important deadline, coincident with IT support (or anyone who is capable of fixing the license manager) being out of the office for an extended period.
They regularly do "license compliance shakedowns". This is not some trade secret, lots of ISV's do it. So the following is describing broadly how ISV's do it and nothing specific to Flexera.
The way it works is to have a licensing model not enforced perfectly by the DRM. Sell licenses per user, per machine, but allow usage outside that in some way. Make it the customer's duty to enforce license usage instead of the vendor.
Wait a while. Sales comes back and runs an audit, they see more users than licensed in the last X amount of time and require a "true up" fee before more licenses can be sold, or possibly under threat of terminating existing licenses.
The intent is to use the threat of disruption to the business as leverage to cough up more revenue than the customer planned to provide initially per their license agreement.
It is shady, but it works, and a widespread practice.
Assuming the original version from 2007 was guaranteed to be internal only, it's not looking good for whoever decided to expose the knowledge base. Bonus points for outsourcing to a third party support forum so we can admire the self-pwn while they struggle to find who has admin privileges to take it down. How much was that MBA's bonus?
Back in my days of programming shiny round discs, we had a client request to put a time bomb in an interactive CD-ROM. To test it, we adjusted the date on the computer that did our MPEG-2 encoding for DVD. As was bound to happen, the date did not get reset to current time, so that some DVD encodes were encoded in the future. It took so many calls back&forth with support to figure out why these files were misbehaving.
TL;DR becareful when adjusting the dates as there may be unintended consequences
I work in Security and we talk about barrier management. A security barrier is be something you implement to avoid a certain hazard to begin traversing your bowtie risk model (google it).
This particular case of doing a technical check by chcking files" timestamp for timestamps set in the future is NOT a security reason. It is a license compliance check, but has nothing to do with security.
Also, if I were a customer of this company which apparently sells me IT Lifecycle tools that should help me with IT cataloging and omventory, I would be livid if the solution stopped working because it had identified "bad date" files somewhere in my IT landscape. I would migrate the hell away from it there are plenty of other vendors.
The customers for this software are companies like Cadence or Synoptics, who then use it to encourage license compliance by their customers. As a Cadence customer, my employer could use strace to observe the license daemon behavior and figure out how to cheat, but we're not at all interested in doing so, both from an ethical position and as a matter of maintaining a long term relationship.
We have dedicated VMs to host the license daemons, so the failure scenarios proposed are unlikely: we've experienced - and corrected - time skews, but they didn't come close to affecting the license servers. Maintaining the license servers are an accepted part of the license cost.
the flexlm usecase is: protect revenue for vendors that sell into large companies/organizations by making drm that is sufficiently annoying to defeat and/or live with in a degraded state such that it's more annoying than dealing with internal bureaucracy to get accounts payable and information technology to actually pay the software vendor.
saas of course just threatens to turn things off when the bill isn't paid.
it's how big organizations work, nothing happens until it's annoying.
Sadly, my experience with FLEXlm has been far from fascinating. Matlab uses it, and Matlab has some weird license types (that we use) that don't map well to FLEXlm, so they approximate it in odd ways.
I build (internal only) Debian packages for Matlab and FLEXlm, and admin the license server. I've seen far more of FLEXlm than I care to.
Mathworks made the mistake once of asking for my feedback about their product, from a sysadmin's perspective. They received about three earfuls from me, about half of which was dedicated to my disdain for FLEXlm.
FLEXlm seems simple on the surface, but has poor and outdated documentation (even once you find and read through the 300-400 page tome that's floating around) and is a pain to debug when under fire.
We have it running well enough now, but the road to get there should frankly embarrass those who ship (and/or rely on) the software today. Frustratingly, Mathworks' response to my feedback largely boiled down to "it's 3rd party software, so we can't do anything about it." As if FLEXlm were a force of nature, and there were no viable alternate models for physics. Not a good look.
Ha. Files that won’t be made for >24hr according to your system clock in important directories will flag for abuse. Good to know how to screw with your users I guess?
I don’t know much about DRM methods, but I assume this is a Windows95-level weak one?
> I don’t know much about DRM methods, but I assume this is a Windows95-level weak one?
Checking for files-from-the-future as evidence of clock-tampering is certainly not a new technique - and I'm sure it predates Windows 95.
I am familiar with a slightly improved version of the technique: rather than checking actual filesystem files, instead the DRM opened the HDD as a raw device and would write multiple redundant copies of timestamps and usage logs to unallocated parts of the disk - so even restoring a HDD (at the filesystem level) wouldn't be enough to make the DRM system think it was back-in-the-past. You'd have to do a raw low-level HDD restore that included the state of unallocated - but written - disk contents. I gather it would also raise a fuss if it couldn't find any of its previously written logs either.
...I don't know what happens if you try to run the software on a disk with zero free disk space, however.
I think it was used by some Macromedia titles in the late 1990s - or software of that variety.
People assume that DRM is way stronger than it actually is. Most DRM for engineering software (>$20k per license) is easily defeated by just changing your MAC ID to match.
Using a special MAC ID is way more convenient each time you buy a new workstation, or i.e. get it back with new components on warranty, or whatever, than waiting days or weeks for support to generate new keys.
But yeah, it's 2021, and most DRM is pathetic. Hardware keys are honestly the only truly effective DRM. (Although re hardware keys: Very annoying when you have 5+ softwares and need 5+ USB ports ... perhaps someone should create a bluetooth based DRM dongle or something like that.)
The target audience of FLEXlm is large companies with the ability to pay for many licenses of expensive per-seat software. For instance, MATLAB, AutoCAD, and various commercial FPGA and hardware design tools (Altera, Xilinx, Synopsis, etc.), etc. use FLEXlm.
So the threat model isn't really folks who are pirating any of this software off random warez sites and finding a crack - those users wouldn't be able to pay for a legitimate license anyway, so it's not like you're really losing profit from them.
This is more of a "locks keep honest people honest" licensing scheme. Your IT department is unlikely to set up a large-scale system for distributing cracks, so it makes sure that a company that can afford it and is willing to pay for it is paying for the right number of licenses. But just like mostly-well-meaning people might wander into a place without locks, mostly-well-meaning people might "temporarily" forget to get a proper license for a new hire and then forget to ever fix it, or put the software on a shared drive, or never get around to doing the paperwork to buy a renewal, or whatever. Having any license-checking scheme at all makes them remember to do that.
MATLAB, for instance, currently sells a "standard" license for $2,150, not counting annual support costs. They also sell a "home" license for $149. By doing that, they're already banking on the fact that no serious company's IT department is going to just buy a bunch of "home" licenses and save themselves 93% of the licensing cost. They clearly don't need the DRM for the last 7% to be foolproof.
I remember the date trick, many computers were set at the wrong date back then for that reason.
But nowadays, a computer at the wrong date is pretty much unusable because of certificates, so much that it has become one of the typical tech support question, just after "is it plugged in".
[+] [-] codetrotter|4 years ago|reply
On a related note I remember many years ago when I was using Windows, and there was a third-party utility to monitor the registry for changes.
I only had the trial version of the utility, but using the utility itself I found that they were storing information in the registry about when the trial would expire. So I was able to use the utility to discover and defeat the trial protection of itself.
So that was cool in and of itself. But I also found that, even though this was in a time before most software would do online checks, many pieces of software were able to know that the trial had expired even if I tried things like setting the clock back or removing registry entries they had created.
Probably some of those pieces of software were doing similar things to the one mentioned in the OP. But it never occurred to me at the time. I’m not even sure I would have thought of this even today if I were to try it.
But these days I use software that’s open source for a lot of things instead, and where I need proprietary software I pay for it instead. If it’s proprietary and not worth the money then it’s not worth using either. Though I am still sad that Adobe switched to a subscription based payment which I ended up not being able to afford and don’t want to sign up for again because of their horrible billing practices. So I am stuck not being able to run Adobe software even though I would have liked to.
[+] [-] phire|4 years ago|reply
They could get very creative about where the trial end date could be hidden. They could write it to random blocks of the fat32 partition marked as "free". They could even find unallocated blocks outside of the partition table and write it there.
Or you could write it to the contents of a file without going though the regular file APIs, so it's modification date wouldn't change.
As long as just one copy of the trial end date stays intact, it can simply take the latest one.
[+] [-] Causality1|4 years ago|reply
I believe a full version of Opera was eventually released but it took a very long time.
[+] [-] alternatetwo|4 years ago|reply
Of course that's all rather silly since a 1 byte change in WinMain also defeats this, but that requires modifying the program ...
[+] [-] Benjamin_Dobell|4 years ago|reply
This is why I used to feel bad for Hex Rays / IDA Pro. When your product is a disassembler, there's bound to be someone in your target audience capable of cracking your software.
P.S. Don't use a cracked IDA Pro. Checkout Hopper instead. It's reasonably priced and really solid software. Been using it on and off for years.
[+] [-] ChuckMcM|4 years ago|reply
[+] [-] sneak|4 years ago|reply
Blackmagic Davinci Resolve is pay-once-for-life, works on linux, and is better than Premiere.
Even if it were only equally good, not being subscriptionware means I'm a loyal user.
[+] [-] taitems|4 years ago|reply
[+] [-] cantrevealname|4 years ago|reply
FLEXlm was originally written by just one guy. I think I remember his name -- his initials are M.C. if anyone would like to confirm that I'm recalling correctly. When he sold his stake he got ~$10 million. The software went through many ownership changes. I think this was when it went from Globetrotter to Macrovision. When he got his ~$10 million he gave about $2 million to his current employees as a gift. I thought it was a very honorable thing. He had no legal obligation to do so.
This isn't inside information; it was all published somewhere but it's funny how the web can "forget" things after a couple decades.
EDIT: I found something that at least confirms the name I was remembering, Matt Christiano, and a history[1] of license management that he wrote in 2007.
[1] http://reprisesoftware.com/blog/2007/01/a-brief-history-of-s...
[+] [-] dane-pgp|4 years ago|reply
It's like the word "protection" in the terms "copy protection" or "content protection". Those at least make clear that it is not the user who is being protected, but it's still disingenuous to suggest that a file is somehow harmed by being copied. If anything, having more copies of a file only makes it safer.
[+] [-] floatingatoll|4 years ago|reply
"Does having more copies of a file generally improve revenue security?" is probably a solid "no, not generally" with some very interesting exceptions.
[+] [-] chasil|4 years ago|reply
A string dump of the binary would likely show these directories, and even if they were obfuscated, an strace would reveal them as they probed the file dates.
[+] [-] chii|4 years ago|reply
[+] [-] da39a3ee|4 years ago|reply
It's the same in medium-size and large companies with "legal". All you need say is "Oh that's required by legal" and no-one applies any rational scrutiny to it because for some reason the "legal" and "security" departments are considered to house minds far superior to those of anyone else.
[+] [-] I_Byte|4 years ago|reply
https://web.archive.org/web/20210829234321/https://community...
[+] [-] SilverRed|4 years ago|reply
[+] [-] eitland|4 years ago|reply
It turned out the server didn't register them in when someone signed off.
So after troubleshooting we ended up doing exactly what this trick is protecting against, setting the server clock to somewhere in the future.
Worked nicely back then.
This was just as I left that place, a few weeks later my college told me they had found the problem: our previous it manager had installed a new instance of the license server on a faster machine. He had not installed the license files (nor documented it anywhere) though so the new server would just say thank you and discard the license token whenever anyone signed out.
[+] [-] userbinator|4 years ago|reply
[+] [-] rathel|4 years ago|reply
[+] [-] krylon|4 years ago|reply
[+] [-] musicale|4 years ago|reply
It's a beautiful comment though, and an interesting scheme that could potentially break relatively easily.
In my experience, the license manager usually goes out to lunch at the most inopportune moment – usually before some important deadline, coincident with IT support (or anyone who is capable of fixing the license manager) being out of the office for an extended period.
[+] [-] habeebtc|4 years ago|reply
They regularly do "license compliance shakedowns". This is not some trade secret, lots of ISV's do it. So the following is describing broadly how ISV's do it and nothing specific to Flexera.
The way it works is to have a licensing model not enforced perfectly by the DRM. Sell licenses per user, per machine, but allow usage outside that in some way. Make it the customer's duty to enforce license usage instead of the vendor.
Wait a while. Sales comes back and runs an audit, they see more users than licensed in the last X amount of time and require a "true up" fee before more licenses can be sold, or possibly under threat of terminating existing licenses.
The intent is to use the threat of disruption to the business as leverage to cough up more revenue than the customer planned to provide initially per their license agreement.
It is shady, but it works, and a widespread practice.
[+] [-] kevin_thibedeau|4 years ago|reply
[+] [-] dylan604|4 years ago|reply
TL;DR becareful when adjusting the dates as there may be unintended consequences
[+] [-] unixhero|4 years ago|reply
This particular case of doing a technical check by chcking files" timestamp for timestamps set in the future is NOT a security reason. It is a license compliance check, but has nothing to do with security.
Also, if I were a customer of this company which apparently sells me IT Lifecycle tools that should help me with IT cataloging and omventory, I would be livid if the solution stopped working because it had identified "bad date" files somewhere in my IT landscape. I would migrate the hell away from it there are plenty of other vendors.
[+] [-] thyrsus|4 years ago|reply
We have dedicated VMs to host the license daemons, so the failure scenarios proposed are unlikely: we've experienced - and corrected - time skews, but they didn't come close to affecting the license servers. Maintaining the license servers are an accepted part of the license cost.
[+] [-] robertlagrant|4 years ago|reply
I regret googling it.
[+] [-] gmiller123456|4 years ago|reply
1. Incorrectly set clock, corrected after files were modified.
2. Slightly corrupt file system.
3. Copied files from another system.
4. You're testing your own DRM.
5. Other software doing similar crazy things you're unaware of.
6. Testing software that needs the date changed for certain scenarios.
7. Bug in time sync software.
Others?
[+] [-] a-dub|4 years ago|reply
saas of course just threatens to turn things off when the bill isn't paid.
it's how big organizations work, nothing happens until it's annoying.
[+] [-] a-dub|4 years ago|reply
[+] [-] analognoise|4 years ago|reply
[+] [-] Alexqw85|4 years ago|reply
I build (internal only) Debian packages for Matlab and FLEXlm, and admin the license server. I've seen far more of FLEXlm than I care to.
Mathworks made the mistake once of asking for my feedback about their product, from a sysadmin's perspective. They received about three earfuls from me, about half of which was dedicated to my disdain for FLEXlm.
FLEXlm seems simple on the surface, but has poor and outdated documentation (even once you find and read through the 300-400 page tome that's floating around) and is a pain to debug when under fire.
We have it running well enough now, but the road to get there should frankly embarrass those who ship (and/or rely on) the software today. Frustratingly, Mathworks' response to my feedback largely boiled down to "it's 3rd party software, so we can't do anything about it." As if FLEXlm were a force of nature, and there were no viable alternate models for physics. Not a good look.
[+] [-] userbinator|4 years ago|reply
[+] [-] SV_BubbleTime|4 years ago|reply
I don’t know much about DRM methods, but I assume this is a Windows95-level weak one?
[+] [-] DaiPlusPlus|4 years ago|reply
Checking for files-from-the-future as evidence of clock-tampering is certainly not a new technique - and I'm sure it predates Windows 95.
I am familiar with a slightly improved version of the technique: rather than checking actual filesystem files, instead the DRM opened the HDD as a raw device and would write multiple redundant copies of timestamps and usage logs to unallocated parts of the disk - so even restoring a HDD (at the filesystem level) wouldn't be enough to make the DRM system think it was back-in-the-past. You'd have to do a raw low-level HDD restore that included the state of unallocated - but written - disk contents. I gather it would also raise a fuss if it couldn't find any of its previously written logs either.
...I don't know what happens if you try to run the software on a disk with zero free disk space, however.
I think it was used by some Macromedia titles in the late 1990s - or software of that variety.
[+] [-] aetherspawn|4 years ago|reply
Using a special MAC ID is way more convenient each time you buy a new workstation, or i.e. get it back with new components on warranty, or whatever, than waiting days or weeks for support to generate new keys.
But yeah, it's 2021, and most DRM is pathetic. Hardware keys are honestly the only truly effective DRM. (Although re hardware keys: Very annoying when you have 5+ softwares and need 5+ USB ports ... perhaps someone should create a bluetooth based DRM dongle or something like that.)
[+] [-] geofft|4 years ago|reply
So the threat model isn't really folks who are pirating any of this software off random warez sites and finding a crack - those users wouldn't be able to pay for a legitimate license anyway, so it's not like you're really losing profit from them.
This is more of a "locks keep honest people honest" licensing scheme. Your IT department is unlikely to set up a large-scale system for distributing cracks, so it makes sure that a company that can afford it and is willing to pay for it is paying for the right number of licenses. But just like mostly-well-meaning people might wander into a place without locks, mostly-well-meaning people might "temporarily" forget to get a proper license for a new hire and then forget to ever fix it, or put the software on a shared drive, or never get around to doing the paperwork to buy a renewal, or whatever. Having any license-checking scheme at all makes them remember to do that.
MATLAB, for instance, currently sells a "standard" license for $2,150, not counting annual support costs. They also sell a "home" license for $149. By doing that, they're already banking on the fact that no serious company's IT department is going to just buy a bunch of "home" licenses and save themselves 93% of the licensing cost. They clearly don't need the DRM for the last 7% to be foolproof.
[+] [-] GuB-42|4 years ago|reply
But nowadays, a computer at the wrong date is pretty much unusable because of certificates, so much that it has become one of the typical tech support question, just after "is it plugged in".