Legend Image Data Storage

Research on legend image data
I have been playing legend recently. In addition to fun, I also have some research meanings (haha, an excuse ).
Today, I have studied the legendary image data storage.
Do you want to know how the legendary data is stored? Or, if you want to learn how to crack game images, come with me. But before that, you must prepare some tools.
1 --- The hexadecimal editor is the main tool for cracking. We recommend that you use HEDIT, which is available on the huajun homepage.

2 --- image processing program this is used to process images. It mainly generates the image framework we want. In this case, use the paint brush that comes with WINDOWS.

3 --- calculator this is used to convert hexadecimal and 10hexadecimal, which is often used. WINDOWS comes with it.

4 --- notepad records important data in the cracking process.

5 --- a programming tool that can process binary files. This tool is used to write cracking programs. Because it is too tired to manually copy an image file from a file. Especially when the data is large.

6 --- then, the data stored by some preliminary knowledge in the PC is high and low. That is to say, the hexadecimal 0xf8890 is like this in the hexadecimal Editor: 90 88 0f 00. This is very important.

Now, let's get started.

First of all, I opened a WIL file and looked at it. Then I opened a WIX file and found such text in the file headers of the two files. # ILIB v1.0-WEMADE Entertainment inc (this is the WIL file header) # INDX v1.0-WEMADE Entertainment inc (this is the WIX file header ). From the above we can see that WIL is the meaning of LIB, that is, the meaning of the library. WIX is the INDEX file, which means the INDEX. In this way, we will first know that the data is stored in WIL, and the data index is stored in WIX.

What if you do not know the index ?? You do not know the index .. Dizzy 4). Let me tell you something. An index is similar to an address book. You can find the address of the data from the index (this address is not a memory address, but an address in the file ). With this address, you can find the data in the database.

Now that we know where data indexes are stored, let's start to find these indexes.
We use HEDIT to open two WIX files for comparison. We found that the data before OFS = 36 is fixed. Then, we will look at the subsequent data. I found a small WIX file. Then select from OFS = 36. The WIX of DNITEMS is used here. I found that the number of bytes selected is 1656, and we know that a file is usually stored in four bytes. That is to say, the total number of images may be 1656/4 = 414, use a calculator to calculate that the hexadecimal value is 0x19E. At this time, we will find the hexadecimal value 9E 01 at the beginning, there is a 9B 01 close to 9E 01 in OFS = 44, so we will know that the subsequent information is not the file address. Because we need to record the number of images. Therefore, we choose from the end of the Data. When the number in the lower right corner reaches 0x19b, we stop and find that it is just in front of 0X44. Haha, we know that all the data is the file location. This 9B 01 is the number of images. So what is the first file location for? I opened two WIX files and found that the same location is where the file location information after OFS = 44 starts, the data is always at 38: 00 00. Oh, you see, this is the starting position of the image data. That is, the starting position of the first image.

Then, convert the starting position to 0X438 = 1080. That is to say, the first 1080 bytes in WIL are not image data. So what are they?

Based on our experience, we know that the color palette in the BMP file is a 4-byte DWORD value, so the 256 position is 1024 bytes. Haha, it's very close. Then I compared two WIL files and found that the first 44 bytes are very similar. Therefore, we subtract 44 bytes to 1036 bytes. So what are the remaining 12 bytes? Well, I don't know. Don't worry about him anymore. We only need images.

At the 0X438 position of WIL, we found a number of 14 00 0D 00. I guess the image must not exceed 65535, so I guess this is the data of two USHORT images.

So I multiplied them, and then I found a file location after 0X438, and then subtracted to get the data length. Subtract the image size data, huh? Four more bytes are allowed. Well, I cannot figure out their usefulness. Well, I jumped over because I think they generally have nothing to do with images.

Then I copied the image data. I opened the paint brush, set the image attribute to 0X14 * 0X0D, and save it as a 256-color bitmap. Then, use HEDIT to open the bitmap and paste the data at 0X1078. Save the disk and exit. Then open the image file with a paint brush. Haha, you see the image. It looks like a character. However, the color is incorrect. Well, I entered legend. Cut a graph with PAUSE, open it with HEDIT, and select 1024 bytes at 54. Copy, open the image file, paste it in 54, save the disk, exit, and open it with a paint brush. Haha. Is a book.

Ah, I finally got it. I drew the following conclusion from the above action.

1. The Image Location index is in *. wix.
2. The image information is in *. wil.
3. The image index starts from OFFSET 0X2C and has a DWORD total number of images.
4 followed by the OFFSET Value of DWORD. The OFFSET Value of the first image is fixed to 0X438, = (1080) 10.
5. In WIL, 1080 bytes are available at the beginning.
6 In WIL, the 44 bytes starting with the file are the same. Therefore, another 1036 bytes is used for other purposes.
7 (this is not solved) 1036 in 1024 is a 256-color palette, so what are the remaining 12 bytes used?
8 In legend, there is a function to save the color palette in the image is the color palette of Game image data.

Then, the rest of the work is to write code to parse the image.
I will not elaborate on this issue any more, because the program is well written by knowing the data format of image storage.
Well, now I have to write a program. I think I have written a lot. But rest assured that this is not copyrighted and can be pulled at will.

Another supplement:
I have not made it clear that these images are completely stored in the file in 8-bit bitmap mode. Not compressed or encoded