


If we adjust the ASM as needed, we can reuse it like this: Unpacking the file is fairly trivial, we can just steal the decryption method from the games file and use it locally.

Afterward, we must also set the files new size and its new entry point. So each section must be rebuilt and realigned with the file. text section must be resized to its proper size containing the new raw data which in turn unaligns all the other sections. However, handling this unpacking externally from a static context is a bit more difficult because it involves having to rebuild the PE file on disk after it is unpacked. Some basic shifting and such and the unpacked data is obtained fairly easily. Like much of SE’s other packing / encoding methods, the encryption of the section is not very secure or unique.

If we load FFXiMain.dll inside of OllyDbg, or any other debugger / disassembler, we will see this at the files current entry point: text data is actually within the POL1 section. This is because the actual data does not exist in the file until its unpacked. In this image you’ll see something strange. text section data, but is packed.įor example, this is the games FFXiMain.dll as of Jan 01, 2015: In many of the game files, there is a packed section called POL1. Square Enix has taken the time to create an internal packer of the games sensitive data for the PE files (.exe and. One of the many aspects of reversing Final Fantasy XI be it statically on disk or live in memory requires that parts of the game files are unpacked.
