Search multiple .e0...
 
Notifications
Clear all

Search multiple .e01 images for specific file.

Page 1 / 2
flyingdingy
(@flyingdingy)
New Member

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 it possible to search for the file in multiple .e01 acquisitions/images at once without having to open one at a time?

Quote
Topic starter Posted : 22/04/2021 11:36 am
Thomas
(@thomas)
Member

As far as I know you can mount multiple images in FTK imager. But you still have to mount them seperately, and the number of images is limited to the available letters. However, this gives you the opportunitiy to search through all of them at once.

Maybe its better to write a simple script that mounts an image, reads (and indexes and if possible makes a hash of each file) and searches for the specific file(s). When completed the script goes to the next .e01 image, etc.

 

ReplyQuote
Posted : 23/04/2021 7:49 pm
minime2k9
(@minime2k9)
Active Member

I suspect, based on your question, that you are using freely available tools?

If so, maybe try autopsy which will allow you to create a case and add multiple images to it.

If you are using commercial tools, many of them allow you to all multiple image files to a single case; X-Ways, Blacklight, FTK etc.

ReplyQuote
Posted : 24/04/2021 7:10 am
flyingdingy
(@flyingdingy)
New Member

Thanks for reply guys!

I do have access to some commercial tools, Magnet Axiom, FTK, blacklight, autopsy, encase, and so forth.

The problem with all of them is that it needs to process before any search can be done, I have yet to find any good way to only process the file tree.

It might be like Thomas said that the best method would be to create a script using ewfmount or similar, but I must admit that I am not sure how I would go about to make that script auto mount next .e01 in a different folder and index all the files.

Lets say I am in the root folder of the case, and all the evidence is listed in their own directory. So the path is /casenumber/evidencenr/image/***.e01

What I am trying to do is to index/search all the .e01 in the subfolders of /casenumber/ to find these specified filenames. (no hashes)

ReplyQuote
Topic starter Posted : 26/04/2021 12:36 pm
azrael
(@azrael)
Senior Member

Get a Linux box, mount them as drives (see here) and use the find command.

Quick, effective and free...

ReplyQuote
Posted : 26/04/2021 1:31 pm
azrael
(@azrael)
Senior Member
Posted by: @azrael

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.

 

 

ReplyQuote
Posted : 26/04/2021 1:43 pm
hommy0
(@hommy0)
Member

Hi,

 

EnCase does not need to be processed before a search can be conducted.  With all the evidence files loaded in Entries view, you can blue check select those files of interest and use the RAW Search option that will become enabled.  The Raw Search also provides the option of GREP.

As mentioned blue check a single file, a folder, multiple folders or the complete evidence file to perform the Raw Search.

The Raw Search will have limited success with compressed document types such as DOCX and PDF (hence why processing is suggested).

Alternatively the following EnScript provides the option to select the files of interest from your evidence, the option is then to do a Raw Search as before or a Transcript Search.

The Transcript Search will allow for searching of content in compressed document types such as DOCX and PDF

https://security.opentext.com/appDetails/Keyword-Search-with-Range-Bookmarking

Processing is there to be used (and with the release of 21.2 I see OCR has been added).

However this is not always practicable, hence the above options for Raw Search or using the EnScript, means a search in real time of your selected files of interest - no pre-processing required.

 

However if you want to use the index and process, you can create a Logical Evidence File of your selection, or create a Result Set.  Both of these can contain a much smaller sub-set of data from your E01's and they can both be processed - and thus indexed.

 

Hope that helps a little

 

Regards

ReplyQuote
Posted : 30/04/2021 10:08 am
JerryW
(@jerryw)
Member

"The problem with all of them is that it needs to process before any search can be done, I have yet to find any good way to only process the file tree."

Are you only trying to find the file then? If so, can you not just add all the E01 files in to Encase and sort all by filename? That would also identify link files to the target file

If you are trying to find whether there are any traces of that file, such as within system files then you will need to do some indexing/processing.

ReplyQuote
Posted : 30/04/2021 4:34 pm
Passmark
(@passmark)
Active Member

OSForensics can search multiple E01s for files, by file name, without any pre-processing.

(Use the "File Name Search" module)

ReplyQuote
Posted : 02/05/2021 10:50 am
hommy0
(@hommy0)
Member
Posted by: @flyingdingy

 

What I am trying to do is to index/search all the .e01 in the subfolders of /casenumber/ to find these specified filenames. (no hashes)

Forgot to mention, EnCase has default conditions that allow searching for filenames - or virtually any metadata that you can see on the table.

You can find them in the lower 4th pane.  

Again no pre-processing is required to use a condition, and can run them against multiple E01’s

ReplyQuote
Posted : 02/05/2021 6:25 pm
flyingdingy
(@flyingdingy)
New Member
Posted by: @passmark

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)

ReplyQuote
Topic starter Posted : 16/06/2021 12:58 pm
Passmark
(@passmark)
Active Member

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.

ReplyQuote
Posted : 17/06/2021 3:35 am
jaclaz
(@jaclaz)
Community Legend
Posted by: @passmark

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

ReplyQuote
Posted : 17/06/2021 7:44 am
Passmark
(@passmark)
Active Member
Posted by: @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.

ReplyQuote
Posted : 17/06/2021 8:00 am
jaclaz
(@jaclaz)
Community Legend
Posted by: @passmark
Posted by: @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.

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

 

ReplyQuote
Posted : 18/06/2021 9:08 am
Page 1 / 2
Share: