Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have two disks. They're both bootable and run Linux. When I physically mount the disks, I can see scsi devices get added. /dev/sdb and /dev/sdc. However the partitions are not detected. I can't see for example /dev/sdb1. It seems like someone has gone into a lot of effort to hide the partitons but I don't know how.

I've tried using testdisk and it detects 2 partitons on each disk, but I know there are more than that. The partitions found are quite useless and I know there must be a boot partition. I've tried changing the disk geometry but this hasn't helped.

How can I work out how they've been hidden and any suggestions on how to unhide them so that we can mount those other partitons?

EDIT: This is what is displayed during boot:

Mar 27 12:44:11 (none) user.notice kernel: sd 0:0:0:0: [sda] 8388608 512-byte hardware sectors (4295 MB)
Mar 27 12:44:11 (none) user.notice kernel: sd 0:0:0:0: [sda] Write Protect is off
Mar 27 12:44:11 (none) user.debug kernel: sd 0:0:0:0: [sda] Mode Sense: 61 00 00 00
Mar 27 12:44:11 (none) user.notice kernel: sd 0:0:0:0: [sda] Cache data unavailable
Mar 27 12:44:11 (none) user.err kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
Mar 27 12:44:11 (none) user.info kernel:  sda:
Mar 27 12:44:11 (none) user.warn kernel: custom_partition sda: partition 4 exceeds device capacity using largest possible size reduced from 5120000 to 4259840
Mar 27 12:44:11 (none) user.notice kernel: sd 0:0:1:0: [sdb] 167772160 512-byte hardware sectors (85899 MB)
Mar 27 12:44:11 (none) user.notice kernel: sd 0:0:1:0: [sdb] Write Protect is off
Mar 27 12:44:11 (none) user.debug kernel: sd 0:0:1:0: [sdb] Mode Sense: 61 00 00 00
Mar 27 12:44:11 (none) user.notice kernel: sd 0:0:1:0: [sdb] Cache data unavailable
Mar 27 12:44:11 (none) user.err kernel: sd 0:0:1:0: [sdb] Assuming drive cache: write through
Mar 27 12:44:11 (none) user.info kernel:  sdb: unknown partition table
Mar 27 12:44:11 (none) user.info kernel: kjournald starting.  Commit interval 5 seconds
Mar 27 12:44:11 (none) user.info kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 27 12:44:11 (none) user.info kernel: kjournald starting.  Commit interval 5 seconds
Mar 27 12:44:11 (none) user.info kernel: EXT3 FS on loop1, internal journal
Mar 27 12:44:11 (none) user.info kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 27 12:44:11 (none) user.warn kernel: Clocksource tsc unstable (delta = 607842230 ns)
Mar 27 12:44:11 (none) user.info kernel: kjournald starting.  Commit interval 5 seconds
Mar 27 12:44:11 (none) user.info kernel: EXT3 FS on sda4, internal journal
Mar 27 12:44:11 (none) user.info kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 27 12:44:11 (none) user.info kernel: Adding 1048568k swap on /dev/swap.  Priority:-1 extents:1 across:1048568k
Mar 27 12:44:11 (none) user.info kernel: kjournald starting.  Commit interval 5 seconds
Mar 27 12:44:11 (none) user.info kernel: EXT3 FS on sdb2, internal journal
Mar 27 12:44:11 (none) user.info kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 27 12:44:11 (none) user.info kernel: EXT3 FS on dm-0, internal journal
share|improve this question
1  
From the output you've got, the partition table on sda is valid, it's just the partition it describes is too big for the disk. This can happen with RAID volumes. I'm not sure how the partition table is invalid on sdb, yet sdb2 has been detected as ext3. Scary! –  user2213 Apr 4 '13 at 21:37
    
How is this even possible?! Does the loop1 indicate some sort of encryption using the system loop device? –  Mike Apr 4 '13 at 22:11
    
unix.SE closed the post over there, so we can keep it. –  Rory Alsop Apr 5 '13 at 14:46

1 Answer 1

up vote 7 down vote accepted

How can I work out how they've been hidden

Hiding partitions is actually relatively straightforward. First up, some theory.

Your disk is a big bunch of memory addresses as far as the operating system knows - we call this LBA addressing. Ignore everything your read about CHS unless you're dealing with XP and earlier - modern hard disks do not come with cylinders, heads and sectors although they do come with some strange compatibility support for people who want CHS values.

Now, on this big empty space you need to decide how to lay out your data. You do this by having a partition table - that is, a known area of the disk that holds data describing your partitions. There are two schemes in use in most consumer PCs - MBR partitions and GPT ones. MBR stands for the master boot record and everything, the code needed to launch the OS and the partition table, lives in the first 512 bytes. Wikipedia describes the format as it goes for GPT partition schemes.

Things can get more complicated. As you are no doubt aware, MBR limits you to four partitions per disk, which is how logical volumes were born. Logical volumes are basically another type of partitioning scheme inside one of your four MBR partitions. Of course, when I say "logical volumes" I could mean logical volumes from Microsoft, LVM as part of the Linux Kernel and so on. These schemes are unnecessary (but LVM can and might be used) on GPT disks because these support unlimited partitions, or if you are on Windows, an arbitrary 128-partition limit. Mind you, you can't have that many drive letters in Windows anyhow.

So back to your question: how do you hide a partition? Two ways, as far as Linux is concerned:

  • remove the entry from the partition table by supplying a null entry where the partition should have been.
  • fill up the partition table, but don't fill up the disk. Allocate the new partition in the free space.

These two have the same on disk result - they're just different in the order of events that are needed to make them happen.

and any suggestions on how to unhide them so that we can mount those other partitons?

The most obvious way would be to re-write the partition table entries for these partitions. You can then run kpartx -l to see what would be mounted and kpartx -a to trigger a re-evaluation.

However, editing partition tables is a bit of a fraught process unless you're really happy totally breaking things and I'm not sure I'd recommend it. Luckily the Linux kernel has an awesome trick called device mapper.

The sole purpose of device mapper is to take one or more block devices and map them in some defined way to produce a virtual block device. Long story short, you can use device mapper to say "map from my hard disk starting at block 1000 and ending at block 2000 this new block device". Then the resultant device is a 1000 block device which maps back to the original device but can be used as a block device in its own right - containing a filesystem! If you're familiar with loopback devices, the trick is quite similar.

To create such a mapping, simply do:

dmsetup create mappingname --table "0 2048000 linear /dev/sdx 0"

where 0 2048000 represents the starting block and ending block this "window" creates on device /dev/sdx. If this succeeds, you should have a block device /dev/mapper/mappingname. You can find the documentation for this as part of the Linux kernel.

As an aside because I can't help myself, "fake" RAID cards on Linux works in exactly this way. The command dmraid -ay analyses your attached disks for RAID card metadata and creates the appropriate device mapper mappings.

It seems like someone has gone into a lot of effort to hide the partitons but I don't know how.

Now, the ultimate crux of the issue is that whatever you do, you need to know where the partition is on the disk. Most filesystems have recognisable super-block structures. NTFS for example begins with a BIOS parameter block and various other metadata - you can see this here. Ex4 has a superblock with various magic values. Repeat for just about every file system out there.

How you go about finding partitions matching a given set of file systems - well, I would have hoped TestDisk would have identified the metadata. Failing that, you could write something yourself.

An encrypted volume may be more problematic. Depending on the software in use, there may be no magic value that indicates a file system at all - indeed, it may be indistinguishable from the random junk also on the disk and abandoned by legitimate file systems. The only hope you have in this case is that the disk has not ever been repartitioned and there are still identifiable "empty zones" between the valid partition ending and the encrypted partition beginning.

At this point, you've exhausted my personal knowledge. It looks very much like you may need to write some custom scripts/tools to parse your disk (image) to find what you need, identify the range and then map the volume. There may be users here who have more experience of forensics and can point you at existing tools, so I'd be tempted to hang around and wait to see if any materialize.


Disclaimer: I work in disk imaging and recently happen to have upgraded our Linux environment to support fake RAID cards. Oh and LVM too.

share|improve this answer
    
A fantastic answer. And I, too, am curious to see whether any forensics people materialize out of the ether to share their expertise... –  root Apr 5 '13 at 14:17
    
A fantastic answer. Thank you for that. I've actually figured out that that hard drives have been encrypted with cryptsetup. –  Mike Apr 11 '13 at 5:28
    
@Mike excellent, glad you found out what the scheme was :) –  user2213 Apr 11 '13 at 8:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.