Been digging into how the Taito Egret II Mini locks its game cards. I know you can modify the bootloader but I wanted to read and write SDcards like the original. Short version of what I've found:
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) and 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.
Anyone here with an Egret card + a Raspberry Pi / SD breakout who wants to help testing?
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) and 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.
Anyone here with an Egret card + a Raspberry Pi / SD breakout who wants to help testing?
Last edited by DaMonkey13,
