E01 Image format / tools

If you really want reverse sector order, why not just read the .E01 file in reverse. As with others who have replied, I do not understand the requirement

If you really want reverse sector order, why not just read the .E01 file in reverse. As with others who have replied, I do not understand the requirement

As minime says above. It was due to problematic drives.

You could image a problematic drive normally, but it would get to a certain point, where the drive would become unresponsive.
If that point was near the start of the drive you might be getting say 1% of the drive imaged.
The reverse imaging option allowed people to image forwards, until it hung, then image backwards until it hung.
That meant, instead of getting the 1% of the drive, for example, people could get perhaps 99% of the drive imaged.

use ftk imager as source is image file you can convert image

But the whole thing is a complex mess now and it often isn't even possible to know the real low level disk layout for modern drives as they have layers of virtualisation on them.
https://en.wikipedia.org/wiki/Cylinder-head-sector

OT, but JFYI, a nice article about finding out geometry/layout of disks

http//blog.stuffedcow.net/2019/09/hard-disk-geometry-microbenchmarking/

jaclaz

If you really want reverse sector order, why not just read the .E01 file in reverse. As with others who have replied, I do not understand the requirement

I think the point of my original question has got somewhat lost along the way. This is my fault because when I first asked, I didn't understand the limitations of the E01 format. There may be (rare) occasions when a reverse image is necessary but this is actually not relevant to my question which I think I can answer myself now.

The problem appears to be the limitations of the E01 format itself

1. The image starts at sector zero - You can create an image of either a physical disk or a single partition but the image itself doesn't record the starting sector.

2. It is implicit that the E01 data chunks are stored in ascending order - Although there is a little wriggle room here because although the "tables" section assumes the data chunks are in ascending order they can actually be stored out of order in the "sectors" section (used by more recent imaging tools)

3. The data chunks each represent a fixed sized (typically 32KB) and, whilst they can be compressed, they must all be present. e.g. The E01 format doesn't seem to support any kind of 'sparse' storage. This seems like a huge oversight since many drives will contain a significant amount of unused storage.

I think this "wriggle room" could be used to create a backwards image but would be limited in practice because the E01 file is typically split into segments (e.g. 2GB or 4GB) and each segment has the same assumption that it contains data chunks in ascending order.

Yes, you can workaround this limitation by creating a "DD" image first. Sometimes this may be necessary. No, reading the E01 image backwards misses the point - the question was could the image be created in reverse. Based on the above limitations, I think the answer must now be no it cannot. This has nothing to do with if this technique would be useful or why it may help - rather it boils down to a limitation in the E01 format.

Jim

www.binarymarkup.com

This has nothing to do with if this technique would be useful or why it may help - rather it boils down to a limitation in the E01 format.

Sorry, but I am not following (or I am not understanding) you.

It seems to me like being "out of scope" for the format, or at least I am understanding "limitation" as something that should be there but isn't. ?

The only reason (AFAIK/AFAICU) why you image (with a "plain" dd) in reverse is when - for *whatever reasons* - imaging forward doesnt' work/doesn't proceed (i.e. you have somehow defective media in your hands).

This implies that there are very good chances of missing/unreadable (filled with 00's in the image) sectors, so - provided that the idea of an E01 is to have a hashed (and rehashable) exact, complete, "perfect" image of the source "as is" - it doesn't seem to me like a "limitation".

jaclaz

It seems to me like being "out of scope" for the format, or at least I am understanding "limitation" as something that should be there but isn't. ?

Yes, that is now my understanding. I (wrongly) assumed E01 could be used to directly store a reverse image. After more research, it looks like it cannot because of the inherent assumptions/limitations in the format. These could be worked around by creating a raw image first or by a lot of data processing but underneath the fact remains E01 must store data in ascending sector order and, apparently, does not store the starting sector inside the image. I'm surprised I didn't spot this until now but everyday you learn something new.

Jim

www.binarymarkup.com