The accompanying interview with the founder of Quaid Software who defeated the Vault Prolok is also very interesting:

[0] https://martypc.blogspot.com/2024/09/pc-floppy-copy-protecti...

The scheme to damage hardware or data when Prolok Plus thinks someone's using a pirated copy seems ludicrous. Who wants to deal with the liability when this goes wrong due to a bug or unexpected circumstances?

It seems like it only deletes pirated software. It is hard to understand what they actually claimed it to do without there being an actual source.

"Bright" ideas were and always will be a thing in copy protection mechanisms.

https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... for a much newer example, albeit non-destructive. I vaguely remember some much more recent destructive examples, not sure if implemented or threatened, but I might be confusing things.

Edit: Found the incident I was thinking about using Gemini. A flight sim addon company FSLabs shipped malware with their installer. It didn't wipe data, it stole your Chrome password manager instead. https://www.reddit.com/r/flightsim/comments/xa58qz/a_retrosp... is a reddit summary, https://forums.flightsimlabs.com/index.php?%2Fannouncement%2... the company explaining/justifying what they did and why (TL;DR it was meant to be a targeted attack against some specific pirates).

A similar, even higher profile case that shook the electronics industry around a decade ago was chip manufacturer FTDI releasing an update to their drivers that would detect and semi-permanently brick clones of FTDI USB serial bridge chips [1]. The bricking was performed by setting the USB product ID to zero, preventing Windows and macOS from detecting the device at all; the Linux drivers quickly got updated to recognize the new PID, allowing for the development of unbricking tools. Somewhat ironically, the detection relied on errata of the original parts that the clones fixed [2].

The backlash to this measure was massive, as many legitimate products turned out to use counterfeit FTDI parts without the manufacturers' awareness due to unreliable supply chains. Microsoft quickly pulled the update but FTDI seemed not to care for the most part, eventually releasing another similar update a couple of years later that would deliberately corrupt all data sent through clone chips.

[1]: https://en.wikipedia.org/wiki/FTDI#Driver_controversy

[2]: https://github.com/therealdreg/ftdibrick#diving-deep

The whole better way electronics saga as well.

For a old geek like me, its a good interesting read.

My first consulting gig was writing a copy protection mechanism (floppy-based) for a DOS application. So this brings back memories.

ha I had one of those "Copy II PC Option Board" and remember TRANSCOPY

it could pretty much copy anything

copying disks in 1980s was like radar vs radar-detector battle, always escalating

https://www.robcraig.com/wiki/copy2pc-option-board-status/

Maybe my reading comprehension can't grok it, but it appears defeat-able by MFM reading and recreation like almost every other form of "special disk" modification. Kyroflux, greaseweazle, Copy II PC Option Board, etc.

My understanding is that it worked by doing read/write on a known bad sector to verify that the physical defect is there. Replicating that on normal discs sounds hard.

The problem with all these protection schemes is somewhere in the code they could usually be bypassed by turning a JNE to an unconditional jump.

So you had to add code to detect modifications which itself could be bypassed.

>So you had to add code to detect modifications which itself could be bypassed.

Right, which is why DRM schemes aren't typically implemented in a straightforward way. Instead license checks are added to critical program logic so you can't easily skip it, anti-tamper/debug is added to thwart runtime analysis, and on top of all of this the code is obfuscated to thwart analysis even further. You might be eventually be able to figure it out, but it's designed to make it enough of a slog that nobody bothers to work through it all.