Author: Runik

Happy new year everyone !

 

Regarding configuration files for SegaDecrypt, I decided to give libconfig a go as a replacement for my big clumsy xml file. I went for version 1.5 as the last version (1.6) has some problems preventing it to compile on my dev setup.

Now each set has its own configuration file, as you can see in the following example, extracted from a real set :

//--------------------------------
// Super Hang On Sitdown 317-0039
//--------------------------------

name =  Super Hang On Sitdown;
version =  317-0039;
protection =  FD1094;

program:
{
    files = [
         epr-10857.25, 
         epr-10859.31 
    ];
    key =  317-0039.key;
    size = 0x20000;
};

override:
{
    process_data_manually = true;
    irq_vector_lower_bound = 0x108a;
    irq_vector_upper_bound = 0x108a;
    post_decryption_copy = ( 
        (0x400, 0x1000,  DATA ),
        (0x1A22, 0x20000,  DATA )
    );
};

crc:
{
    type =  outrun ;
    storage_address = 0xFF0;
    start_address = 0x1000;
    initial_block_size = 0x1F000;
};

Almost everything can be overridden, allowing to handle specific cases required for some sets.

---

Now that the configuration problem is solved, I started working on the MC8123 decryption. The MC8123 is a Z80 with built-in encryption, Program opcodes and data are encrypted differently, which explains why bootleggers used doubled eproms back in the days : one half was used for the decrypted program, the other half for the decrypted data, and the correct addressing was chosen at runtime.

Using the same technique I used to decrypt FD1094 files, I should be able to generate decrypted files for MC8123.

There are some difficulties though :

• Opcodes operands are considered as data, and they don’t have a fixed size → a pass to check opcode type and operand size has to be done.
• There are data chunks interleaved with Z80 encrypted code, and unlike FD1094 encrypted code, there are no data markers allowing to know their boundaries → solution will be to consider everything as data first, and then to follow code flow from interrupts start vectors, jumps, branches, etc. in order to get the program code.
• Previous point has some weaknesses though : some opcodes (like JP (HL) for instance) are supposed to do an unconditional jump, which destination is based on a processor register. Problem is, the register content is set up at runtime, meaning that you can’t know its value without effectively running the code.

Time to get my hands dirty !

While I was gathering information about how various Sega encryptions worked, it became obvious that some had a lot in common. So I decided to regroup all the decryption routines into the same software, to be able to capitalize on previous work instead of starting from scratch when working on a new decryption.

I just finished adding FD1089A/FD1089B decryption to the software, meaning that I can generate decrypted sets for PCBs using this kind of encryption. So far Aurail is done (sets 317-0167 and 317-0168), and checksums are automatically fixed. You’ll be able to get them from Porchy’s when the sets will be uploaded.
I’ll try to add more decrypted sets when I have some spare time, but if you need one quick just drop me a line 😉

Next step decryption wise will be to move FD1094 decryption code to the new software. After that I’ll have a look at System 24 FD1094 (floppy drive based), and MC8123 (Z80 based, which I’m far from being fluent with :p

Cheers !