theSLAYER Posted May 21, 2018 Posted May 21, 2018 6 hours ago, YoshiMoshi said: aura mew distribution and 10 ANNIV cartridge got leaked 6 hours ago, Deoxyz said: There's no Japanese Aura Mew, but I'm sure you just mistyped that. Technically speaking, Japanese "Aura" Mew would be Hadou Mew, lol. But yeah, Hadou Mew distribution wasn't leaked, it was Aura Mew (international). These get leaked possibly because: 1. The carts get moved around, to be brought to event venus (unlike being situated at Pokemon Centers)2. Maybe some disgrunted staff took them from a warehouse post event (when it wasn't a focus anymore), and wasn't destroyed after events. In my mind, both points are similar to how the NDS distribution carts always end up getting leaked. except the production of these are a heck load higher, as described by Deoxyz. 2 hours ago, YoshiMoshi said: I'd love to see a picture of this lol! Back from when our staff @ReignOfComputer went to Japan (more images here and here) 1
Sabresite Posted May 21, 2018 Posted May 21, 2018 Even though Hadou and Aura are the same name, the distribution software was different. Lots of reasons for why that is. 2
Guest Posted May 21, 2018 Posted May 21, 2018 (edited) This is Off-Topic... but I would like to add that PokePark Mew and Mystery Mew were both based on the Hadou Mew software. We know this because the OT Gender randomization is identical and they were all very likely seeded XORing the save file section checksums.Trash Bytes are identical as well. I personally believe that GCEA and all events that followed after were built on the Hadou Mew software as well... but this will probably never confirmed unless we get more roms. In relation to this Topic I have added a lot more content to the first post of the Thread, including the official sample scripts in readable form. Be sure to check out! Only stuff that's still missing is information about the Berry-Structure and Trainer-structure. Also thanks to @BlackShark who has provided a lot information in the past in this Thread which was very helpful, if there is anything more related that could be added let me know and I will edit it into the first post. Edited May 21, 2018 by ajxpk
BlackShark Posted May 21, 2018 Posted May 21, 2018 @ajxpk e-Reader Trainers Spoiler e-Reader Trainer Data Structure (188 Bytes) Save offset: RS 0x498 (Section 0) Em 0xBEC (Section 0) FRLG 0x4A0 (Section 0) RAM offsets: English, French, German, Italian, Spanish RS 0x0202533C E 0x02025640 FRLG 0x02024A28 Japanese RS 0x0202509C E 0x020252E4 FRLG 0x02024988 --------------------------- 0x00 - Battle Tower Type 0x01 - Trainerclass sprite indexes differ between the game versions 0x02 - Battle Tower Lv 0x00 => Lv 50; 0x01 => Lv 100 0x03 - 0x00 0x04 - Trainer Name RS (US/EU): up to 7 Bytes + string terminator 0xFF RS (Jap), FRLG & E: up to 5 Bytes + string terminator 0xFF 0x0C - Trainer ID default: 0x0000 0x0E - Trainer SID default: 0x0000 0x10 - Intro quote 6 x 2 Bytes 0x1C - Win quote 6 x 2 Bytes 0x28 - Lose quote 6 x 2 Bytes 0x34 - 1st Pokemon 44 Bytes 0x60 - 2nd Pokemon 44 Bytes 0x8C - 3rd Pokemon 44 Bytes 0xB8 - Checksum 4 Bytes (all 184 Bytes of the trainer data added together as words) Pokemon structure (44 Bytes) 0x00 - Species 2 Bytes 0x02 - Item 2 Bytes 0x04 - 1st Move 2 Bytes 0x06 - 2nd Move 2 Bytes 0x08 - 3rd Move 2 Bytes 0x0A - 4th Move 2 Bytes 0x0C - Level 0x0D - 0x00 0x0E - HP EVs 0x0F - Atk. EVs 0x10 - Def. EVs 0x11 - Init. EVs 0x12 - SP.Atk. EVs 0x13 - SP.Def. EVs 0x14 - ID 2 Bytes 0x16 - SID 2 Bytes 0x18 - IVs 4 Bytes 0x1C - PID 4 Bytes 0x20 - Nickname up to 9 Bytes + string terminator 0xFF 0x2A - 0x00 0x2B - 0xFF For the trainer class indexes you can refer to here: RS, FRLG, Emerald For the win/lose/intro quotes you can refer to here: RSEFRLG - Dictionary (Easy Chat) e-Reader Berries Spoiler e-Reader Berry Structure (1328 Bytes) Save Offset RS 0x2E0 (Section 4) RAM Offsets RS (EU/US) 0x02028894 RS (JP) 0x020285F4 --------------------------- 0x000 - 0x006 berry name + 0xFF string terminator 0x007 firmness 0x008 - 0x009 size (in mm) 0x00A max yield 0x00B min yield 0x00C - 0x00F berry tag line 1 RAM offset 0x02028D50 (US) / 0x02028AB0 (JP) 0x010 - 0x013 berry tag line 2 RAM offset 0x02028D7D (US) / 0x02028ADD (JP) 0x014 growth time per stage (in hours) 0x015 - 0x019 flavor 0x01A smoothness 0x01B 0 0x01C - 0x49B berry sprite (4bpp) (48 x 48 px) 0x49C - 0x4BB palette (16x2 Bytes / 5 bits per color) 0x4BC - 0x4E8 berry tag line 1 0x4E9 - 0x515 berry tag line 2 0x516 - 0x519 effect in bag 0x520 - 0x527 filled with 0 0x528 - 0x529 effect as held item 0x52A - 0x52B filled with 0 0x52C - 0x52F checksum Effects as held item 0x00 no effect 0x04 cures poison 0x05 cures burn 0x06 cures freeze 0x08 cures confusion 0x17 restores a lowered stat 0x1C cures infatuation Checksum unsigned long berryChecksum(char* berry) { int x; unsigned long checksum = 0; for(x = 0; x < 0x52C; x++) if(x < 0xC || x >= 0x14) checksum += (berry[x] & 0xFF); return checksum; } 1
theSLAYER Posted May 27, 2018 Posted May 27, 2018 @YoshiMoshi here's a gif for the receiving process: 10ANNIV Spoiler AURA Mew (sent to French Ruby): Spoiler Shiny Zigzagoon Spoiler 1
PMArkive Posted January 22, 2019 Posted January 22, 2019 I was curious how the US Colosseum Bonus disc knows whether the Wishmaker Jirachi has been received on a save, but it doesn't appear to be through any flags that PKHeX can diff (along with much of the save's data moved around). Here are the save files if anyone else wants to look at what changes Sapphire Before Jirachi.sav Sapphire Post Jirachi.sav
BlackShark Posted January 22, 2019 Posted January 22, 2019 1 hour ago, PMArkive said: I was curious how the US Colosseum Bonus disc knows whether the Wishmaker Jirachi has been received on a save, but it doesn't appear to be through any flags that PKHeX can diff (along with much of the save's data moved around). Here are the save files if anyone else wants to look at what changes Save block 4 offset 0x2B1 is set to 1 when Wishmaker Jirachi was received. That's at 0x82B1 in your Post Jirachi save file.
PMArkive Posted January 23, 2019 Posted January 23, 2019 1 hour ago, BlackShark said: Save block 4 offset 0x2B1 is set to 1 when Wishmaker Jirachi was received. That's at 0x82B1 in your Post Jirachi save file. Aye, you're right. I don't know if you found this in the Ruby/Sapphire disassembly, but I didn't think to look there until after your post... I tested with this code in PKHeX (well, a worse version of the code at first): public bool WishmakerJirachiGiven { get => GetFlag(BlockOfs[4] + 0x2B1, 0); set => SetFlag(BlockOfs[4] + 0x2B1, 0, value); } @Kaphotics would you be interested in adding the flag into PKHeX somewhere? 3
Kaphotics Posted January 23, 2019 Posted January 23, 2019 RS: https://github.com/pret/pokeruby/blob/51ecf10029f84dd5423cd59582d01eaee9140c0e/include/global.h#L727 E: https://github.com/pret/pokeemerald/blob/master/include/global.h#L885 FRLG: https://github.com/pret/pokefirered/blob/8367b0015fbf99070cc5a5244d8213420419d2c8/include/global.h#L745 seems like it was just an unused byte that was reused by the disc; since it only can be delivered to RS, I added some safeguards: https://github.com/kwsch/PKHeX/commit/7bb3f14e1f5eb3a49330a3b23207523a7783010e no gui support atm; can flip it pretty easily with linqpad: var path = @"savefile full path goes here"; var data = File.ReadAllBytes(path); var sav = new SAV3(data, PKHeX.Core.GameVersion.RS); sav.HasReceivedWishmkrJirachi = false; File.WriteAllBytes(path, sav.Write(false, false)); 2
Sabresite Posted January 24, 2019 Posted January 24, 2019 Most likely other events had flags too. I think I remember Bulbapedia saying something about 48 celebi total being able to be transferred? How is that determined?
Guest Posted January 24, 2019 Posted January 24, 2019 (edited) @Purin is right. Distribution Count must have been stored on the Colosseum save file. The flag is indeed checked and set only by the Wishmaker Jirachi Multi Boot ROM, which does have FRLG support, it’s just locked by the function that calls the subroutine to check the GameCode. This check was exclusively added for the Wishmaker Multi Boot ROM, I think because of the Berry Program Update. The same Jirachi flag however is also used by the known earlier version of the software (client.2003_1112.bin/Meteor Jirachi) which uses the same Jirachi flag, there it only checks the language version and that’s why it always works with RSFRLG by default. Interesting to note: The Meteor Jirachi Multi Boot ROM doesn’t have any function of the SIIRTC library so this was added for Wishmaker. Also the Setup for the Origin Game is missing in the Meteor Jirachi version what I think could be leftover from the Alternate Negaiboshi Jirachi (distributed via GCN development system) where it was not needed as it was determined by the GameCode of the inserted cartridge, same as the OT Gender is missing which was based on the Trainer's OTG. I think that the Jirachi flag could be originating from it, because it looks the alternative Negaiboshi Jirachi was self-service and that's possibly why they added that restriction. However without an original save file we are unable to confirm it. Also I have read that some PCNY events were limited, not sure if it was about the GBC Events or GBA Events as it was a blog entry about PCNY Events in general. What’s interesting... client.bin and client.2003_1112.bin have Emerald support (which must have been in early phase) and there even is a check whether the cartridge inserted is inserted, although not working by default, but with some little tweaks these Multi Boot ROMs also work with Emerald. Why it works even Emerald was not finished yet is simple to explain because the Multi Boot ROM support as far as preparation of Offets goes for FRLG and E is identical. In these games close to the ROM header (starting at Offset 0x08000128) there is some information stored which is used by the Multi Boot ROMs to determine specific save file offsets universally. Obviously when they made the newer GBA Pokémon Games they added this for a better Multi Boot support, they didn't had to add much new code for new games and it also keeps the Multi Boot ROMs as light as possible. Edited January 31, 2019 by ajxpk
UndeadxReality Posted April 10, 2020 Posted April 10, 2020 I'm sorry to bump this thread after over a year and a few months but I was looking through the thread and noticed the scripts pertaining egg events didn't seem to have a line dedicated to OT, Trainer ID, and Secret ID. In theory wouldn't that be something we could script in to change or would that be impossible?
Sabresite Posted April 11, 2020 Posted April 11, 2020 Which egg scripts? Wondercard? If so that is all done when generated in-game
UndeadxReality Posted April 11, 2020 Posted April 11, 2020 Just the mystery.gift.tool scripts you can get from xse export.
Sabresite Posted April 12, 2020 Posted April 12, 2020 I think you can do quite a bit but there is limited space because it's a fixed size iirc. If it's an egg then it doesn't matter once it hatches.
BlackShark Posted May 28, 2020 Posted May 28, 2020 Hasn't been documented anywhere yet I think: FRLG/E e-Berry Structure FRLG: Section 4 - 0x026C E: Section 4 - 0x0378 0x00 - 0x06 berry name + 0xFF string terminator 0x07 firmness 0x08 - 0x09 size (in mm) 0x0A max yield 0x0B min yield 0x0C - 0x0F berry tag line 1 ROM offset 0x10 - 0x13 berry tag line 2 ROM offset 0x14 growth time per stage (in hours) 0x15 - 0x19 flavor 0x1A smoothness 0x1B 0 0x1C - 0x1F effect in bag 0x24 - 0x27 unknown pointer 0x28 - 0x2B unknown pointer 0x2D - 0x2E unknown 0x2E - 0x2F effect as held item 0x30 - 0x33 checksum The size is 52 bytes. Checksum is calculated the same way as in RS, except that it does not skip 0xC - 0x14 for the sum. 3 1
Guest Posted May 29, 2020 Posted May 29, 2020 Good to have it confirmed now. I have added it to the first post.
superguideguy Posted July 2, 2020 Posted July 2, 2020 I've been lurking for a while now, but I think I'm finally ready to add what information I know about the distribution ROM. I apologize if I repeat something that was already known, but I checked the last 5 or so pages, and I didn't find the information I have. The actual script data for the Aurora Ticket distribution starts at 0x12728. It is the raw data - unencrypted and uncompressed. Noteworthy is the fact that the checksum and header are not stored here. I edited the script to give me both the Aurora Ticket and Mystic Ticket, and it worked! This means the checksum is calculated dynamically, rather than stored elsewhere on the ROM. The Wonder Card starts at 0x14FB8. At least, that is where the checksum would be. I haven't confirmed if the checksum is calculated dynamically, but I can't find it stored anywhere in the ROM, so I'm assuming it's dynamic. I tried my hand at disassembly. Here's what I've learned: The disassemblers designed for generic ARM7-TDMI code don't like disassembling THUMB code. The disassemblers designed specifically for the GBA (e.g. luvdis) don't like disassembling ARM code. Overall, I'm bad at reading assembly code. Something (maybe) useful: the Wireless Adapter uses the 32-bit "normal" serial communication mode. (It sends data by writing to register 0x04000120.) Not strictly about the distribution ROM, but the "virtual" script functions (opcodes B8 through BF) can access data in the Wonder Card and Wonder News sections. Thus, a properly crafted Wonder Card could add an additional 320 bytes of script data. Finding a way to distribute Wonder News would add another 440 bytes of usable script data. I've been doing some digging into the decompilation projects, and I've found two functions that might be responsible for Emerald rejecting the distribution: "ValidateMEventClientHeader" / "sub_801B6A0" FireRed: https://github.com/pret/pokefirered/blob/2880cf2a51ea36fa36f00d9ecf07177e5955c882/src/mevent.c#L788 Emerald: https://github.com/pret/pokeemerald/blob/4dd3cc7b7691afb8ecd2e8af8b2ebfa717dd2414/src/mevent2.c#L380 "CheckCompatibility" Ruby: https://github.com/pret/pokeruby/blob/f839afb24aa2c7b70e9c28a5c069aacc46993099/src/mystery_event_script.c#L38 FireRed: https://github.com/pret/pokefirered/blob/2880cf2a51ea36fa36f00d9ecf07177e5955c882/src/mystery_event_script.c#L30 Emerald: https://github.com/pret/pokeemerald/blob/4dd3cc7b7691afb8ecd2e8af8b2ebfa717dd2414/src/mystery_event_script.c#L28 Given that "ValidateMEventClientHeader" appears in FRLG and Emerald, but not RS, I suspect it is this function that is used for the Wireless Adapter, while "CheckCompatibility" is used for the eReader. Regardless, as long as it is one of these two functions, the remedy is the same. Replace a 0x1 somewhere with 0x5, and replace a 0xF with 0x20F or 0x38F. Unfortunately, like the checksums, these values do not appear to be stored directly on the ROM. They are likely caused by MOVS or ADDS instructions, instead. I hope this helps, and let me know if there's anything else I can do to help. 5
superguideguy Posted July 9, 2020 Posted July 9, 2020 Long-winded story in the spoiler tag. Spoiler For the past week I've been working on finding out how the distribution ROM was sending the compatibility header to the game. To cut a very long story very short, that adventure was fruitless. First, I tried making a custom disassembler. My issue with reading assembly was that it looked weird, so I thought that if I translated every THUMB function to a "C" look-a-like, I would understand it better. I got pretty far, but then I ran into the horror that are function pointers. This also caused my trials with luvdis's configuration mode to end as well. Simply put, without an extremely good guessing algorithm, function pointers make it near-impossible to analyze a ROM. I turned back to the internet, and researched if there were any other GBA disassemblers other than luvdis. I found a Medium article that recommended ISA Pro, but at ~$2600, I said no way. In desperation, I stumbled across a blog post (https://cturt.github.io/pinball.html) that recommended a program called Ghidra. Ghidra is a multi-platform, free and open source decompiler, that is compatible with ARMv4T. The one major issue that I have with it is that it is developed by the NSA. Yes, that NSA. The tool took some getting used to, but I found that it turned the ROM from a messy mix of THUMB and ARM functions into a nice C-style program (save for the absolutely useless variable names like "bStack11"). Even with this, though, I failed to find how the program was writing the script to the SIODATA32 register. (I still have not found how it does this. My best guess is that it actually sends a command to the Wireless Adapter to DMA from ROM, or from WRAM around 0x03002500.) What Ghidra did help me find was similarities between the distribution ROM and FireRed/Emerald. In particular, I found some low-level functions in the FireRed/Emerald disassemblies (called STWI), that were also present in the distribution ROM. This reminded me that FireRed & Emerald can send Wonder Cards, and thus act as a server as well as a client. Even this was a wild goose chase. I was unable to find out how the server commands linked to the low-level STWI commands. Thus, I turned back to my original strategy of looking for the hex values associated with the compatibility header, in particularly 0x101. To my surprise, Ghidra found a function that relied upon it. A very familiar function... It was a copy of FireRed's ValidateMEventClientHeader function! Nothing called it, of course; stupid function pointers ruining everything. But it made me wonder, why was it here? As I wondered, I returned to common_mainseq_4 (https://github.com/pret/pokefirered/blob/2880cf2a51ea36fa36f00d9ecf07177e5955c882/src/mevent_server.c#L118), which had been a common thread in my investigation. Indeed, I had been puzzling over this function for weeks. But, I had been looking at Emerald's version. The one thing the FireRed disassembly has over Emerald's is that more functions and constants have names. This ended up being the key factor in the solution. In a fit, I looked at FireRed's gMEventSrvScript_SendCard. Emerald's is an absolutely atrocious mess (https://github.com/pret/pokeemerald/blob/5183cdb35722549d6b465ccaf8c4a21422ecb254/src/mevent_scripts.c#L178). But FireRed's is much cleaner (https://github.com/pret/pokefirered/blob/a0b2fa5d33c43bc4f42fc4f132f73e960d771d5b/src/mevent_scripts.c#L179). In particular, it has the line "SRV_SEND(0x20, gMEventClientScript_Send1442CC),". I knew that 1442CC was associated with the compatibility header, so I went down the rabbit hole. The first instruction sent was by gMEventClientScript_Send1442CC was "CLI_SNDHEAD". I realized that I had everything all wrong. The distribution ROM doesn't send the compatibility header to the games, the games send the compatibility header to the distribution ROM! The only reason the games have the ValidateMEventClientHeader is because they can act as the server. I checked the definition of CLI_SNDHEAD, and saw it was client instruction 8. I looked at the client's version of common_mainseq_4, case 8, and found a function called "BuildMEventClientHeader" (https://github.com/pret/pokefirered/blob/2880cf2a51ea36fa36f00d9ecf07177e5955c882/src/mevent.c#L753). The function, as expected, builds the header in question. Emerald's counterpart is sub_801B580 (https://github.com/pret/pokeemerald/blob/ebade7affb31d5bcdc17cdcd3895758010ee6f66/src/mevent2.c#L338), which also build the header as expected. At least, if "a1" is 0. If a1 is not 0, then it should already be compatible. One more trace later, and I discovered that a1 is 1 for Wonder News, and 0 for Wonder Cards. Finally, the mystery had been solved. TL;DR: Rather than the games checking the compatibility header, the distribution ROM does. Patch instructions below. (If anyone wants to make an IPS/UPS/BPS patch, go ahead! I just don't feel like downloading one more program for this project to make one.) Due to space constraints, it is impossible to patch a fix in to the same location. However, it is possible to patch out the check completely. Replacing 0x714C through 0x7173 (inclusive) with 0x00 patches out the region, game, and language checks. It leaves the sanity check, however. (Also, see below regarding the language check.) Why does this matter? Using direct injection, I already knew that it is possible to use "comparefarbytetobyte 0x80000AE 'E'" (ASCII 'E', not the proprietary encoding 'E') to check for whether a game is Emerald or not. "comparefarbytetobyte 0x80000AF" can also be used to check for language. Thus, while scripts for both versions - and texts for all languages - would need to fit into 1000 bytes, it is now possible to make a multi-version multi-language distribution ROM. One last thing. I found a glitchcity forum post (Reply #35 at https://forums.glitchcity.info/index.php?topic=7114.30) that confirmed my suspicions regarding the CheckCompatibility function. FireRed, LeafGreen, and Emerald act as Japanese cartridges, regardless of their actual language. This carries over to ValidateMEventClientHeader. Thus, all games can receive the Mystery Gift, regardless of the language of the distribution. This does leave a question as to how the European distribution ROM knew which version to send. It may be the case that only English carts act as Japanese carts. However, without a European decompilation, and without a European cart of my own, I'm left without means to test this hypothesis. 2
skyparrillo Posted February 12, 2021 Posted February 12, 2021 I'm curious as to how possible it would be to edit these event files, or other ROMs that have been released public like Aura Mew, to distribute custom Pokemon. Say I wanted to create an event cartridge using a flash card on my GBA to share a custom shiny Bulbasaur with my friends, instead of just trading it over. To try and recreate the feeling of getting a cool new event Pokemon through an "actual" event. How possible is this currently?
superguideguy Posted February 12, 2021 Posted February 12, 2021 On the event side, it’s just a flag. (See first post in thread for which flag.) If the flag is set, the event can be redistributed to the same region. (FRLG can distribute to FRLG, and E can distribute to E.) As for if you want to distribute to both FRLG and E at the same time, you need a special distribution ROM. Luckily, any FRLG/E version can be turned into a distribution ROM with a simple patch. That is, if you know where the function is. I’ve been a bit busy with university, so I haven’t updated it in a while, but I actually have a patcher on my GitHub. As long as you have an English FireRed/LeafGreen v1.1 or English Emerald, you can make a distribution ROM from it. GitHub is here: https://github.com/superguideguy/gen-iii-event-patcher
Recommended Posts