How does brute force work?

Using PhotoRec to recover lost data
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Locked
Message
Author
andrewjsmart1988
Posts: 3
Joined: 30 Apr 2016, 20:49

How does brute force work?

#1 Post by andrewjsmart1988 »

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.

andrewjsmart1988
Posts: 3
Joined: 30 Apr 2016, 20:49

Re: How does brute force work?

#2 Post by andrewjsmart1988 »

Toying around here: https://github.com/AndrewSmart/testdisk ... 497cc56c06

Have a stack/list of resumable files set up. Want to check those if a block is read that has no known file header starting on it. Can't quite figure out where to place that logic, my first try in the 'Pass 2 STATUS_EXT2_ON_BF' didn't work. So next I'll try in the 'Pass 1 STATUS_EXT2_ON'? Need to figure out the program flow better. I'll try for another day or two and see if I can recover the remainder of that file.

I've read through photoruc_bf some but still don't understand the _aux, _frag, and _frag_fast subroutines.

andrewjsmart1988
Posts: 3
Joined: 30 Apr 2016, 20:49

Re: How does brute force work?

#3 Post by andrewjsmart1988 »

All right, photorec_aux looks much cleaner to hook into than the bf stuff. The bf algorithm is more meant for just jpg's on flash media from what I gather. I had assumed my proposed search for the next valid flv tag was best there. I no longer seek to know how the photorec bf routines work.

I can see now that photorec on ext2 does not utilize the ext indirect blocks, it does identify and skip over those indirect blocks which are linear (same delta through each element). I suppose it is possible for an indirect block to be non-linear, not be skipped over, the data_check would fail, and thus the file would be interpreted by photorec as corrupt and reading would stop there. Maybe fix for this can be to allow certain # of non-linearities.

I can see that both the 'foremost -d' and scalpel tools utilize indirect blocks (instead of photorec's flv approach of checking each packet). https://digital-forensics.sans.org/blog ... le-systems
Those tools operate simply off of header & footer and don't support more complex logic like this tool does.

In my mv-then-small-write tests they find the whole flv file, but it is corrupt and unplayable from the segment photorec stops due to data_check failure.

The flv file can possibly be fixed via flv fixing tools like 'ffmpeg -I .flv -o .mpg'.

However I think if on ext2 photorec were to more robustly interpret indirect blocks then it should be possible to, (on a new pass?) carve the whole file out, use the indirect blocks to identify blocks that were part of the file but are no longer in the free space (they were allocated to something else), and use the knowledge in data_check to resume the file in a seamless way (resulting in ideally best non-corrupt file possible). With both this change and handling of nonlinear indirect blocks things on ext2 would be improved!

Locked