ROM Hack Pokemon Black/White Hacking Documentation

[Spenstar]

Yeah, thanks for quoting that here SpenStar. Was going to do but got sidetracked.

yeah, no problem.

 

[Neobenedict]

http://gbatemp.net/t255889-pokemon-black-w...n-fixes-meeting

 

[Rykin]

Position 0x1, length 0x2: always "0200"
position 0x3, length 0x2: word with the number of sentences stored in the file

REST UNKOWN AT THE MOMENT

The first set of HEX is the filename number, the next list how many items (sentences) are stored in the file, and then the parts following that point to where the sentences are stored in the file.

This is, of course, after it's decrypted.

 

[windwakr]

The first set of HEX is the filename number, the next list how many items (sentences) are stored in the file, and then the parts following that point to where the sentences are stored in the file.

This is, of course, after it's decrypted.

Position 0x0 , length 0x2: Always "02 00"
Position 0x2 , length 0x2: Word with the number of sentences stored in the file
Position 0x4 , length 0x2: Unknown, but seems to still function when zeroed out
Position 0x6 , length 0xA: Seems to always be '00 00 00 00 00 00 14 00 00 00'
Position 0x10, length 0x6: Uknown, but seems to work when these are zeroed out

Pointer table seems to start at 0x16
Pointers seem to be encrypted

Pointer format as I see it:
Size 0x4: Encrypted location
Size 0x4: Unknown value. If it's too low, the text will displayed as garbage. Too high, and text will appear fine.

Repeat the pointer format the number of times given in the word at 0x2.


One of the first three sentences starts at 0x160. The only pointers that could use that(I zeroed out the rest, so it has to be one of these) are:
QUOTE

00 24 01 00 Location
00 15 00 00 Unknown

01 4E 01 00 Location
00 17 00 00 Unknown

01 7C 01 00 Location
00 15 00 00 Unknown

Find out how one of those gets decrypted to 0x160 and we'll be making some progress.


I've managed to zero out everything in 179 except 0-0x2C and 0x160-0x369 and still have it function if I set byte 0x2 to '03'(change the number of sentences to three). So, the first three sentence in the file are located in the block 0x160-0x369.


EDIT:
The second menu option is stored at 0x190-0x1A5. Each character must be encrypted separately, because if I modify something in that sentence, only the character I modify corrupts. The characters are stored two bytes each.


I'd try debugging in the No$ debugger, but I can't get the damn game to run in it.

 

[Deleted User]

Hey, how would I change the ROM Header with DSLazy?

 

[Spenstar]

Hey, how would I change the ROM Header with DSLazy?

I actually would use DSbuff found here to change the header. It's similar to DSlazy but has a better UI.
If you need more help, just ask.

 

[Chopders]

Hey, how would I change the ROM Header with DSLazy?

I actually would use DSbuff found here to change the header. It's similar to DSlazy but has a better UI.
If you need more help, just ask.

Do you think it's possible to extract the 3D models from the game and open them in a 3D software? Thanks

 

[Rykin]

My mistake. I was looking at my old HGSS files.

 

[Aerow]

Although I told my wife I wouldn't try to crack this game, I've already given in and downloaded the files so I could take a peak at this script file. At first glance, it would appear that the format is slightly different than that of the older DS games, and this is partly true.

Some of the files seem to retain properties similar to that of DP/GS. For example, bin number 791 (there are more, but this one is a large example) can easily be encrypted/decrypted the same way as the older DS games. However, there seem to be new configurations (such as that with 179, the title menu) which has a different structure. Looking at it, I believe it's the same encryption as the older games as well- however, it doesn't work with newpoketext because newpoketext is looking for a very specific setup which this file doesn't match.

I have to go to work now, so I won't be back till much later. However, here is a rar containing file 791, encrypted/unencrypted, and a htm file of the ripped text (I believe it is Pokedex Entries). This is just being posted as proof that I'm not BSing (to stop the haters).
http://www.megaupload.com/?d=G7KFXQZO

So what you are saying is that the game can easily be Decrypted?

 

[windwakr]

Although I told my wife I wouldn't try to crack this game, I've already given in and downloaded the files so I could take a peak at this script file. At first glance, it would appear that the format is slightly different than that of the older DS games, and this is partly true.

Some of the files seem to retain properties similar to that of DP/GS. For example, bin number 791 (there are more, but this one is a large example) can easily be encrypted/decrypted the same way as the older DS games. However, there seem to be new configurations (such as that with 179, the title menu) which has a different structure. Looking at it, I believe it's the same encryption as the older games as well- however, it doesn't work with newpoketext because newpoketext is looking for a very specific setup which this file doesn't match.

I have to go to work now, so I won't be back till much later. However, here is a rar containing file 791, encrypted/unencrypted, and a htm file of the ripped text (I believe it is Pokedex Entries). This is just being posted as proof that I'm not BSing (to stop the haters).
http://www.megaupload.com/?d=G7KFXQZO

What file is that 791 located in? There's only 200 some files in 0/0/2.

 

[Rykin]

Only 200 some? Are you certain you extracted the narc properly? pokemon games have been known for using a narc file that doesnt have filenames for the individual parts and as such you need a special build of narctool to decompile it. Of course, i could have my folders mixed as i did this very quickly this morning. when i get home from work i will double check, but i am rather certain there are 700+ files much like the msg,narc of games before.

 

[_Julián_]

Save Research BW:

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.

 

[windwakr]

Only 200 some? Are you certain you extracted the narc properly? pokemon games have been known for using a narc file that doesnt have filenames for the individual parts and as such you need a special build of narctool to decompile it. Of course, i could have my folders mixed as i did this very quickly this morning. when i get home from work i will double check, but i am rather certain there are 700+ files much like the msg,narc of games before.

What did you use to extract the Narcs?

 

[Michael Myers]

please accept my pokemon black dsv desmume save

http://www.2shared.com/file/qJZ1E4Th/pokem...ck_version.html

 

[Rykin]

Oh. My mistake. It seems that I had some of my HGSS files mixed in with the BW files.

There are 272 files in /0/0/2.

Looking at the files, I believe the problem with Poketext is that the pointers are now not encrypted, which they were before, so Poketext throws an error because of this. The only way I can test for sure is to load the poketext source into a compiler, but I no longer have one installed on my PC. Seeing as Kazowar has already made some progress on a patch, I'm going to step out of the scene and just watch this run.. I'm too busy playing Halo Reach and finishing school.

Peace out, ya'll. :>

 

[Deleted User]

EDIT: NVM, works

 

[windwakr]

Oh. My mistake. It seems that I had some of my HGSS files mixed in with the BW files.

There are 272 files in /0/0/2.

Looking at the files, I believe the problem with Poketext is that the pointers are now not encrypted, which they were before, so Poketext throws an error because of this. The only way I can test for sure is to load the poketext source into a compiler, but I no longer have one installed on my PC. Seeing as Kazowar has already made some progress on a patch, I'm going to step out of the scene and just watch this run.. I'm too busy playing Halo Reach and finishing school.

Peace out, ya'll. :>

No, the pointers are encrypted. For example, the second menu item is located at 0x190 in the 179 file. The only pointers that could possibly point to it are(I zeroed out the rest):
QUOTE00 24 01 00 Pointer 1
00 15 00 00

01 4E 01 00 Pointer 2
00 17 00 00

01 7C 01 00 Pointer 3
00 15 00 00

BTW: It's pointer 3.

As you can see, there's no 0x190 in there, so they must be encrypted.

EDIT: Also, 179 for the title menu only applies to Black from what I see. It must be different in White.

 

[Zarxrax]

If someone could convert the script to text and post it somewhere, that would be awesome.

 

[whyyes]

If someone could convert the script to text and post it somewhere, that would be awesome.

Extracting the script isn't the problem. When you open it, it's all messed up.

 

[Rykin]

Oh. My mistake. It seems that I had some of my HGSS files mixed in with the BW files.

There are 272 files in /0/0/2.

Looking at the files, I believe the problem with Poketext is that the pointers are now not encrypted, which they were before, so Poketext throws an error because of this. The only way I can test for sure is to load the poketext source into a compiler, but I no longer have one installed on my PC. Seeing as Kazowar has already made some progress on a patch, I'm going to step out of the scene and just watch this run.. I'm too busy playing Halo Reach and finishing school.

Peace out, ya'll. :>

No, the pointers are encrypted. For example, the second menu item is located at 0x190 in the 179 file. The only pointers that could possibly point to it are(I zeroed out the rest):
QUOTE00 24 01 00 Pointer 1
00 15 00 00

01 4E 01 00 Pointer 2
00 17 00 00

01 7C 01 00 Pointer 3
00 15 00 00

BTW: It's pointer 3.

As you can see, there's no 0x190 in there, so they must be encrypted.

EDIT: Also, 179 for the title menu only applies to Black from what I see. It must be different in White.

Yeah. I just looked at the hex some more (despite saying I wouldn't) they are encrypted. However, I still think the issue is that Poketext isn't expecting the extra header info that is added.

By the way, the format is this:
00 24 01 00 -- Pointer 1
00 15 00 00 -- Length of hex being pointed to.