Cracking encrypted z80's for dummies.


A z80 is a cpu on a chip. The chip has pins that communicate with the circuit board by turning on and off to control memory or ports. An opcode is a command that (usually) does something to the circuit board by turning off and on pins in sequence; we can watch the pins to observe the results of a mystery opcode. Since there is no way to hide the behaviour of the pins and have the z80 still work this should work on any type of encrypted z80. My interest in this is Sega system 1. I was working on Gardia, trying to do it the hard way by looking at the roms. I could get the first half but the second half it was soon obvious to me I would likely never get. Unfortunately after building the device and all this time I still have not found a gardia board with the cpu intact. It seems like they were all converted to Wonderboy long ago.


Lets look at an example opcode: LD A,($4000) This compiles to 3 bytes: 3a 00 40 The 3a is the opcode the other 2 bytes are data. Generally that is the way it works, 1 byte opcode followed by 0 to 3 bytes of data. If we put 3a 00 40 at the start of a z80's program and watched we would see.

1. reads the opcode 3a in from location 0000
2. loads the second byte(data) 00 from location 0001
3. loads the 3rd byte 40(data) from location 0002
4 loads the byte(data) at location 4000 from location 0003
5 reads the next opcode from the next consecutive location. from location 0004


These 5 things describe the category. All 256 opcodes are assigned a category(sometimes 2, more on that later) Now if a mystery value fits into this category we can say it is an opcode in this category. How useful is that? How many categories are there? Well it turn out there's quite a few. There is one annoyingly large category I call NOP (they don't do anything external to the cpu) but other than that most of the categories are fairly small. Even better, a dozen of the categories have only 1 member.


Encryption during this time period is usually bitswap/xor. By that I mean you write out the encrypted value in binary, scramble the bits, and invert a couple of them. This is an easy matter to brute force. A dozen pairs of data is more than enough to define the pattern if you are lucky. What I mean by that is if you know a few pairs suprisingly enough you will actually know more than those few pairs. But since you didn't require any more knowledge to get these pairs, the converse is true. If you are given one of these pairs it supplies no new knowlege to you. That's where some of the other categories come in. For example if a category has 5 members and 5 unknowns you can use the bitswaps you know to determine the possible matches of the 5. I have writen a program that uses inputs of the pairs you know and an unkown and returns the possible decrypted values.


Getting back to some having 2 categories, let's look at the JUMP category.

1 reads the opcode from location 0000
2. loads the second byte (data) from location 0001
3. loads the 3rd byte (data) from location 0002
4. reads the next opcode from a NON-consecutive location. from location !=0003

It of course contains the JP opcode, but also JP Z, JP NZ, etc. The second 2 are conditional jumps based on the zero flag is set or not set. We don't know the state of the flags, so only about half the opcodes in the jump category will show up in this category when you test. The others will show up in a diffent category (3byteNOP). hat's not necessarily a bad thing. It puts us that much closer to narrowing down which of these is the unconditional jump. These conditional jumps will help us figure out how to load the flag register and once we do that it's simple to sort this category out.

What happens if it doesn't use a bitswap/xor like the NEC. Well, that's a problem. Hopefully there's still a pattern to it, it's just a different pattern and still easy to brute force. What if it's a lookup table? Well I really, really hope not. But if it is, more opcodes can be found by writing more test code. For example we can look at the POP category. If it's POP AF then it affects the flags used in the jump, if it's POP BC, it affects the DJNZ command, etc, Once you know the pop commands, it's a simple mater to find the push commands. Once you can read and write all the registers it's a simple but tedious matter to subdivide the NOP category(and others) by what it does to the internal registers.

I haven't talked about data at all. It's done using a different bitswap/or, but it's really easy. Look at the jump definition. If I define byte 2 and 3 as the numbers 00-255 and keep track of where the jump lands I can just write the table down. But you say I don't know which opcode is the jump? That's true, but I don't have to. I just start with the first opcode in the jump categoy. If it works great. If it doesn't it must have been a conditional jump, I can move on to the next one on the list. So I can do 2 things at once here.

So how do you apply this theory? Well it's pretty simple. The z80 will clock as slow as you want so speed is not a problem. I ordered an inexpensive used pci I/O board on ebay. I hooked up all the required lines to the z80 and used the pc to emulate a circuit board. At the appropriate time I put data on the bus so the cpu thinks it's reading a rom. I read the pins when the cpu thinks it's doing something. I repeat for every address since it can be different for every address. Anyone with basic knowledge of how a z80 is used in a circuit can build it. Anyone with the basic knowlege of how clock cycles work on the z80 can write the test program.

Will it work on other cpu's? Only if they will clock slow enough, or you can speed up the PC program fast enough. 16 bits is much more difficult than 8 bits though. It also appears that the FD1094 does not use all the opcodes. It seems they anticipated my plan and eliminated the most useful opcodes. Fortunately Charles has that one under control.

Will it work on MCU's? No. A mcu has the memory internal to the chip. For the most part there are no pins to watch. If a mcu puts missing data onto the bus for protection, you might learn that but it will get you no closer to figuring out what's in the mcu.

Dave Widel