The last few days have been very hot and it's going to be like that until Monday or so. I can't be even bothered to play games :) The temperature last night was somewhat more manageable though so I've experimented a bit with NAOMI.

It's important to mention that carts using M1 are always based on a single-chip solution, namely a fat FPGA from ACTEL. Well it's not all that much compared to, say, current Cyclone or Spartan series (and those are not top shelf either) but enough to give any potential hacker lots of trouble. To add insult to injury I was unable to make the decryption DMA work on EPROM data, the only thing I can actually change on the cart, so I can't just "change a byte and see what happens". Or rather, I can, but it doesn't seem to have any meaningful results...

I'll spare you the boring details, just keep in mind that even meager results like these takes hours, if not days, of repetitive (and sometimes risky) hardware tests. Take a look at this, it's the result of "decrypting" a sequence of 64 zero bytes:

Not saying much, huh. I decided to try a walking bit pattern next. It seems rather pointless but seeing how M2/M3 had an "enable bit" in the first word of the encrypted sequence I figured it's worth a try. The word in question was 16-bit long so a full test would require all 2^16 combinations - but if all we care about is one bit, there is a pretty good probability of hitting something in just 16 tries.
Unlike M3, which is RAM-buffer based, M1 DMA operates on cart data only. Also, to make sure address bits do not affect the result, I couldn't just fill the chip with all sequences I needed to test. In other words, for each bit pattern I would: remove the chip from cart, put it in programmer, change the pattern, put it back in cart, boot NAOMI and finally dump the DMA data. Having ZIF-socketed FLASH replacement for the original EPROM makes tests like this not only easier but in fact feasible in the first place :)

About half an hour later I had the files I needed and I calculated CRC32 for all of them. This is how it looked like:

fe2f76cd 80100200_0000.bin
fe2f76cd 80100200_0001.bin
fe2f76cd 80100200_0002.bin
fe2f76cd 80100200_0004.bin
fe2f76cd 80100200_0008.bin
fe2f76cd 80100200_0010.bin
fe2f76cd 80100200_0020.bin
fe2f76cd 80100200_0040.bin
fe2f76cd 80100200_0080.bin
fe2f76cd 80100200_0100.bin
fe2f76cd 80100200_0200.bin
fe2f76cd 80100200_0400.bin
fe2f76cd 80100200_0800.bin
fe2f76cd 80100200_1000.bin
fe2f76cd 80100200_2000.bin
92f7ea03 80100200_4000.bin
fe2f76cd 80100200_8000.bin
fe2f76cd 80100200_BFFF.bin


Noticed anything? Namely, 0x4000 pattern has a different CRC. I didn't expect such a "clean" result but I'm not complaining :) This is the actual decoder output for bit 14 set:

And so you have some context, this is what we are looking for:

You can't deny it, there is some resemblance. Could be a fluke, and I can't even verify that right now, but I'm going to assume it's not until proven otherwise.

After some head scratching I also came up with a theory as to why the EPROM data cannot be decoded properly. There is no special lockout or anything, other then the design of the cart itself. You see, ROM chips on these are arranged in such a way that each read accesses two at a time (one on each side of PCB). Every ROM has 16-bit wide data path, so with data being stored interleaved you read 32-bit double words on each access.

Now, the program EPROM has 16-bit data path as well but there is only one so the missing 16 bits are taken from inactive bus (pulled high/low or maybe even floating, depends on how the FPGA does it internally). This is also why I seem to be unable to affect some bytes in the output sequence...



Source:dknute.livejournal.com