And they just flat out told everyone who pointed it out -- nope, you're looking at it wrong; and anyway we already paid those consultants so we'd better use it, what?
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.
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.
That feature sounds amazing! I tried searching wayback etc but wasn't able to find any more details. Do you happen to know of any screenshots / deeper descriptions for it?
Perhaps we could nerd snipe Marginalia Search to add it :)
> Slumber is a terminal-based HTTP client, built for interacting with REST and other HTTP clients
I wonder what that means -- I looked around the docs but didn't see that it interacts with other clients. I thought maybe it would show a generated curl command or something along those lines. But perhaps it's just a typo for HTTP servers?
I don't think it matters. It's their store, and they can do it. I suspect that if Inkwell was trademarked (which it sounds like it's not), they could bully through the reviewers. Apple certainly didn't have any legal standing to deny my app name, and I likely could have bullied them into approving it, but it wasn't worth the agita.
I do have a registered trademark (not for an app name, though). It's a really painful process. I can see why folks wouldn't want to go through that for every app name. I don't bother, with most of mine, but I do search for other registered marks.