Tux Posted October 30, 2015 Posted October 30, 2015 I've been doing some research about PBR since yesterday, and found some really interesting stuff. The save file, which is location is "nand:/title/00010000/52504250/data/GeniusPbr/PbrSaveData" is made of two contiguous "save slots" ("current" and "backup"), each one being 0x1c0000 bytes of size. It turns out that they are encrypted the same way save slots are. The encryption/decryption/checksum calculation routines can be here. Without further ado, here is what I know about the various structures. Save slots (0x1c0000 bytes): /* struct SaveSlot (size = 0x1c0000) */ 0x00: u16 encryptionKeys[4] ****************ENCRYPTED DATA**************** (refer to decryptSaveSlotAndCheckChecksums for more details) ** Start of game config data ** /* Checksum from 0x00 to 0x100. Refer to decryptSaveSlotAndCheckChecksums for more details. */ 0x08: u32 configChecksum[16] ... unknown data ... 0x1c: u8 isBackup (computed at runtime from saveCount) ... unknown data ... 0x4c: u32 saveCount ... unknown data ... ** End of game config data ** 0x100 to 0x37f: unknown 0x380: SaveSubSlots subSlots[4] (each one is 0x6ff00 of size and is associated to a particular NDS save file (probably by the TID/SID)) 0x1bff80 (= end - 0x80): u32 checksum[16] (of the whole structure (i.e. 0 to 0x1c0000)) (refer to decryptSaveSlotAndCheckChecksums for more details) 0x1bffc0 -- end: probably padding Pokémon: 140 bytes. I don't know anything else about these. Trainer cards: 0x738 bytes. When sent to/received from Wiimotes, 8 bytes of encryption keys and 64 bytes of checksum (same algorithms as before) are prepended. You can actually trigger a buffer overflow vulnerability (by playing with the trainer's name), but that's not really something exploitable.
Mr. ZARDE Posted April 23, 2016 Posted April 23, 2016 Great Research! Now i'll ask a question: What's taking you so long for making a Battle Revolution Save Editor? Just asked because i can't stop waiting and nothing was announced about a Battle Revolution Save Editor, since the only way to have a Pokémon Battle Revolution Save with my Pokémon is restore digital save=>cart/syncing DS Save with Real Wii with Battle Revolution/backup Battle Revolution save/Renaming Save On Dolphin Save Folder, which is utterly Annoying but i have no other choice. Any Plans for a Battle Revolution Save Editor Or Am I Asking Too Much? Good night!
codemonkey85 Posted April 23, 2016 Posted April 23, 2016 Now i'll ask a question: What's taking you so long for making a Battle Revolution Save Editor? If it's so easy, make one yourself.
Mr. ZARDE Posted April 23, 2016 Posted April 23, 2016 (edited) Grrrr! I'll Remember This! Ok, i was rough, my bad. I Solved My Own Problem. Thanks... Enviado de meu SM-J200BT usando Tapatalk Edited April 25, 2016 by Maddaren
WhatHappenedToStairs Posted August 23, 2016 Posted August 23, 2016 (edited) I am new to encryption and what-you-have, but I have a question. Is there anything that could be done to help with this? I would like to see a PBR Pokemon/save editor someday. I've tried messing around in Dolphin's (5.0-419) debug mode to see how the game stores moves; alas all I got was memory addresses it seems to use for storing moves during a battle--and not the storage Pokemon--editing which does nothing - probably due to the way PBR handles it. Is checking memory even worthwhile? Slot 1's (top-left) first move (top-left) is: 0x00463B700x00463DFC0x00467204 For reference, here's slot #2 (top-right) moves 0x00463BDc (top-left)0x00463Be0 (top right)0x00463Be4 (bottom-left)0x00463Be8 (bottom right) And slot 3 (middle-left) 0x00463c480x00464ce4 This was a 3v3 fight. Yes, everything but slot #2 has more than one place with what seems to be move data. Shifting Pokemon changes slots. The moves seem to be written as 0XXXYY03; where XXX is move's index number and YY is amout of remaining PP. YY is changed at the end of turn. Move's values are the same as in core series, so eg. Petal Dance would be 050 as this equals to 80 in hexadecimal. Edited August 23, 2016 by WhatHappenedToStairs
StarsMmd Posted August 25, 2016 Posted August 25, 2016 Tux doesn't appear on the forums very often and I'm not even sure if he's still working on this or even planning on making a program at all. Looking at the RAM probably won't help since the save data will most likely be in a slightly different format. However, the first post has code for decrypting the save file. You could start by creating some save files with known data, decrypt them and see if you can figure out the data formats like how the pokemon are stored. Tux mentioned where to find them but didn't go as far as figuring out which bytes correspond to which values. If you could figure that out then making a program to edit them would be a trivial process.
WhatHappenedToStairs Posted August 25, 2016 Posted August 25, 2016 Wish I could do that, but as I said: I am new to this kind of research. What kind of program would be good?
codemonkey85 Posted August 26, 2016 Posted August 26, 2016 If you're on Windows, I recommend using HxD to look at the file. Then you'll want to seek out known values, like the Pokémon's PID or moves, etc.
WhatHappenedToStairs Posted August 26, 2016 Posted August 26, 2016 (edited) I have indeed tried using HxD (and currently I am even trying to dig through a save I've downloaded that has all 493 Pokémon because I am too lazy to get a living Dex myself; I've written down one of the Pokemon's number, its moves' numbers and the item's numbers to make things easier). The other person has mentioned decryption code. Is it something I should worry about using in HxD, or is it more or less the order in which PBR stores data? (Being newbie sucks. ) The biggest part will probably be finding out the order in which Pokémon data is stored - like if moves are all in row (probably?), whether they come before an item, what begins the whole block of Pokémon data--is it the Pokémon's index number or something else? And on HxD side: if I am searching for Sandlash, should I try searching for 01C or 1C? After all, this is Generation IV, so moves, items and Pokémon values are obviously stored as (at least) 2 bytes, considering there's more than 256 of each. Dolphin's RAM would suggest that at least moves have the same values as in core series. This is what I am assuming for not only moves, but Pokémon and items during my search. This is the only sane way of proceeding here. Edited August 27, 2016 by WhatHappenedToStairs
SciresM Posted August 30, 2016 Posted August 30, 2016 I am new to encryption and what-you-have, but I have a question.Is there anything that could be done to help with this? I would like to see a PBR Pokemon/save editor someday. Someone just has to make an editor, really. As I commented on reddit, Pokemon are just 140-byte unshuffled, Big Endian PK4s. Also their checksums are different, but you could surely reverse that with dolphin if you were so dedicated.
StarsMmd Posted August 30, 2016 Posted August 30, 2016 I have indeed tried using HxD (and currently I am even trying to dig through a save I've downloaded that has all 493 Pokémon because I am too lazy to get a living Dex myself; I've written down one of the Pokemon's number, its moves' numbers and the item's numbers to make things easier). The other person has mentioned decryption code. Is it something I should worry about using in HxD, or is it more or less the order in which PBR stores data? (Being newbie sucks. )The biggest part will probably be finding out the order in which Pokémon data is stored - like if moves are all in row (probably?), whether they come before an item, what begins the whole block of Pokémon data--is it the Pokémon's index number or something else? And on HxD side: if I am searching for Sandlash, should I try searching for 01C or 1C? After all, this is Generation IV, so moves, items and Pokémon values are obviously stored as (at least) 2 bytes, considering there's more than 256 of each. Dolphin's RAM would suggest that at least moves have the same values as in core series. This is what I am assuming for not only moves, but Pokémon and items during my search. This is the only sane way of proceeding here. I'd presume that you have to run the save file through the decryption code to get it in a readable format. Otherwise it will just look like a bunch of random values with no real meaning. You have the right idea though. You'd want to look at the decrypted save data and figure out where everything is. E.G. First pokemon is at offset 0x100. First 2 bytes is the species, next byte is the level, next byte is it's nature, etc. With that information it's easy to write programs to modify that data.
WhatHappenedToStairs Posted August 31, 2016 Posted August 31, 2016 I'd presume that you have to run the save file through the decryption code to get it in a readable format. Otherwise it will just look like a bunch of random values with no real meaning. This is the part I am having problems with, as I have no idea how to use it; and I fear doing it the wrong way just to mess it up even more (this is why I am asking here and eg. not just Googling it).
StarsMmd Posted August 31, 2016 Posted August 31, 2016 This is the part I am having problems with, as I have no idea how to use it; and I fear doing it the wrong way just to mess it up even more (this is why I am asking here and eg. not just Googling it). So the original post has a link to the source code. You need to download that code, compile the code and then run the program with the save file in the same folder and the save file should be named "PbrSaveData" unless you change the source code. If that doesn't make sense to you then you can send me the file and I'll try running it and sending the decrypted file back your way if it all works out.
WhatHappenedToStairs Posted September 2, 2016 Posted September 2, 2016 (edited) So I've got savefile I was researching decrypted by StarsMmd, and here's what I've got already. [b][size=4]000391-39B[/size][/b] - First savefile slot's name.[b][size=4]0003B1-3BC[/size][/b] - Whatever was set as birth date in MM/DD format. The middle bytes (3B5-3B8) are empty, for some reason.[b][size=4]0003C9-3E2[/size][/b] - Ditto, but for self-introduction Interestingly enough, HxD reads all of this fine (ie. it doesn't display as random characters). Now, here are values for Pokemon. First comes... Bulbasaur! Box 1, row 1, column 1. [b][size=4]000980-981[/size][/b] - Pokémon's index number.[size=4][b]000982-983[/size][/b] - Held item's index number.[size=4][b]000986-987[/size][/b] - OT's number.[size=4][b]0009A0-9AD[/size][/b] - OT's name, in whatever hexadecimal replacement system game uses (HxD displays random characters); in this case it's 6 letters long. I don't remember what was the limit on player's name in Generation IV.[size=4][b]0009C0-9C7[/size][/b] - Moveset.[size=4][b]0009C8-9CB[/size][/b] - Moves' PP.[size=4][b]0009E0-9F3[/size][/b] - Nickname, the same system as OT's name. Note that BULBASAUR is 9 letters, so terminator byte appears early. There's a whooping 12 of 00 bytes after the FFFF bytes which end the nickname. I am not sure what they all do, since nickname at best is going to be 2 bytes longer... Now here's where it gets a bit problematic. (The red 20s are my custom edits/markings to remind me where are the Pokemon's numbers) This is Charizard's moveset. Fire Blast, Air Slash, Dragon Pulse and Blast Burn... With the PP. The problem's that the ID for species and item is stored much later. Like, very close to next Pokemon's Squirtle. (Yes they all apparently hold Focus Sash/0113; except for Blastoise with Leftovers/00EA). Similar thing happens with Charmander (007E 0035 0053 00F6) but not Charmeleon (01A8 0151 01A5 009D). This quirk seems to repeat for Ivysaur (014B 004B 0016 0026)--but not Bulbasaur or Venusaur (004C 00BC 0159 00CA and 004C 00BC 019C 0152)-- and Blastoise (0038 003A 01AE 0134)--but not Squirtle or Wartortle (0038 003A 014A 0039 and 0191 0082 0118 002C). This seems to cause the distance between two bytes deciding what species is in the specified place to vary (while Tux's information says all Pokemon are 140 bytes long). Also, I haven't checked too many Pokémon in detail, but it seems that PBR recognizes Deoxys' Forme (and probably other Pokémon with more than one form) by something else than index number (if I've been reading the data correctly, all of them are using 0182, which is 386 in hexadecimal and therefore regular Forme's index number). For some of the things, I might need to learn how to decrypt and encrypt savefile, so I can change things and see what I've just did ( ), since I don't think I'll be able to find certain things otherwise (eg. Poké Ball type or Trainer Memo data, if it stores these at all). Do we have any kind of online chat for this kind of thing? Or should I just post here, hoping that someone helps me with this? (Cause as you can see in the spoiler part above, there are some curveballs that I can't explain.) Edited September 2, 2016 by WhatHappenedToStairs
StarsMmd Posted September 2, 2016 Posted September 2, 2016 So I've got savefile I was researching decrypted by StarsMmd, and here's what I've got already. [b][size=4]000391-39B[/size][/b] - First savefile slot's name.[b][size=4]0003B1-3BC[/size][/b] - Whatever was set as birth date in MM/DD format. The middle bytes (3B5-3B8) are empty, for some reason.[b][size=4]0003C9-3E2[/size][/b] - Ditto, but for self-introduction Interestingly enough, HxD reads all of this fine (ie. it doesn't display as random characters). Now, here are values for Pokemon. First comes... Bulbasaur! Box 1, row 1, column 1. [b][size=4]000980-981[/size][/b] - Pokémon's index number.[size=4][b]000982-983[/size][/b] - Held item's index number.[size=4][b]000986-987[/size][/b] - OT's number.[size=4][b]0009A0-9AD[/size][/b] - OT's name, in whatever hexadecimal replacement system game uses (HxD displays random characters); in this case it's 6 letters long. I don't remember what was the limit on player's name in Generation IV.[size=4][b]0009C0-9C7[/size][/b] - Moveset.[size=4][b]0009C8-9CB[/size][/b] - Moves' PP.[size=4][b]0009E0-9F3[/size][/b] - Nickname, the same system as OT's name. Note that BULBASAUR is 9 letters, so terminator byte appears early. There's a whooping 12 of 00 bytes after the FFFF bytes which end the nickname. I am not sure what they all do, since nickname at best is going to be 2 bytes longer... Now here's where it gets a bit problematic. (The red 20s are my custom edits/markings to remind me where are the Pokemon's numbers) This is Charizard's moveset. Fire Blast, Air Slash, Dragon Pulse and Blast Burn... With the PP. The problem's that the ID for species and item is stored much later. Like, very close to next Pokemon's Squirtle. (Yes they all apparently hold Focus Sash/0113; except for Blastoise with Leftovers/00EA). Similar thing happens with Charmander (007E 0035 0053 00F6) but not Charmeleon (01A8 0151 01A5 009D). This quirk seems to repeat for Ivysaur (014B 004B 0016 0026)--but not Bulbasaur or Venusaur (004C 00BC 0159 00CA and 004C 00BC 019C 0152)-- and Blastoise (0038 003A 01AE 0134)--but not Squirtle or Wartortle (0038 003A 014A 0039 and 0191 0082 0118 002C). This seems to cause the distance between two bytes deciding what species is in the specified place to vary (while Tux's information says all Pokemon are 140 bytes long). Also, I haven't checked too many Pokémon in detail, but it seems that PBR recognizes Deoxys' Forme (and probably other Pokémon with more than one form) by something else than index number (if I've been reading the data correctly, all of them are using 0182, which is 386 in hexadecimal and therefore regular Forme's index number). For some of the things, I might need to learn how to decrypt and encrypt savefile, so I can change things and see what I've just did ( ), since I don't think I'll be able to find certain things otherwise (eg. Poké Ball type or Trainer Memo data, if it stores these at all). Do we have any kind of online chat for this kind of thing? Or should I just post here, hoping that someone helps me with this? (Cause as you can see in the spoiler part above, there are some curveballs that I can't explain.) It's good to see you've made some progress! I don't know if you're doing this already but I have some advice from trying to reverse engineer pokemon data. What I'd do in your situation is to copy the save data, delete the first 0x980 bytes ( I think that's what you said was the start of the pokemon data) and then change the bytes per row in HxD to 140. By doing this, each row in HxD will represent one pokemon's data. That will make it a lot easier to compare and contrast between them. It would also make it check if the 2 bytes issue is happening and how often it happens. Also, I'd still recommend posting on the forums because it's a good way to archive the information for anyone who may stumble across it in the future. It also means other people can jump in and help. I got a lot of great help from so many people with so many different skillsets.
SciresM Posted September 2, 2016 Posted September 2, 2016 ...did nobody read my post that said they're Big Endian PK4s? That's a well-documented format....there's no need to research how they're stored, I already said that.
WhatHappenedToStairs Posted September 3, 2016 Posted September 3, 2016 ...did nobody read my post that said they're Big Endian PK4s?That's a well-documented format....there's no need to research how they're stored, I already said that. how do I read. ...You mean something like this, right? Cause I've totally forgotten this even exists. Okay, it says Pokemon are 136 bytes in these games, while Tux has said they are 140 bytes in PBR. I've noticed that there are two empty (00) bytes between held item (00EA) and OT (8522) in PBR. There's also something between OT and secret OT (circled in green); haven't checked enough to guess what it is.
aaaaaa123456789 Posted September 5, 2016 Posted September 5, 2016 I found this thread a long time ago and used the info in the OP to make a save editor library; I didn't think anyone would want me to bump this thread with that back then, so I didn't bother making an account just to post this. I guess I should have. Anyway, this is what I made: https://github.com/TwitchPlaysPokemon/pokerevo/tree/master/utils/libeps Allows editing Pokémon data from a savefile, and a few other basic operations such as copying one saveslot onto another, etc. Also allows raw access to the (unencrypted) saveslot and savefile data in case someone manages to find useful pointers. I also took the liberty of making the encryption and checksumming code a lot shorter and less repetitive; it might not look like it at first glance, but it's completely equivalent to the code that was posted here. Keep in mind that this is a library, not a full program; someone would have to write a full program to make use of it in order to make it usable for non-coders. The library is written in C, but it also has bindings for C# and Python; any of those languages can be used to interface to it. Documentation is available in the docs.md file. If anyone wants to use it, go ahead. I know there's no license file there (because the repo has other stuff too), but as far as the library itself goes, feel free to use it for whatever you like. I'll try to stick around to answer any questions if anyone wants to ask something. I hope this helps someone out there. Thanks to Tux for the info in the OP; it was extremely helpful.
Blob55 Posted September 7, 2016 Posted September 7, 2016 Does this mean we can change the rental Pokémon to something that doesn't suck?
StarsMmd Posted September 7, 2016 Posted September 7, 2016 Does this mean we can change the rental Pokémon to something that doesn't suck? I haven't played much battle revolution myself but I doubt the rental pokemon are affected by save data. I took a look at the game files a few months ago and I made a start on researching the actual game data which probably includes rental pokemon somewhere. It's all straightforward enough to edit but it's just been a low priority for me since I'm focusing on :GoD hacking for now.
Blob55 Posted September 9, 2016 Posted September 9, 2016 I haven't played much battle revolution myself but I doubt the rental pokemon are affected by save data. I took a look at the game files a few months ago and I made a start on researching the actual game data which probably includes rental pokemon somewhere. It's all straightforward enough to edit but it's just been a low priority for me since I'm focusing on :GoD hacking for now. That makes sense, it's just that I've been meaning to play PBR, but the rentals suck and I want to find a way to replace them.
chocolatehail Posted September 9, 2016 Posted September 9, 2016 I am trying to retrieve/recreate some old pokémon from PBR since I lost the DS game that they were saved on. The only thing I don't know are the IVs and EVs of the pokémon I want to recreate in Pokésav. Would there be a way for me to find the EVs and more importantly IVs of pokémon from a PBR save file?
aaaaaa123456789 Posted September 19, 2016 Posted September 19, 2016 I am trying to retrieve/recreate some old pokémon from PBR since I lost the DS game that they were saved on. The only thing I don't know are the IVs and EVs of the pokémon I want to recreate in Pokésav. Would there be a way for me to find the EVs and more importantly IVs of pokémon from a PBR save file? Absolutely. Upload the save file somewhere and I'll gladly give you a full dump.
chocolatehail Posted September 24, 2016 Posted September 24, 2016 Absolutely. Upload the save file somewhere and I'll gladly give you a full dump. Thanks a ton! here is a link, http://www.mediafire.com/download/991sidnsiaez7oz/PbrSaveData
aaaaaa123456789 Posted September 26, 2016 Posted September 26, 2016 Thanks a ton! here is a link,http://www.mediafire.com/download/991sidnsiaez7oz/PbrSaveData Here's your data: http://pastebin.com/tURxezwf Moves, abilities, species numbers and items are all there by number because this was a quick and dirty program; you can find the index number for everything in Bulbapedia. (Index numbers for natures are never listed, but they go in the same order as they appear in the Natures page; first one is 0 and last one is 24.) Special, non-ASCII characters in nicknames show up as ^ in the dump. EDIT: by the way, whenever you see (+3) next to a move number, it means that move had 3 PP Ups. (Same for (+1) or (+2), obviously.) If you happen to see (=xx), where xx is some number, it's because that move had fewer remaining PP than the total available; I don't think this is possible in PBR without hacking, though. If anyone for some reason wants the program I used, here it is: http://pastebin.com/pkYy2eQb
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now