Operation Orchid


By: Wuotahylr

Tags: forensics PicoCTF-2022

Problem Description:

Download this disk image and find the flag.


Reveal Hints (None)

Download the disk image. It is a .gz file, so use the command to extract:

gzip -d disk.flag.img.gz

The extraction leave disk.flag.img. Now, we would like to know the partition of this disk, so by using the command:

mmls disk.flag.img

The table:

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000206847   0000204800   Linux (0x83)
003:  000:001   0000206848   0000411647   0000204800   Linux Swap / Solaris x86 (0x82)
004:  000:002   0000411648   0000819199   0000407552   Linux (0x83)

The Primary Table is the table we see right now, so we can ignore that. The unallocated memory is unlikely to contain the flag (unless there is a manipulated pattern with the data to show a flag, but that isn’t the case here). The Solaris is an operating system, so the flag is also unlikely to be there. Therefore, we are interested in inspecting the memory space from 2048 to 206847 and from 411648 to 819199.

To inspect a region of the memory, use the command

fls -o 2048 disk.flag.img

This will show all the different files/directories in the region that starts on inode 2048 (that is what -o 2048 does)

d/d 11: lost+found
r/r 12: ldlinux.sys
r/r 13: ldlinux.c32
r/r 15: config-virt
r/r 16: vmlinuz-virt
r/r 17: initramfs-virt
l/l 18: boot
r/r 20: libutil.c32
r/r 19: extlinux.conf
r/r 21: libcom32.c32
r/r 22: mboot.c32
r/r 23: menu.c32
r/r 14: System.map-virt
r/r 24: vesamenu.c32
V/V 25585:      $OrphanFiles

Nothing stands out here (do not be fooled by names like “lost+found”). We then run

fls -o 411648 disk.flag.img

which gives

d/d 460:        home
d/d 11: lost+found
d/d 12: boot
d/d 13: etc
d/d 81: proc
d/d 82: dev
d/d 83: tmp
d/d 84: lib
d/d 87: var
d/d 96: usr
d/d 106:        bin
d/d 120:        sbin
d/d 466:        media
d/d 470:        mnt
d/d 471:        opt
d/d 472:        root
d/d 473:        run
d/d 475:        srv
d/d 476:        sys
d/d 2041:       swap
V/V 51001:      $OrphanFiles

This region contains the root directory, so we might be on the right track. We dig further into the root directory:

fls -o 411648 disk.flag.img 472

The 472 is to specify the file/directory associated with the inode 472.

r/r 1875:       .ash_history
r/r * 1876(realloc):    flag.txt
r/r 1782:       flag.txt.enc

Seeing the ash history file and the encoded file, we suspect that a user used a command was used to encrypt flag.txt to flag.txt.enc and then removed flag.txt, but all the actions of the user would be stored in the ash history file. Sure enough, by outputting the contents with the command:

icat -o 411648 disk.flag.img 1875

We get

        touch flag.txt
        nano flag.txt 
        apk get nano
        apk --help
        apk add nano
        nano flag.txt 
        openssl aes256 -salt -in flag.txt -out flag.txt.enc -k unbreakablepassword1234567
        shred -u flag.txt
        ls -al

Our theory is proven. One way to finish the problem is to first copy the contents of flag.txt.enc and then use the decode command:

icat -o 411648 disk.flag.img 1782 > flag.txt.enc
openssl aes256 -d -salt -in flag.txt.enc -out flag.txt -k unbreakablepassword1234567
cat flag.txt

We get the flag:


Alternatively mount the thing and make sure your file manager is showing hidden files. There’s also a chance you can do the disk image reading with…7zip