That is, given the post-imaging nature of the experiment and to seek robustness in those procedures and confidence by examiners that follow them regarding the "effectiveness of commonly used software processes to check the validity of forensic images." no matter which forensic tool is being used?
I am not a native English speaker, maybe that is the reason why I cannot understand the above quote.
Is it an actual question?
Am I missing a verb?
Am I wrongly adding a comma?
I read it as:
That is, < longish parenthetical sentence > , no matter which forensic tool is being used?
Â
jaclaz
I understand. Indeed I see many posts on here that don't quite fit how people would say them but I leave it alone so long as I understand the point being made. So don't worry about your native tongue 😊Â
I think you have the general drift from the remarks you made.
Yes, it is a question for anyone to respond to, if they so wish. If you don't agree a procedure should include checking for the validity of forensic images, how would you handle it?
I understand. Indeed I see many posts on here that don't quite fit how people would say them but I leave it alone so long as I understand the point being made. So don't worry about your native tongue 😊Â
I think you have the general drift from the remarks you made.
Yes, it is a question for anyone to respond to, if they so wish. If you don't agree a procedure should include checking for the validity of forensic images, how would you handle it?
I am not at all worried, I am missing what is the question.
Care to re-phrase it in a clearer way?
Or is this:
If you don't agree a procedure should include checking for the validity of forensic images, how would you handle it?
the question?
jaclaz
The functionality of editing an image must always be viewed a problem. Images are considered to be sacrosanct: the possibility for deliberate or indeed non-deliberate changes reduce the trust in one.
However ... if editing (to restore what is a probable error in a partion table to legal values, and so allow further processing) or suppression (remove partitions that are so far outside the legal scope of the inquiry that they cannot be allowed to remain) is present, bugs, errors, mistakes will surely also be a cause of changes. And that may be another important threat that needs to be met.
I can imagine some way of 'overlaying' an image with editing instructions: these bytes are changed to some others, these areas are overwritten entirely, and so. But I can't imagine that the source image should be changed to reflect those changes: instead, it seems, that additional info is added or a a new image should be generated.
But to work on that kind of layered image probably means a very deep redesign of any existing product. The simple problem (e.g. byte 42 must not be fetched from the image, but from a manual patch) seems technically possible: it only replaces data, it doesn't relabel it. But the problem of suppressing existence of files, directories, partitions, ... while at the same time presumably retaining the original offsets means that the entire tool may need to be redone: if I'm iterating through a partition table, and one entry has been blancoed, I can't stop, but need to find the following one.
In some cases that does not seem possible to do: ISO 9660 directory sectors terminate when a directory record starts with 0x00, which notionally is the length of the next record. But I have to be able to go on to the second next entry (if it exists) in the same sector, and still not get confused abut actual byte content or labelling: that means some heavy-weight data wrapping mechanics as well as extensive internal retooling of any internal iteration functionality. It would be interesting to see an image file design that allowed for suppression of file system entities, but mainly as a pathological phenomenon, not as a practical one.
I'd view that kind of functionality -- suppression -- with very high degree of suspicion: if it is added to an already existing tool, I don't see I could trust it in any way. If it's done as a separate tool, it needs very careful design and considerable SOPing to ensure that the original image doesn't leak, and that the blancoed image can be identified
In fact it seems that in that case imaging must be done by someone authorized to access the data, and competent to suppress those part that can't be allowed to be left, and so a new edited image must be generated from the raw one. The SOP changes may be solvable; the technical issues though seem very difficult to solve.
Â
Â
@athulin
Â
That is an EXCELLENT response and exactly the views I hoped to receive. A couple of points you raised I hadn't thought about in the same terms you mentioned.