Number of pictures ...
 
Notifications
Clear all

Number of pictures misleading, frames aren't picture files.

6 Posts
6 Users
0 Reactions
539 Views
(@yunus)
Estimable Member
Joined: 17 years ago
Posts: 178
Topic starter  

Hello,

We have a case where we must review pictures in a hard drive, so we scanned the hard drive with various software, Encase, FTK and IEF, and IEF suprsingly has found thousands MORE Pictures which is unbelivably higher than the number of pictures found by other forensic software, Encase and FTK.

So, we chose to review the pictures found by the IEF, as we thought it must have recovered more pictures than others. However, as we proceeded with examinations, we saw that thousands of those pictures -on which we had wasted our time revieweing one by one- were not actually deleted pictures but were the frames from existing videos in the hard drive. So what we thought as recovered picture files were not really recovered pictures files and but the frames from already existing AVI files.

That was quite misleading. Actually there has never been those picture files in the hard drive. The number of real picture files in the hard drive is, in fact, much less. And IEF does not give you any note regarding the number number of pictures SHOWN is not the real number of pictures, but a number including the frames from a video files in the hard drive. So we now can conclude that IEF might even show millions of more frames (making us believe that we have recovered such a lot of pictures), if it puts more frequent frames amongst the originally picture files.

So, once again, an examiner should not trust fully on any software and consider such misleading things and not say in their report "I have recovered x number of picture files from the hard drive." Because he actually did not. There has never been that number of picture files in that hard drive.


   
Quote
aeiforensics
(@aeiforensics)
Eminent Member
Joined: 13 years ago
Posts: 27
 

On the frames from videos portion of your posting - were the videos MJPEG compressed?


   
ReplyQuote
jhup
 jhup
(@jhup)
Noble Member
Joined: 16 years ago
Posts: 1442
 

My guess is the allocated space was carved with no sector boundary concern.


   
ReplyQuote
(@mcman)
Estimable Member
Joined: 15 years ago
Posts: 189
 

Just to give it an IEF perspective
IEF (and most carving tools) will carve data based on particular file signatures no matter where the data is found on the image, it doesn’t really matter if it’s part of another file, picture or video if that signature matches, it’s a carved picture from the image. This is why we’re able to carve pictures from within documents or other files. If we did a simple file signature check for each file in the file system or only carved data from unallocated space, we would certainly be missing a lot of pictures from the computer image which could be valuable to an investigation. It’s typically up to the investigator to confirm whether the carved data is valuable to their case or not.

Specifically for the video
Most videos don’t encode their content with these picture signatures but like aeiforensics hinted to, some videos will encode the data in a particular way so that the frames in the video appear to be pictures. Even though they are part of a single video, looking at the raw data, those are all pictures and will likely produce a valid picture file when carved out.

Jamie
jamie(dot)mcquaid(at)magnetforensics(dot)com


   
ReplyQuote
(@anirudhrata)
Active Member
Joined: 10 years ago
Posts: 17
 

IEF carves pictures from the disk based on file signatures. Also if there are any compressed formats (docx,pptx) it expands and then carves out images from them. IEF provides a source location in the description of each image. You can easily check where the image is coming from and also the check it in the hex viewer it is indeed an image on your disk.


   
ReplyQuote
(@mscotgrove)
Prominent Member
Joined: 17 years ago
Posts: 940
 

Looking the source code for my data carving, I can see I trap such JPEGs

If there is a string "AVI" starting at offset 6, then I assume this is part of an AVI video, rather than a stand alone JPEG. I therefore ignore it.

Does this match what you are seeing?


   
ReplyQuote
Share: