| |
Krill
Registered: Apr 2002
Posts: 2825 |
Release id #197710 : Transwarp v0.64
General Q&A thread, also report problems and error logs here. |
|
... 162 posts hidden. Click here to view all posts....
|
| |
BiGFooT
Registered: Mar 2002
Posts: 31 |
Quote: Excellent work! =)
Now i wonder, how hard is it now (and would have been before your work) to find a key for a file with an unknown plaintext (which also can't be guessed that early after just finding a few start bytes)?
I knew that picking a somewhat known file with known properties would ease it quite a bit, on top of the many sidechannels to attack, and of course the encryption isn't very strong to start with. But i didn't want to make it too tough as it might have spoiled the fun. :)
It's only easy when you know what you want to find.
Plaintext is somewhat easy as you can count and match the characters. A binary however with a different start address and unknown entry point... would be much harder. Still, the first 256*6*6*6 iteration is not that much. For example you can guess the key with bitmap graphics pretty easily just by visualizing the memory and do a few trial and errors. Packed data is the worst to recover.
So yes, in this exact case "cracking" the key was fast, but less possibilities means less necessary resources to do so.
If the basic line got no hint then you're still able to guess it. Comparing with known depackers, or a parser based on the revealed information (validator for basic code, or machine code) as everything have some kind of pattern. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Ok, so who'd be in for a second challenge, then, with a high-entropy plaintext file that is still sensible (and rewarding to decrypt, not just random bitsalad)? :) |
| |
BiGFooT
Registered: Mar 2002
Posts: 31 |
Quote: Ok, so who'd be in for a second challenge, then, with a high-entropy plaintext file that is still sensible (and rewarding to decrypt, not just random bitsalad)? :)
I'm in with https://en.wikipedia.org/wiki/Frequency_analysis ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
@bigfoot: thanks!! |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting BiGFooTByte 2&3 contains the load address, 4&5 is the end
andress. Worth noting here, imho, is that Byte 1 contains a CRC8 checksum over the entire file. This is only computed (because slow) and checked when there are block checksum errors with retries, but ultimately a successful file load.
It does happen that funky drives or semi-broken disks load successfully eventually, and this second line of defence decreases the likelihood of false positives (good checksum despite bad data) quite a bit, even with the first line being somewhat more sophisticated than simple byte-wise EOR. :)
Ah, and byte 0 is the file's starting track. :D |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Another trick: JMP ($DD00) for less jitter when reacting to drive signals.
Normally you'd do things like- bit $dd00
bpl/bmi/bvc/bvs - to wait for a state change on the serial bus. This has a jitter of 7 cycles (on PAL, 8 cycles on NTSC/PAL-N because the C-64's CPU is clocked faster than the drive's CPU),
Using JMP ($DD00), this is reduced to 5 (6) cycles of jitter.
$DD01 (the RS232/parallel port bits connected to the user port) needs to be set to output and initialised to the high-byte of a jump table.
So it's trading size for speed, as this jump table is slightly more than $c0 bytes big, due to the incoming bus state bits sitting on bits 7 and 6. (Can of course stuff unrelated stuff into the gaps of this sparse table.)
Using this trick, it is possible to have a minimum of 6 cycles between serial bus signal updates (instead of 8 normally) without requiring further jitter reduction (using the half-variance technique), such that things likeldx #$0a ; CLKOUT + DATOUT
sax $1800; 2 data bits
asl
sax $1800; 2 more data bits sending multiple bitpairs over serial can be done quicker. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Another trick: JMP ($DD00) for less jitter when reacting to drive signals.
Normally you'd do things like- bit $dd00
bpl/bmi/bvc/bvs - to wait for a state change on the serial bus. This has a jitter of 7 cycles (on PAL, 8 cycles on NTSC/PAL-N because the C-64's CPU is clocked faster than the drive's CPU),
Using JMP ($DD00), this is reduced to 5 (6) cycles of jitter.
$DD01 (the RS232/parallel port bits connected to the user port) needs to be set to output and initialised to the high-byte of a jump table.
So it's trading size for speed, as this jump table is slightly more than $c0 bytes big, due to the incoming bus state bits sitting on bits 7 and 6. (Can of course stuff unrelated stuff into the gaps of this sparse table.)
Using this trick, it is possible to have a minimum of 6 cycles between serial bus signal updates (instead of 8 normally) without requiring further jitter reduction (using the half-variance technique), such that things likeldx #$0a ; CLKOUT + DATOUT
sax $1800; 2 data bits
asl
sax $1800; 2 more data bits sending multiple bitpairs over serial can be done quicker.
Neat trick. Love it! Also like how you use the word ’stuff’ both as a verb and a noun in the same sentence! ❤️ Almost like the Smurfs smurfing smurfs up. |
| |
Richard
Registered: Dec 2001
Posts: 619 |
Transwarp's speed is amazing. It would probably make a great C64 filebrowser/menu system ;) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
User Comment
Submitted by ThunderBlade [PM] on 27 November 2020
I've waited for this since Heureka Sprint. The 64'er magazine had an article on it concluding with "In theory it should be possible to get even faster than that". Proven now! :) Hmm, but (slightly) faster systems than Heureka Sprint have been existing since before it was invented*. =)
It also seems like some conscious concessions were made for Heureka Sprint, paying with slightly slower speed for standard format compatibility. It uses a 70% encoding, not 75% as the original Vorpal (and its knock-off Action Replay Warp*25) does.
Transwarp does the same. If it were not for the intended d64 compatibility, it could use a slightly denser encoding and thus slightly more speed. But that decision was easy, nobody really wants to transfer weirdo g64 images to real disks. :)
* https://www.lemon64.com/forum/viewtopic.php?t=41482 |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting RichardTranswarp's speed is amazing. It would probably make a great C64 filebrowser/menu system ;) Not before there is a built-in 2-rev fallback fastloader for standard format. And that one will probably be somewhere slightly above half the speed of the custom format. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 18 - Next |
