You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, bytes beyond the valid data length are reported as file data (by The Sleuth Kit). This is incorrect, technically such bytes belong to the slack.
This also leads to unexpected results — a file exported using The Sleuth Kit has different data compared to the same file exported using Windows (because Windows reports such uninitialized data as null bytes).
Here is an example:
$ icat -V
The Sleuth Kit ver 4.11.1
$ icat exfat_allocation.raw 2058 | hexdump -C
00000000 50 54 52 4e 50 54 52 4e 50 54 52 4e 50 54 52 4e |PTRNPTRNPTRNPTRN|
*
08000000
Hello.
According to the exFAT specification, the valid data length field is used to define which data in the stream is uninitialized.
Currently, bytes beyond the valid data length are reported as file data (by The Sleuth Kit). This is incorrect, technically such bytes belong to the slack.
This also leads to unexpected results — a file exported using The Sleuth Kit has different data compared to the same file exported using Windows (because Windows reports such uninitialized data as null bytes).
Here is an example:
A corresponding directory entry set is:
ValidDataLength is 0, DataLength is 0x08000000. So, this file actually contains null bytes, not the "PTRN" pattern.
The text was updated successfully, but these errors were encountered: