Jump to content

SciresM

Member
  • Content Count

    85
  • Joined

  • Last visited

Recent Profile Visitors

1,094 profile views
  1. Hi there. A few weeks back, I documented the growth rate cipher for Fire Emblem Awakening. Apparently, FE12's growth rate cipher was also undocumented. Let's fix that :) As an example, I will be using Marth's growth rates. Note: Much of this is copy/pasted from my awakening growth document, but this was documented by loading FE12 in No$GBA's debugger. Also note: decrypt_class_growth(classdata_ptr, enciphered_growth_rate, growth_rate_index) is at 0x2049418 when FE12 is in RAM. decrypt_unit_growth(unitdata_ptr, enciphered_growth_rate, growth_rate_index) is at 0x2049280 when FE12 is in RAM. Unit Growth Rates Growth rate data is stored, enciphered, as a sequence of 8 bytes, in the usual stat ordering (HP, Str, Mag, Skl, Spd, Lck, Def, Res). Marth's growth rates for example, are the highly inscrutable `D1 E3 6C E1 F6 2E 15 49 98`. The conversion process is both simple, and fairly complex. To lookup the growth rate for the stat at index N (zero-indexing), we perform the calculation INDEX = (ENCIPHERED[N]- (0x57 * ((CHARACTER_ID ^ 0x3E) - 3 * N) ^ 0xF5)) & 0xFF; GROWTH_RATE = LOOKUP_TABLE[INDEX]; Where LOOKUP_TABLE is the following lookup table, found at 0xF408 in FE12Data.bin: 3C 7F 83 81 80 78 6A 08 BC D8 75 89 2C 41 BD C6 4A C7 AE A0 19 72 28 03 40 99 43 42 07 A5 74 B4 DB D0 50 18 A4 F9 91 88 CB 5F 55 DD 82 3A 93 0A D4 26 1A D1 29 85 AB EF 5A 12 B0 EA 7C 6B 4F 9D 06 27 E2 64 4C E4 BB EE 6F 8B 2F 30 51 61 65 A7 77 FA 5D E1 CE FD 5C F8 8F 8C C3 A1 CA DE CF F5 B2 69 D5 B5 23 C8 0B 31 3F 60 20 C2 3B AF 1C 05 92 6D 8E 71 36 96 22 2B 1B 3D FF 73 59 BE 35 BA B1 45 15 CC 4B 1D 7A 9C 0E 84 49 67 AD F0 0F 2E 5E 16 7B F7 52 BF EB 9B C5 E3 DC 02 8D 04 F6 21 C0 38 3E 4D 11 E9 1F FB A6 AC 94 62 2A D9 A8 C4 F3 00 C1 CD D3 9F A3 9E EC D7 FC E8 0D 47 48 90 E5 58 DA A9 56 FE D6 34 6E AA 0C 8A 95 17 01 68 09 B7 E7 37 25 79 E6 63 98 B9 33 B6 87 86 24 A2 70 76 5B F2 44 13 E0 46 53 B8 32 2D 10 1E C9 7D 14 F1 9A D2 57 4E F4 ED 97 B3 DF 39 54 66 6C 7E Okay, there's basically no chance that was clear. So let's do the calculations, to make it a bit clearer. Suppose we want the HP growth rate. That's stat 0. Enciphered[0] is 0xD1, and Marth's character ID is 0, so we calculate INDEX = (0xD1 - (0x57 * ((0 ^ 0x3E) - 3 * 0) ^ 0xF5)) & 0xFF = 0xEA. The value in the lookup table at index 0xEA is 0x32, or 50 -- Marth's base HP growth rate. Suppose we want the Lck growth rate. That's stat 5. Enciphered[5] is 0x2E, and Marth's character ID is 0, so we calculate INDEX = (0x2E - (0x57 * ((0 ^ 0x3E) - 3 * 5) ^ 0xF5)) & 0xFF = 0x22. The value in the lookup table at index 0x22 is 0x50, or 80 -- Marth's base Lck growth rate. Class Growth Rates As with unit growth rate data, class growth rate data is stored, again enciphered as a sequence of 8 bytes in the usual ordering. Marth's base class is Lord, which has enciphered growth rate `32 C7 C4 B3 D8 46 21 06`. The conversion process for class growth rates proceeds much like the unit growth rate -- the formula is just different. We perform the calculation: INDEX = (ENCIPHERED[N]- (0xB3 * ((CLASS_ID ^ 0x9D) - 7 * N) ^ 0xDB)) & 0xFF; GROWTH_RATE = LOOKUP_TABLE[INDEX]; Where LOOKUP_TABLE is the same as it was for unit growth rates. Again, walking through the calculations for Lord: Suppose we want the HP growth rate. That's stat 0. Enciphered[0] is 0x32, and Lord's class ID is 0, so we calculate INDEX = (0x32 - (0xB3 * ((0 ^ 0x9D) - 7 * 0) ^ 0xDB)) & 0xFF = 0x16. The value in the lookup table at index 0x16 is 0x28, or 40 -- Lord's base HP growth rate. Suppose we want the Lck growth rate. That's stat 5. Enciphered[5] is 0x46, and Lord's class ID is 0, so we calculate INDEX = (0x46 - (0xB3 * ((0 ^ 0x9D) - 7 * 5) ^ 0xDB)) & 0xFF = 0xB1. The value in the lookup table at index 0xB1 is 0x00, or 0 -- Lord's base Lck growth rate. Hope this is clear, feel free to ask any clarifying questions, and have fun playing around with growth rates!
  2. Hi there. As you may, or may not know, growth rates in Fire Emblem: Awakening are stored enciphered, so as to prevent easy datamining of growth rates. As far as I can tell, the deciphering process has never been documented before. Let's fix that, shall we? :) As an example, I will be using Lissa's growth rates. Unit Growth Rates Growth rate data is stored, enciphered, as a sequence of 8 bytes, in the usual stat ordering (HP, Str, Mag, Skl, Spd, Lck, Def, Res). Lissa's growth rates for example, are the highly inscrutable `20 BC AA D5 74 39 E8 BD`. The conversion process is both simple, and fairly complex. To lookup the growth rate for the stat at index N (zero-indexing), we perform the calculation INDEX = (ENCIPHERED[N]- (0x63 * ((CHARACTER_ID ^ 0xA7) - 0x21 * N) ^ 0xD9)) & 0xFF; GROWTH_RATE = LOOKUP_TABLE[INDEX]; Where LOOKUP_TABLE is the following lookup table, found at 0x4001C in GameData.bin: 59 89 D2 D1 DE C6 47 21 BA DB C5 EC 35 BD 9F 9B 2D 7B B2 09 F7 53 99 8F C4 90 FA 34 F8 19 94 02 ED 56 40 6C F4 88 4F 2B B4 BB EB 74 B7 0D C2 A4 EE 93 CF 42 F1 17 BF F0 A5 BC 0F 6E 1B 73 8D A6 3B 50 33 E0 AF 9D DD FF FE AA CE 12 62 E2 FB C1 23 49 D6 CD 04 2F 41 15 1A 32 03 8A 14 58 0A A3 D0 71 7D D3 A0 52 BE D7 8B 48 37 13 A8 44 08 3C E3 63 F6 DF 16 7C 46 F3 07 CC 79 C3 6B 3F 81 00 20 28 AE EF 6D 8E 0E 1D 4B 95 A1 B6 D4 C7 3E E5 D8 5A 43 26 7A E4 4E 9C 30 4C C8 97 FD 54 68 C0 FC 36 1C 75 01 96 E9 1F 45 06 70 2C 29 67 2E F5 9E 92 60 3D E8 E7 66 2A 91 EA 57 A9 1E 5F 27 51 C9 65 18 AB 83 D5 85 61 0C 77 7E F9 7F 5E DC 84 5C 6A 39 4D 87 5B DA 69 E6 5D 11 82 10 55 D9 CB 8C 72 86 6F 64 80 CA A2 05 AC 4A B1 0B 38 E1 AD 31 B3 98 78 B8 22 76 9A 24 A7 25 B5 F2 B9 B0 3A Okay, there's basically no chance that was clear. So let's do the calculations, to make it a bit clearer. Suppose we want the HP growth rate. That's stat 0. Enciphered[0] is 0x20, and lissa's character ID is 4, so we calculate INDEX = (0x20 - (0x63 * ((4 ^ 0xA7) - 0x21 * 0) ^ 0xD9)) & 0xFF = 0x50. The value in the lookup table at index 0x50 is 0x23, or 35 -- Lissa's base HP growth rate. Suppose we want the Lck growth rate. That's stat 5. Enciphered[5] is 0x39, and lissa's character ID is 4, so we calculate INDEX = (0x39 - (0x63 * ((4 ^ 0xA7) - 0x21 * 5) ^ 0xD9)) & 0xFF = 0x56. The value in the lookup table at index 0x56 is 0x41, or 65 -- Lissa's base Lck growth rate. Class Growth Rates As with unit growth rate data, class growth rate data is stored, again enciphered as a sequence of 8 bytes in the usual ordering. Lissa's base class is Cleric, which has enciphered growth rate `11 A6 E5 D2 CF 01 67 A6`. The conversion process for class growth rates proceeds much like the unit growth rate -- the formula is just different. We perform the calculation: INDEX = (ENCIPHERED[N]- (0x23 * ((CLASS_ID ^ 0x46) - 0xF1 * N) ^ 0x78)) & 0xFF; GROWTH_RATE = LOOKUP_TABLE[INDEX]; Where LOOKUP_TABLE is the same as it was for unit growth rates. Again, walking through the calculations for Cleric: Suppose we want the HP growth rate. That's stat 0. Enciphered[0] is 0x11, and cleric's class ID is 0x35, so we calculate INDEX = (0x11 - (0x23 * ((0x35 ^ 0x46) - 0xF1 * 0) ^ 0x78)) & 0xFF = 0x50. The value in the lookup table at index 0x50 is 0x23, or 35 -- Cleric's base HP growth rate. Suppose we want the Lck growth rate. That's stat 5. Enciphered[5] is 0x01, and cleric's class ID is 0x35, so we calculate INDEX = (0x01 - (0x23 * ((0x35 ^ 0x46) - 0xF1 * 5) ^ 0x78)) & 0xFF = 0x7F. The value in the lookup table at index 0x7F is 0x00, or 0 -- Cleric's base Lck growth rate. Hope this is clear, feel free to ask any clarifying questions, and have fun playing around with growth rates!
  3. If they're encrypted in SoV, I will figure out how to decrypt them.
  4. An undub, at least, I can commit to making happen. Censorship/bad translation...less likely, but we'll see. I plan on putting the same amount of effort into tools for SoV as I did into If.
  5. Here's a complete text dump: https://mega.nz/#!gAdi1DAA!OF5gTPppxGNePZpYNp2-XseegAvUZRP_jaT22a4efzM Of course, you can also replicate it yourself, since FEAT's updated with support for Heroes message archives.
  6. Have some confessions text dumps: EN: http://pastebin.com/hHydP034 JP: http://pastebin.com/VTDtHZsK
  7. Yeah, Awakening. If/Fates use the process name "Iron15", and internally codename as "Iron15" (Iron15_Sound in the romfs, etc). Awakening uses the process name "quartz", and internally codenames as "14Iron" (14Iron in all the same places If/Fates use Iron15).
  8. The game internally refers to itself as "Iron15."
  9. So, the RomFS contains a stacktrace for the game. Which leads to stuff like this: Yay, IDA.
  10. Because there's no publically released ARM9 exploit or ARM11 Kernel exploit on firmwares higher than 9.2. If you don't know what that means, you won't understand more technical explanations. If you do know what that means, then we don't need to explain anything else because the implications about our ability to modify a user's system on firmwares higher than 9.2 are obvious: (we can't).
  11. I can understand mentioning the files, but tools? Literally every tool I've ever made I've thrown up on Github for people to use...
  12. In the same directory as the .3DS you used as input :)
  13. If you don't want to download the patch to see the Readme.txt file, please see here: http://pastebin.com/WKvH9MQP
  14. Thank you very much for your translations -- I'm working on implementing them into a patch: http://imgur.com/a/B5rqs
×
×
  • Create New...