YJencrypted Issues

[RibShark]

These carts should be fully dumpable with the right techniques:

• First the cart needs to be "initialised" with the exact/similar reads to a GBA, parsing the header ideally on the first read (some bytes in the Nintendo logo are replaced if the header is read a second time, and sometimes will contain trap zones too).
• Second, the cart needs the addresses to be read in roughly the same way as the game does. I am unsure of the details here, it could be as simple as first reading the initial jmp, following to that location and reading that, or it could be more complex requiring a certain level of emulation to follow the right path. Doing this "unlocks" reading the rest of the cart, which would otherwise stop reading entirely at around ~0x100 (IIRC).
• In most of these carts, there are "trap zones" which, upon reading, will prevent any further reads of the cart. From my experience, these come in two types: a 4-byte long zone, of which there are many, usually near the start of the address space, and a large chunk (typically 0x10000 bytes or more) of which reading any bytes will prevent further reads (returning either 0x00 or a repeating pattern of 4 bytes). Not all YJencrypted cards have these areas (my Mario Cart cart doesn't, for instance), but most do. Once a trap zone has been hit, the cart will need to be powered off and reinitialised to read any further.
• The full 32mb address space needs to be dumped, as this cart appears to mirror the ROM in unpredictable ways that are unique to each cart, and the code will jump to addresses in the mirrored areas.

Right now, FlashGBX fails at the start, refusing to even read the header of any of my carts (Sonic 3 Fighter Sonic, Crash Advance IV, Rayman IV and Mario Cart). Since your firmware doesn't appear to be open source, I can't say for certain what is going wrong here, but it is possible the AGB_BOOTUP_SEQUENCE command does not simulate the cart reads correctly. On an actual GBA, reading 0x080000B4 (8-bit reads), then 0x0BFFFFE0 to 0x0BFFFFF2 (16-bit reads), then 0x0800009D-0x080000B7 (8-bit reads) is enough to at least get the header. There could also be some factor I am not aware of outside of reads affecting this, such as timing. For the trap zones, the best way to do it would be to power on/off the device whenever a trap zone is detected (can be done by attempting to read an earlier address and comparing values), though I do not believe every USB hub allows powering off like that.