03-18-2017, 11:25 PM
Certainly!
So firstly I ignored the first byte, because it didn't really correspond to anything.
The next byte (One before the name you see there in the archive with the extension) corresponds to the length of each file name when you highlighted it. So i used the command:
getdstring NAME FNAMELENGTH
the fnamelength, being from the byte we grabbed from before.
now another issue we faced is that the offset data was weird. Because, it was padded/aligned data, so we needed to skip over those 0's until we got to the offset, which came after that "20" value. So, i wrote that little do while statement in order to skip over the zero's, until it grabbed the 20 byte and broke as the condition becomes false, as the byte grabbed is no longer a zero.
The script then starts off at the position one byte after the "20" byte, which would be the size value, followed by the offset value. The way i checked this was, the first value had an offset of 0x270 (it was in little endian). So i jumped to that position and the file began after the filenametable. From there, i took the last value and added it to the offset, to check if it was the size. It was, as it was 0x2 bytes under the next supposed offset in the data table.
Then i saved the file using the log command, then started again at the top with grabbing the null byte(the script loops). and continued to loop until it broke out to an incorrect file input size value, which ends after all the files have been read.
So firstly I ignored the first byte, because it didn't really correspond to anything.
The next byte (One before the name you see there in the archive with the extension) corresponds to the length of each file name when you highlighted it. So i used the command:
getdstring NAME FNAMELENGTH
the fnamelength, being from the byte we grabbed from before.
now another issue we faced is that the offset data was weird. Because, it was padded/aligned data, so we needed to skip over those 0's until we got to the offset, which came after that "20" value. So, i wrote that little do while statement in order to skip over the zero's, until it grabbed the 20 byte and broke as the condition becomes false, as the byte grabbed is no longer a zero.
The script then starts off at the position one byte after the "20" byte, which would be the size value, followed by the offset value. The way i checked this was, the first value had an offset of 0x270 (it was in little endian). So i jumped to that position and the file began after the filenametable. From there, i took the last value and added it to the offset, to check if it was the size. It was, as it was 0x2 bytes under the next supposed offset in the data table.
Then i saved the file using the log command, then started again at the top with grabbing the null byte(the script loops). and continued to loop until it broke out to an incorrect file input size value, which ends after all the files have been read.