Improved Error Reporting for skunked CD encryption tool

[+cubanismo]

TL;DR: @ggn, here's a patch that improves the error reporting in your/reboot's skunked CD encryption program.

 

Whimsical story version: I encrypted my first CD on the skunk this weekend, and quadruple checked everything to make sure I got correct reads and had the real hashes of all the tracks.  To my surprise,  I got 4 identical keys running the encryption program twice on two different CDs.  So what's all this about error reporting?  Well, it didn't go completely smoothly.  It got pretty hot here on Saturday, and I had several encryption runs fail entirely.  They'd just get stuck on one of the later tracks printing one of the "CD error [1st/2nd] pass retry #1..." error messages.  Well, those lie: It could be retry #24523523 and it still prints retry #1, and I was in fact stuck in such a situation as far as I could tell.  No better time than a HW failure to bolsture your error handling though, so I whipped up a patch to print more useful error messages that night, but by then of course it had cooled down and I couldn't get any failures.  I ran it all day Sunday with the windows closed though, and eventually got it to actually test the error handling in both the scan and md5 hashing passes, including multiple failures in a row on some tracks a few times.  I tested the overflow case (See the patch) by artificially initializing the error count to 99.  Even after some cases where I got a few dozen errors + retries, I ended up with the right encryption key, so the program seems pretty robust as long as it can eventually get a good read.  I was pretty impressed.

 

Sample output seen on screen, after 5 read errors on track 10 during the md5 pass, while currently on the md5 pass for track 11:

 

Before:

CD error 2nd pass retry #1...

No way to tell if this track has failed, how many times it has failed, if you're stuck in a never-ending retry loop, if the program has just frozen entirely, etc.

 

After:

CD err trk 10 2nd pass retry  5...

It's easily deduced that track 10 was the issue, not the current track 11 (so far), and track 10 had to retry a rather high 5 times, but it eventually got a valid read.

0001-Display-better-error-messages.patch

[ggn]

10 years old project, whew! I literally had to dust off the cowebs from the source :). In any case, patch applied and binary rebuilt: cden_skunk_1.1.zip

 

@CyranoJ is the server meister these days so I'm sure it'll appear in Reboot's site soon.

 

(Since this thread started with a whimsical story, allow me to contribute one:

 

I have never owned a JagCD and probably never will. So how did I ever manage to make this thing? Well, @sh3-rg was the only one of has who owned a JagCD at that point, and we were looking into producing our own CD run of a title, doesn't matter which really.

 

The first CD run we made was made with the aid of Jagware (I think @Fredifredo encrypted it for us but memory is very hazy. Thanks to whoever did it!). We really weren't keen on finding old machines with parallel ports and making a custom cable just for the sake of encrypting a damn CD! Especially not when we had those shiny new skunkboards that were supposed to transfer data to and from the machine!

 

So I took a look at the source code Matthias Domin had on his site and took a wild stab at adding skunklib and initiating a transfer using skunk functions. I sent that to @sh3-rg and of course it didn't work! This triggered a pretty wild session of me debugging using colours I stuck into the BG register, and @sh3-rg then trying the binary and telling me what colour he would see when the program froze. I can't stress how confusing this was because a) @sh3-rg is colour blind so haha nice try I used some weird colour, b) I was assuming that the colour format for BG was something else than it actually was (something like RGB16 vs CRY? Really can't remember) so the colours I would get back looked nothing like the ones I assumed I was setting!

 

In the end someone suggested ROMWIDTH was the issue (either @sh3-rg, @SCPCD or @Zerosquare. Maybe perhaps someone else? Sorry, it's been so long!). Bloody ROMWIDTH, it's always that thing when things go South. Anyway, saving and restoring it before the skunkboard transfer magically made things work! Of course we hit another snag, the transfer would freeze for some unknown reason. I guesstimated that it might be the transfer chunk size so I set that to a very low value and it worked. We could have tried increasing the chunk size so it would transfer the key faster but in the end we shrugged it off, closed all the source code and command line tabs, and went and did other things...

 

So there you go, just an amusing story for interviews I guess(or something to tell to young know-it-alls who think they know stuff!): I once debugged a piece of code 3000km away from the actual machine by changing the palette registers)