Finding the offset for ext4 partition

There isn't a standard offset per-se, as of course you can start the partition wherever you want. But let's assume for a moment that you're looking for the first partition, and it was created more or less accepting defaults. There are then two places you may find it, assuming you were using a traditional DOS partition table:

1. Starting at (512-byte) sector 63. This was the tradition for a very long time, and worked until someone came up with 4K disks...
2. Starting at (512-byte) sector 2048. This is the new tradition, to accommodate 4K disks.
3. A bonus option! Sarting at sector 56. This is what happens if someone moves the 63-start partition to make it align with a 4K sector.

Now, to proceed, you'll want to pick up your favorite hex-dump tool, and learn a little about the ext4 Disk Layout. In particular, it starts with 1024 bytes of padding, which ext4 ignores. Next comes the superblock. You can recognize the superblock by checking for the magic number 0xEF53 at offset 0x38 (from the superblock start, or 0x438 from the partition start, or 1080 in decimal.) The magic number is little-endian. So it's actually stored on disk as 0x53EF.

Here is what that looks like with xxd -a:

0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ * 0000400: 0040 5d00 0084 7401 33a0 1200 33db a600 .@]...t.3...3... 0000410: 4963 5300 0000 0000 0200 0000 0200 0000 IcS............. 0000420: 0080 0000 0080 0000 0020 0000 6637 0952 ......... ..f7.R 0000430: 6637 0952 0200 1600 53ef 0100 0100 0000 f7.R....S....... 0000440: 9938 f851 004e ed00 0000 0000 0100 0000 .8.Q.N..........

Note, that when you give the offset to mount (or losetup), you must give the offset to where the padding starts—not the superblock.

Now, if its not the first partition, or otherwise isn't in one of the two (three) expected spots, you basically get to search for the magic number 0xEF53. This is what testdisk (recommended in a comment) does for you.

If you can't mount the image you might still be able in some cases to "stream out" some of its data with cpio.

Once you've ascertained whether the image is:

• An image using a supported filesystem and a partition --> mount
• An image using a supported filesystem and more than one partition --> mount with offset, or use dd to extract a partition with offset then mount that partition only or use something like kpartx
• An image not using a supported filesystem or with no filesystem at all --> kernel support and further investigation...

You can use the hexdump and strings utilities to try to analyze the header and to extract text strings from the image and gain more information about the image file and its structure.

Something captured my interest in doing so:

@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF

There's a line like this for every single binary in the image so you somewhat know what's in there. Also, in this case, when you take a closer look at how the installation process occurs on the original platform with installpkg, you find out that:

The basic mechanism to transfer software from a floppy disk to the UNIX System V /386 hard disk is cpio.

Basically, the data is extracted with cpio to /usr/tmp/install and a series of files are included with this (an install, ascii, file, name and size file). It so happens here that this command:

cat U19.IMA | cpio -imdv

outputs malformed number errors to begin with, but then creates a /usr/bin folder with the contents of the image! The tr I was looking for is there:

#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.

Trying cpio in the first place can't hurt!