I'm close. I have reverse-engineered the SDCard because I don't want to modify the bootloader and just make my own sdcards and backup what I have.
Update on the Egret II Mini SD protection — I've gotten a lot further. Short version:
- Games on the SD card are stored as WinZip-AES-256 encrypted ZIPs.
- The card is MMC password-locked (CMD42) — that's why it shows up as "needs formatting" on a PC.
- The AES password AND the CMD42 unlock password are both derived from the card's CID, using a routine I pulled out of game_launcher plus a 16-byte constant baked into the firmware. I reconstructed the algorithm and validated it against the actual firmware code (800/800), and it's byte-identical from the 2022 firmware to today , so it applies to any card/firmware version.
- Correction to what I said earlier: the SW2001 secure element is NOT on I²C.
The disassembly shows it's talked to over the MMC bus via MMC_IOC_CMD ioctls, using ISO-7816 smartcard APDUs (success = status word 0x9000). It's a secure element on the console mainboard, not in the card.
- Important: the CMD42 password is purely CID-derived — SW2001 does NOT modify it. SW2001 is a separate session/anti-clone check that gates booting the games, using a per-boot table that only exists in RAM. So off-console you can likely unlock+decrypt a card, but the SW2001 session is the thing that gates actually launching games on the console.
- The "11455a" CID prefix is only the genuine-card check (3 of the 16 CID bytes). It's useless for decryption — the key derivation uses essentially all 16 bytes (the serial included), so you need the full CID, not just the prefix.
Bonus stuff I found while in there:
- That 64-hex string someone posted ages ago (cd4c434a...) is real, but it'sNOT a checksum and NOTthe game key — it's the STATIC password that decrypts /usr/egret2/egret2 (the emulator itself, which is also an AES-256 zip → a 12 MB ARM ELF). It's hardcoded in game_launcher. That matches the old "the password is in the rootfs" hint.
- The emulator is M2's "Zirconia" engine. Its per-game classes are literally the same hardware drivers as MAME (taito_f2, taito_f3, taito_sj, taito_8080, qix, twincobra,bubblebobble, arkanoid,etc.), loading standard functional ROM regions (maincpu.rom, soundcpu.rom,tiles.rom, sprites.rom,color.rom...) and CRC-checking them. So the games are NOT some exotic format, they're standard arcade ROM dumps (MAME-equivalent bytes), just merged per region, renamed,and AES-encrypted.(A few old titles use recorded sound samples instead of sound ROMs.)
- The built-in games (resource1) are AES-256 encrypted too, with a different, static key computed inside the emulator (not recovered yet).
Also: game_launcher (not the emulator) does the CID check + unlock + decrypt. I found the two branch checks in main() that gate it, and in a Unicorn sandbox a 2-byte NOP patch each makes the launcher accept any plain (unlocked, non-genuine) FAT32 card while keeping the stock UI, you could sidestep CMD42/SW2001/CID-cards entirely with a small firmware patch flashed over FEL.
Not done yet: none of it is tested on a real card. I'm waiting on an SDbreakout (or I'll read the CID over FEL via the P2 USB port) to confirm the unlock/decrypt on real data.
The one real open question is whether the SW2001 session can be passed/needed off-console.
Screenshot is a UI mockup of the toolkit I'm building (read/write CID, unlock, pack/encrypt games) and values shown are placeholders.
Last edited by DaMonkey13,
