Configure PhotoRec To Recover All Inodes And Zone Data

[keenan]

My partition table is toast, but the actual area where files exist has not been touched.

I tried testdisk but it says the superblock is corrupted so I was unable to recover the partition and see the files.

I tried photorec and it brought back every file except my binary files that have no extension and lack magic numbers.

But I really, really, really need these binary files.

Is there a way to configure/hack/trick PhotoRec to get everything by not requiring extensions or magic numbers?

If not, can someone show me the source code where this requirement is made and suggest a patch so it just recovers all possible files irregardless of missing extensions and magic numbers?

[cgrenier]

What was the filesystem type of your partition ? ext2/3/4, xfs ?
PhotoRec only works with magic bytes.

[keenan]

What was the filesystem type of your partition ? ext2/3/4, xfs ?
PhotoRec only works with magic bytes.

It was ext4.

I'm a bit confused after reading up on ext4 inodes https://en.wikipedia.org/wiki/Inode In order to find the data associated with the magic bytes of a specific file it must read the inode block where the magic number is found.

So does test disk only look for a string of magic numbers and secondly confirm the inode block it is within, then use the inode block to get the pointers to the data? vs....

Searching for inodes, then checking the inodes fields for extensions and magic numbers, then reading those inode pointers to get data?

[recuperation]

But I really, really, really need these binary files.

In this case you have to contact a professional recovery service.

Is there a way to configure/hack/trick PhotoRec to get everything by not requiring extensions or magic numbers?

No.

If not, can someone show me the source code where this requirement is made and suggest a patch so it just recovers all possible files irregardless of missing extensions and magic numbers?

You don't need PhotoRec for that.
You just produce files as combinations of all available clusters. Unfortunately that number of files is already bigger than the numbers of atoms in the universe.

[keenan]

You don't need PhotoRec for that.
You just produce files as combinations of all available clusters. Unfortunately that number of files is already bigger than the numbers of atoms in the universe.

That sounds intimidating. I'm under the assumption that a programmer would just need to create a disk image. Open the disk image and seek block by block. When encountering a block just check if it fits the bit structure of an inode. Then use the inode checksum to make sure of it's integrity. It it passes that test, then use the pointers to the zone data of the file. Write that file to a recovery disk. Then move to the next block to read. It would seem that magic numbers and ext are an unnecessary factor in recovery and instead it's whether or not the inode and it's corresponding zones are intact.

Is there something wrong with my logic?

[recuperation]

It would seem that magic numbers and ext are an unnecessary factor in recovery and instead it's whether or not the inode and it's corresponding zones are intact.

Is there something wrong with my logic?

Yes.
Fingerprinting, ("magic numbers") is a fantastic generalized concept that enables recovery in cases of extreme destruction where metadata (p.e. inodes) is lost. It can be easily extended to new formats.
Beside PhotoRec which appears to me as the most powerful one according to independent third party tests - despite being a free and open source program.
There are commercial programs that use the same approach.

Other approaches are possible.

[keenan]

Fingerprinting, ("magic numbers") is a fantastic generalized concept that enables recovery in cases of extreme destruction where metadata (p.e. inodes) is lost. It can be easily extended to new formats.
Beside PhotoRec which appears to me as the most powerful one according to independent third party tests - despite being a free and open source program.
There are commercial programs that use the same approach.

Other approaches are possible.

So PhotoRec doesn't rely on identifying ext4 inode blocks to link to a corresponding extent where the file data is stored? And goes directly after the extent block of a file, where upon reading the extent data a magic number is found at the beginning or not?

[recuperation]

No. That's why defragmentation determines the recovery success.

[keenan]

No. That's why defragmentation determines the recovery success.

So if a file's data is written in non contiguous blocks it is not recoverable by this the magic number method?

[recuperation]

Yes.