Reisyukaku

seems buggy (or maybe its just my browser acting dumb), but here it is http://reisyukaku.org/tools/boxsim/ let me know if i should change the name of the root folder to something more creative then 'boxsim' or something

I could probably host it if you want.. what language? html/php would be preferable, but I can do java applets and CGI scripts too.

well you could always email them asking for a japanese key if you only need the japanese cart to work. But yea, i think the only reason they do that is to distinguish which region you are so they can route the traffic to the appropriate 3DS farm, heh.. Me and like 1 or 2 other people where writing our own programs to rip saves, but i hit a road block on mine, and i havent heard anything on theres, so maybe we all failed.. but that of course wont help if all you want is the cheats, so yea.. Also a note on the cyber editor, im almost positive it doesnt work on CARD2 (NAND saved carts). So it wont work on pokemon X or Y

It doesnt work with my Japanese cart. I think you need a Japanese key for it, and I've already sent emails back and forth with Datel about it since i have an american cart too.. they cant give me multi region keys, and they wont give me 2 keys.. it's either or.

No problem. Also as far as that idea goes, I'll start by saying the reason you're able to share saves is because the ROM is the same for everyone, so that means the unique key is the same, so the KeyY is the same, so the encryption (xorpad) is the same.. you still have to recalculate hashes and such if you're trying to inject. So it all still boils down to needing the AES MAC calculated still. Also as far as creating your payload to sign saves, yea, its easier said then done, lol.. I talked to slashmolder about it before. (Him and Bond are the ones that decrypted GW's payload, so I trust his opinion, heh)

Only if you know how to write your own payload using the same exploit that GW uses. The real difference between a standard cart, and a rom on GW is that GW bypasses a part when calculating the KeyY which is used to calculate the xorpad.. so essentially, its not any easier to decrypt than a normal cart is.. assuming you use the methods we do. All I can really say on this is that PKHex only reads FULLY decrypted files... doesnt matter what it is.. all saves look the same when decrypted whether it be phyical cart, digital or GW.. I'm still not sure how you've 'fused' a save or whatever because every bit matters when calculating the checksums and hashes to fix the file.[...] again, a 'modded' 3DS is any 3DS you can exploit to run a custom payload to do whatever it is you want.. if you know how to somehow call the SHA256_Update() fuction in the AES engine, and sign your save, you'll be a hero.

cart is probably dirty

what are you even talking about? It works perfectly fine. If at any time the codes go down, its usually for maintenance.

I've seen this done before, but nonetheless, its still pretty cool from a programmer's point of view.

Hmm.. thats weird then.. Assuming you're doing the process correctly, then that's just bizarre, lol.

It's just the first 2.. the pokemon data is saved in the order that you see the boxes.. the boxes themselves arent distinct entities. its just a way of moving data around. Also names shouldnt matter since thats saved in a different location.

Hmm.. if you look at the file in a hex editor and do a ctrl+A .. see how many bytes it is.. if 0x100000 then it should be fine as a .sav, if not, get rid of the first few bytes till it equals that. Other than that, idk.. i'd have to try it myself.

Essentially, yea.. that's probably how Datel does it, but thats not something thats all that easy to do.

Then why are you here then? Seriously though, this program does everything pikaedit does and more.

I'm gonna assume the R4i doesnt add a header to its file, so the only difference between it and powersave is that powersave adds a 0x9C long header to its saves, and it also saves them as .bin files. I'm also gonna assume that this program takes into account that header when parsing, so if the file is .bin, the program thinks its powersaves file, so it will take that into account, but a digital save has no header, and has .sav extension, so if the program sees .sav, it knows there is no header and parses accordingly. So the solution would either be to rename your file to a .sav file, or add 0x9C bytes at the begining of the file.

sounds like you goof'd try again with the proper ROM :u or use a hex editor and leet hax

I hope you're not too disappointed when you realize its harder than it looks. :^)

wut? just get an emulator for the phone.

People having been doing this since day 1 though `-` Not to mention replace the 2nd person with pokebank and thats how everyone else does it.

It'd kinda hard to figure out your problem with just that.. clearly there was an error in the process. After you make the blank file with the correct xorpad, you xor it with any of your recent save files and then the output is partially decrypted (0x5400 - 0x6AFFF to be exact).. so just delete the powersaves header from that output file (first 0x9C bytes). You can add in the DISA/DIFI headers and all that crap if you want, but not necessary to load the file.

Basically it's a matter of calculating the AES MAC given the DISA header (0x100 bytes) and some other specific data.. The stuff that goes on in the AES engine to achieve this calculation is unknown due to the fact that it uses hardware to do that stuff, so we cant use software exploits to peak at it.. so either someone decaps a studies the chip, or we use a hacked 3DS to sign things. That's to my understanding anyways.

Then take the time to.. lol any change at all to the save, even by 1 bit throws off at least 1 checksum, 4 IVFC hashes, DIFI/DISA hash, and the AES MAC.. we can fix everything up to the MAC.. we just cant do the MAC because the 3DS hardware wont tell us it's secrets.

I believe it's to apply the correct xorpad. I'm not entirely sure why the xorpad isnt correct after having the game initialize the data.

What? IVs, EVs and all that stuff is in pkhex itself if used as pokegen.. what would you need the other functions for if they arent your own mons?.. either way, just create a file of length 0x100000 filled with 00s, save as .bin file and open in pkhex.. voila~!

if you're using the 'dirty decryption' method as some call it (where you take a blank save and boot the game to the langauge menu and close, etc) then after you get the save partition decrypted, I just paste in the DISA/DIFI headers and recalculate everything till it checks out and then xor with the original save in hopes of getting a more or less accurate xorpad.