[CSDb] - User Forums - Release id #197710 : Transwarp v0.64

Loading "CIPHER" and "CHALLENGE" file without a good parameter respond with
"71,DIR ERROR,00,00" and was the first hint to where to search. Block reading
directory with AR6 monitor (@BR 12 01 1000) and checking the entries showed
an interesting Transwarp structure after the filename, starting after the
"TW" marker. A quick trial with other files in the directory was helpful to
find out which means what. Byte 2&3 contains the load address, 4&5 is the end
andress.

(Example:
LOAD"ALGODANCER",8,8

SEARCHING FOR ALGODANCER
LOADING $0801-$B626: 2.6S, 16.9KB/S, 43X

.:1090 A0 A0 A0 A0 A0 54 57 57
.:1098 14 E2 01 08 26 B6 CB 00
)

It was totally different for the "CIPHERED" file. So I had to figure out the
"encryption" for this structure. It was pretty easy as you can load with the
PI parameter. It loads between $0801 and $517C, so the structure must be
this: ?? ?? 01 08 7C 51 ??.
The xor value was $DA, coming from $DB ^ $01, $D2 ^ $08,… easy enough, right?
Of course, this was a red herring... Finding the xor value of "CHALLENGE" was
just a few seconds ($DF ^ $01, $D6 ^ $08,…) and it was $DE. Based on the
structure it loads from $0801 to $D000. Okay, need to find out the rest.

The value of PI is hardcoded in the rom at $AEA8 as 82 49 0F DA A1.
Hmm… I saw that $DA just a second before! What if we change it to $DE?

LDA #$A8
LDY #$AE
JSR $BBA2
LDA #$DE
STA $64
JMP $BDDD

The result is in the memory at $0100 as 3.14159265. When you try to load
"CHALLENGE" you get the usual "71,DIR ERROR,00,00". Damn. This was the point
where the real work started and Krill’s released source code was so helpful.
Getting a label list for the compiled binary was a huge time saver as like
the various "key" labels to start with. Knowing that there is only two
"drive.key" variable (0,3) present I’ve tried to find out what is happening.
The directory encryption is based on the "key0" variable in
"drive.prepareload" fuction. It’s a plain xor, so what sets it? It’s at the
end of function "prepareload". Dissecting this function was fun, it sets up
the encryption keys and bit scrambling. "key3" came from "GRBPTR" xored with
value $C3. "GRBPTR" was set up in the same function from "floatbuffer", a
few JSR’s after proved that this variable is not a pointer at all.

Function "setscrable" divides the "GRBPTR" by 6 and the remainder used as
the offset of scrambling tables and called 4 times in total. Knowing this
decrypting the first half of the "key" was easy:
$8249 = 33353
33353 % 6 = 5; int(33353 / 6 ) = 5558
5558 % 6 = 2; int(5558 / 6 ) = 926
926 % 6 = 2; int(926 / 6 ) = 154
154 % 6 = 4; int(154 / 6 ) = 25

Based on this the "scrable0..3" offsets is 5,2,2,4, the value for "key3" is
25 ($19), so "key3" = $19 ^ $C3 which is $DA, the xor value of the directory
entry. We need a number for the "CHALLENGE" file $DE xor value, it’s
$DE ^ $C3 = $1D. We can create a new number from this!

((($1D * 6 + 4) * 6 + 2) * 6 + 2) * 6 + 5 = $9689

Asking our beloved breadbox with the previous floating number routine it
answers -2244608. Testing the "CHALLENGE" file with this parameter starts
loading. Now ready for next step…

Inspecting the source code for scramble labels pointed out two functions:
"receivchunk" (s0..2) and "recvblkbuff" (s3) and there’s a "key2" label just
before latter. Nice! Killing "recvblkbuff" at $e4bc, filling the memory and
loading "ALGODANCER" proved the function is not necessary to load and thus
there is no need to care about "key2". What else? "key3" at drive code with
some kind of buffer fizzling… As the recvblkbuff just killed, skip it. Okay,
"key4" and "scramble0..2" awaits. You should ask the question, what is
scramble? Transwarp can swap bits 10,32,54 in any order during transfer.
For example it’s possible to store a byte in bit order of 76105432,
761321054, etc.

It was a mere hour to create a converter to GCR sector, rip out decodetable,
re-implement the drive "readloop" and breadbox "receivchunk" function in PHP.
With this base it’s possible to decode and read the first $c0 byte of any
Transwarp. Dumping track 20 sector 0 showed that it’s the beginning of
"ALGODANCER". Bruteforcing the "CHALLENGE" for "key4" and "scramble0..2"
involved a neat little trick. Knowing that the program loads to basic start
address and occupy almost the whole memory one can assume that the 2nd byte
is $08 (next basic address), 5th is $9e (SYS basic token) and 7th-9th is a
PETSCII number. Just 4 loops (55296 iterations in total) and a compare later
got two hits for "CHALLENGE".

HIT: S0: 5 S1: 5 S2: 1 K4: a3 2b 08 e3 07 9e 32 30 36 39 35 80 2d 1d 1d ...
HIT: S0: 5 S1: 4 S2: 1 K4: ac 24 08 e3 07 9e 32 30 39 36 3a 8f 22 14 14 ...

Checking both result reveals that the 2nd hit is our valid key. Listing the
result showed something interesting.

2019 SMB.64, V1.2

With the help of CSDB, searching 2019 releases with name containing "v1.2" in
it show a mere list of 8 releases. "Super Mario Bros 64 V1.2" was the best
match, digging out the file from the deep proved that it’s the one you’re
looking for. With this information the rest is guessable again as the output
is already known. In about an hour later, implementing the "recvblkbuff" and
"bufferdata" related wheels the next cracker for key2..3 and scramble3 was
ready. It’s a little bit slower with the possible 393216 iterations but the
concepts remained the same. Decode everything whit known information and
matching the unknown with brute force. Surprisingly there was 3 hit with
different "key2" to short match:

HIT: S0: 5 S1: 4 S2: 1 S3: 0 K2: 13 K3: fa K4: ac a9 08 c9 e2 b0 dd ...
HIT: S0: 5 S1: 4 S2: 1 S3: 0 K2: 1f K3: fa K4: ac a9 08 c9 e2 b0 dd ...
HIT: S0: 5 S1: 4 S2: 1 S3: 0 K2: 75 K3: fa K4: ac a9 08 c9 e2 b0 dd ...

Comparing the whole output reveals that the only valid result was the latest.

With every information available we can solve the puzzle:

Scramble 0..3: 5,4,1,0
Key0: $1D
Key2..4: $75, $FA, $AC
((($1D * 6 + 0) * 6 + 1) * 6 + 4) * 6 + 5 = $9311
The floating point number thus the key we’re looking for is

$93,$11,$75,$FA,$AC

Converting this number with our beloved breadbin show the number 297903.834.
Great! Loading "CHALLENGE" with this parameter… is a fail. DAMN!

It was necessary to write a short program with more precision which reveals
the number 297903.83349609. Trimming the parameter by last digits got the
final answer is

297903.83349

The package with sources and the text is downloadable here: http://bigfootinformatika.hu/challenge.zip

2020-11-25 21:39

Shine

Registered: Jul 2012
Posts: 327

WOW ... better than a good Sherlock Holmes Story!
What a dedication! Thanks a lot ... even i understood only 5% (maybe!) :)

2020-11-25 21:45

Krill

Registered: Apr 2002
Posts: 2828

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. :)