xcellerator / tetsuji Goto Github PK

As a follow up to #1, there's a few things that are incorrect in the article. Some of these are nitpicks, some of these are more significant, but I felt they all warranted being pointed out somewhere.

Mobile adapter documentation

• The unlimited battle adapter is reflected by the third byte of the 0x17 telephone status command being 0xf0 or higher. This is sampled during the mobile adapter splash screen and stored in the save file from there on (although it's reset when the splash screen detects an adapter once more). Source: Dan docs
• The first byte in a transfer data packet is the socket id. This is useful when opening multiple tcp connections to a server, but in direct call (p2p) connections it's always set to 0xff and ignored by the adapter. Source: Dan docs
• The second byte in the transfer data packet for a p2p connection is a size byte, not a packet id. This is imposed by the mobile adapter library, although I'm not sure why it exists as it's not used by the adapter itself. The best way to identify what packet is what is likely through the sequence id, like you've identified. Source (recent research)

General pokemon game knowledge

• クりス is the default player name for the female character, Kris.
• The random 10-byte packet is likely the RNG seed, as this is necessary for multiplayer battles to function.

Misc

• The 4F character is the <LINE> character. The reason it's used in the 1500 payload is to set the text writing pointer to a predictable location (the start of the textbox), as this pointer is written to the jump destination, and will be the first two bytes that are executed.
• The first self-contained bootstrap on the glitch city page works on JP - I've just tested it, the jump destination is $CD46 - but player and pokemon names are too short to store anything useful, and usually names are first copied to wStringBuffer1 ($D05B) before being executed, so they're truncated. There may be ways to chain multiple strings together by jumping to a different one (like with the 3F/<ENEMY> character, and doing something like "4F 15 08 05 C9 3F" followed by "15 00 <code>" in wOTClassName), but it's a bit complicated in this exploit scenario. (letterbombs by attaching mail to traded mon are very much possible with this)
• Across the article Nintendo is attributed for various things in Game Freak's game. The character encoding and the mobile scripts being a few examples.

Lacking research

• I wonder if the limit_crystal packet includes the remaining battle time for the player, as the battle needs to stop before the timer runs out for the player with the least time.
• There's various things that must be transferred during battle which might be amongst the packets you weren't sure about. One are the configurable battle messages through the easy chat system, printed at the start of a battle, and when the opponent wins or loses. Another being the mobile trainer cards, which you won't see unless you've made your own.

I'd like to start by mentioning that I enjoyed your article, it goes into a lot of original research that I haven't seen documented yet, but one thing that bothers me is that the mechanics of the final exploit are never explained, so I decided to research this myself.

Character 3F is <ENEMY> which causes the text parser to call PrintEnemysName to print wOTClassName during link battles. Writing this in wOTClassName causes an infinitely recursive loop when <ENEMY> is parsed.

This loop causes a stack overflow, putting the stack pointer in SRAM. Thankfully, nothing in this loop is reading values from the stack, as it's only pushing and calling. However, once an interrupt triggers, it needs to store the address to return to. Since we can't write to SRAM as it's closed, writes will be ignored, and reads will (usually) all be $FFFF.
However, once the interrupt returns through reti, it returns into $D9D9 thanks to open bus behavior (D9 is the reti instruction). Open bus behavior is when a device stops pulling data lines (as is the case here since SRAM is closed), and for a short time the last value is preserved and will be read, in this case D9 from the last instruction read. This jumps lands in a nop sled, until the timer interrupt occurs.
The timer interrupt, since the mobile adapter is turned on, will attempt to bankswitch to bank $44, however, in doing so it'll encounter a ret instruction instead, now jumping to $C9C9, which is part of WRAM. This time interrupts are disabled (reti enables them), so it can slide indefinitely along WRAM. With some luck there's no bytes in the way that break the slide, and it'll end up
at the controllable data area, $CA4F.

This is a lucky turn of events, since if the timer interrupt happens at a moment when the stack pointer hasn't fully reached SRAM yet, different things can happen depending on what code finally tries reading from the SRAM. One particularly bad example is when a ret instruction reads only the upper half of the address from WRAM, and the lower half from SRAM (with open bus
behavior, so always C9), as this will jump to the address $xxC9, where xx is the upper part of the real return address. And that's without mentioning that open bus behavior is hard to predict, and while it might work with an MBC30 in GBC double-speed mode (the few people I've consulted say it would probably be fast enough to read the same value twice), it likely doesn't work with flashcarts and a fair amount of different emulators.