The first 0x100 bytes of expansion disks are encrypted to attempt to prevent any old person from hijacking a game and running their own script. So far, it looks like this is usually at LBA 0x230. This script decodes it. rom.file.seek(pos,0) enc = bytearray(rom.file.read(0x100)) rom.file.close() dec = bytearray(0x100) count = 0 # Bytes are copied at 17 byte intervals for i in range(0x100):dec[count] = enc count+=17 count&=0xFF out.write(dec) out.close() Note, the in-game decoder is itself encrypted using its function address as the key. Basically, there's two functions that are encrypted and are called to reset the game. The first waits for the SP to clear, clears all interrupts, decrypts the disk bootcode, sets osResetType to 2, erases itself and, occationally, its caller. The second resets the cache and reboots starting at the bootcode. The function that decodes these uses this algorithm: key = sum of four bytes for function 1 address & 0xFF, used for both functions (for example, 800BB67C: (0x80+0x0B+0xB6+0x7C)&0xFF = 0xBD) for i in range(start,end,4):i[2]-=key i[3]+=key I have a few examples of these already done, if posting disassembled code is permitted.
Nope. Expansion disks will reboot the game, effectively faking a reset, and start executing their own game code. In other words, Nintendo was hijacking their own games ;*) To prevent any old program on disk from hijacking any old combo title they encryted the first 0x100 bytes of the 'boot sector' of this new 'game'. Just like starting a fresh cart, the code will set the stack pointer, initialize some memory, and JR to whatever starts up the game. In general, due to design and compilation and all, it appears these dual-boot things are always at the start of zone 2. As for the normal disk bootcode that the IPL would trigger, that would be in LBA 0x18 (the first 'real' LBA) and doesn't appear encrypted at all if we trust Paint Studio: 3C088007 LUI T0,8007 3C090004 LUI T1,0004 250871B0 ADDIU T0,T0,71B0 35296730 ORI T1,T1,6730 2129FFF8 ADDI T1,T1,-8 AD000000 SW R0,0000 (T0) AD000004 SW R0,0004 (T0) 1520FFFC BNE T1,R0,-4 ;initialize 800771B0 through 800BD8E0 21080008 ADDI T0,T0,0008 3C0A8000 LUI T2,8000 3C1D8008 LUI SP,8008 254A1360 ADDIU T2,T2,1360 ;start execution at 80001360 01400008 JR T2 27BD91B0 ADDIU SP,SP,91B0 ;SP=80079180 Also, for the record, the diskID can be stored in either LBA 0xE or 0xF (both are tested), LBA 0 stores the checksum (0x18 bytes), a -1, and boot address (usually 80000400).
Pretty cool. So I guess we can generate those System Datas for emulation in the meantime? (and with the data we have)
