Man, if I were id, I'd sue the hell out of Testdrive for selling me that broken security system...

But it sounds like it wasn't Testdrive's fault; iD implemented it incorrectly. Their phone support weren't issuing the decrypt code, just a simple checksum:

> Described as is, there is no flaw in this process. The secret seed comes from the unlock server, tied to a CHALLENGE/SERIAL that could not be reused. But the hacker team GNOMON found a way.

> The QUAKE unlock program FLOW.EXE that ships on the CD is capable of generating the SERIAL from the CHALLENGE on its own. All it does is check that its own locally-generated SERIAL and the SERIAL entered by the user match! The entire protection mechanism relies on security by obscurity.

▲

codebje 6 hours ago | parent [-]

If the phone support issued the decrypt code, you could just replay that same code for every CD stamped from the same master.

If phone support issued an encrypted decrypt code that could only be used with your challenge code to decrypt the decrypt code, replay wouldn't be as trivial.

Every CD is identical, so no matter how iD went about this there's only ever one decryption key (per title, I assume) and those keys must either have been encoded in iD support's response, or already stored on the CD. TestDrive sold iD on the notion that the process was too hard for hacker groups to reverse engineer, and it wasn't.

	▲	jandrese 4 hours ago \| parent [-]
		There was some replay protection as described in the article, but in the end the system was flawed enough that it didn't matter.