DAT (Ever17): Difference between revisions

From Game Research Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 30: Line 30:
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.  
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. A small local subroutine for a function at 0x0000D286(input file) 0x0040D286 appears to be the annoying function. Seems the whole list of numbers used as the number that is subtracted from the incoming number from the extracted file, is in memory and not generated durring this operation. It may be generated sometimes else or a static set from the EXE image that may be used with other functions so there may be other files, such as the scripts, that may have obstructed spots in the file.
2014/07/10 Currently looking into this with a dissembler and debugger. Found the sub-routine the is changing these bytes. It takes 1 byte number (depending on how you interrupt this), and subtracts it from the number at a specific location, between 4352 to 4608, in the JPG file that came from the archive that is loaded in memory. Once it does the operation on all 256 bytes, it will then write the file to disk.
 
Subtraction numbers till method of generation is found...
 
E6C9708B0A1D34FF6EB138B312857CA7F69900DB1AEDC44F7E81C80322550CF70669902B2ABD549F8E51585332259C471639207B3A8DE4EF9E21E8A342F52C972609B0CB4A5D743FAEF178F352C5BCE736D9401B5A2D048FBEC1084362954C3746A9D06B6AFD94DFCE9198937265DC87567960BB7ACD242FDE6128E382356CD76649F00B8A9DB47FEE31B8339205FC277619805B9A6D44CFFE014883A2D58C7786E910ABAA3DD41F0ED1D8D3B2A51CC796B9A0FBBA0D646F1EA16823C275AC17A689304BCADDF4BF2E71F873D2453C67B659C09BDAAD840F3E4188C3E215CCB7C62950EBEA7D145F4E111813F2E55C07D6F9E03BFA4DA4AF5EE1A86302B5EC57

Revision as of 08:01, 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
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.

2014/07/10 Currently looking into this with a dissembler and debugger. Found the sub-routine the is changing these bytes. It takes 1 byte number (depending on how you interrupt this), and subtracts it from the number at a specific location, between 4352 to 4608, in the JPG file that came from the archive that is loaded in memory. Once it does the operation on all 256 bytes, it will then write the file to disk.

Subtraction numbers till method of generation is found...

E6C9708B0A1D34FF6EB138B312857CA7F69900DB1AEDC44F7E81C80322550CF70669902B2ABD549F8E51585332259C471639207B3A8DE4EF9E21E8A342F52C972609B0CB4A5D743FAEF178F352C5BCE736D9401B5A2D048FBEC1084362954C3746A9D06B6AFD94DFCE9198937265DC87567960BB7ACD242FDE6128E382356CD76649F00B8A9DB47FEE31B8339205FC277619805B9A6D44CFFE014883A2D58C7786E910ABAA3DD41F0ED1D8D3B2A51CC796B9A0FBBA0D646F1EA16823C275AC17A689304BCADDF4BF2E71F873D2453C67B659C09BDAAD840F3E4188C3E215CCB7C62950EBEA7D145F4E111813F2E55C07D6F9E03BFA4DA4AF5EE1A86302B5EC57