Jump to content

Search the Community

Showing results for tags 'reverse engineering'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Important Links
    • Serenes Forest Code of Conduct
    • Mistakes or Errors on the Site
  • Important Forums
    • Announcements
    • Member Feedback
    • Site Content
  • General Forums
    • Introductions
    • General
    • Far from the Forest...
    • Creative
    • Fan Projects
    • General Gaming
  • Fire Emblem Forums
    • General Fire Emblem
    • NES and SNES Era
    • GameBoy Advance Era
    • GameCube and Wii Era
    • Nintendo DS Era
    • Nintendo 3DS Era
    • Fire Emblem: Three Houses
    • Fire Emblem Heroes
    • Fire Emblem Warriors
    • Tokyo Mirage Sessions #FE Encore
  • Miscellaneous
    • Forum Graveyard

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Interests


Location

Found 3 results

  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. Hello. I wanted to figure out how the game determines what item slot a character has equipped for various reasons. Usually slot one, but the unit could have an item in slot one and weapon in slot two, or be unequipped. SURE, I could write my own, but first off, I want to see how the game does it, and second off, it's easier just to write a bl call. Okay, so I set out debugging FE7. I figured that equipping is vital to attacking, so I checked docs for battle routines, and the closest I came to actually determining equipped item is in Nintenlord's "pre battle.txt" which tells me that byte 0x48 after 0203A3F0 will contain "Equipped item after battle"(and also 0x4A for "Eqipped item pre battle"). So I set my debugger to auto-break after detecting a write to 0203A43A, and I played around a bit. It does indeed pause when I go to the pre-battle screen, when I press R over a unit and when I go into the items menu(and for that matter, it re-updates when I scroll around on item menus). Most importantly, it does seem to contain the equipped item. So analyzed the code that was editing it, and moved up a little bit and found (at 08028806) a ldrh r0, [r0], which always loads the correct item ID, meaning if I could find how the game generated the r0 pointer, that would be the pointer to the slot of the correctly equip-able item. My debugger reports r0 as being 0203A40E, whis is by nintenlord's notes the item 1 slot. So then in turn I tried to figure out how the computer gets the correct equip in that slot (It correctly loads the items if I stick a vulnerary in slot 1, although it does trip up if there are no equip-able items, though I can probably look at writes to 0203A43A with no equips to see how it determines that.) (Now that I type that maybe that's an indication that I still have yet to find the exact routine that checks for that). So I set my debugger again to stop when that byte was edited... and I came across a subroutine that I realized copies data from one section of the RAM to another (It's at 090BFFC2). Oh great. After running a few times, it doesn't always use the same source ram(though it is always in the 3000000s, the quickly-accessible RAM). So uh, I still need to find the subroutine, and does anyone want to guide me on how to proceed from here? I'm really at a loss.
×
×
  • Create New...