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

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #197710 : Transwarp v0.64

2020-11-22 17:12

Krill

Registered: Apr 2002
Posts: 2839

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

2020-11-25 16:14

Dano

Registered: Jul 2004
Posts: 226

@bigfoot: yeah me, totally!

2020-11-25 21:20

BiGFooT

Registered: Mar 2002
Posts: 31

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: 2839

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

2020-11-25 22:03

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.

2020-11-25 22:11

Krill

Registered: Apr 2002
Posts: 2839

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

2020-11-25 22:14

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 ;)

2020-11-25 23:40

JackAsser

Registered: Jun 2002
Posts: 1989

@bigfoot: thanks!!

2020-11-25 23:47

Krill

Registered: Apr 2002
Posts: 2839

Quoting BiGFooT

Byte 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

2020-11-27 12:32

Krill

Registered: Apr 2002
Posts: 2839

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 like

ldx #$0a ; CLKOUT + DATOUT
sax $1800; 2 data bits
asl
sax $1800; 2 more data bits

sending multiple bitpairs over serial can be done quicker.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 18 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

metalux/G★P
Scrap/Genesis Project
Apollyon/ALD
Clown
Martin Piper
Mr.Ice
Mason/Unicess
tempest/extend
Guests online: 141

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)

Top onefile Demos

1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Diskmag Editors

1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

Page generated in: 0.107 sec.