Research on legendary image data
I have been playing legends recently. In addition to being fun, I also have the meaning of research (hehe, excuse).
Today I studied the legendary image data storage a little, haha, I finally understand.
Do you also want to know how the legendary data is stored? Or, if you want to learn to crack game pictures, then follow me, but before that, you must prepare some tools.
1---Hexadecimal Editor This is the main tool for cracking. It is recommended to use HEDIT, which is available on the Huajun homepage.
2---Image Processing Program This is used to process pictures. It mainly generates the picture frame we want. This is done with the brush that comes with WINDOWS.
3---Calculator This is used to convert hexadecimal and decimal, which is often used. Just come with WINDOWS.
4---Notepad is used to record important data of the cracking process.
5---A programming tool that can handle binary files This is used to write cracking programs. Because it is so tiring to copy image files manually from files. Especially when the data is relatively large.
6----Then, a little bit of preparatory knowledge stored in the PC is the high position in front and the low position in the back. That is to say, hexadecimal 0xf8890 is like this in the hexadecimal editor: 90 88 0f 00. This is quite important.
OK, let's start now.
First of all, I opened a WIL file and looked at it, and I felt that I had no clue. Then I opened a WIX file, and in the file header of both files, I found such text. #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 this we can see that WIL means LIB, which means library. WIX is the INDEX file, which means index. In this way, we have a preliminary understanding that data is stored in WIL and data index is stored in WIX.
If you don't know the index yet (what?? You don't know the index.. I'll tell you something. An index is something similar to an address book. You look up the address where the data is located from the index (this address is not a memory address, but an address in the file). Then through this address, you can find the data in the library.
OK, now that we know where the data index is stored, then let’s start finding these indexes.
We used HEDIT to open two WIX files for comparison, and we found that the data before OFS=36 are all fixed, so we will look at the following data. I found a smaller WIX file. Then select from the place where OFS=36. Here we use DNITEMS WIX. I found that the number of bytes selected is 1656, and we know that a file location is generally stored in 4 bytes, that is, the total number of images here is 1656/4 = 414. Use a calculator to calculate that its hexadecimal system is 0x19E. At this time, we look for the hexadecimal system at the beginning. We found that there is a 9B 01 in the place where OFS= 44, which is very close to 9E 01, so we know that the subsequent information is not all file addresses. Because we also need to record the number of images. So, we started to select from the end of the data, and when we looked at the number in the lower right corner to 0x19b, we stopped and found that we were just stopping in front of 0X44. Ha, we know, these data are all file locations, and this 9B 01 is the number of images. So, what is the first file location for? I opened two WIX files and found that in the same location, it is where the file location information after OFS = 44 starts. The data is always 38 04 00 00. Oh, I understand, this is the starting position of the image data. That is the starting position of the first image.
Then let's convert this starting position, 0X438 = 1080, haha, that is, the first 1080 bytes in WIL is not image data. So what are they?
According to experience, we know that one of the color palettes in the BMP file is a 4-byte DWORD value, so the 256 positions are 1024 bytes, ha, it's very close. Then I compared the two WIL files and found that the first 44 bytes are very similar. So we subtract 44 bytes and it is 1036 bytes. So what are the remaining 12 bytes? Haha, I don’t know, don’t worry about him. We only have images.
At the 0X438 position of WIL, we found the number of 14 00 0D 00. I guess the image must not exceed the size of 65535, so I guess this is the image size data of the two USHORTs.
So I multiply them, and then I found a file location behind 0X438, and then subtracted it to get the length of the data. Subtract the image size data, ah? There are actually 4 bytes extra. Haha, I can't figure out their use now. Well, I jumped over because I think they generally have nothing to do with the image.
Then I copied the image data, I turned on the brush again, set the image attributes to 0X14*0X0D, and then saved it into a 256-color bitmap. Then use HEDIT to open the bitmap and paste the data at 0X1078. Then save the disk and exit. Then use a brush to open the image file. Ha, I saw the image. It looks like a symbol. But the color is wrong. Yes, I'm entering the legend. I took a picture with PAUSE, then opened it with HEDIT, and selected 1024 bytes at the position of 54. Then copy, open the image file, paste it at 54, then save it, exit, and open it with a brush. ha. It's a book.
Ah, I finally got it. I got the following conclusion from the above action.
1 Image position index in *.wix
2 Image information is in *.wil.
3 Image index starts with OFFSET 0X2C, with a DWORD total number of images
4 Then the OFFSET value of DWORD, the OFFSET value of the first sub-image is fixed to 0X438, = (1080) 10
5 So, that is, in WIL, there is 1080 bytes of free start.
6 In WIL, the 44 bytes at the beginning of the file are all the same. So, that is, there is another 1036 bytes for another purpose.
7 (This is not solved) 1024 of 1036 is a 256-color palette, so what is the use of the remaining 12 bytes?
8 Under Legend, there is a screenshot function to save the palette in the image, which is the palette of the game image data.
Then, the rest of the job is to write code to cut the images.
I will not explain this issue anymore, because the program will be easy to write after knowing the data format of the image storage.
Well, now I'm going to write a program. Look, I think I have written a lot. But don't worry, this thing has no copyright, just use it casually.
One more addition:
I didn't make it clear that these images are stored in the file in a 8BIT bitmap. No compression or encoding