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

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

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.

Here is something like pokesav in GBA: http://projectpokemon.org/forums/showthread.php?6683-GBA-to-NDS-pkm-files&p=63922&viewfull=1#post63922