imagemounter
imagemounter copied to clipboard
Error when LVM is Inside LUKS
I get an error when LVM is inside an encrypted LUKS partition. It tries to determine the decrypted LUKS file system type instead of the logical volume. This is on version 3.1.0.
# imount -vvvv --fstypes 6=luks /media/veracrypt1/forensics/test.E01
[ snip ]
[+] Found allocated : block offset: 3123200, length: 973649935
Initializing volume 6:-
[+] Mounting volume 6:-
$ fsstat /tmp/image_mounter_uek4ki6g/ewf1 -o 3123200
$ losetup -f
< /dev/loop0
$ losetup -r -o 1599078400 --sizelimit 498508766720 /dev/loop0 /tmp/image_mounter_uek4ki6g/ewf1
$ cryptsetup isLuks /dev/loop0
[-] No key material provided for 6:-
$ cryptsetup -r luksOpen /dev/loop0 image_mounter_luks_39596
Enter passphrase for /tmp/image_mounter_uek4ki6g/ewf1:
$ cryptsetup status image_mounter_luks_39596
< /dev/mapper/image_mounter_luks_39596 is active.
< type: LUKS2
< cipher: aes-xts-plain64
< keysize: 512 bits
< key location: keyring
< device: /dev/loop0
< loop: /tmp/image_mounter_uek4ki6g/ewf1
< sector size: 512
< offset: 32768 sectors
< size: 973617167 sectors
< mode: readonly
Initializing volume 6.0:LUKS Volume
[+] Mounting volume 6.0:LUKS Volume
Trying to determine fs type from 'LUKS Volume'
Trying to determine fs type from 'None'
$ blkid -p -O 0 /dev/mapper/image_mounter_luks_39596
< /dev/mapper/image_mounter_luks_39596: UUID="6RvJ8A-AgY9-Lk0d-G7gc-05tR-lKaG-tGVW7z" VERSION="LVM2 001" TYPE="LVM2_member" USAGE="raid"
Trying to determine fs type from 'LVM2_member'
[+] Detected lvm2_member as lvm
$ fsstat /dev/mapper/image_mounter_luks_39596 -o 0
$ losetup -f
< /dev/loop2
$ losetup -r -o 0 --sizelimit None /dev/loop2 /dev/mapper/image_mounter_luks_39596
losetup: failed to parse size: 'None': Invalid argument
[-] Loopback device could not be mounted.
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/imagemounter/volume.py", line 530, in _find_loopback
_util.check_call_(cmd, stdout=subprocess.PIPE)
File "/usr/local/lib/python3.9/dist-packages/imagemounter/_util.py", line 116, in check_call_
return subprocess.check_call(cmd, *args, **kwargs)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['losetup', '-r', '-o', '0', '--sizelimit', 'None', '/dev/loop2', '/dev/mapper/image_mounter_luks_39596']' returned non-zero exit status 1.
[-] Execution failed due to <class 'imagemounter.exceptions.NoLoopbackAvailableError'>
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/imagemounter/volume.py", line 530, in _find_loopback
_util.check_call_(cmd, stdout=subprocess.PIPE)
File "/usr/local/lib/python3.9/dist-packages/imagemounter/_util.py", line 116, in check_call_
return subprocess.check_call(cmd, *args, **kwargs)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['losetup', '-r', '-o', '0', '--sizelimit', 'None', '/dev/loop2', '/dev/mapper/image_mounter_luks_39596']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/imagemounter/volume.py", line 750, in mount
self._open_lvm()
File "/usr/local/lib/python3.9/dist-packages/imagemounter/volume.py", line 976, in _open_lvm
self._find_loopback()
File "/usr/local/lib/python3.9/dist-packages/imagemounter/volume.py", line 533, in _find_loopback
raise NoLoopbackAvailableError()
imagemounter.exceptions.NoLoopbackAvailableError
[-] Exception while mounting 6.0:LUKS Volume
The error seems to stem from the fact that --sizelimit None
is passed to the losetup
call. This should already be fixed in master. Could you try this again with the master version?
I am currently away from the image but I will try with master and update this as soon as I am able.
@ralphje Here is the output with the current master.
# imount -vvv --fstypes 6=luks /media/veracrypt1/forensics/test.E01
[ snip ]
[+] Found allocated : block offset: 3123200, length: 973649935
Initializing volume 6:-
[+] Mounting volume 6:-
$ fsstat /tmp/image_mounter_hbsy5mo7/ewf1 -o 3123200
$ losetup -f
$ losetup -r -o 1599078400 --sizelimit 498508766720 /dev/loop0 /tmp/image_mounter_hbsy5mo7/ewf1
$ cryptsetup isLuks /dev/loop0
[-] No key material provided for 6:-
$ cryptsetup -r luksOpen /dev/loop0 image_mounter_luks_59107
Enter passphrase for /tmp/image_mounter_hbsy5mo7/ewf1:
$ cryptsetup status image_mounter_luks_59107
Initializing volume 6.0:LUKS Volume
[+] Mounting volume 6.0:LUKS Volume
Trying to determine fs type from fsdescription 'LUKS Volume'
Current certainty levels: Counter({<class 'imagemounter.filesystems.LuksFileSystem'>: 0})
Highest certainty item is lower than 50, continuing...
Trying to determine fs type from guid 'None'
$ blkid -p -O 0 /dev/mapper/image_mounter_luks_59107
Trying to determine fs type from blikid 'LVM2_member'
Current certainty levels: Counter({<class 'imagemounter.filesystems.LuksFileSystem'>: 0})
Highest certainty item is lower than 50, continuing...
Using python-magic Python package for file type magic
Trying to determine fs type from magic 'DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 976773167 sectors, extended partition table (last)'
Current certainty levels: Counter({<class 'imagemounter.filesystems.LuksFileSystem'>: 0})
Highest certainty item is lower than 50, continuing...
$ fsstat /dev/mapper/image_mounter_luks_59107 -o 0
$ mount /dev/mapper/image_mounter_luks_59107 /tmp/im_6.0_ovasy26b_ -o loop,offset=0,sizelimit=None,ro
[-] Execution failed due to <class 'subprocess.CalledProcessError'> Command '['mount', '/dev/mapper/image_mounter_luks_59107', '/tmp/im_6.0_ovasy26b_', '-o', 'loop,offset=0,sizelimit=None,ro']' returned non-zero exit status 1.
[-] Exception while mounting 6.0:LUKS Volume
It seems that we fail to detect a LVM volume in the new version when blkid provides 'LVM2_member'. That is clearly a bug.
I believe that we should have a check that properly handles this case though. Could you try imount --check
and see whether you miss any dependencies that may resolve this in the meantime?
Here is the information. Also, I am running this under a virtualenv if that helps.
# imount --check
The following commands are used by imagemounter internally. Without most commands, imagemounter works perfectly fine, but may lack some detection or mounting capabilities.
-- Mounting base disk images (at least one required, first three recommended) --
INSTALLED xmount
INSTALLED ewfmount
INSTALLED affuse
MISSING vmware-mount needed for VMWare disks
MISSING mountavfs needed for compressed disk images, part of the avfs package
INSTALLED qemu-nbd
-- Detecting volumes and volume types (at least one required) --
INSTALLED mmls
INSTALLED pytsk3
INSTALLED parted
-- Detecting volume types (all recommended, first two highly recommended) --
INSTALLED fsstat
INSTALLED file
INSTALLED blkid
INSTALLED python-magic (Python package)
INSTALLED disktype
-- Mounting volumes (install when needed) --
INSTALLED xfs
INSTALLED ntfs
INSTALLED lvm
MISSING vmfs-fuse needed for VMFS volumes, part of the vmfs-tools package
INSTALLED jffs2
INSTALLED squashfs
INSTALLED mdadm
INSTALLED cryptsetup
INSTALLED bdemount
INSTALLED vshadowmount
INSTALLED photorec
Here is the output of pip list
.
# pip list
Package Version
------------- --------
imagemounter 3.1.0
pip 20.3.4
pkg-resources 0.0.0
python-magic 0.4.27
pytsk3 20211111
setuptools 44.1.1
termcolor 2.1.1