Receiving FLEXlm Error -88,309: System Clock Has Been Set Back (2020)

I believe a full version of Opera was eventually released but it took a very long time.

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.

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.

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.

Of course that's all rather silly since a 1 byte change in WinMain also defeats this, but that requires modifying the program ...

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.

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.

"Does having more copies of a file generally improve revenue security?" is probably a solid "no, not generally" with some very interesting exceptions.

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.

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.

I regret googling it.

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.

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.)

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.

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.