Locating images fro...
 
Notifications
Clear all

Locating images from C4All FileOffset/PhysicalLocation info

6 Posts
4 Users
0 Likes
1,119 Views
one234
(@one234)
Posts: 16
Active Member
Topic starter
 

Hi everyone,

I am reasonably new to the industry and and coming across my first C4All reports. However I'm encountering big headaches and hopefully I could find some help from the community of experts here.

For this IIOC case I'm working on I received a C4All/C4P image report from the opposition team. Since almost all the images were recovered from unallocated clusters, there's only the 'File Offset' and 'Physical Location' information listed with each image.

As I understand (correct me if I'm wrong!) the 'Physical Location' refers to the start of the cluster in which the image is contained, so I went for the 'File Offset' instead. I did a bit of research on the net and understood in order to obtain the sector in which a file is stored I divide the File Offset value by the sector size (i.e. 512 in my case). I followed this method and attempted looking for this physical sector using the 'disk view' in EnCase (v6.19.4 I'm using), and here the problem comes, the physical sector does not contain the image I'm after!

I believe this has to be something I didn't do right, and therefore may I ask for your kind help to direct me on finding images identified in C4All reports in EnCase, using 'File Offset' and 'Physical Location' values.

Thank you so much in advance!!

 
Posted : 04/03/2015 2:35 am
PaulSanderson
(@paulsanderson)
Posts: 651
Honorable Member
 

Forensic software usualy considers unallocated to a be a very large very fragmented file and the file offset will be an offste into this file. There are a number of ways of determining what is unallocated space (use the volume bitmap/calculate yourself etc.) so it may be that your software calculates unallocated in a different way than their software.

Is there no one in your organisation that can help with this?

 
Posted : 04/03/2015 2:50 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

Big caveat - this is all off the top of my head so I haven't verified it - sorry if it's total bunk. I am also assuming that you are talking about C4All v1.x.

In C4All, "File Offset", as I remember it, refers to the offset where the image starts. This is from the start of the "file" in question, not from the start of the disk (which is where I think you went wrong). The "Physical Location" refers to the physical sector where the "file" starts.

EnCase regards unallocated clusters (UC) as a file of sorts (in fact it's an entry, but..), so the "file offset" value is from the start of this UC entry. Bear in mind that UC is a roll up of all the relevant clusters on the volume, so it is not neccessarily contiguous - this means you won't be able to find the first cluster in UC, go to disk view, and count sectors to get your result. Instead you will need to select UC, and ensure your cursor is at the start of it (SO 000 FO 0) - like this

Then right-click on the view pane, choose "Go to..", and enter your file offset in the "Other" box. Like this

You should then find the start of your image.

Out of interest - as you have the c4all files, can you not re-import them into EnCase directly? From the "Data Migration" menu? Or if you don't have the files, is it possible to request the caseref.c4p5 file from the "opposition"? How many images are you talking about (roughly)? Because if you have a PDF with 5000 images and you're having to manually verify each one, you're going to have a bad time. ?

 
Posted : 04/03/2015 2:54 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Though I have NO idea how C4All (or Encase for that matters) notates addresses, more generally you have to consider how the offset to a cluster is NOT an "absolute" address, but rather a "relative" address from the start of the volume (and not of the disk).

If you prefer, you can move a volume "as is" from one absolute start sector to another changing just the "sectors before" in the bootsector (or likely being NTFS in the $Boot file).

As an example in NTFS Cluster n will be at "absolute" disk sector address

n*sectors_per_cluster+offset_in_sectors_to_volume

and in bytes
(n*sectors_per_cluster+offset_in_sectors_to_volume)*bytes/sector

On common NTFS volumes the $MFT is on cluster 786432 (which someone will probably like to consider being 0x0C0000 wink ), and when using the most common 4096 bytes/cluster size and 512 bytes/sector size (i.e. 8 sectors per cluster) you would have for the first volume created on a Vista or later OS at 0/32/33 or LBA 2048
Absolute offset in sectors=786432*8+2048=6293504
Absolute offset in bytes=(786432*8+2048)*512=6293504*512=3222274048

Maybe that is where the issue is. ?

jaclaz

 
Posted : 04/03/2015 5:36 pm
one234
(@one234)
Posts: 16
Active Member
Topic starter
 

Thank you Paul, Chris and Jaclaz for your explanation!!

Chris - So I tried selecting the unallocated cluster in EnCase first then 'go to' the File Offset, but unfortunately I still don't find the image in question -/ I did see some JFIF file headers near the location of the File Offset but when I select it, I still don't see the image..

I only have the PDF with 300 odd images at the moment but then I think it is a very good idea to request the working file if they can be imported into EnCase directly, that'll surely save me a lot of time!

However it is comforting to know that different software determines unallocated space differently so I guess it could be a possibility as to why a valid method on one cannot be followed and repeated on another.

Paul - It happens that I'm working for a very small company so no one else can help me with this -\ I'm very grateful there are industry experts on this forum like yourself and others who are willing to give a hand, when my own research doesn't lead me anywhere.

Jaclaz - valuable information! I'm yet to try this, will let you know if I succeed, however I hope I won't have to do this calculation for 300+ images..! > <

Thank you all again, your information is very much appreciated!!

 
Posted : 05/03/2015 4:00 am
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

OK there are two things to bear in mind here.

1) UC (in EnCase 6) can change.
2) File Offset is a relative value.

Point 1 might suprise you, but it's true - and it can sometimes change in unexpected ways. And because point 1 is true, it means that relying on file offset is somewhat unpredictable.

I have a test HDD here which has the following values for UC (click me to see the full size)

That's size, Physical Location, and Physical Sector respectively. This is the "unadulterated" drive, with no processing undertaken thus far.
At File Offset 7037716912 we have the following critical case data

MAX-AGE=30! Oh man, what amazing evidence.

By running the "Recover Folders" option, these values for UC change. They are now as follows (click me to see the full size)

As you can see, there is a big difference. (I am pretty sure that something weird has gone on, since EnCase is reporting UC to start at sector 8 - which is outside the boundaries of that partition).

I check for my critical evidence at File Offset 7037716912 at what do I find?

It's no longer there! Aw, shucks.

In conclusion if you have used EnCase v6 to record that data resides in UC, but only provided the Physical Location and File Offset, you might be in for some chop later.


What does this mean for you?

Essentially, unless you have the original .case file then it will be difficult for you to pinpoint the exact location of the images in question. Personally I think that you might have problems getting that, as folks can be cagey. BUT you are perfectly entitled to ask for the contemporaneous notes made by the analyst in question, so you should be able to see step-by-step what happened.
Alternatively, try running Recover Folders and check the file offset again.

 
Posted : 05/03/2015 3:37 pm
Share: