Save Research BW

[_Julián_]

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.

[Codr]

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

[_Julián_]

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 <.<)

[Poryhack]

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.

[Codr]

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.

[codemonkey85]

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.

[_Julián_]

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 :-)

[piotr_mil]

I was wondering if it is possible to compare two save files to check what part of the save file is responsible for pokemon/trainers to appear in white forest/black city.