Zaz

I padded the file size to 128 KB, opened the file in VBA & it loaded, saved the file two times to rewrite the save slots, and now it loads in A-Save (the editor of this thread.) You probably need to find out how to ensure your emulator loads and saves 128 KB save files if you wish to use it. gbavc.sav

Thanks. What game is the save from? And do you remember the trainer name?

Soundd like a save without the redundant copy. Could you upload the file so I can have a look?

I just don't like people that hoard information without sharing. Especially if it is information I want. ^^ srsly, keeping information in walled gardens just slows down progress for everybody.

Cool tool, is the source available anywhere? : D

And they haven't published how they do it? I'm calling them names, bad names, in my head as I'm typing this.

Example: lets use the pokemon provided in section 11 in this document http://www.ppnstudio.com/maker/PokemonMakerHelp.txt 9de847ff e1dd6e3b bdbbcdbd c9c9c8ff 80430202 c5d9e2ff ffffff00 a4f10000 7c3529c4 7c3529c4 7c3529c4 593429c4 013529c4 7c7329c4 7c0eace4 5875f8c9 7c3529c4 163529c4 7c3529c4 623529c4 Remember the endianness. Its little-endian, so when you do maths, the pid isn't 9de847ff. You have to reverse it one byte at a time. The pid is ff47e89d. Same with the next line, the original trainer id. (The SID and TID) is 3b6edde1. Xor these two to get the key: C429357C Now we take the subsection data: 7c3529c4 7c3529c4 7c3529c4 593429c4 013529c4 7c7329c4 7c0eace4 5875f8c9 7c3529c4 163529c4 7c3529c4 623529c4 Each line is one part. Remember it is little-endian, so each line has to be reversed before we do maths: c429357c c429357c c429357c c4293459 c4293501 c429737c e4ac0e7c c9f87558 c429357c c4293516 c429357c c4293562 Now xor each line separately with the key c429357c 00000000 00000000 00000000 00000125 0000007D 00004600 20853B00 0DD14024 00000000 0000006A 00000000 0000001E Until now the endianness actually didnt really matter since we did it both to the data and the key. But now we start adding, so now it gets confusing if you didnt do it at the start. Split each line in two. 0000 0000 0000 0000 0000 0000 0000 0125 0000 007D 0000 4600 2085 3B00 0DD1 4024 0000 0000 0000 006A 0000 0000 0000 001E And add them together and take the lowest 16 bits, the result in this case is F1A4 Remember that you have done the little-endian conversion, and you have to convert this number back before you write it to the file. 9de847ff e1dd6e3b bdbbcdbd c9c9c8ff 80430202 c5d9e2ff ffffff00 a4f10000 <-- Here it is 7c3529c4 7c3529c4 7c3529c4 593429c4 013529c4 7c7329c4 7c0eace4 5875f8c9 7c3529c4 163529c4 7c3529c4 623529c4

Is it a problem with endianness? I do the calculation on lines 453-470 here https://github.com/Zazcallabah/PokeSave/blob/master/PokeSave/MonsterEntry.cs Maybe no help if you cant read code, so basically this happens: * Group the entire array of data into 12 sections with 4 bytes in each section. (Not 4 sections with 12 each.) * The key you want to xor each section with is, as you say, the PID xor:ed with the original trainer id. * In every section, after xor:ing with the key, take the high 16 bits and the low 16 bits and add them together. (You now have a number that is the sum of 24 other numbers) * The low 16 bits of that number is what you want I can give you an example, if you want, I just need to look through my notes for a good sample

Do they modify an existing save or insert a new, as Purin mentions, 'pre-edited' one?

Hi, sorry for being very late to the party, but I've read through the thread and if you learn best by looking at source code, and want to code a Gen3 save editor in C#, you are very welcome to look at mine. https://github.com/Zazcallabah/PokeSave also, codemonkey85, I love your work but dude it is really backwards of you to consider C++ a superior choice in this instance.

Did the cloning work? : D

Thanks for the info, I really appreciate that you guys take the time to explain these things. : )

I have used those bulbapedia articles extensively to parse the save files, but the focus of the articles are where to find the data in the encrypted file, not how to combine the result into a pkm file. It is only through subtext that the sub section order is understood to be what it is. Anyway, I know no one asked, but I will say it anyway. :b I simply load the encrypted data into a buffer and lazy load the encryption/decryption work until it is actually needed. It made for a very sleek and intuitive solution that was really easy to extend to cover the entire save file. At least it seemed like a cleaner solution compared to most other tools i've checked out, but then I couldn't find any sources for most any tools? Don't you guys share code in any way? I know codemonkey is on github and evandixion has code on codeplex, which is great, but those is the only one i have found? The other tools I had to reflect into to figure out how they worked. ^^

Yeah, I know.. (still makes me a sad panda ^^ ) Do you know if the exact specs for a third gen pkm file are published somewhere? I guess its just XOR the stuff that should be xor'ed, and store the subsections in the order {species, moves, EVs, misc} since that is the order every example seems to give? Also, I just realized I lied about the type example thing. It is too found in the subsections, so that was a bad example. >_<

Evandixon, one thing I think you're skipping over without mentioning is my assertion that there isn't one single version of the 'decrypted' data. (But I will admit that it seems that everyone but me seem to use the same variant.) My argument is basically 'one encrypted version, many decrypted versions - hierarchically, the encrypted one is the only arbiter of truth'. Also, bin files - binary files - would be a fitting extension to both these kinds of files, since they both contain binary data. But that extension also carries no association with pokemon, so maybe .epkm or something would be better? ^^ Now the reason to store them encrypted I'd think be self evident. If i wish to copy one pokemon from one save file to another, I'd just copy the correct 80 bytes from one file, and write them to the other. No calculation, encrypting, decrypting, moving bytes around needed at all. Also it seems unneccesary to decrypt the entire file if maybe I'm just interested in some specific part of the file. Say I wish to just list which unique monster types are stored in a save. I don't actually need to calculate any sub sections for that, so 'decrypting' the data would be wasted effort And I admit that it is an extra step, but it is a step that every application that parses save files already has code for. theSLAYER, I like your argument, it seems almost philosofical in a 'stickin it to the man' kind of way. : ) You basically mean that the developers of the game have one version of the data, the 'truth' so to speak, and then add encryption and obfuscation to hide it from us. And we are smart enough to see through their deception and display the truth for all to see? Anyway, thanks for replying you guys, I really appreciate it. : )

I'm currently trying to figure out Gen 3 game saves, and it is going quite well, however when reading discussions on this forum I find one thing confusing. While discussing PKM files, the consensus seem to be that storing the data in decrypted form is much better than the alternative. I'd like to argue that the opposite is true. The main argument for the decrypted storage is, as far as I can tell, that parsing the files is faster. My counter to that is: Is that really relevant? My computer can parse around 50000 encrypted gen 3 files in a second, so unless gen 6 adds a considerable load, aren't we good performance-wise? The argument I wish to present _against_ decrypted storage is that the file format feels very unintuitive from an implementation standpoint. Basically, someone has to define exactly what 'decrypted' means. While the answer to questions like "Which is the correct subsection order?" or "Big endian or little endian?" may feel intuitive, someone that is not-official has to make that decision. While the encrypted format is pre-defined as valid when the game can parse the file, the decrypted files are valid when unofficial software considers them valid. This just seems strange to me. I would guess that the praxis grew out of the fact that one very popular piece of software started doing it and all others just conformed to that behavior. I figure every piece of software that handles pkm files already has parts that take the raw byte array (or stream) from the file save and creates some sort of internal storage representation to use internally. All software can also export the internal version back to the encrypted form. So why add another conversion to the _other_ external form? I haven't been coding save files for very long, so I expect that there are many things I don't know here, so feel free to educate me. : D And yes, I only made this topic because exporting encrypted storage files is much easier for me right now. Anyone curious about why can ask, but I guess most people wont be. ^^

Are you looking for "HM 01 (CUT)"? A special measure of time used by the game. One 1/60th of a second. I typed "ev iv" into google and found this site: http://www.smogon.com/ingame/misc/evs_ivs very tl;dr: IVs are random and unique for each pokemon, EVs can be changed using berries etc. Both affect pokemon stats.

Yeah, i know. I coded a hex editor that specifically takes care of that.

Hi, How did you figure out which parts of the save file does what? I know there is some articles on bulbapedia, but not everything can be found there. The Pokedex, for instance, is not detailed yet your editor can change it. Looking at a few different saves in a hex editor I figure it should be some where around offset 0x28 in the first section, but changing those values seem to have no effect? Anyway, thanks for making this tool.