Edit OT in FR/LG

[Arqui]

Hi to everybody!

Well, I'd like to edit the OT from my FR sav. I know there is no editor (like PokeSav), and the only way is editing with an hexadecimal editor.

I've been trying to find the OT but I suposse that It's in hexadecimal, and I don't find it.

Does anyone can edit that? I need edit it. If someone can tell me, thanks.

[codemonkey85]

I've been trying to find the OT but I suposse that It's in hexadecimal, and I don't find it.

What are you looking for, the OT name, or OT ID / SID?

If you are looking for the OT name, you should check out this RS text table. There is a bit of information about the general save structure here too.

For the OT ID / SID, it's pretty easy to convert decimal to hexadecimal.

Also, if you make any changes to the save file, you will need to recalculate the save file checksum(s).

[Arqui]

What are you looking for, the OT name, or OT ID / SID?

If you are looking for the OT name, you should check out this RS text table. There is a bit of information about the general save structure here too.

For the OT ID / SID, it's pretty easy to convert decimal to hexadecimal.

Also, if you make any changes to the save file, you will need to recalculate the save file checksum(s).

Oh thanks. I got it.

This thread can be closed.

[Syberia]

You could also use something like Ciro's Pokemon Maker to create a code to change your OT/ID/SID with AR.

[Shiny164]

I'm trying to figure this out myself at the moment. I've found where the Trainer name, ID, and Secret ID are stored, but I don't know where the checksum is or what to change it to. Does anyone know how to work it out? I'd really appreciate any help you can offer.

[codemonkey85]

I think SCV knows about the GBA save file structures, but not too many other people do. All I know is that the save file is split into sixteen (!) different blocks, all with their own checksum, and that those blocks shift positions relative to each other (or something like that).

[Shiny164]

Okay, thanks! I think I've narrowed the checksum location to one of two places in the save file I have right now, so I guess I'll just keep looking for how to calculate what it should be.

I am sort of wondering what they were thinking when they made the games like that, though. Wouldn't it have been simpler for them to have everything in fixed locations? Surely they didn't just do it to make hacking harder.

[ifyfg]

maybe!

can't the guy who started this thread say how he did it? (if it's not too much to ask.)

[Shiny164]

I was kinda hoping so, to be honest. They might not be watching this post any more though.

[Pup]

Hey, sorry about resurrecting a 2 week old post but I saw that codemonkey85 had referenced my page (http://furlocks-forest.net/wiki/?page=Pokemon_GBA_Save_Format) and that people didn't get much info on how the original poster managed to do what he set out to do.

Just thought I'd open myself up to questions since I've had a fair bit of experience examining the GBA pokemon save format.

[codemonkey85]

I would like to open this discussion up, for sure.

For starters, do you know the overall placement of the blocks comprising the GBA save files, and what purpose each block serves? Do you know how to tell which blocks are current and which are backups?

There appears to be info out there already for how to calculate block checksums and how to encrypt / shuffle PKM data in the GBA, so if the above questions are answered, I may start digging into GBA save files this week to see if I can extract Pokémon data. At that point, it should be easy enough to convert that data into the DS structure. Then a "virtual Pal Park" app should be doable.

[Shiny164]

Arqui used an AR code generator in the end, and gave me the download link so I could use it as well. That sorted out what I wanted to do, but I'm still interested in directly editing the save file, since I'm not a massive fan of cheat codes and they don't seem to be too fond of me either :-)

The main issue I came across was checksums - if you know anything about how they're calculated for the Pokemon GBA games, that would be wonderful!

Also, I think the trainer details (name, ID, SID) are somehow linked to the amount of money the player has, since when I copy-pasted the entire block that the trainer details are stored in from one brand new save file to another, the trainer details all came out exactly as planned, and everything seemed fine except that I had $?6371 (yes, that question mark was intentional). So if you know anything about that I'd be very interested as well, but I'm not expecting anything since it's probably not an issue that comes up all that often!

codemonkey85, this many seem like a stupid question, but why would you want to do that? I mean, if you have the ability to directly edit your save files, wouldn't you also have the ability to back up and restore them? So you could take a backup of the GBA save, Pal Park your Pokemon, and then restore the backup so that your Pokemon are still on the GBA game. I'm not criticising or anything, just curious. And probably missing something blindingly obvious.

[codemonkey85]

codemonkey85, this many seem like a stupid question, but why would you want to do that?

This isn't meant for personal use; I plan to add Pal-Parking as a feature in my code library, and I know PPSE will have such a feature as well. It's meant so that you can import Pokémon from GBA games to DS games in a way that is 100% legal and accurate.

Not to mention the million other uses I could think of if one were able to extract PKM data from GBA games, like mass-dumping of PKM files for instance.

[Pup]

For starters, do you know the overall placement of the blocks comprising the GBA save files, and what purpose each block serves? Do you know how to tell which blocks are current and which are backups?

Each block of 4KB has 12 bytes at the end of it that you can identify it by:

0x0FF4 - byte - Block ID (0x00-0x0D)

0x0FF5 - byte - Unknown

0x0FF6 - word - Checksum (total value of first 3968bytes of block, Modulus 0xFFFF)

0x0FF8 - long word - validation code 0x08012025

0x0FFC - long word - save ID - (highest value is most recent save)

(this is stored in little endian so in a hex editor you'll see the bytes in reverse order - the validation code will show as 25 20 01 08 for example.)

You have to process the blocks and rebuild the whole file before you can really start looking at the data as certain structures, such as PC boxes, cross block boundaries. When you're rebuilding the file, you just take the first 3968bytes of each block and put them all together in order.

In the rebuilt file, party pokemon are at 0x11B8 in RSE and 0x0FB8 in FrLg and box pokemon are at 0x4D84 in all versions. I haven't taken the time to locate pokemon in the day care but they should be easy to find if you look up their names with the appropriate text table.

Does that cover everything? :3

Not to mention the million other uses I could think of if one were able to extract PKM data from GBA games, like mass-dumping of PKM files for instance.

I was going to do something like this for the DS, so you could extract stuff directly from the GBA pokemon cart and basically trade via the internet. It never happened though.

[codemonkey85]

You have to process the blocks and rebuild the whole file before you can really start looking at the data as certain structures, such as PC boxes, cross block boundaries.

Wow, what a pain in the neck.

Hm. Well, that covers the important stuff. Since I already have the aforementioned text table and months of experience in hacking DS saves, this is all the info I need to do... everything.

Thanks!

---------- Post added at 07:08 AM ---------- Previous post was at 06:38 AM ----------

0x0FF4 - byte - Block ID (0x00-0x0D)

0x0FFC - long word - save ID - (highest value is most recent save)

You have to process the blocks and rebuild the whole file before you can really start looking at the data as certain structures, such as PC boxes, cross block boundaries. When you're rebuilding the file, you just take the first 3968bytes of each block and put them all together in order.

Couple questions:

1. If Block ID only goes to 0xD, does that mean there are only 14 blocks instead of 16?
   
2. You say that each block has a save ID, but some data crosses block boundaries. Does that simply mean half of the blocks comprise the current save and half comprise the backup, like in DS saves? And data within one half can cross block boundaries within that same half?
   

[Pup]

1. If Block ID only goes to 0xD, does that mean there are only 14 blocks instead of 16?
   
2. You say that each block has a save ID, but some data crosses block boundaries. Does that simply mean half of the blocks comprise the current save and half comprise the backup, like in DS saves? And data within one half can cross block boundaries within that same half?
   

1. Yeah there's 14 blocks per save file, and there are 2 save files, so 28 blocks. The rest is just padding/empty space.
   
2. Basically, the file isn't sctructured as 14 seperate blocks, it is just split and saved that way. And yes, there's a back up save but the two are completely seperate - you wouldn't need to rebuild both files.
   

[codemonkey85]

1. Yeah there's 14 blocks per save file, and there are 2 save files, so 28 blocks. The rest is just padding/empty space.
   
2. Basically, the file isn't sctructured as 14 seperate blocks, it is just split and saved that way. And yes, there's a back up save but the two are completely seperate - you wouldn't need to rebuild both files.
   

So the 28 blocks of the save file, once they are unshuffled and stripped of their footers, are all in sequence with no spacing / padding? When you say there is padding, is that padding located at the end of the save file? Or is there padding between the two halves of the file? I believe the save file is 0x20000 (131,072) bytes long, AKA 128kb... is that right?

I wish I had a GBA save to look at now, but I'm at work actually. >_>

[Pup]

So the 28 blocks of the save file, once they are unshuffled and stripped of their footers, are all in sequence with no spacing / padding?

Not sure what you're asking.

When you say there is padding, is that padding located at the end of the save file? Or is there padding between the two halves of the file? I believe the save file is 0x20000 (131,072) bytes long, AKA 128kb... is that right?

It's at the end of the save file. So you've got 14 blocks of file 1, 14 blocks of file 2, then padding upto the end of the file, which is 128kb as you say.

I wish I had a GBA save to look at now, but I'm at work actually. >_>

Check your PMs :3

Edited July 31, 2009 by Pup

[codemonkey85]

EDIT: If there are any mods around, maybe this thread should be moved to Save Research & Development at this point.

Not sure what you're asking.

So you've got 14 blocks of file 1, 14 blocks of file 2, then padding upto the end of the file, which is 128kb as you say.

Nevermind, that first question was answered by the answer to the second question. Sometimes I word things all funny-like.

I'll check my PMs, thanks!

EDIT:

Just a quick update: thanks to Pup and his wonderful information and explanations, I have spent my lunch hour writing up structure definitions for GBA save blocks, GBA save block footers, and a couple of bare-bones definitions for RSE and FRLG save files. Thanks to the miracle of binary serialization, it is a trivial matter to extract the 28 save blocks, and hopefully tonight I can finish my function for unshuffling those blocks and converting the data portion of each block into a complete save file. If I can get that to work, I'll get to work on the explicit layout of the save files, and then the conversion of GBA PKMs to DS PKMs, and after that... the Pal-Parking will commence!

FYI Shiny164, if I get to that point, I will help you by creating a program to directly edit your OT info.

Edited July 28, 2009 by codemonkey85

[Pup]

I have spent my lunch hour writing up structure definitions for GBA save blocks, GBA save block footers, and a couple of bare-bones definitions for RSE and FRLG save files. Thanks to the miracle of binary serialization, it is a trivial matter to extract the 28 save blocks, and hopefully tonight I can finish my function for unshuffling those blocks and converting the data portion of each block into a complete save file.

Glad to be of help. I don't suppose you'd mind sharing your methods would you?

Edited July 31, 2009 by Pup

[codemonkey85]

Naturally. My code library is, after all, going to be open source.

I'm almost there... just turns out unshuffling / decrypting the PKM data is slightly more annoying than I thought it would be.

[Shiny164]

Oh, wow! You guys are awesome!

Pup, thank you so much for your help with the checksum! I really appreciate it. I am now the proud owner of my very first edited-myself-without-corrupting-it save file, thanks to your research

codemonkey85, thank you very much for your offer of making a trainer detail-changing program! I don't need it, since I've got the changes I needed working now, but it was really kind of you to offer Will the program you're working on now be able to convert DS -> GBA, or only GBA -> DS? 'Cause I bet there are a few people out there who've Pal Parked a Pokemon and then later regretted it.

[codemonkey85]

Unfortunately, for some odd reason I am getting the wrong species ID number from any Hoenn Pokémon when reading the save file, and until I fix that I can't do anything. Other data is correct, and the species ID is correct for Kanto / Johto Pokémon, so I'm not sure what the problem is... blargh.

But when I am finished (and have GBA --> DS working right), I will consider a DS --> GBA converter as well. It's an interesting idea to be sure.

[Pup]

Hey. I know I replied to this in PM but just in case anyone else could use this information ->

The species in the pokemon data on the GBA isn't the pokedex index number, it's done using a slightly different list which includes a large gap filled with non-pokes between Celebi and Treecko.

Full details of the index number can be found here. In my experience though you can ignore the egg and Unown letters past 411 as these aren't used in this data structure - all Unowns will have species ID 201 and eggs are determined by bit 30 in the IV data (see here for position of IV data) and I think a sanity byte (see here) of 6.

Edited July 31, 2009 by Pup
remembered something

[codemonkey85]

Yes, I finally stumbled across that Bulbapedia article regarding the GBA Pokémon index numbers last night after much frustration. If I ever meet someone from the team that programmed the GBA games, mark my words, I will kick them in the shins. Repeatedly. And vigorously.

Anyway.

The current task is to convert the GBA data to DS data. Right now I am constructing a function to copy data from the GBA structure properties to the DS structure properties, but I am wondering if I will have to make a lookup table to convert item index values and stuff to the DS values like I had to do with the species ID (I assume I will, argh!). So it's tedious work, but it's coming along.