jaclaz wrote:
Well, I am not the analyst, nor the one that writes a tool, I am simply someone passing by and trying to understand - since at first sight I notice something that seems to me "just not right" - if there are some margins for improvements in the tool, in the procedure or in both.Ironic, The person that is interested the most is neither of roles I would have *assumed* this to be most relevant for. Teaches me for assuming <img src="images/smiles/icon_wink.gif" alt="Wink" title="Wink" />
jaclaz wrote:
I would think that recovery/carving tools would need to be *somehow* modified to take account of the rare possibility of a non-common fourth byte value.Just an update, C. Grenier has implemented the following change for photorec:
http://git.cgsecurity.org/cgit/testdisk/commit/?id=4c5fcd4164b7fd06eafa54fa44ecfb9fb2d02d00
At least one carving tool more that now does this <img src="images/smiles/icon_wink.gif" alt="Wink" title="Wink" />
photorec should also handle 0xff-pre-segment-marker values [I have not confirmed this yet]
jaclaz wrote:
This could be done in several ways, as an example with a "switch" to look only for "more common" and a switch for "all values" (or something similar),
Agree there is a definite need for what was dubbed as "anomaly detection" in tools. Though I would personally like this be relative to a sample set I as an analyst can control not someone else's model of the world.
jaclaz wrote:
JFYI (about how the standard is a mess) see here:
Now if it only were JPEG I would be very glad. IMO alas this is more rule than exception (that file formats have idiotic designs).
↧
