Greetings
I’m a former Windows power user, now a Linux newbie slowly learning the ropes.
I recently used Foremost to recover data from a USB drive that died; ironically during the process of backing up its contents.
Foremost was able to recover pretty much everything I had in that USB, specifically from a .img disk image I made before discarding the thing.
With the exception of archive files.
From memory, I remember that the USB contained at least 2 encryted archives; one in PGP format and another in 7z format.
With proper configuration of the .conf file, I’ve already been able to make Foremost detect 7z files. However, it outputs hundreds of “chunks” rather than 1 complete archive, far in excess of the size of the actual archive I’m trying to recover.
If it makes any difference, the 7z archive contains only video files, in the 3gp format.
I also recall having non-encrypted 7z archives in the drive, wich Foremost isn’t recovering neither.
My question is: is this inherent to the nature of archive files or encryptation? Or is this a simple matter of my .config file still not being properly written?
I can post the .config file if it helps.
As for the PGP file, I have yet to find a configuration tho successfully detect it. This makes me wonder that maybe the file may actually be a gz.pgp or tar.pgp, using GNUPG if I recall correctly.
Because Foremost performs file carving instead of relying on filesystem metadata, I think it’s irrelevant to Foremost if your file is encrypted or not and if it’s an archive or not: provided that Foremost knows the file extension, whether the header and footer are case sensitive or not, the maximum file size in Bytes and the header structure of the file type, it should be able to recover the encrypted and/or archive files – but then you would have to decrypt the recovered encrypted file(s).
Therefore, if Foremost is not recovering the archive and encrypted files, it’s likely due to Foremost’s configuration.
Well, Foremost’s config file for non-encrypted 7z files should look like this (assuming that the largest non-encrypted 7z file is no larger than 500 MB. I used the hexdump -C command on a non-encrypted .7z file to read its header):
# 7Z (7zip archive file)
# 7z y 500000000 \x37\x7a\xbc\xaf\x27\x1c\x00\x04
…and the PGP one must look like this (also assuming no PGP file larger than 500 MB. I applied hexdump to a PGP public key block file):
# PGP (Pretty Good Privacy file)
# pgp y 500000000 \x2d\x2d\x2d\x2d\x2d\x42\x45\x47
If Foremost fails to recover them, these files are likely damaged/corrupted on the source, or a file footer data must also be provided at the config file. If I were you, I would create sample files on a non-corrupted file system (e.g. encrypted and non-encrypted .7z and .pgp files like the ones that you’re trying to recover) and then run hexdump -C /path/to/sample/file |head to check if the header that you’re using matches the header found with hexdump. You can also read the file footer provided by hexdump and add it to the Foremost’s config file so the chances of Foremost recovering such files increases.
