Operation Orchid

Download this disk image and find the flag.
Note: if you are using the webshell, download and extract the disk image into /tmp not your home directory.
Download compressed disk image

The file is disk.flag.img.gz, meaning it is gzipped. Unzip it with gunzip disk.flag.img.gz → disk.flag.img
Let’s use SleuthKit tools to explore the disk.
mmls disk.flag.img

1
DOS Partition Table
2
Offset Sector: 0
3
Units are in 512-byte sectors
4

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

The Linux (0x83) partitions are the only ones we need to worry about, so let’s check those out.
fls -o 2048 disk.flag.img

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

This doesn’t look very promising. Let’s take a look at the second partition.
fls -o 411648 disk.flag.img

1
d/d 460:        home
2
d/d 11: lost+found
3
d/d 12: boot
4
d/d 13: etc
5
d/d 81: proc
6
d/d 82: dev
7
d/d 83: tmp
8
d/d 84: lib
9
d/d 87: var
10
d/d 96: usr
11
d/d 106:        bin
12
d/d 120:        sbin
13
d/d 466:        media
14
d/d 470:        mnt
15
d/d 471:        opt
16
d/d 472:        root
17
d/d 473:        run
18
d/d 475:        srv
19
d/d 476:        sys
20
d/d 2041:       swap
21
V/V 51001:      $OrphanFiles

This looks a lot better!
As a general rule of thumb, I always check home and root. home is empty, but root contains the following:

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

We have 3 files (as evidenced by the r/r), one of which, flag.txt, appears to have been removed, i.e. its memory reallocated. Let’s check out the two other files still existing.
icat -o 411648 disk.flag.img 1875

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

This appears to show the history of the commands executed here. As we noted previously, the flag.txt file was removed, as evidenced by the shred -u flag.txt. Meanwhile, the important (bolded) command appears to show that flag.txt was encrypted using the aes256 encryption scheme with the option -salt and a password of unbreakablepassword1234567.
Let’s check out the .enc file.
icat -o 411648 disk.flag.img 1782

1
Salted__S+%+Okђ(Ac
2
                  @]ԣ
3
ޢȤ7 ؎$'%

As you might expect, this doesn’t appear to tell us anything relevant, only that the -salt is likely a necessary option for decrypting.
To work with this encrypted file, let’s put it in our local machine.
icat -o 411648 disk.flag.img 1782 > enc
Now, let’s try and reverse the encryption command.
openssl aes256 -d -salt -in enc -out flag.txt -k unbreakablepassword1234567
Note that -d simply tells openssl to decrypt, rather than encrypt, the input file.

cat flag.txt
picoCTF{h4un71ng_p457_1d02081e}