This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=170

RetroHelix, posted Sat Sep 27, 2014 3:40 pm (571)

---

Hi,

it looks like these SPF files are archives but I can't make much sense of them. At 0x08 is a DWORD that seems to be the numberoffiles. Starting from 0x20 there are some file informations and pointers to the filenames, 0x10 bytes per file. But I can't find the pointers to the files inside the archive. Please take a look at it:

http://www54.zippyshare.com/v/35739302/file.html

Thanks in advance.

RHX

aluigi, posted Sat Sep 27, 2014 4:46 pm (572)

---

http://aluigi.org/papers/bms/others/jeanne_darc.bms

RetroHelix, posted Sat Sep 27, 2014 5:22 pm (573)

---

Wow, so fast. Impressive

Can I ask you about how you examine these files? Is it "just" looking what every byte (4 bytes in this case) could stand for and your experience? I mean how you found out about the multiplying by 0x10 to get the offset?

aluigi, posted Sat Sep 27, 2014 5:44 pm (574)

---

I do everything by watching the hex editor, reading the 32bit fields and then doing some math calculations to check if everything matches.

For this archive the only field that is "weird" is the number of files, because it's not exact (files 1).

The size of each entry is visible by checking the location of the constant fields and the incremental values of some fields.
For example they are 4 fields per entry and one of them is ever zero, if you watch the file with a hex editor (which is set to 16 bytes per row), you will notice a column all of zeroes.

Then we need to locate the files and checking what's their size, in this case they are all PNGs so it's very easy.
The first PNG is at offset 0x290, the "IEND" 4 delimiter finishes at 0x7471.
The second starts at 0x7480.

In our table we need to find the size and offset fields.
0x7471 - 0x290 is 0x71e1 which is just the second field of the first entry

Regarding the offset we have 0x20, 0x73f, 0xa5a and so on.
The first two offsets remember the offsets of the PNG files, so I multiplied them by the ALIGN value (I have just fixed the script because it had 0x10 hardcoded) and added that field found in the archive header.

The rule for the file extraction is to find SIZE and OFFSET, optionally also the NAME.

Here we know that there are filenames and we have only one field left in the table, luckily it was a simple absolute offset to the name

As you can see it was very simple, that's why I was so fast in making the script.

RetroHelix, posted Sun Sep 28, 2014 9:45 am (578)

---

MMh, I see. Looks like I just have to practice these things a bit more.

aluigi, posted Sun Sep 28, 2014 10:12 am (579)

---

The secret is being able to "see" the fields inside the hex editor using just the eyes.

When you have the following in your hex editor

Code:

01 00 00 00 02 03 00 00 00 04 00 05 00 00 00 06

and you read it as:

Code:

little endian
 1 (32)
 2 (8)
 3 (32)
 4 (16)
 5 (32)
 6 (8?)

on the fly, then I guess all the rest of the "file format reversing" work is a lot easier.