DAT (Ever17): Difference between revisions

From Game Research Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 32: Line 32:
Stored file size is doubled. Actual file size = (file size /2).
Stored file size is doubled. Actual file size = (file size /2).


Internal formats, specifically *.JPG's from the wallpaper.dat have a strange thing about them. While I have only tested a few files, it appears about 4,000 bytes into the file, there is a 256 byte chuck that differs which breaks the image. When using the in-game option to save wallpapers, the image is proper and correct. Will most likely require a disassembler to figure out what exactly is going on. Note: This is only about the *.JPG's inside wallpaper.dat. Other files don't show this pattern.
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.  


2014/10/07 Research<br />
2014/07/10 Currently looking into this with a dissembler and debugger. Looking like XOR was used in some way.
 
Program only reads from 'wallpaper.dat' when saving files. In-engine view of picture uses the game asset version loaded from 'bg.dat'. Currently using dissembler/debugger to see what it does with the file after it has loaded it into memory. External monitor shows it first loads the first 16 bytes of the file (wallpaper.da), which is the header, and then loads 22,778 bytes which is probably the entire index since when it reads the JPG file, it seeks to position and reads size of JPG without checking index. Need to compare more than one jpg to see if part that is different is predictable. This may only apply to wallpaper.dat since no other files extracted show this issue. the JPGs could have been
processed before building the wallpaper archive and the engine, when saving, will reverse/repair the broken part when saving.
-Possible test:
Extract all data and replace a specific image and try to extract it and see what the results are.

Revision as of 00:38, 11 July 2014


Seen/used in the follow game(s):

  • Ever17

Structure

Header
Size Content Description
4Bytes Magic/ID
4Bytes File Count
8Bytes 0x00 Filler
class="wikitable" Index
Size Content Description
4Bytes Offset
4Bytes File Size
24Bytes File name

Stored offset starts at zero. Actual offset = (16+(file count * 32)).

Stored file size is doubled. Actual file size = (file size /2).

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.

2014/07/10 Currently looking into this with a dissembler and debugger. Looking like XOR was used in some way.