SciresM

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!

There's a new skill that affects growth rates.

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!

If they're encrypted in SoV, I will figure out how to decrypt them.

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.

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.

Have some confessions text dumps: EN: http://pastebin.com/hHydP034 JP: http://pastebin.com/VTDtHZsK

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).

The game internally refers to itself as "Iron15."

So, the RomFS contains a stacktrace for the game. Which leads to stuff like this: Yay, IDA.

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).

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...

In the same directory as the .3DS you used as input :)

If you don't want to download the patch to see the Readme.txt file, please see here: http://pastebin.com/WKvH9MQP

Thank you very much for your translations -- I'm working on implementing them into a patch: http://imgur.com/a/B5rqs

The entirety of the third path is on the Nintendo servers and thus, due to the way dlc works on the 3ds, piratable and playable... It's already been uploaded in two places I've seen.

The English at the bottom of that screenshot is because I tested whether the DLC actually let me play the third path in my partially-menu-translated rom hack.

Good news: It should be really, really easy to make a menu translation patch. Normally there are some issues with English Text's Kerning: But if you replace If's font with US Awakening's, those all go away and translating the game is as easy as changing the JP text in a text editor.

So Fire Emblem If save files use...literally exactly the same checksum/compression as Fire Emblem Awakening. I'll need to update the file lists in FEAST to support hex editing Fire Emblem: If saves, but they really re-used a lot of stuff from Awakening.

File formats are basically the same as Awakening, by the way, for what it's worth, Vincent. If you'd like I can upload then PM you the rom's contents I've been dumping in /feg/.

Said 'leakbro' would be me, and yeah, doesn't get more spoilery than that.

Anyone who was using that save tool, there was a pretty major bug in it. I've fixed it, new release is here: https://github.com/SciresM/FEA-Save-Tool/releases

Save format is identical across regions. Here you are: https://github.com/SciresM/FEA-Save-Tool/releases/ Drag/drop a folder containing the Global/Chapter/Map files, save Decompressed folder, hex edit the files in the Decompressed folder, drag/drop the Decompressed folder onto the tool, Save compressed folder, import the compressed, edited files with Savedatafiler. Should be pretty simple?

That'd be helpful, yeah.

Okay, sure. By the way, could you send me those Map# files from the other thread? I can do automatic checksum fixing for Global and Chapter#, but I don't have any Map# files, so I can't tell what's checksummed there.