OSForensics can search multiple E01s for files, by file name, without any pre-processing.
(Use the "File Name Search" module)
Thank you, but could you describe how?
I open the "File name search" , but as far as I can tell it can only search mounted drives/partitions and not .e01 files directly without mounting them? Or am I missing something?
I can off-course mount the .e01 as drives and then search, but would like a more elegante solution. (PS: the task that originated the question is solved, ended up mounting one-by-one and search, but would be nice to know how for the future)
could you describe how?
In OSForensics V8 / V9
1) In "Add Device" window. Add all the E01 images. This is a one off manually step, but should only take 10 second per image file.Â
2) In "File Name Search" window, click on Config and select the disk images / folders you want to search. "Add" each one to list of directories. Again it is manual, but only ~5sec per drive.
3) Back in "File Name Search" window, do your searches by file name. If your backing storage for the disk images is a local SSD, then each disk image should take around 20 sec to search. If your backing storage is something like a remote NAS, then it will be slower.
If the initial manual setup in Step 1 was a big issue, contact us, it would be fairly trivial to add a Python API command to add devices.
Not also that you don't need to mount them as Window's drives with drive letters. This is possible, but not required and would take longer. You'd probably also run out of drive letters.
You'd probably also run out of drive letters.
... unless you use mount points, instead, of course.
 BTW, though surely having the volumes mounted to mountpoints in a NTFS directory will be slower than interpreting/parsing them "directly", it should allow to use *any* search tool as to the OS all mounted volumes will appear as a number of sub-directories on a same volume, even a simple DIR /S or a DIR /S| FIND "name.ext" should work just fine (though the latter would probably take forever with no progress bar of sorts.
jaclaz
even a simple DIR /S should work just fine.
Sometimes it might. But generally it won't. The main problems are 1) you won't have permission to view many folders for the newly added drives (and setting read permissions means being Admin and writing to the drive). 2) Some files are permanently hidden from the user if you are using the Windows Win32 API to read the files, which is what DIR /S does. 3) External tools, like DIR can only deal with FAT & NTFS file systems. So if the E01 is using HPFS, EXT3, etc.. it won't work.
So the direct access method is preferred as it avoids all of these issues.
even a simple DIR /S should work just fine.
Sometimes it might. But generally it won't. The main problems are 1) you won't have permission to view many folders for the newly added drives (and setting read permissions means being Admin and writing to the drive). 2) Some files are permanently hidden from the user if you are using the Windows Win32 API to read the files, which is what DIR /S does. 3) External tools, like DIR can only deal with FAT & NTFS file systems. So if the E01 is using HPFS, EXT3, etc.. it won't work.
So the direct access method is preferred as it avoids all of these issues.
Yep, that is essentially the reason for the "even" and "should".
On the other hand, and limited to NTFS ONLY, a search tool that directly parses the $MFT, as an example SwiftSearch:
https://sourceforge.net/projects/swiftsearch/?source=dlp
will probably run circles around any other common "file listing" or "file searching" tool.
As always, it depends, and while a good, dedicated tool like OSForensics has obviously more/better capabilities than "generic" tools, sometimes you can get what you need/want with "normal" tools.
As someone else earlier suggested, however, (and of course IMHO) Â the "right" approach (no matter the tool actually used) in this specific case:
I've got multiple .e01 images in a case (bunch of usb sticks, hdd, sdcard, ++), and we are looking for a specific file that we know the filename to.
is NOT:
1) mount all images
2) search all images
But rather:
1) automate the mounting of the images one at the time from a list
2) search in the single currently mounted image
3) if desired result is reached exit, otherwise mount next image and loop to #2
that is if you need to find only first instance of that file (as opposed to find ALL devices to which the specific file is stored, i.e. all multiple copies of it), on average you will need to mount and search only half of the images, and (again it depends) you might have some "more probable" images that you can put early in the list.
Â
jaclaz
Â
Get a Linux box, mount them as drives (see here) and use the find command.
Quick, effective and free...
Sorry - didn't read the final response in this chain before answering.
Iterating over a list is a fairly common programming task and I'm sure that you can find a good example of iterating over files in any language you see fit. There will be slight complications if there are multiple partitions per image - as per the second part of the link that I sent first - however, you could still address this in a script. If you create mount directories in line with the image &/or partition names, you'll easily be able to identify which image the file has been found in.
After that, I wouldn't bother creating an index - you know the file name, so once all the images are mounted you can do:
find /search_mount_directory/ -name "mysuspectfile.txt"Â
Linux will do the rest - it would print results listing the directory that it has been found in, and, if you've named them correctly this will show you which image &/or partition it is from.
Â
Â
Running updatedb to generate an index:
- Eliminates the need to write a script
- Fast multiple searches
- Case free searches
- Wild card searches
Using locate.
A perfect I know the one thing I want right down to exact name and case without error is rare enough that an index is almost always the way to go.
I thought I made a mistake once, but I was wrong.
You could use iped and do a fast process in ALL e01.
@flyingdingy it is incorrect to say that you need to process your case first in EnCase before you can search. How you search is very much dependent on what you are searching and what you are search for. In EnCase, you can perform a RAW search, which is to search the data as it sits in clusters. This requires no processing. You can select and index your data, for this you do process the case. Regardless of which option you choose, it can be done on single or multiple evidence or on single or multiple files.