"Let us know if you test it out, and how the two compares!"
Here is a comparison in French
http//
English summary of that comparison
TCHunt is 10 times faster and found 100% of the test TrueCrypt volumes. The other tool only found 83% of the volumes and was much slower.
Disclaimer. I am not associated with the folks who did that comparison, but I am the primary researcher behind TCHunt. While TCHunt is not open source, we do publicly disclose our methodology… because of that, you'll probably see a lot of tools start doing this sort of thing.
Thanks TCHunt.
Are you a representative of TCHunt?
Is your commercial product capable of searching through image files (raw, dd, E01, etc.)?
Looking at your methodology, spreading sufficient amount of fake files could be a detriment to the search. (div 512 block size, no header, sufficient size)
How do you define "header"?
In my "check" your product hit several .vdf and .bin files from UBCD4Win as potential.
"Are you a representative of TCHunt?"
I'm the primary researcher at 16 Systems. We wrote TCHunt. We're a small R&D company. We have no commercial products available to the general public.
Yes, using dd with input from /dev/urandom (for example) to create a lot of random files would make TCHunt less useful. By default, dd creates files that are modulo 512 and /dev/urandom produces data that easily passes chi square testing.
However, files with this sort of content really stand out and are not normally found on average end use systems en mass. So, unless you are a researcher in Mathematics, Physics, etc. or you use encryption tools you probably won't have a good explanation for these files. And trying to explain them away only creates more issues.
How do you define "header"?
What capabilities are you planning to build into the commercial product?
I ran TCHunt, and it returned 20 hits on my regular drive (120GB).
Not one of them was real encrypted file.
I think the problem, at least for me, is the false positives are still too high for forensic work.
If I was working on a case, 2-3 x 80GB drives with even 10 hits on each, is enormous drain on the already thin resources.
FYI, I purchased the registered version of FI Tools and found that it was limited to 30,000 entries. I haven't confirmed if this is scanned entries or recovered entries. When I tried to limit the file types to Encrypted (headerless), it crashed with a memory error, twice, on Windows 2003 64-bit.
I plan to attempt the same thing on 32-bit Windows and will report back when I do.
Given the number of false positives I wonder if a file flagged as encrypted by TCHunt can then be taken to Court and based on the TCHunt results shown beyond reasonable doubt that the file was encrypted with Truecrypt. I think not…
Just so we can help TCHunt - here are some of the files that came back as a possible hit
4 C/UBCD4Win/BartPE/PROGRAMS/AntiVir/antivir0.vdf
5 C/UBCD4Win/BartPE/PROGRAMS/AntiVir/antivir1.vdf
6 C/UBCD4Win/BartPE/PROGRAMS/AntiVir/antivir2.vdf
7 C/UBCD4Win/BartPE/PROGRAMS/AntiVir/antivir3.vdf
8 C/UBCD4Win/plugin/AntiVirus/Antivir9/files/antivir0.vdf
9 C/UBCD4Win/plugin/AntiVirus/Antivir9/files/antivir1.vdf
10 C/UBCD4Win/plugin/AntiVirus/Antivir9/files/antivir2.vdf
11 C/UBCD4Win/plugin/AntiVirus/Antivir9/files/antivir3.vdf
12 C/WINDOWS/system32/dllcache/oembios.bin
13 C/WINDOWS/system32/oembios.bin
Nothing weird or esoteric.
Entries 12 and 13 on that list are indeed encrypted. Not TrueCrypt encrypted, mind you, but they are encrypted nonetheless… in this case by Microsoft and/or one of their partners (Dell, HP, etc) I suspect the other files on that list are as well. When the content of a file passes chi square testing, there are only two possibilities
1. Random file.
2. Encrypted file.
False positives can be ruled out. Have a look at a few of those file in a hex editor. What do they look like?
How do you define "header"?
What capabilities are you planning to build into the commercial product?
I haven't had the chance to look at the bins just yet, but it is possible they are encrypted.
Beginning of the first 3 files on the listVirus Database File
Version 7.1.0.0
FUP 0
License date 27.10.2008
VDF date 27.10.2008
Minimum engine 7.5.0.1
Signatures 992796
Virus Database File
Version 7.1.2.12
FUP 0
License date 11.2.2009
VDF date 11.2.2009
Minimum engine 7.5.0.1
Signatures 1240990
Required linked VDF 7.1.0.0
Source 7.1.2.11
Compiler 1.4.0.2
Virus Database File
Version 7.1.3.63
FUP 0
License date 16.4.2009
VDF date 16.4.2009
Minimum engine 7.5.0.1
Signatures 1355388
Required linked VDF 7.1.2.12
Source 7.1.3.62
Compiler 1.4.0.2
indeed oembios.bin is "encrypted".
It is 100 hash blocks each 131072 bytes long, for the Windows Genuine Advantage OEM version licenses. It should be present on all Windows machines which runs OEM MS OS.
Technically speaking you are correct, it is "random" or "encrypted".
I cannot make up my mind if the tool should, or should not exclude this, or at least help the user by marking it "known" entity…
Here is a reference just in case - there are some interesting things in there
http//