Main Menu
Main Page
Forums
Recent changes
Random page
Help

Databases
GlitchDex
AttackDex
ItemDex

Major Glitches
Trainer escape glitch
Old man trick
Celebi trick
Select glitches (Japan)
SRAM glitch
CoolTrainer♀ corruption
LOL glitch
Rival LOL glitch
Super Glitch
ZZAZZ glitch
Pomeg corruption glitch (Glitzer Popping)
Tweaking
Elite Four door glitch (Japan)
Pokémon merge glitch
Pokémon cloning
Time Capsule exploit
Arbitrary code execution
Coin Case glitch
More

Other Glitch Categories
Glitches by generation
Glitches between two generations
Japan-only/language specific glitches
Music glitches
Natural glitches
Non-core series glitches
Non-Pokémon glitches
Officially acknowledged glitches
Recurring glitches
Dead glitches

References
Pokémon GameShark codes
The Big HEX List
GB programming
Curiosities
Debugging features
Easter eggs
Error traps
Glitch areas
Glitch myths
Non-glitch exploits
Placeholder texts
Pokémon glitch terminology
Unused content and prerelease information

Useful Tools
8F Helper
GBz80 to Items
Old man trick name generator
PATH (Prama's Advanced Tweaking Heaven)
Save file editors
Special stat/Pokémon converter
Trainer escape Trainer Pokémon finder

Affiliates
Legendary Star Blob 2 (Hakuda)
Pokémon Speedruns wiki
PRAMA Initiative
Become an affiliate!

Search Wiki

 

Search Forums

 

Author Topic: Anatomy of an e-Reader Mystery Event  (Read 10118 times)

0 Members and 1 Guest are viewing this topic.

Team Fail

  • GCLF Member
  • Offline Offline
  • CHARIZRAD 'M ROXORX or is it.
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #30 on: June 10, 2015, 07:39:00 pm »
They do have the e-Reader code, it's just skipped out on. Normally, if a Wireless Adapter is not detected, it will default to e-Reader mode in the Japanese versions (Otherwise go to Mystery Gift if it is attached), but this check simply errors out on you and tells you it's not attached (Or if attached, it does go to Mystery Gift), so it never does jump to the code responsible for e-Reader usage in the international releases. However, by editing the Main Menu option to allow the original Japanese behaviour, you can connect to an e-Reader, all the code is still there and completely functional:



(Note that the text is not actually in the ROM, so I had it ripped from the Japanese games and translated. This is how it looks without the text.)

I see, thanks. So, to clarify, the Japanese FireRed and LeafGreen will load the same Mystery Gift screen as the localizations when the Wireless Adapter is attached and detected by the game, correct?


Yes, that would be correct. They made use of the Wireless Adapter as well.

Háčky

  • Distinguished Member
  • *
  • Offline Offline
  • Pick which packet as an error?
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #31 on: June 13, 2015, 07:18:17 pm »
I figure that Team Fail has a better handle on the FR/LG side of this than I do, so I decided to look into how the program run on the e-Reader works.

It uses the e-Reader API to load the VPK data of a scanned card into a buffer at $2005C6D, and decompress it into another buffer at $200645C. It then grabs a $3D4-byte Trainer Tower data structure from offset $100 of the card data. (It ignores everything else on the card, which is just a Z80 program that displays the error screen I posted earlier.) The data from up to 8 cards is stored consecutively starting at $200749C.

The data is sent to the game using a very similar protocol to the R/S/E Mystery Events. First the “GameFreak inc.” packet is sent, which, as Team Fail noted earlier, has the value $02 instead of $01 at offset $24. The second packet contains the card data preceded by two dwords: the first is the number of cards, and the second is a bytewise checksum of all the card data.

The Trainer Tower data structure appears to be the same as the one on Bulbapedia except that the trainer names are 8 bytes instead of 11, and consequently an alignment byte is added at offset $3CF. The dword at $3D0 is a bytewise checksum. (It’s possible that if the English FR/LG can be made to accept Trainer Tower e-Reader data, it will expect the trainer names to be 11 bytes.)

It seems that the language code at offset $2A of the “GameFreak inc.” packet is the only method of language lockout used. There’s nothing in the card data indicating which language version of FR/LG it’s for, although the Japanese cards can only be scanned on a Japanese e-Reader+. Curiously, the program contains the string 「リージョンエラー」 Region error, but it’s unreferenced. (「つくられた カードデータを おくり なおしますか」 is also unreferenced.)

There’s also no apparent indicator that Trainer Tower data, rather than some other type of data, is being sent, unless this is what the $02 at offset $24 of the “GameFreak inc.” packet means. It could be that FR/LG’s Mystery Gift will accept only Trainer Tower data over the link cable, and any other kind of Mystery Gift requires the wireless adapter.

The Japanese FR/LG is able to communicate with this program even if it’s already running on the e-Reader; it’s not strictly necessary for the game to send the program to the e-Reader first before it receives the data. This implies that it would be possible to write an e-Reader dotcode application that can send data to the game without using the built-in program.

Háčky

  • Distinguished Member
  • *
  • Offline Offline
  • Pick which packet as an error?
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #32 on: June 14, 2015, 10:08:43 pm »
It looks like the e-Reader side of Mystery Gift is in fact limited to Trainer Tower data, and everything else goes through the Wireless Adapter.

The functions of R/S/E’s Mystery Events are present in FR/LG (see the jump table at $81DBCF0 in the English FireRed), with the exceptions of $0B (gift item when mixing records) and $0E (in-game clock adjustment), which understandably display the message “This data can’t be used in this version.” It appears that this system is somehow tied into the Wireless Adapter side of Mystery Gift. The upside is that these functions ought to work in the English version without alteration; the downside is that I have no idea how to go about accessing them.
« Last Edit: June 14, 2015, 10:10:00 pm by Háčky »

Team Fail

  • GCLF Member
  • Offline Offline
  • CHARIZRAD 'M ROXORX or is it.
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #33 on: June 15, 2015, 12:57:28 am »
It looks like the e-Reader side of Mystery Gift is in fact limited to Trainer Tower data, and everything else goes through the Wireless Adapter.

The functions of R/S/E’s Mystery Events are present in FR/LG (see the jump table at $81DBCF0 in the English FireRed), with the exceptions of $0B (gift item when mixing records) and $0E (in-game clock adjustment), which understandably display the message “This data can’t be used in this version.” It appears that this system is somehow tied into the Wireless Adapter side of Mystery Gift. The upside is that these functions ought to work in the English version without alteration; the downside is that I have no idea how to go about accessing them.
So at this point, all that the e-Reader can send over is trainers then, while other events use the Wireless Adapter?


Also, if you want a fixed copy of the ROM for testing with, I can probably provide you with a patch or something.

Team Fail

  • GCLF Member
  • Offline Offline
  • CHARIZRAD 'M ROXORX or is it.
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #34 on: July 07, 2015, 09:27:40 pm »
I really hate double-posting, but I think this is a rather important development in this particular thing, so I'm going to go out on a limb here and do this.
I figure that Team Fail has a better handle on the FR/LG side of this than I do, so I decided to look into how the program run on the e-Reader works.
That I do, and I come bearing good news.


Prof9 and I were talking on Project Pokémon's IRC, and he told me of a way to activate e-Reader support for USA copies of Emerald, and funny enough it literally only requires you to change ONE BYTE to enable it.

"Change the byte at 0x02F97E to 0x02" as he said. Then, when on the Continue screen, select "Mystery Gift" to access a glitchy version of the application. It works in the same way as the FireRed one, although you'll still need a Japanese e-Reader to work with it. Scanning and sending cards seems to error out for some reason though.

Anyways, on the FRLG front, I finally got it working with the English e-Reader, yet again with Prof9's assistance (And in the process showing how little I know of No$GBA's debugger and how powerful it is). I'll probably issue a preliminary patch so people can try getting cards working, however, I think I'm encountering region errors, because I cannot scan in any FRLG cards, they all result in this:


If I revert to a version that connects with a Japanese e-Reader, it will accept the cards, but when I go to transmit the data to FRLG, it errors out, same as Emerald, presumably because of a region error. I think at this point, a disassembly of the FRLG and Emerald cards may be necessary to change their region and get them working on English games.


Edit: I have a preliminary patch here if you wish to try this.

Edit 2: After looking at your first post in the thread again, I may be able to adjust the VPK data and get it working. I may know how to fix this.


Edit 3: Nothing yet. Haven't gotten it working. I do have the cards working on USA systems though, but the card scanning application still won't accept it for whatever reason.
« Last Edit: July 09, 2015, 01:20:54 am by Team Fail »

Háčky

  • Distinguished Member
  • *
  • Offline Offline
  • Pick which packet as an error?
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #35 on: July 09, 2015, 08:19:17 am »
I was able to read a card through the application on the English e-Reader after altering the card header to have the correct region code. (Specifically, I took card 15-A001, converted the .raw to .bin with nedcenc, and changed offset $0D [region code] to $F1 and offset $2E [checksum] to $0E.)

The remaining issue is that, as I suspected earlier, the English games expect a 992-byte Trainer Tower data structure as documented on Bulbapedia rather than the 980-byte structure used in the Japanese version. Attempts to send the Japanese card data will fail when the English game tries to verify the checksums. The cards and the application will both need to be modified to use the 992-byte structure.

As a test, I dummied out the function at $0815D6B4, which is called by the Mystery Gift routine to verify the checksums. With that alteration, I was able to successfully complete the Mystery Gift process. The data was stored in the save file, but had no apparent effect on the Trainer Tower. I then tried editing the saved data to match the 992-byte structure, but I still saw no effect. I would guess some further reprogramming is needed to restore the Trainer Tower’s original functionality.

(While editing the saved data, I noticed that on Trainer Tower cards with fewer than three trainers, the unused trainer slots have their names set to ゲーフリ, which was previously used as a hidden default name in the Japanese Pokémon Blue.)

By the way, in case you’d like to spell Pokémon properly in your translated application title and cards, $7F represents é in the English e-Reader’s pseudo-ASCII.



In unrelated news, after looking at the leftover Mystery Events functions in FireRed, I discovered that the header (chunk $01) has a totally different structure than what I’d previously thought. I suppose it was purely accidental that my earlier German Eon Ticket experiment worked.

Code: [Select]
$0  4  Pointer base address ($02000000)
$4  2  Language group bitfield
         bit 0: Japanese
         bit 1: English
         bit 2: German, French, Italian, Spanish
$6  4  Language bitfield
         bit 0: Japanese
         bit 1: English
         bit 2: German
         bit 3: French
         bit 4: Italian
         bit 5: Spanish
$A  2  Game region bitfield
         bit 0: FireRed, LeafGreen
         bit 2: Ruby, Sapphire, Emerald
$C  4  Game version bitfield
         bit 0: FireRed
         bit 1: LeafGreen
         bit 7: Ruby
         bit 8: Sapphire
         bit 9: Emerald

“This data can’t be used in this version.” will appear if any of the four bitfields don’t have the necessary bit set.

All versions of FireRed, LeafGreen, and Emerald expect Mystery Events data to be marked as Japanese, regardless of the actual game language. (I still don’t know of a way to actually send Mystery Events to FireRed/LeafGreen or non-Japanese Emerald.)

It seems fairly pointless to have used four bitfields for this rather than two, and fairly obvious what the unassigned version bits might have represented.

Team Fail

  • GCLF Member
  • Offline Offline
  • CHARIZRAD 'M ROXORX or is it.
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #36 on: July 09, 2015, 12:36:31 pm »
Well, I'll keep my eyes out for other cards, like the trainer cards for the house on Seven Island. That's the card type that I'm wanting to be able to import, at least for now. I'm also trying to figure out on what part of the data the checksum is calculated so I can import my edited e-Reader file with the original header data intact, in case there's anything important that's read from there. Or would using nedcmake be perfectly fine for turning the VPK data into valid card data, and would the FRLGE application still accept it?

Háčky

  • Distinguished Member
  • *
  • Offline Offline
  • Pick which packet as an error?
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #37 on: July 09, 2015, 05:41:46 pm »
Well, I'll keep my eyes out for other cards, like the trainer cards for the house on Seven Island. That's the card type that I'm wanting to be able to import, at least for now.
The Trainer Tower cards were the only kind of card released for FireRed/LeafGreen, and I’m fairly sure Trainer Tower data is the only type of data accepted by the e-Reader version of Mystery Gift. The house on Seven Island, by analogy to those in Mossdeep and Sootopolis, would likely house a Mystery Events trainer if there were some way to send Mystery Events data to FireRed/LeafGreen, but I still don’t know if there is. The Pokémon Wiki article on Seven Island seems to say that the house was unused: 「民家には箱に覆われた謎の扉があるが、解明されることはなく、イベントなどは一切起こらない。」

I'm also trying to figure out on what part of the data the checksum is calculated so I can import my edited e-Reader file with the original header data intact, in case there's anything important that's read from there. Or would using nedcmake be perfectly fine for turning the VPK data into valid card data, and would the FRLGE application still accept it?
For some reason, nedcmake generates a completely different type of card header than what the original cards use—compare GBATEK’s documentation, which matches the original cards (and tells you how the checksums are calculated), to nedclib’s documentation. The format generated by nedcmake works with Scan Card, but apparently not with the Mystery Gift application.

Team Fail

  • GCLF Member
  • Offline Offline
  • CHARIZRAD 'M ROXORX or is it.
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #38 on: July 11, 2015, 09:47:27 am »
Hm. I was hoping to be able to import other things, like perhaps an unofficial gift for the special tickets, but it looks like that won't be possible then. I did notice though, that there were special FRLG cards that changed the layout of Trainer Tower. Are those still undumped?


As for the header issues, perhaps if I can figure out how to re-calculate the checksum programmatically, I can simply import VPK data into a ripped header and perform any necessary calculations on the checksum that are needed rather than making a new header completely.

SatoMew

  • Member+
  • *
  • Offline Offline
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #39 on: August 27, 2015, 03:32:24 pm »

Wack0

  • Coder, reverser, beta collector [BetaArchive staff]
  • Staff
  • *****
  • Offline Offline
  • Gender: Male
  • cBRH - Doing nothing since 2k7
    • View Profile
Re: Anatomy of an e-Reader Mystery Event
« Reply #40 on: February 24, 2017, 11:58:27 am »
Whilst reversing Gen III and adding the save structures of the various games to my payload code, I noticed something.

The Enigma Berry structure is different in FR/LG/Emerald!

It's only 0x30 bytes long; the sprite, palette and tag description elements were removed, leaving only the base Berry structure (0x1C bytes), the item-usage-by-trainer structure (0x12 bytes), the hold item effect (2 bytes) and bytewise checksum (4 bytes).

edit: the change was made in FR/LG, not Emerald (Emerald just inherited it)
« Last Edit: February 25, 2017, 09:57:08 am by Wack0 »
C H E C K E D . B U I L D S . A R E . A W E S O M E N E S S

BetaArchiveSoftHistory Forumsirc.rol.im #galaxy,#softhistory

Also known as The Distractor.

Shane, please stop telling children that there's a Mew outside under the delivery trucks. - Management

Pokémon: arbitrary code execution 1996-2016