Block index out of bounds

The error suggests you do not have the correct combination of EWF file 'parts'. You allude that there are 'several E01 files in several folders', do they all have the file extension E01?

If it is a 'part' of a larger set (with other files of extension E02, E03, E04) they will all need to be present in the same 'area' (i.e. folder) to load.

You also mention this is an image of a HDD? What is the original capacity of the imaged HDD and how big is the E01? This may indicate if this is a part of an EWF set (i.e. 320GB HDD and 1 2GB EWF file) or if there may be potentially something wrong with the image (i.e. 320GB HDD and 120GB of EWF parts).

A little more info may help diagnose fixes.

Rgds and good luck

Shep

Explicate?

T…

You also mention this is an image of a HDD? What is the original capacity of the imaged HDD and how big is the E01? This may indicate if this is a part of an EWF set (i.e. 320GB HDD and 1 2GB EWF file) or if there may be potentially something wrong with the image (i.e. 320GB HDD and 120GB of EWF parts).

…

I've been sent a hard drive for analysis. The content of the hard drive is several folders, each folder contains an .e01 image.

That is, you have multiple image files for a single hard drive? Sounds odd. Unless you have separate images of each partition.

Me, I'd ask the sender for clarification.

None of the images are mountable in FTK or Encase, instead an error pops up when trying to mount them "Please select a valid image file"

And how did you receive these files? On a disk? If EnCase doesn't accept them as images, they probably have been damaged.

When trying to export the images, they each result in a message that says "(filepath) Block index out of bounds."[.quote]

Don't understand. How can you export anything if EnCase etc won't accept the images in the first place? Export what from where?

Are the image files on a hard drive? Is *that* hard drive damaged? Run whatever file system checking program you have – fsck or chkdsk or … – before you try anything else.

Does anyone have suggestions for how to fix this without the original drives? Is it possible to hexedit in the correct drive size into the e01 (assuming that is the cause of the issue)?

First determine what the problem is. You need the sender to provide you with an inventory, and preferably separate hash sums of each of those files you have. If they don't match …

Alternatively, return the images you can't read them, so there's something wrong. Could be the sender messed his end of the business up. (Can you verify that the .exx files are EWF files – use file(1) or something?)

ill try to be more clear…

I was sent a hard drive for analysis.

Hard drive contains 3 folders,

Folder A Contains ImageA.e01, ImageA.e02, all the way up through ImageA.e26.
Folder B Contains ImageB.e01, ImageB.e02, all the way through ImageB.FBY (.e01 incremental extension naming gets interesting when making large images, the source of this one was 2TB).
Folder C Contains ImageC.e01, ImageC.e02, all the way through ImageC.FBR (see above, another 2TB image).

So there are 3 "images" on this hard drive, each one composed of your normal .e01 type incremental files.

When attaching the hard drive and viewing its contents with FTK Imager or Encase Imager, none of the images are mountable. When trying to export them (right clicking a .e01, .e02, or the directories they are in and selection export), I get the "Block Index out of bounds" error.

I was eventually able to logically copy out (numerous failed attempts using windows explorer) all of Folder B, the contents of which now mount properly.

In the case of Folder A, I am able to logically copy out all but the first file. That is, I can copy out ImageA.e02 through ImageA.e26, but ImageA.e01 will not copy out.

In the case of Folder C, I am only able to logically copy out the earlier of the contents. That is, I can copy out ImageC.e01 througn ImageC.EOU, but ImageC.EOV through ImageC.FBR will not copy out.

I understand that I need all of ImageA.e01 through ImageA.e26, to mount ImageA. What I am saying is, FTK and Encase aren't reading the first image file of ImageA (that being ImageA.e01), so I cant mount it. Same for ImageC but with many more of the files (ImageC.EOV through ImageC.FBR).

I am thinking this is because either
- The original drives these images were taken from were failing at the time
- The hard drive these images were written too may have been damaged in transit, causing some of the files that are on there to not be readable
- Some of the image files may be "corrupt" (which could really just be a result of the previous statement).

I likely cannot return the images or request new ones. They are from an out of country LE Agency and it is likely that the items they imaged for our organization either no longer exist or have been significantly changed given the time that has elapsed since they were taken, so I am trying to make the best of what I have.

I will post the results of –fsck or chkdsk when it completes to try to narrow down if the hard drive the images reside on is the problem, but even if it is, I still have to exhaust all possibilities for getting these items off the drive.

I am wondering if it is possible to repair partial .e01 files. If I toss the files that can't be copied out through windows explorer or exported from FTK/Encase Imager into a hex editor, their is some data in there. Example ImageA.e01 is missing 00000000 through, say, 02a70000. So no header, and whatever the earliest contents of that file would be.

What directions could I take this?

Adding the header back on? I would think that the large amount of missing information after the header would still result in failure.
Data carving? I think that because these are .e01 type images, that I can't data carve (have to have the whole set together and working to mount them, right, cant parse and data carve the encrypted .e01 format).
LibEWF? I am not very familiar with this tool but it looks to have some interesting capability.

Hmmm, you said
numerous failed attempts using windows explorer
copy out all but the first file.
I am only able to logically copy out the earlier of the contents.

The original disk failing would result in a complete set of E01 files with parts inside the E01 with all zero's. The only reason you see this kind of errors is the disk which contains the evidence files is corrupt.
Repairing information on a broken disk, I dont think thats the way to go. You need a new copy.
Run a diskchecking program on that disk, have a look at smart errors etc