Most WinFE answers can be found at the free WinFE online course - http//
Virtually any software, including non-forensic software, can be used forensically with the results admitted into court. Conversely, virtually any widely-used forensic software can be used and results NOT admitted if the examiner did it wrong.
Nowhere is it written that you can't use both *nix and WinFE, depending on the computer configuration or how you feel that day in using the one you want. I like WinFE best, until I like DEFT better on a different day, or PALADIN on another day…all depends on the set up of computers that have to be imaged and examined.
Nowhere is it written that you can't use both *nix and WinFE, depending on the computer configuration or how you feel that day in using the one you want.
Personally, I prefer WinFE on wednesdays, as it goes better with the striped blue shirt, while CAINE is definitely more suitable for fridays. wink
jaclaz
I'd love to make a WinFE disc but I'm afraid that would likely cause more trouble in court than a widely-used solution like DEFT/CAINE/PALADIN/etc would.
"Widely-used" is not equal to "works as expected" (which is "forensically sound"). Latest versions of DEFT Linux / CAINE / PALADIN have data alteration issues, so you can't say that WinFE is definitely worse, because it is not "widely-used".
But Troy Larsson, Colin Ramsden, Brett Shavers (to name the main three people among the originators/supporters of WinFE) are not widely known for playing pranks on digital forensic investigators and should be granted, based on their curricula/good reputation, at least the benefit of doubt
You can say the same about DoJ, DHS and NIST. However, since there is no proper methodology for Live CD / Live USB testing, there are no valid tests conducted and there are no confident results therefore.
Let's take a look at DHS
Now take a look at DoJ
Both reports contain the results of tests based on NIST CFTT methodology. But these results are not systemic there are no specific tests for "dirty" file systems, and such file system state is introduced in a test by chance. Although reports described above look trustworthy, they are based on flawed (extremely confined) tests.
Even if you expand the tests above by adding drives with "dirty" file systems, you won't get adequate results. Imagine that there is a file system with two boolean flags in a superblock in order to test it properly, you actually need to test four states of that file system. But real file systems have a lot of possible states, and you need to test thousands of drives in order to get results close to reality (I don't even speak about file system states that are unlikely in reality). Also, sometimes data modifications may not happen if you boot from CD, but they will happen if you boot from USB, and you can get different results based on live media type USB Flash or USB SSD/HDD (proven by my tests). Multiply by three. Did you test HDDs? Test SSDs now. Multiply by two here (or there is no guarantee, that live operating system will not TRIM a source drive in schedule).
If you don't want to spend years practicing in theory of combinations, you need to think a better way to test a Live CD / Live USB. Source code examinations are no solution here (Linux has >1 million lines of code in file system drivers and Windows is closed source).
So… if anyone says "I performed some tests on 10 HDDs and data didn't change", consider these words to be applicable to an extremely limited subcase, not even a general case.
Virtually any software, including non-forensic software, can be used forensically with the results admitted into court. Conversely, virtually any widely-used forensic software can be used and results NOT admitted if the examiner did it wrong.
Of course, I wasn't putting the fact it could be used in doubt, but it could expose you to a lot more mud-slinging from consultants hired by the adverse party. If I used DEFT/CAINE I can simply say "this is the X version I used, this is the X hash of the DVD matching the official version" and if I have any problem I'd likely be backed by other DEFT/CAINE users or the authors themselves that are both Italian. WinFE instead could make things fare more complicated non-opensource, discs prepared by myself, "supposedly less safe because it's Windows", etc., not that I'm saying that any of those arguments are valid but you never know who the judge is going to trust so I'd really want to avoid adding more variables to the equation.
"Widely-used" is not equal to "works as expected" (which is "forensically sound"). Latest versions of DEFT Linux / CAINE / PALADIN have data alteration issues, so you can't say that WinFE is definitely worse, because it is not "widely-used".
But the changes done by DEFT/CAINE can be explained and documented. I mean, even turning on an hard drive could change the contents inside (SMART/user partition) but that's acceptable and so are DEFT/CAINE changes if that's the best you could use at the time. But if you use WinFE and the other consultant maybe with far more qualifications than you claims the image could have been infected, that you could have made it wrong, or what it did may not be reproducible/documented since it's closed source and you have nothing/nobody to back you it's going to become one hell of a mess. Should I tell the judge "BRB, I'm going to have all the documentation/tests done on WinFE translated?". That's not going to be very effective.
In the end of course you could prove that what you did was perfectly right/forensically sound, but are you sure the judge is going to give you the chance to do so?
But the changes done by DEFT/CAINE can be explained and documented
How are you going to document them? By testing or reviewing the source code? If you are going to explain and document the changes after they happened in a particular case, how will you know that data did change? There could be no timestamps or system log indicators informing you about the changes. For example, DEFT Linux / CAINE will sync mirrored device-mapper volumes if they are out of sync, and you can't tell that these volumes were out of sync several mins ago (by looking at the modified data). You will loose the data and won't even notice this.
But the changes done by DEFT/CAINE can be explained and documented
How are you going to document them? By testing or reviewing the source code? If you are going to explain and document the changes after they happened in a particular case, how will you know that data did change? There could be no timestamps or system log indicators informing you about the changes. For example, DEFT Linux / CAINE will sync mirrored device-mapper volumes if they are out of sync, and you can't tell that these volumes were out of sync several mins ago (by looking at the modified data). You will loose the data and won't even notice this.
That sounds more like one of the cases where DEFT/CAINE shouldn't have been used on the machine itself. If the machine could not be acquired by other means (or in a reasonable amount of time or within a reasonable cost) then there's not much to do other than taking the risk or giving up on acquiring the evidence. But that doesn't change that a more widely used/tested/known tool is likely going to sound more credible than something you prepared yourself at home, something on which you could end up roasted on. Of course there could be some unavoidable changes in the data but it's usually going to be something that has already happened before and can be reproduced/explained/documented/justified since those tools are more common. If you couldn't use anything else but DEFT/CAINE (due to hardware/time/cost constraints) but that ruined part of the evidence then ok, that evidence has less value, but it's still better that not having the evidence at all. In the end everything has to be weighted accordingly to the circumstances but if widely-used tools are usually considered more credible (more known/more tested) I think it's better to keep that into consideration. Just like you have to weight the risk of data being changed when using Ubuntu-based forensic distributions you also have to weight the risk of your evidence being thrown away because you couldn't get the chance to prove it was acquired correctly.
That sounds more like one of the cases where DEFT/CAINE shouldn't have been used on the machine itself.
Yes, we are talking about cases where a hardware write blocker can't be used for some reason (no adapter, etc).
But that doesn't change that a more widely used/tested/known tool is likely going to sound more credible than something you prepared yourself at home
I doubt that. In order to mitigate arbitrary code execution risks grml allows examiners to rebuild the ISO image using a simple tool. It's also possible that a tool you prepared at home has less known issues than a public tool.
If you couldn't use anything else but DEFT/CAINE (due to hardware/time/cost constraints) but that ruined part of the evidence then ok, that evidence has less value, but it's still better that not having the evidence at all. In the end everything has to be weighted accordingly to the circumstances but if widely-used tools are usually considered more credible (more known/more tested)
That depends on your jurisdiction. In Russia and many ex-USSR countries an examiner should obtain a written permission from a court / pre-trial investigator before changing the evidence. If an examiner changes the evidence without such permission, he is wrecked. This is because only a court / pre-trial investigator knows which part of the evidence is critical for investigation, and which is not. How will you obtain the permission to change the evidence, if you can't explain, what exactly may be altered and why? Written permissions for "any kind of changes" work only with bad defense attorneys.
Also, imagine a judge asking you did your tool change anything on that drive? In case of device-mapper the only correct reply is "may be" (even if you saved all log files from /var/log in a live file system). Sounds bad, yeah?
Just like you have to weight the risk of data being changed when using Ubuntu-based forensic distributions you also have to weight the risk of your evidence being thrown away because you couldn't get the chance to prove it was acquired correctly.
But don't forget that your evidence can be thrown away because of the changes discussed. The tools used for acquisition are subject to similar problems as Linux environment has. Do you trust dcfldd? But it misaligns the data after a bad sector in a source drive.
I doubt that. In order to mitigate arbitrary code execution risks grml allows examiners to rebuild the ISO image using a simple tool. It's also possible that a tool you prepared at home has less known issues than a public tool.
Sure, but will you get the chance to prove that? Or do you risk other consultants insinuating that your custom tool isn't as valid as it seems? It all depends on which risks you want to take.
That depends on your jurisdiction. In Russia and many ex-USSR countries an examiner should obtain a written permission from a court / pre-trial investigator before changing the evidence. If an examiner changes the evidence without such permission, he is wrecked. This is because only a court / pre-trial investigator knows which part of the evidence is critical for investigation, and which is not. How will you obtain the permission to change the evidence, if you can't explain, what exactly may be altered and why? Written permissions for "any kind of changes" work only with bad defense attorneys.
[/quotes]
Same here, but it depends on what kind of offense is being investigated. If there's a chance the data could be changed and it's one of those offenses where the copy must be repeatable you have to ask for authorization (the adverse party may even name another consultant to assist the copy/agree on the methods). I usually consider acquisitions done with distros on-par with live acquisitions (non-repeatable) for that same reason, because you never know what could happen when the machine boots up, maybe it wouldn't show the boot menu or get into the BIOS interface at all, thus booting directly into the installed OS.Also, imagine a judge asking you did your tool change anything on that drive? In case of device-mapper the only correct reply is "may be" (even if you saved all log files from /var/log in a live file system). Sounds bad, yeah?
Yes, but as I said it all depends the available choices (and of course also on what you're looking for). What's truly important is to agree on the compromises with the agents/attorney first.
But don't forget that your evidence can be thrown away because of the changes discussed. The tools used for acquisition are subject to the similar problems as Linux environment has. Do you trust dcfldd? But it misaligns the data after a bad sector in a source drive.
Do I trust them? Not much. That said I had troubles with some acquisitions done on Windows too. But do most other consultants trust them? AFAIK yes, so I try and keep that into consideration. (Still, the faster they fix those crazy issues the better it is 😯 )
Lots of good debate, but in my humble opinion, the practicality of actually using forensic tools comes down to the examiner and his or her ability to effectively describe the use of the tools in court.
Rare is the court that does not allow evidence that was seized using reasonable means given the totality of the circumstances. The "best" option need not be chosen, only a reasonable option. The best option can only be chosen on Monday after the game. During the game, you take what you can get based on what you know and the time available.
No tool is 100% foolproof. Search the Tableau support notices and you will find a fairly recent problem of potential writes to the evidence while using the Tableau hardware write blocker. Hardware write blockers can have errors. Software is not different. Have you been in forensics more than a few years? Then you have seen more than the occasional update to a forensic tool where you were capturing or analyzing evidence wrong for months until the 'bug' was found…Today's tool is not better than tomorrow's.
No examiner is 100% correct 100% of the time. Courts know this. You make the best decisions at the time based on what you know, what you see, what you have, what your goals are, and a ton of 'unknowns'. Carelessness, recklessness, and bad intentions won't save you. But good faith and good decisions based on what is at hand will. If you have a missing child case where the running computer is instrumental in recovering the child, shutting down and removing the drive to image behind a write blocker would not be the best decision. Changes to the drive would be acceptable as you should get into the volatile memory and find time sensitive intelligence. Each situation is different, as are the choices made by the examiners that need to make them.
Beating up WinFE or any *nix bootable system with hypothetical scenarios is not conducive to figuring out how to effectively and reasonably use them. Test what you believe is reasonable because you cannot test every situation theoretically possible. Pick a reasonable tool for the task at hand, the best that you can based on what you know of the environment at hand.
I do not know of many examiners who can testify to the 'code' of any forensic bootable system, whether it is open source, closed, commercial, freeware, or shareware. However, not knowing the code to WinFE or DEFT/Linux does not mean you cannot be an expert at using it or building your own. How many airline pilots know every detail of every part of the jet they fly? Yet, they are expert pilots . and most certainly can testify as an expert in court (for a flying related case…). If you choose to go down the road in court of testifying to source code when you have no idea is a road you will regret during cross examination. Take some training in the 'how to use' functions. Test it. Confer with others about it. Use it reasonably. No need to get under the hood if you really don't have to. But if you want, more power to you.
I have seen 'experts' ruin the credibility of a valid forensic software with effective cross examination. I have seen another expert testify to the use of a regular/normal/common software like Microsoft Word and make it sound like he wrote it himself and used it forensically for a purpose it was never intended. It is not the tool (a hammer or Encase) that makes the case. It is the examiner. Always. Picasso could paint a masterpiece with crayons. A great examiner can analyze a hard drive with a hex editor. The better you become at analysis, the more you rely upon yourself and not the tool.
Given the number of forensic examiners that use WinFE and/or *nix distros, you will be hard pressed to find someone not using them or having never used them. Is there any expert that will state under oath that WinFE is not a forensically sound acquisition tool? More accurately, it is the manner in its use that makes the difference, which applies to all forensic tools. Opposing experts concentrate on exposing weaknesses in procedures and mistakes in analysis (false assumptions of data, etc…). Opposing experts won't usually attack the tool unless it is an uncommon tool, untested, outdated, proven unreliable, or not licensed.
Sure, but will you get the chance to prove that?
And if another consultant successfully demonstrates design flaws in your tool that result in missing / corrupted evidence?
Or do you risk other consultants insinuating that your custom tool isn't as valid as it seems? It all depends on which risks you want to take.
These risks depend on how tricky the opposite consultant is. He may tell the court that your tool is inadmissible because
- it was designed and produced in another country,
- it's not certified (by no matter who, just the word "certified" sounds great),
- the methodology you used is not described in the appropriate literature, etc.
There are tons of similar tricks, you can't be prepared for all of them. I don't think that serious decisions should be made based on a possibility of future groundless complaints.
If <tool #1> is used wider than <tool #2> and <tool #1> alters more bytes than <tool #2>, I choose <tool #2>. I don't think that "court-verified" argument should be used here.