Operation Orchid
03/27/2022
By: Wuotahylr
Tags: forensics PicoCTF-2022Problem Description:
Download this disk image and find the flag.
Hints:
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
openssl aes256 -salt -in flag.txt -out flag.txt.enc -k unbreakablepassword1234567
shred -u flag.txt
ls -al
halt
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:
picoCTF{h4un71ng_p457_5113beab}
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