Here's one for you all… The only related post I could find dates back to 2006 without any real resolution to it.
If I am carving out a PST file from unallocated space, I can identify the start of data from the file header, specifically searching for !BDN in plaintext or 21 42 44 4E in Hex. The trouble is, the PST doesn't appear to have an identifable or consiustent footer.
I've tried dropping a working PST into HxD and the final sections of the file are populated with 00 values. Is there any additional data contained within the headers that would identify the length of the file so it can be accurately carved out and recreated?
I am looking for a physical way of doing this so forensic tools such as EnCase etc or data recovery tools such as EaseUS are not an option.
Any help much appreciated as always!
Is there any additional data contained within the headers that would identify the length of the file so it can be accurately carved out and recreated?
http//
http//
Check addresses 0a8 and/or 0b8
32 bit
….
00a8 total file size [4 bytes] 0x270400 in this case
64 bit
….
00b8 total file size [8 bytes] 0x042400 in this case
Nothing of use in the actual documentation?
http//
Like (example) wink
ibFileEof (Unicode 8 bytes; ANSI 4 bytes) The size of the PST file, in bytes.
ibAMapLast (Unicode 8 bytes; ANSI 4 bytes) An IB structure (section 2.2.2.3) that
contains the absolute file offset to the last AMap page of the PST file.
cbAMapFree (Unicode 8 bytes; ANSI 4 bytes) The total free space in all AMaps, combined.
cbPMapFree (Unicode 8 bytes; ANSI 4 bytes) The total free space in all PMaps, combined.
Because the PMap is deprecated, this value SHOULD be zero. Creators of new PST files MUST
initialize this value to zero.
….
And
http//
jaclaz
I'll get right on to looking through all those. Thanks for the pointers jaclaz ) )
Good luck, but carving a PST file is very unlikely to work.
My reasons are that PSTs tend to be large. PSTs tend to grow. Both of these reasons mean that there is a very high chance that the PST will be fragmented. Straight carving will not recover fragments - it requires extra intelligence to find potential fragments and stitch them back.
Your best hope - for a NTFS disk is to see if you can find the relevant associated MFT entry for the file.