And if another consultant successfully demonstrates design flaws in your tool that result in missing / corrupted evidence?
It could be, but as I said it depends on how you weight the risks. To me the chance of trouble for using less-known tools is even more likely. Also WinFE certainly wouldn't be perfect too, e.g. I remember all the trouble I had with the wrong versions of Via and nForce chipsets drivers. In the end it all depends on how you weight the risks, the risk of the adverse party/judge naming a consultant that knows nothing about WinFE therefore putting doubt on the methodology doesn't seem that remote to me since I still haven't met a single consultant that ever mentioned it.
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.
From an absolute POV choosing the tool with the lowest chance of messing the data is certainly the right choice. But consider that CAINE/DEFT are made here in Italy, were used in lots of cases and are well (not perfectly, of course) documented, those are still pretty good reasons to me to give them the priority even simply against other distros. Of course, all this, case by case, if I know it's going to mess with some data that'll likely be important I'd leave them last. Another consultant may point the flaws in the distros but you could find just as easily another consultant or even the authors refuting, circumscribing or giving better context to the issues. I'd have a very bad luck finding somebody to do that regarding WinFE, with an even higher chance of another consultant mud-slinging the fact it's Windows, homemade, etc. Maybe WinFE is more popular in Russia but here I'd really not want to take the risks. And that said from somebody who still makes his own custom XP discs.
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.
Yes. But the existence of live forensics and mobile device forensics does not authorize uncontrolled changes to evidentiary media by a tool used in "dead" forensics.
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.
You can't do that. The number of situations possible in practice of an examiner is beyond the scope of traditional approaches to forensic tool testing (hash a drive, use a tool, hash again, compare hash values), as I described earlier in this thread. I don't think that the word "reasonable" is a synonym for "very limited". You can't adequately test a computer algebra system by solving 10 equations only, you can't do the same with a complicated forensic environment and 10 HDDs.
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.
If a court wants to know something about internals of a jet, a court will ask an engineer, not a pilot. Pilots and aircraft engineers testify in different areas of knowledge. You can't say that an aircraft is a black box for an aircraft engineer. Computer forensics tools should not be a black box for examiners too.
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.
You are talking about accuracy of results. I'm talking about data integrity. If you use a tool to interpret some data, you can certainly do the same with another tool or even by hand (using a HEX editor). You can verify any doubtful result this way, because input data is always the same. But what if your tool changes input data, and you don't know when (why) and how? That's not about incorrect data interpretation, that's about unexpected changes to the data - you can do nothing with a HEX editor here, because it can't recover overwritten data.
@Francesco
I see what I believe are a couple potentially "dangerous" fallacies in your way of reasonings, far more seriouos than *nix is better than WinFe, no, WinFe is better debate.
Fallacy #1
Caine is made in Italy, so it is better.
This, with all due respect is "pure bullshit".
Caine is an exceptionally good platform ) because Nanni Bassetti and the Caine team of Authors/contributors are very good people, very dedicated to the project and managed to put together an excellent product, most of the tools are NOT written by Italians and main contributors such as John Lehr, Maxim Suhanov and Hans-Peter Merkel do not sound particularly "italian".
Fallacy #2
*Caine* (you can replace *Caine* with any other tool) is widely used locally, so I will have less troubles in Court.
This is the same kind of lazy, contrary to scientific/technical development attitude that I can see from time to time in this field (which should in theory be the "bleeding edge" of innovation).
If everyone in the field reasoned by this token, everyone would still be doing hex dumps on screen with debug and write down the hex values by hand. 😯
If you choose to use Caine or WinFE (or anything else) you should be convinced of it's validity, believe that it is the right tool for the task at hand and be ready to defend this choice against possible attacks.
jaclaz
@Francesco
I see what I believe are a couple potentially "dangerous" fallacies in your way of reasonings, far more seriouos than *nix is better than WinFe, no, WinFe is better debate.Fallacy #1
Caine is made in Italy, so it is better.
This, with all due respect is "pure bullshit".
Caine is an exceptionally good platform ) because Nanni Bassetti and the Caine team of Authors/contributors are very good people, very dedicated to the project and managed to put together an excellent product, most of the tools are NOT written by Italians and main contributors such as John Lehr, Maxim Suhanov and Hans-Peter Merkel do not sound particularly "italian".
But I didn't mean better from an absolute POV, better as having your back easily more covered in case another consultant insinuates the copy may have not been done correctly. I believe WinFE to be far less likely to cause changes (though I still have doubts about acquiring the data when older chipsets with horrible drivers are involved).
Fallacy #2
*Caine* (you can replace *Caine* with any other tool) is widely used locally, so I will have less troubles in Court.
This is the same kind of lazy, contrary to scientific/technical development attitude that I can see from time to time in this field (which should in theory be the "bleeding edge" of innovation).
If everyone in the field reasoned by this token, everyone would still be doing hex dumps on screen with debug and write down the hex values by hand. 😯
If you choose to use Caine or WinFE (or anything else) you should be convinced of it's validity, believe that it is the right tool for the task at hand and be ready to defend this choice against possible attacks.
But you cannot be convinced of its validity beforehand. How do you know the system was shut down correctly? That none of the filesystems on the machine are marked as dirty? Or that there isn't a software raid 1 with dead disks just waiting for you to push the power button? I could as well boot grml-testing (that shouldn't be as risky) and start ewfacquire but isn't the fact it's a testing version plus the fact nobody here knows that distro going to sound bad in court? I just believe that the tool reputation/popularity also has to be taken into account and not that DEFT/CAINE should be used no matter what even when they can destroy some relevant data. If there's a chance there might be changes to the evidence ok, better take that in account, but most of the times it's going to be perfectly alright. In the end everything has to be weighted and I think the popularity/reputation have weight as well. Every time I save to RAW/E01 format I cringe but it's not like I go and write a custom bitrot-resistant format just because it would absolutely be the best thing I would be roasted in court in no time.
The first time I saw that "fixing" message I asked another consultant and he told me that in no way it would change the data because it doesn't mount the partitions (pretty much the same answer you'd get almost everywhere), yet I still didn't trust him especially since I knew filesystem access dates were already being changed by other distros. But let's say I stopped using CAINE/DEFT entirely and relied exclusively on WinFE but the adverse party calls another consultant and the judge also calls another consultant and they both say they haven't met WinFE before and can't vouch for its validity, and they both regurgitate the usual "he should have used DEFT/CAINE because they don't alter any of those precious tiny data bits" shouldn't I consider that too? It's not laziness it's just taking more variables into consideration, I just think WinFE would be far more subject to criticisms here compared to DEFT/CAINE.
Of course you have all the rights in the world (plus one) ) to use the tool you feel safer with (actually the one that hypothetically will cause you less practical problems).
The point is merely philosophical and has no connection to the specific Caine or WinFE (which AFAIK/IMHO) are BOTH very good tools and suited to image a disk.
Still, if everyone does like you do, every developer should stop right now to create new tools/devise new approaches, everyone would use a given "approved" or "applauded by a standing ovation" tool, or the one that gets the most "Likes" on it's facebook page or has more followers on Tweeter. 😯
Heck, we are talking of making a dd-like image, you can use DOS debug and save one sector at the time.
The sheer moment you use a batch to repeat for each sector in a disk you expose yourself to some critics, as you have introduced something new that the other party is not familiar with and that may hypothetically be criticized.
Still, if the resulting dd image is an actual unmodified image, and this can be verified, you can stand by it even if the other party is used to a transnuclear-mega-para-hyper-fira-peta-imager on - say - a Cray 1 and believes it is the only way to make a forensic sound image.
If real world worked like that we would still be waiting for a lightning to strike before we could get some fire. (
jaclaz
in no way it would change the data because it doesn't mount the partitions (pretty much the same answer you'd get almost everywhere)
Absolutely wrong answer.
The point is merely philosophical and has no connection to the specific Caine or WinFE (which AFAIK/IMHO) are BOTH very good tools and suited to image a disk.
Indeed I didn't put that in doubt.
Still, if everyone does like you do, every developer should stop right now to create new tools/devise new approaches, everyone would use a given "approved" or "applauded by a standing ovation" tool, or the one that gets the most "Likes" on it's facebook page or has more followers on Tweeter. 😯
But I didn't mean that. When I said that the tool reputation/popularity are to be taken into account I meant that of course within reasonable limits, I didn't mean that it's the only thing that matters. It's not like I want to go and wreck every RAID setup in town just to stick with the most common tool.
If real world worked like that we would still be waiting for a lightning to strike before we could get some fire. (
Everything has to be weighted, I didn't want to sound like one should stick to the most used tool exclusively because it's the most used, but just that you can be damned if you do but also you can be damned if you don't.
BTW If everybody actually did as I do then it would be quite the opposite and the world would be flooded with tools, horrible horrible tools (some of which (disgracefully) already hit this forum 😯 )
Edit Apparently the new Caine (6.0) that came out today fixes the booting issue. And apparently also the text on the wallpaper o .
Everything has to be weighted, I didn't want to sound like one should stick to the most used tool exclusively because it's the most used, but just that you can be damned if you do but also you can be damned if you don't.
Well, you did manage to sound like that.
Possibly it is a nuisance of the English (or how I read it), but you posted this
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. Plus driver nightmares that would basically halve the cases where I could use it (e.g. older machines with SCSI/custom RAID controllers from hell). Does Automount set to 0 truly prevents any write to the drives?
Which means (as said as I read it)
I am holding back from doing something that I would like to do because I am afraid that it will have bad consequences, thus I will continue using the something that all other people around me use commonly as it is safer.
This is an almost exact transliteration of
[Italian]
Chi lascia la via vecchia per la nuova sa quel che lascia ma non quel che trova.
[/Italian]
Which translates roughly (for our English speaking friends) to
http//
The actual English corresponding proverb is even more suitable to the specific
Better the devil you know than the devil you don't know
but it was not among the preferred ones by (say) Newton (disputed ? )
If I had stayed for other people to make my tools and things for me, I had never made anything.
or (say) Galilei
In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual.
jaclaz
Which means (as said as I read it)
I am holding back from doing something that I would like to do because I am afraid that it will have bad consequences, thus I will continue using the something that all other people around me use commonly as it is safer.
(more like "as they think it is safer" 😯 )
Back then I was actually considering making one as a primary replacement to live CDs. But I didn't want to sound like I would absolutely exclude using one if it's required (e.g. special RAID setups/live distros not working/crashing/self-bricking Samsung laptops/etc). The more I think about it the more it sounds like a bad idea though (using it as primary choice), e.g. I remember having tons of troubles with FTK Imager in case of dead sectors on drives. I'm sure those masterfully crafted VIA IDE drivers that scale down to PIO mode in case of read errors are just there waiting for me! 8)