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.
It will still work, at least on windows. That's because it reserves some sectors at the end as hidden sectors that applications can't directly access. source: https://en.wikipedia.org/wiki/Microsoft_Reserved_Partition
This craps itself when you run Grub, which happily scribbles itself to the same area
Why does [insert random program here] need admin rights? Now you know!
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.)
Honestly, I hate all of these things. My employer spends multi-millions on software licenses every year. All these DRM schemes are painful, insulting, and inevitably break at the worst possible moment. We have one box -- legally acquired -- with a hardware dongle, plugged in the back of the machine. Someone smashed it when moving the thing accidentally. Were we inclined, with SEM, TEM, AFM and plenty of x-ray facilities, I'm sure that it's not beyond our ken to crack the sodding thing, and honestly, after that experience I was sorely tempted.
I'm fed up of being treated as a rich criminal by businesses. They want an un-get-out-able subscription agreement, for life, and with "markets made" at every available opportunity, i.e. $METRIC_FUCKTON_OF_MONEY for $MINIMAL_INCREMENTAL features. One commercial FEM solver I use charges per GPU, per CPU, and per year. The whole thing is based on maths invented in my university!
If you're paying bigbucks, try asking for better terms. Explain how painful it is for you, not to pay them, but to not be able to use their software. Maybe it will work.
Yes it is, and while I've not seen any evidence, I suspect that's partially why AutoDesk are changing their subscription model.
As for dongles, you can pay to have them cloned. Claimed turnarounds cheaper and faster that getting them from the software supplier in at least one instance. I've not used it, but godamn was tempting.
I see cracked releases of flexlm software all the time (eg. autodesk products), so it's definitely being cracked.
And that's one of the reasons why I'm glad we used HP servers with internal usb ports for this.
They also use encryption for their IP cores. It's RSA. The private key is conveniently called "rsa_key" in their binary. Which they shipped with symbols. Once you decrypt the IP cores you get the full source code, with original comments, to do with as you please.
It's all for show; the DRM in these "professional" tools is sillier than what games used in the 90s.
HA I may or may not have cracked something similar back in the day. It was using GetIfTable() which meant that you'd need to have a NIC with the exact same name and mac address.
Of course just dumping the output from a licensed machine and injecting it into the memory when needed did the trick.
[1]: I would link CrackWatch but they seem to be down atm. https://www.reddit.com/r/CrackWatch/comments/lnbi5a/crack_wa...
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.
Vendors should be pushing for organization-level licensing. Anything per-user/core/project/etc. is going to require a lot of tracking overhead, and create much more incentives to game and gimmick it. I'm picturing the shops which stagger shifts at sites in different time zones so as to keep the simultaneous user count low, or people buying specific weird hardware to keep core counts low on per-core-licensed software.
If you're just doing organization-level licensing, you can scale all the counting back to a less disruptive and intensive "analytics-only" level, and just use it to inform the next round of negotiated pricing. "We know you have 500 simultaneous users, so we know this package is worth $50,000 per year to you."
That's like 1-2 simulator licenses per year. You really don't know the cost of the software generally being protected by FlexLM do you? When I was working in defense contracting, every new grad that we hired into our FPGA or ASIC groups had to be accompanied by a $100,000/yr budget just to pay for EDA tools for their jobs. For more senior employees who'd generally work more in parallel, it wouldn't be odd to see $300-500k/yr in software licenses budgeted. Because of this, we basically tried to staff as many software engineers as possible on projects as most of what we billed them at was just profit as they're incredibly cheap to employ compared to other engineering disciplines.
FlexLM is annoying, but the things it's usually protecting are so expensive (and often extremely niche use) that companies actively try to find every legal way to avoid paying for it.
Mass-market proprietary software generally has far simpler licensing, purely because their customer lists are far larger relative to their staff. The actual development costs spread out more.