ROM Hack Developing PHP-based open source PokéSAV script

[arctic_flame]

Either I'm missing the point, or you are.
I thought this would be web based, meaning you would upload your save file, make changes, and download it again.

+My bad, I meant the save files.

 

[Urza]

Either I'm missing the point, or you are.
I thought this would be web based, meaning you would upload your save file, make changes, and download it again.

+My bad, I meant the save files.

Well I suppose MarkusE would be the one to ask, but I'm pretty sure you just download the script, and no other transfer with the server takes place.

It would be web-based because the script runs your web browser.

 

[arctic_flame]

You'd need to run your own web server on your own machine, in that case, which most people won't know how to/be bothered to do. Or perhaps compile it with PHP-Gtk

 

[MarkusE]

The main reason I'm doing this is for the extra features listed in the first post.

They'd be easy to implement, too, once the encryption algorithm has been figured out.

That said, has anyone had any luck with decoding that?

 

[Nalin]

You could try here. Good luck with it, though. It is in Japanese and Babelfish explodes when translating the page on the save file format.

http://www18.atwiki.jp/pokeanalyze/pages/1.html

 

[MarkusE]

I've looked all over the @wiki already. Nothing.

 

[Raikou]

...

 

[coolbho3000]

bandwidth isnt free.

I don't think such a website will get THAT much traffic so bandwidth will be a problem. With 500 visitors a day, that all upload/download one 512kb save each, it'll use perhaps 200mb of bandwidth a day. 6GB of traffic per month isn't bad at all.

 

[Zaago]

I think I have something about the encryption, not much but maybe a clue.

You see that there is data in a slot even without a a pokemon in it?, I was wandering if that data is vinculated tied the encryption. And I notice that changing the Personality Value not affect the data encrypted only in some cases that this value change the byte $40 (not 100% sure about that).

I hope that this helps anyone, I'm traying to figure out it in my free time.

 

[mountarreat]

Depends on both attribute and checksum.

Attribute: 01 00 00 00 (little endian, $00-03)
Checksum: 03 1f (little endian, $06-07)

$08-87:
d3 c8 19 e2 c4 0d 27 c5 e5 d8 08 0d 73 f6 7a b5 f4 73 f4 2b b3 34 35 56 e1 41 bd fd 08 bd ca 05 bb 1f 9a e0 9f 71 f4 79 43 e6 4f 90 6b f6 0c 0b ac 14 9e 93 91 a3 9b 60 a0 63 fe 0c 05 3a 2f 53 6c 84 68 e2 96 3e 93 17 f5 91 d9 71 87 1e 95 06 08 ee bb 3f 65 7c 57 97 be ab 2f 62 bb 79 fc 5d 70 95 1c 8a d4 4a d9 23 da 93 d1 ef 82 32 d7 95 17 01 db 7f e0 57 a6 f6 2c 16 56 34 4c 9f 3d 29

Attribute: 0a 96 21 8b (little endian, $00-03)
Checksum: 03 1f (little endian, $06-07)

$08-87:
30 c8 fb e2 26 0d c5 c5 07 d8 ea 0d 91 f6 98 b5 16 73 16 2b 4c cb 35 56 e1 41 bd fd 08 bd ca 05 ba 1f 9a e0 9f 71 f4 79 43 e6 4f 90 6b f6 0c 0b ac 14 9e 93 91 a3 9b 60 a2 63 fe 0c 05 3a 2f 53 8e 84 8a e2 74 3e 71 17 17 91 3b 71 65 1e 77 06 ea ee 59 3f 9a 83 57 97 bc ab 2f 62 bb 79 fc 5d 70 95 1c 8a d4 4a d9 23 da 93 d1 ef 82 32 d7 95 17 01 db 7f e0 57 a6 f6 2c 16 56 34 4c 9f 3d 29

Notice the similarity.

So...anyone think he can crack this?

The only similarity that I notice is that attribute: 0A 96 21 8B XOR 01 00 00 00 MOD 03 1F / 2 = E2 is.

If you XOR following values with E2
0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0x16, 0x18, 0x1A (9-times, every 2nd byte)
0x48, 0x4A, 0x4C, 0x4E, 0x50, 0x52, 0x54, 0x56, 0x58, 0x5A (10-times, every 2nd byte)
you get the opposite files values (differences)

But there are exceptions, see complete list of changes:
0x08 = E3 (difference 01)
0x0A = E2
0x0C = E2
0x0E = E2
0x10 = E2
0x12 = E2
0x14 = E2
0x16 = E2
0x18 = E2
0x1A = E2
0x1C = FF (difference 1D)
0x1D = FF (difference 1D)
0x28 = 01 (difference 1F)
0x40 = 02 (difference 20)
0x48 = E2
0x4A = E2
0x4C = E2
0x4E = E2
0x50 = E2
0x52 = E2
0x54 = E2
0x56 = E2
0x58 = E2
0x5A = E2
0x5C = FF (difference 1D)
0x5D = FF (difference 1D)
0x60 = 02 (difference 20)

Maybe someone else can figure out something more... good night folks!

 

[Noitora]

That's awesome,will you release the source code?

 

[yeyezai]

http://bulbapedia.bulbagarden.net/wiki/Pok...cture_in_the_DS

 

[greatfire]

http://bulbapedia.bulbagarden.net/wiki/Pok...cture_in_the_DS

Actually that is a partial translation of this page. And both are outdated: It has been determined that the 85h value actually encodes the original method of the way the pokemon was obtained:
00 - Egg/Pal Parked/Event 02 - Tall Grass 04 - Dialga/Palkia Event 05 - Cave/Hall of Origin 07 - Water 0C - Given pokemon
And now a bit of history:
The original purpose of "pokesav" was to make a GUI that simplified the way of making changes in the sav except for the pokemon themselves because their encryption is too hard.
com made it by fusing the knowledge compiled at pokeanalyze and "pokesum", a tool that automatically obtains a new checksum if you make a change in the sav.
There were two other tools: "shiny", which modifies a pokemon to make it shiny, and "pokemaker" which actually compiles and encripts the pokemon data.
At some point (I don't remember) in the developement both "shiny" and "pokemaker" where added into "pokesav" but the questions are:
Who made "shiny" and "pokemaker"?
How did they broke the encryption?
Did they really broke it?
Did they passed the source code to com or simply allowed com to use both as addons?
Is that why com has refused any contact even from people who actually speaks japanese fluently enough?

The best way of obtaining the desired encryption algorithm seems to be reverse engineer "shiny" and "pokemaker" and/or track the way the pokemon data changes in the memory of an emulator (the gba encryption was broken that way)