Talk:Pokémon data substructures (Generation III): Difference between revisions

From Bulbapedia, the community-driven Pokémon encyclopedia.
Jump to navigationJump to search
(Nevermind I figured it out)
Line 24: Line 24:
Using little endian. This means for every word (two bytes), you reverse the order of the bytes. The encryption and decryption will work as long as you keep the order the same for the key and the data.
Using little endian. This means for every word (two bytes), you reverse the order of the bytes. The encryption and decryption will work as long as you keep the order the same for the key and the data.
[[User:Twigpi|Twigpi]] 14:01, 29 October 2007 (UTC)
[[User:Twigpi|Twigpi]] 14:01, 29 October 2007 (UTC)
== Decryption ==
I think this article needs to be more specific about the decryption. I wanted to verify some of the game mechanics so I learned all about the data structures and how to decrypt them. So far I've figured out most of it but am stuck at the part where you add all the decrypted values up. Are you suppose to add up each individual value, each long value, or what? Also, is the checksum suppose to match the sum of these values? (After modding by 0x10000) If so, I've tried tons of different combinations and no luck. I know I decrypted everything right because all the other calculations work out, but not this one. Any help?
--[[User:EV Love|EV Love]] 16:41, 11 July 2008 (UTC)

Revision as of 01:22, 13 July 2008

The "Order" section must be wrong. When I calculed Personality 3935877326(in decimal) by 24(decimal too) I got "14" - which correspond to order EAGM - but something was wrong. After 4 hours intense counting and trying I realized the ordering was wrong. The correct ordering was GEAM . Game version: Ruby (US version) Pokemon: First in party Myself: ICQ: 343370964 . btw: Now I am stuck at recalculating data checksum. If somebody know... please...

I have solved your problem. 3935877326 turns to 0xEA98B8CE in hexadecimal. You have to use little endian, to which the rule applies, least significant byte first. In other words, the very last byte will end up being first. Rearranged as follows
0x1234ABCD -> little endian -> CDAB3412. So your number should be 0xCEB898EA, or 3468204266 in decimal. 3468204266 MOD 24 = 2, which is GEAM. Nice? Twigpi 20:51, 29 October 2007 (UTC)
Also, the checksum loops. Adding the unencrypted values should give you a value greater then 0xFFFF (max size), so it just loops. To find the correct value, MOD by 65536 (decimal) or 0x10000. Twigpi 20:51, 29 October 2007 (UTC)

Substruct encryption

If you play in an emulator like No$GBA or VBA, you can open a RAM viewer. Sometimes, if you look at a Pokémon data structure, you can see the encrypted substructs change values in a flash. This is because the game decrypts the whole thing for use and encrypts them again immediately afterwards. I always did wonder how it was supposed to use the data if it's encrypted... --Kyoufu Kawa 16:52, 31 July 2007 (UTC)

DVs

Investigation of Fire Red assembly code reveals that the DVs field is not exactly as described. More to follow. --Kyoufu Kawa 20:06, 10 August 2007 (UTC)

As stated in my previous edit, the last two DV bits are actually used. One of them is the egg flag, as opposed to the ribbons, which was an endian error on my part.

Little Endian

Using little endian. This means for every word (two bytes), you reverse the order of the bytes. The encryption and decryption will work as long as you keep the order the same for the key and the data. Twigpi 14:01, 29 October 2007 (UTC)