How does brute force work?
Posted: 30 Apr 2016, 21:25
I can see photorec_bf, photorec_bf_pad, photorec_bf_frag, and photorec_bf_aux in phbf.c but I don't see any high level view of how it works.
I'm interested in augmenting the flv fragment search. I have a ~135mb file and photorec from git in my test is finding 8mb of it before DC_ERROR due to an invalid flv tag (probably on new sector). I'm going to assume it was contiguous (with 10gb free on ~20gb partition) but on shutdown maybe a text file or somesuch was written over a sector or two.
The flv tags have timestamps, which should be good enough to match candidates if the candidate is reasonably soon after the last valid tag then resume from that.
Also from what I'm reading the first packet or two in the flv file are most often meta data containing things like movie length in ms. From that it can be deduced when the last tag is read (and when to stop searching for fragments). I can see in file_flv.h this metadata is passed through. https://www.adobe.com/content/dam/Adobe ... ec_v10.pdf
With the 135mb file I had accidentally mv'd over it. I immediately realized my error, shut down the browser and computer (I guess I should've pulled the plug instead so nothing new would've been written).
So I intend to read that movie length field if present, and augment the search for flv fragments by searching sector by sector for a valid tag from the failure point, and then somehow hook back into photorec's code to resume recovery.
On that search by sector by sector, it could be more optimal to before searching into the sector for a tag, first have photo rec identify if any other file starts there, then skip over that file.
I'm interested in augmenting the flv fragment search. I have a ~135mb file and photorec from git in my test is finding 8mb of it before DC_ERROR due to an invalid flv tag (probably on new sector). I'm going to assume it was contiguous (with 10gb free on ~20gb partition) but on shutdown maybe a text file or somesuch was written over a sector or two.
The flv tags have timestamps, which should be good enough to match candidates if the candidate is reasonably soon after the last valid tag then resume from that.
Also from what I'm reading the first packet or two in the flv file are most often meta data containing things like movie length in ms. From that it can be deduced when the last tag is read (and when to stop searching for fragments). I can see in file_flv.h this metadata is passed through. https://www.adobe.com/content/dam/Adobe ... ec_v10.pdf
With the 135mb file I had accidentally mv'd over it. I immediately realized my error, shut down the browser and computer (I guess I should've pulled the plug instead so nothing new would've been written).
So I intend to read that movie length field if present, and augment the search for flv fragments by searching sector by sector for a valid tag from the failure point, and then somehow hook back into photorec's code to resume recovery.
On that search by sector by sector, it could be more optimal to before searching into the sector for a tag, first have photo rec identify if any other file starts there, then skip over that file.