Jump to content

Save Research BW


_Julián_

Recommended Posts

I reply the same that I put in gbatemp:

I made a bit of researcher in the save files and this is what I found:

- The size of 1 "save state" is 0x24000.

- In the file (512 KB) there are 2 "save state" (just like before), however, the second "save state" does not begins in the offset 0x40000, but 0x24000.

- This seems that in the "save state" is only one block/footer, it is in the offset 0x23F8C with 16 byte of

size.

- The footer structure is (little endian):

--- 0x0: Current number of save count (uint).

--- 0x4: Size of the block (it is 0x23F9C) (uint)

--- 0x8: Constant of the game (in White is 0x31053527) (uint).

--- 0xC: Padding = 00 00 (ushort)

--- 0xE: Cheksum (unknow to me).

Well, the checksum, the most important thing, seems to be changed, I don't know if this is still CRC16, but maybe (I thinks so) GF just changed the initial value or the final XOR value, but I don't know how to find this.

However, the pokemon structure DON'T changed, and fact, anybody can manualy put a pokemon of 4 generation (.bin extension) in the save with the correct offset (but ofcourse too, fixed the checksum), except the size of the pokemon in the party, now is 220 bytes.

This is another usefull offsets:

- Party pokemons: 0x18E08

- Box pokemons: 0x400

- Trainer name: 0x19404

-

PD: I hope that my english can be understand ^ _ ^ U.

Link to comment
Share on other sites

While it's appreciated that you're trying to help and provide information, we already knew all of this. :(

Yeah, the checksum is no given... it's the only thing that matters, but again, I don't know how figure out this.

However, I think that this topic was missing in this forum, and I think that is more important the research initiative, and don't wait for the japanese make all, and translate for example pokesav (btw, COM released pokesavbw).

(I hope a least find any information in google to reversal engineering <.<)

Link to comment
Share on other sites

Yeah, the checksum is no given... it's the only thing that matters, but again, I don't know how figure out this.

However, I think that this topic was missing in this forum, and I think that is more important the research initiative, and don't wait for the japanese make all, and translate for example pokesav (btw, COM released pokesavbw).

(I hope a least find any information in google to reversal engineering <.<)

Development is actually pretty active here, it's just that people don't use the forums a lot. If you want to come to the Project Pokemon IRC and chat you should be able to find lots of r&d talk.

Link to comment
Share on other sites

Yeah, the checksum is no given... it's the only thing that matters, but again, I don't know how figure out this.

It's not particularly easy if you take the assembly route, at least not with the tools I'm familiar with. I'll be trying to get it done today.

Link to comment
Share on other sites

While it's appreciated that you're trying to help and provide information, we already knew all of this. :(
Development is actually pretty active here, it's just that people don't use the forums a lot. If you want to come to the Project Pokemon IRC and chat you should be able to find lots of r&d talk.

True, but _Julián_ is taking a step toward documenting the info where everyone can find it... and that's never a bad thing.

I think it's a good idea for people to collaborate their findings so there isn't duplication of work and we can make faster progress on editing Black and White save files.

Link to comment
Share on other sites

  • 2 weeks later...

Finaly I could find and understand what I needed to know for seek for the whole code of the checksum. This is what I found:

The algorithm is still crc16-ccitt (how I supossed), but the calculations is made: no for 1 block, but 70 in total.

First, the checksum of the footer (see first reply) is calculated, but the data here begins at: 0x23f00 with length of 0x8c. This data is all the checksum ("backup") of each general block in the save file stored sequentially.

After validated the footer checksum, every checksum of the all general blocks is revised. The offset and the length of each one is:

- offset: 0x0 - length: 0x3e0

- offset: 0x400 - length: 0xFF0

- offset: 0x1400 - length: 0xFF0

- offset: 0x2400 - length: 0xFF0

- offset: 0x3400 - length: 0xFF0

- offset: 0x4400 - length: 0xFF0

- offset: 0x5400 - length: 0xFF0

- offset: 0x6400 - length: 0xFF0

- offset: 0x7400 - length: 0xFF0

- offset: 0x8400 - length: 0xFF0

- offset: 0x9400 - length: 0xFF0

- offset: 0xa400 - length: 0xFF0

- offset: 0xb400 - length: 0xFF0

- offset: 0xc400 - length: 0xFF0

- offset: 0xd400 - length: 0xFF0

- offset: 0xe400 - length: 0xFF0

- offset: 0xf400 - length: 0xFF0

- offset: 0x10400 - length: 0xFF0

- offset: 0x11400 - length: 0xFF0

- offset: 0x12400 - length: 0xFF0

- offset: 0x13400 - length: 0xFF0

- offset: 0x14400 - length: 0xFF0

- offset: 0x15400 - length: 0xFF0

- offset: 0x16400 - length: 0xFF0

- offset: 0x17400 - length: 0xFF0

- offset: 0x18400 - length: 0x9c0

- offset: 0x18E00 - length: 0x534

- offset: 0x19400 - length: 0x68

- offset: 0x19500 - length: 0x9c

- offset: 0x19600 - length: 0x1338

- offset: 0x1aa00 - length: 0x7c4

- offset: 0x1b200 - length: 0xd54

- offset: 0x1c000 - length: 0x2c

- offset: 0x1c100 - length: 0x658

- offset: 0x1c800 - length: 0xa94

- offset: 0x1d300 - length: 0x1ac

- offset: 0x1d500 - length: 0x3ec

- offset: 0x1d900 - length: 0x5c

- offset: 0x1da00 - length: 0x1e0

- offset: 0x1dc00 - length: 0xa8

- offset: 0x1dd00 - length: 0x460

- offset: 0x1e200 - length: 0x1400

- offset: 0x1f700 - length: 0x2a4

- offset: 0x1fa00 - length: 0x2dc

- offset: 0x1fd00 - length: 0x34c

- offset: 0x20100 - length: 0x3ec

- offset: 0x20500 - length: 0xf8

- offset: 0x20600 - length: 0x2fc

- offset: 0x20900 - length: 0x94

- offset: 0x20a00 - length: 0x35c

- offset: 0x20e00 - length: 0x1cc

- offset: 0x21000 - length: 0x168

- offset: 0x21200 - length: 0xec

- offset: 0x21300 - length: 0x1b0

- offset: 0x21500 - length: 0x1c

- offset: 0x21600 - length: 0x4d4

- offset: 0x21b00 - length: 0x34

- offset: 0x21c00 - length: 0x3c

- offset: 0x21d00 - length: 0x1ac

- offset: 0x21f00 - length: 0xb90

- offset: 0x22b00 - length: 0x9c

- offset: 0x22c00 - length: 0x850

- offset: 0x23500 - length: 0x28

- offset: 0x23600 - length: 0x284

- offset: 0x23900 - length: 0x10

- offset: 0x23a00 - length: 0x5c

- offset: 0x23b00 - length: 0x16c

- offset: 0x23d00 - length: 0x40

- offset: 0x23e00 - length: 0xfc

The checksum in the file for the block is in: offset+length+2 (I unknow what mean the number before the checksum, but seems that is alwasy 1 or 2 or 3).

After checked the block checksum, is checked also the corresponding checksum stored in the footer block (remember the above description).

And if everything is correct, the game is loaded.

I hope that all the offsets and lengths be right, however I proved this for B and W and seems to be the same.

Now will be more worthy to search for more interesting offset :-)

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...