Join Us!

Editing contents of...
 
Notifications
Clear all

Editing contents of enCase image !  

Page 2 / 3
  RSS
tomforman
(@tomforman)
Junior Member

FTK2 allows you to create a user which can only see particular information, i.e.

You create a Tab called Email, prepare the tab accordingly, and then when the review logs on to look at the case, all they can see is that tab. and not all the other files within the E01 / DD image.

Any help?

ReplyQuote
Posted : 21/08/2008 10:24 pm
joachimm
(@joachimm)
Active Member

Apparently the person(s) responsible for 'libewf' are working on a way to write to and edit EWF (EnCase) files. Don't know how practical this would be, but worth looking at nonetheless.

No longer working on. The current libewf version has a functional Read and Write mode. E.g. mount_ewf.py allows you to mount a set of EWF files in rw mode. This is mainly intended to mount file systems that are unable to mount read only. Libewf does not store its changes in the E01 file but in d01 files (called delta file). The delta files are designed to contain small amount of changes, i.e. for recovered partition tables, etc.

However possible, it is impractical to store changes directly in the E01 files due to compression. Older beta version of libewf allowed changing the E01 files directly.

No need to create dd files and hexedit them. Manipulating an E01 file with libewf is very easy. A proof of concept is ewfalter (only provided in the source package) If an altered image file is created the ewftools will provide for a new MD5 when exported to a new image. So writing down the original MD5 is could be useful practice.

Basically there is no format you cannot change. In theory you can even make changes and have the same MD5, unsure about the practical side of this on images. Some studies were able to calculate MD5 collisions in little time.

Signing the evidence could be good practice. The Advanced Forensic Format (AFF) is one format which supports this. However this means the person who is able to sign the file is able to change it.

ReplyQuote
Posted : 23/08/2008 3:08 am
Jamie
(@jamie)
Community Legend

Jumps in - hi Joachim! - jumps out…

ReplyQuote
Posted : 23/08/2008 4:43 am
seanmcl
(@seanmcl)
Senior Member

Very Impetuous - it is relative straight forward to update the data in segment, modify the segment CRC and then recalculate the whole file hash.

Again, it misses the point. If you want to remove sensitive information from an image, using a hex editor to edit the E01 file is a waste of time and/or your client's money.

I may add this to RevEnge as a proof of concept….

I think we'd all concede the concept that it can be done. You can pay the postal service to deliver your milk but it isn't, necessarily, the best way to get milk on your table.

Incidentally our practice since we started working with Encase about 9 years ago has been to write the hash down - much harder to tamper with a hash when the orginal has been submitted on paper as part of your evidence.

Here I am agreed. I don't believe in allowing our tools to automate what is simply good record keeping/evidence management.

ReplyQuote
Posted : 23/08/2008 4:55 am
joachimm
(@joachimm)
Active Member

Jumps in - hi Joachim! - jumps out…

far off topic but, he Jamie. , How are things ? everything OK? I'll continue on private message. Not to disturb this discussion too much.

ReplyQuote
Posted : 23/08/2008 5:08 am
PaulSanderson
(@paulsanderson)
Senior Member

Very Impetuous - it is relative straight forward to update the data in segment, modify the segment CRC and then recalculate the whole file hash.

Again, it misses the point. If you want to remove sensitive information from an image, using a hex editor to edit the E01 file is a waste of time and/or your client's money.

I think you are misisng the point - there are many reasons to edit an e01 file one that i have come across on a few occasions is you may have a corrupt image (dodgy boot sector/wiped MBR) that you want to mount with something like MIP - quick edit and its working.

Not every one just uses encase images for forensics - I always work on an image including when I do data recovery (my background for over 15 years).

Just because you can not see a point doesn't mean there are not others who could use such the feature. The OP asked for tools that could do this job - you dont know what his exact requirement is, and he made no reference to removing sensitive material, and whether they need to be forensically sound. Having said that and edited image is not necessarily un-sound - if what was done and the reasons for doing it are justified and documented.

A number of poeple have said categorically that it cannot be done - as a result of this thread they can now get hold of libevf (or RevEnge if I bother to add the feature) to educate themselves. I think 'the point' has been made well.

ReplyQuote
Posted : 23/08/2008 12:34 pm
seanmcl
(@seanmcl)
Senior Member

I think you are misisng the point - there are many reasons to edit an e01 file one that i have come across on a few occasions is you may have a corrupt image (dodgy boot sector/wiped MBR) that you want to mount with something like MIP - quick edit and its working.

Agreed. The context of the original message, however, was not data recovery and not fixing a broken EnCase image. It was redaction (not, necessarily, for legal purposes) and it was in this context that I made my reply.

If you create a case in EnCase and then acquire an image, then edit that image and the corresponding checksums and MD5 hash you can still have a valid evidence file. But it won't match the data in the EnCase case file and while you could, possibly, edit the case file, you'd be on shaky legal ground because the specification is not published.

Even from non-forensic perspective, if your intention is to remove files and folders from an image of an acquisition, what about the data acquired from unallocated space? You aren't going to easily get rid of that.

In that context, do you still disagree with the statement that editing the E01 file for redaction purposes is not best way to do it?

Not every one just uses encase images for forensics - I always work on an image including when I do data recovery (my background for over 15 years).

Same here only I started doing data recovery when a friend's practically new Godbout computer crashed. I still have his Heathkit H-19 monitor on which we used to play rogue (until Mike Mauldin created rogomatic and made it pointless). Since EnCase/Expert Witness didn't exist, then, what is the point?

A number of poeple have said categorically that it cannot be done - as a result of this thread they can now get hold of libevf (or RevEnge if I bother to add the feature) to educate themselves. I think 'the point' has been made well.

I didn't say that. I said that it was not the best way to remove files and folders and I stand by that statement.

ReplyQuote
Posted : 23/08/2008 7:52 pm
trewmte
(@trewmte)
Community Legend

I know this thread is over 12-years old and as an update of events back in 2014 I would be interested to read other practitioners views in 2020?

"In typical cases the digital evidence has been ‘preserved’ in a special file or ‘container’ that has been declared to be secure on the basis that it is not possible to tamper with the contents of the container or the information supporting the contents (metadata) without this act being discovered. However, through the use of a freely available open source library, libewf, it has been discovered that the most commonly used forensic container format, Encase Evidence File Format, also known by its file extension .E01, can be manipulated to circumvent validation by forensic tools. This digital forensic container contains an embedded forensic image of the acquired device and metadata fields containing information about the data that was acquired, the circumstances of the acquisition, and details about the device from which the forensic image was acquired. It has been found that both the forensic image and the metadata associated with that image can be freely altered using simple file editors and open source software.

Exploiting these weaknesses within the Encase Evidence File format results in a forensic container that can be altered but fails to provide any evidence that this has occurred. In practice the original device is often unavailable, damaged, or otherwise unable to provide independent validation of the data held in the container. In such situations, it would be difficult, if not impossible, to determine which of two forensic containers held the original record of the evidence."

ReplyQuote
Posted : 14/07/2020 9:16 pm
jaclaz
(@jaclaz)
Community Legend
Posted by: @trewmte

I know this thread is over 12-years old and as an update of events back in 2014 I would be interested to read other practitioners views in 2020?

WHAT is the red part in your post?

A reference to something?

Your take on the matter?

Something else?

There is no weaknesses in the format (not because libewf or other tools can change the contents of the image).

It is the procedures that can have weaknesses and the hashing algorithm that may have them.

Compare:
(good) guy #1:
Take a disk, image it into a .E01, calculate hash, provide .E01, hash matches, OK.

(bad) guy #2
Take a disk, modify its contents, image it into a .E01, calculate hash, provide .E01, hash matches, OK.

(bad) guy #3
Take a disk, image it into a .E01, calculate hash, modify .E01, calculate new hash, provide .E01, hash matches, OK.

(bad) guy #4
Take a disk, image it into a .E01, restore it to another disk, modify its contents, image it into a .E01, calculate hash, modify .E01, calculate new hash, provide .E01, hash matches, OK.

(bad) guy #5
Take an .E01 made by the good guy, calculate hash, modify .E01, further modify .E01 so that new hash is the same of old one (hash collision), provide .E01, hash matches, OK.

There are no differences in practice between #2, #3 and #4, they are simply more complicated ways to achieve the same result.

And not even in #5 UNLESS the #5 is a replacement during the shipping/transport AND there is a practical way to create a hash collision.

But if there is a proper procedure avoiding this hypothetical replacement all is cool and dandy.

jaclaz

 

ReplyQuote
Posted : 15/07/2020 5:35 pm
trewmte
(@trewmte)
Community Legend

Yes, the red highlight was my doing. I wanted to draw attention to the comments from my research to see if 1. it jogged anyone's memory and to see if s/he had read it or were aware of this research and 2. if s/he had any views on it.

The research - Validation of forensic images for assurance of digital evidence integrity http://researchrepository.murdoch.edu.au/24962/

Having spent time researching (before I posted) to see if the topic had been popular by reference to it or tested or analysed I found only one source that of Richard Boddington in his book Practical Digital Forensics 2016. Richard's methodology, set out in his book, was to analyse the problem of the e01 research and show that using IXImager and its own proprietory appoach to containers (.asb) the tool uses a process to highlight if the .asb container had been tampered with causing contaminated data post-imaging. 

I ran the posted scenario across different digital forensics platforms. Not one confirmed or at least admitted to having been aware of the 2014 details, even when I added the reference source details, this did not provoke any further admissions. I didn't know about this 2014 research until about a year ago, so it could be that others were/are in the same position as myself.

At one time e01 was seen as a Gold standard, so any reference to a (my take - anti-forensics) attack on it post-imaging in 2014 might have produced some actual e01 tests to guide examiners. However, there are researchers and examiners still acquiring data (recorded in e01 containers) in 2020, so the 2014 research is not entirely moot.

Helpful feedback in discussions todate from other platforms. The responses acknowledged nothing is really unbreakable (from an intended attack), which is a fairly well understood proposition; there has to be a measure of reliance that the manufacturer has done its job in (exhaustive?) testing; ultimately, trusting the people acquiring the evidence is the 'golden rule'. 

Reference to any specific testing policies, practices and processes (inhouse or standard-wise e.g. ISO.17025) were not stated. 

ReplyQuote
Posted : 15/07/2020 9:41 pm
EnCaseDC
(@encasedc)
New Member

@trewmte not sure why this would be posted on a 12-year old thread, and @jclaz is correct. The only thing this thesis appears to demonstrate is the weakness for trusting file checksum for data tampering validity (something file checksums are not supposed to be used for), rather than 3rd party hashing before/after.

Lastly, EnCase adopted the Ex01 as the standard format, not E01. So bringing the EnCase name into this issue borderlines malicious intent.

ReplyQuote
Posted : 15/07/2020 10:00 pm
trewmte
(@trewmte)
Community Legend

@encasedc hi no malicious attempt at all. But are you even suggesting no one can discuss anything without your approval first?

I didn't write the article in 2014 nor did I write the book reference. Yes I see Ex01, but that is not being discussed. The 12 years reference was only on the basis I used a previous post here at FF for this discussion. 

ReplyQuote
Posted : 15/07/2020 10:16 pm
jaclaz
(@jaclaz)
Community Legend

@trewmte
Well, as you may well be aware of, safes (yes, those huge boxes of metal with complex locks designed, engineered and built with the scope of using them to keep precious things inside so that they are not stolen) have "grades".

Noone even thinks that a safe is actually "safe" in an absolute way, they are rated according to the time (and in some cases also complexity/noise/vibrations/etc.) needed - according to current knowledge - to open them without the original key/combination/whatever.

Maybe - just maybe - the Iximager format has a higher grade than .E01 (and as well possibly .Ex01 had a higher grade) but more likely - according to current knowledge - there isn't (yet) a known/public procedure to alter them, so they are not in any way "safe" at the most they are "temporarily safer than".

If you want a personal anecdata, let's talk of "common" door locks (specifically so-called "Euro" cylinders).

Many, many years ago, my aunt had a "normal" cylinder on her home door.
*Somehow* some thiefs managed to open it and steal from the house (without forcing anything on the lock or door).

Advised by a friend, whom BTW works for a bank, as the "emergency" man that opens safes for the bank when something goes wrong or keys are lost, I installed on the door a "special" cylinder, with numbered/regitered keys that could not be duplicated if not by the factory, etc., etc. costing some 8-10 time a "normal" cylinder.

Fast forward three or four years, my aunt locked herself out (with the keys inside), she called the police for advice and they gave her the reference to an "authorized" blacksmith.

The guy came, looked at the cylinder, rummaged in his toolbox for some 30 seconds, got out of it a sort of key with a number of knobs/dials attached to it, inserted it in the keyhole, jiggled it a little bit, moving the dials and in another 30 seconds opened the lock, much to our bewilderment.

Asked about it, he told us that that particular lock was actually very safe until the year before, when the new tool came out to open it.

Back to file hashing, I am personally (since several years) the (unheard/not listened to) one saying that simple hashing of an image is not a valid approach, and that more "granular" methods should be used, for several reasons, including the anti-tampering:

https://www.forensicfocus.com/forums/forensic-software/different-calculated-hash-in-encase-ftk/#post-6577347

https://www.forensicfocus.com/forums/general/flaw-in-evidence-verification-process/

jaclaz

 

ReplyQuote
Posted : 16/07/2020 10:42 am
athulin
(@athulin)
Community Legend
Posted by: @jaclaz

The guy came, looked at the cylinder, rummaged in his toolbox for some 30 seconds, got out of it a sort of key with a number of knobs/dials attached to it, inserted it in the keyhole, jiggled it a little bit, moving the dials and in another 30 seconds opened the lock, much to our bewilderment.

Off-topic, I know: For further practical showpieces of similar nature, try

https://www.youtube.com/c/lockpickinglawyer

https://www.youtube.com/user/bosnianbill

Both are highly recommended.

ReplyQuote
Posted : 16/07/2020 3:31 pm
trewmte
(@trewmte)
Community Legend

@Jaclaz and @athulin thank you for the safebreaking and lock picking analogies.

The experimentation set out in the 2014 research, which Boddington states in his book (2016), "unequivocally demonstrated that the metadata contained within an E01 image could be manipulated using open source third-party libraries." is indeed an issue for in-house procedures. 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?

ReplyQuote
Posted : 16/07/2020 6:14 pm
Page 2 / 3
Share: