Document Title: [CrazyClimberEncod.html (html file)]
Please note that if anyone does use this info for their own CC emulator
project I do ask that credit be given where credit is due. I'm not
asking for any money, just to be acknowledged in the emulator credits.
It was a LOT of work to crack this:-
As for the decryption algorhythm, a few things; There are two sets of
ROMS in the tant archive (Brian Peek's mirror). One is supposedly the
genuine set, and the other a bootleg. The set I have on my boards seems
to be a hybrid between the two. The program ROMS (7-11) are the same as
the bootleg set and the others seem to be the same as the genuine set.
The encryption on the bootleg set is different to the genuine set. The
following description only applies to the bootleg program ROMs (Only the
program ROMs are encrypted). If you look at ROM11 with a hex editor the
first few bytes should be as follows if you have the right set:-
FE FF FF EE 73 00 A0 96 AC 00 44 54 44 54 44 54
The encryption is quite sophisticated and cannot be decrypted without
dissassembling the code, working out where the data tables are, and then
reassembling. I actually had to write a special Z80
disassembler/unscrambler to do this (This was written on a C64 if you
want the program). ***NOTE: Don't panic! A Z80 emulator program can be
easily modified to decode the encrypted ROMs on the fly. Please don't
ask me for decrypted versions of the ROMs.
On the Z80 there is a pin called M1 or 'machine cycle one'. This pin
indicates when the processor is doing the opcode fetch of an instruction
execution. In other words, for an instruction like a Jump which consists
of 3 bytes, the first byte is the opcode and the following two bytes are
the address to jump to. The M1 pin will only be active while reading the
first byte. The decryption is only applied when the M1 pin is active. in
other words for a Z80 jump instruction:-
ROM bytes xx 00 40 -----> would become C3 00 40 ;xx is encrypted byte.
^^ ^^
Note that the bytes containing the jump address stay the same.
Similarly, for a two byte instruction, only the first byte will be
encrypted, and of course all one byte instructions would be encrypted.
What this means is that decryption cannot be applied to the whole file
because all data reads are unencrypted.
Just to make life a little more difficult, the encryption is different
on odd and even addresses. The encryption involves scrambling bits
0,2,4,6 through a prom which is toggled by A0. The following index
tables taken from my disassembler/unscrambler program decode the opcode
bytes. Use evetab for even addresses and oddtab for odd addresses. The
values in the tables are all decimal. For example for encrypted value of
1 on an even address you would read 84 (decimal). For an encrypted value
of 4 on an odd address you would read 64 (decimal).
evetab:
db 65, 84, 70, 19, 81, 20, 2, 82
db 73, 92, 78, 27, 89, 28, 10, 90
db 5, 16, 67, 86, 1, 85, 6, 22
db 13, 24, 75, 94, 9, 93, 14, 30
db 97, 116, 102, 51, 113, 52, 34, 114
db 105, 124, 110, 59, 121, 60, 42, 122
db 37, 48, 99, 118, 33, 117, 38, 54
db 45, 56, 107, 126, 41, 125, 46, 62
db 68, 17, 23, 66, 0, 80, 83, 87
db 76, 25, 31, 74, 8, 88, 91, 95
db 21, 64, 7, 18, 4, 69, 3, 71
db 29, 72, 15, 26, 12, 77, 11, 79
db 100, 49, 55, 98, 32, 112, 115, 119
db 108, 57, 63, 106, 40, 120, 123, 127
db 53, 96, 39, 50, 36, 101, 35, 103
db 61, 104, 47, 58, 44, 109, 43, 111
db 148, 193, 135, 215, 129, 196, 130, 210
db 156, 201, 143, 223, 137, 204, 138, 218
db 132, 208, 147, 194, 209, 197, 214, 150
db 140, 216, 155, 202, 217, 205, 222, 158
db 180, 225, 167, 247, 161, 228, 162, 242
db 188, 233, 175, 255, 169, 236, 170, 250
db 164, 240, 179, 226, 241, 229, 246, 182
db 172, 248, 187, 234, 249, 237, 254, 190
db 145, 192, 199, 211, 212, 149, 146, 134
db 153, 200, 207, 219, 220, 157, 154, 142
db 144, 128, 198, 131, 213, 133, 195, 151
db 152, 136, 206, 139, 221, 141, 203, 159
db 177, 224, 231, 243, 244, 181, 178, 166
db 185, 232, 239, 251, 252, 189, 186, 174
db 176, 160, 230, 163, 245, 165, 227, 183
db 184, 168, 238, 171, 253, 173, 235, 191
oddtab:
db 80, 17, 18, 82, 64, 85, 86, 87
db 88, 25, 26, 90, 72, 93, 94, 95
db 81, 20, 3, 70, 69, 4, 66, 6
db 89, 28, 11, 78, 77, 12, 74, 14
db 112, 49, 50, 114, 96, 117, 118, 119
db 120, 57, 58, 122, 104, 125, 126, 127
db 113, 52, 35, 102, 101, 36, 98, 38
db 121, 60, 43, 110, 109, 44, 106, 46
db 84, 21, 22, 19, 16, 5, 2, 67
db 92, 29, 30, 27, 24, 13, 10, 75
db 68, 1, 71, 23, 0, 65, 83, 7
db 76, 9, 79, 31, 8, 73, 91, 15
db 116, 53, 54, 51, 48, 37, 34, 99
db 124, 61, 62, 59, 56, 45, 42, 107
db 100, 33, 103, 55, 32, 97, 115, 39
db 108, 41, 111, 63, 40, 105, 123, 47
db 129, 133, 215, 210, 193, 197, 151, 146
db 137, 141, 223, 218, 201, 205, 159, 154
db 212, 208, 131, 134, 213, 144, 195, 198
db 220, 216, 139, 142, 221, 152, 203, 206
db 161, 165, 247, 242, 225, 229, 183, 178
db 169, 173, 255, 250, 233, 237, 191, 186
db 244, 240, 163, 166, 245, 176, 227, 230
db 252, 248, 171, 174, 253, 184, 235, 238
db 145, 149, 199, 194, 209, 148, 135, 130
db 153, 157, 207, 202, 217, 156, 143, 138
db 196, 192, 147, 150, 132, 128, 211, 214
db 204, 200, 155, 158, 140, 136, 219, 222
db 177, 181, 231, 226, 241, 180, 167, 162
db 185, 189, 239, 234, 249, 188, 175, 170
db 228, 224, 179, 182, 164, 160, 243, 246
db 236, 232, 187, 190, 172, 168, 251, 254
I have been thinking that it would be a fairly simple matter to use
these tables in a Z80 emulator so that when it decodes the opcodes it
uses the above tables to index the encrypted ROMs. This would allow an
emulator to use the original encrypted ROM images.
If anyone needs any other help regarding Crazy Climber please email. I
have worked out most of the memory map and have a partly working CC
reconstruction already.
Lionel Theunissen (lionelth@ozemail.com.au)
