DAT (Ever17): Difference between revisions
No edit summary |
No edit summary |
||
Line 31: | Line 31: | ||
There is a subroutine in the EXE that will take 1 byte from the JPG that is stored in memory, subtracted it by a number, then put it back. It does this 256 times, or the whole 256 byte chunk of data that is obstructed and only for locations between 4352 and 4608. The number that is subtracted from the raw value is not the same for each byte. Unsure how the subtraction numbers are generated but it does not appear to be stored in the EXE. | There is a subroutine in the EXE that will take 1 byte from the JPG that is stored in memory, subtracted it by a number, then put it back. It does this 256 times, or the whole 256 byte chunk of data that is obstructed and only for locations between 4352 and 4608. The number that is subtracted from the raw value is not the same for each byte. Unsure how the subtraction numbers are generated but it does not appear to be stored in the EXE. | ||
Subtraction numbers are generated by adding up the 14 characters i the file name and taking the last value (looking at it like a 8 bit number so, if total is 0x00000AE4, you only take E4). This is the first difference number out of 256, numbers then use the previous number to make the new number so... | |||
'a' starts off as the value of the previous number. | |||
{| class="wikitable" | |||
|- | |||
! Order !! Expression | |||
|- | |||
| 1|| d = a + (a*2) | |||
|- | |||
| 2 || d = d + (d*8) | |||
|- | |||
| 3|| a = a+(d*4)+1243 | |||
|} | |||
One unknown thing so far that needs to be figured out for a condition<br /> | |||
0040D25F and eax, 8000FFFFh<br /> | |||
0040D264 jns short loc_40D26D<br /> |
Revision as of 02:04, 12 July 2014
Seen/used in the follow game(s):
- Ever17
Structure
Header | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Size | Content | Description | ||||||||||||
4Bytes | Magic/ID | |||||||||||||
4Bytes | File Count | |||||||||||||
8Bytes | 0x00 Filler | |||||||||||||
Index | ||||||||||||||
Size | Content | Description | ||||||||||||
4Bytes | Offset | Starts from zero. | ||||||||||||
4Bytes | File Size | Stored value is actual size doubled | ||||||||||||
24Bytes | File name |
Notes for 'wallpaper.dat' Extracting images straight from the container file will produce broken images. There is nothing wrong with the extraction process but rather the files themselves. Starting from offset 4352 and ending at 4608 in every single JPG, this 256 byte has been modified in some way.
There is a subroutine in the EXE that will take 1 byte from the JPG that is stored in memory, subtracted it by a number, then put it back. It does this 256 times, or the whole 256 byte chunk of data that is obstructed and only for locations between 4352 and 4608. The number that is subtracted from the raw value is not the same for each byte. Unsure how the subtraction numbers are generated but it does not appear to be stored in the EXE.
Subtraction numbers are generated by adding up the 14 characters i the file name and taking the last value (looking at it like a 8 bit number so, if total is 0x00000AE4, you only take E4). This is the first difference number out of 256, numbers then use the previous number to make the new number so...
'a' starts off as the value of the previous number.
Order | Expression |
---|---|
1 | d = a + (a*2) |
2 | d = d + (d*8) |
3 | a = a+(d*4)+1243 |
One unknown thing so far that needs to be figured out for a condition
0040D25F and eax, 8000FFFFh
0040D264 jns short loc_40D26D