Level 3 - PATIENT0
Palindrome has spread some virus to corrupt machines causing incorrect readings in patients' health measurements and rending them unusable. Inspect the file and see if you can uncover the 8 corrupted bytes that renders the file system unusable?Submit your flag in this format: TISC{last 4 bytes in 8 lowercase hex characters}
PATIENT0
6MB
Binary
The first part of the challenge revolves around figuring out what the provided file is and fixing it.
We can see that this is an NTFS partition.
$ file PATIENT0
PATIENT0: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 0, FAT (1Y bit by descriptor); NTFS, physical drive 0xab3566f7, sectors 12287, $MFT start cluster 4, $MFTMirror start cluster 767, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 05c66c6b160cddda1
If we attempt to mount it, we see an interesting error message.
$ sudo mount -t ntfs ./PATIENT0 ./test
Reserved fields aren't zero (0, 0, 0, 0, 1129531732, 0).
Failed to mount '/dev/loop0': Invalid argument
The device '/dev/loop0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
It seems like
Reserved fields aren't zero (0, 0, 0, 0, 1129531732, 0) is the root cause of the error. If we open the file up in a hex editor, we see that the string TISC corresponds to the bytes 0x43534954 = 1129531732.
This definitely corresponds to at least 4 of the bytes that "render the file system unusable". If we take a look at the NTFS Partition Boot Sector documentation, we would see that the bytes from offset
0x20 to 0x27 are fields in the BPB that are "not used by NTFS".
These 8 bytes are the corrupted bytes that should be patched to null bytes.
The flag for this part is thus
TISC{f76635ab}I also found that by using
binwalk on the NTFS file, we could find a PDF that contained a hint for this part.
Palindrome must have leaked one of their passwords as the 4 corrupted bytes (Part 1 flag)! Dig deeper to find what was hidden! Submit your flag in this format: TISC{md5 hash} <-- will be prompted only after opening hidden room. Note: Please ignore the word 'original' in clue 4.
Once we patched the 8 corrupted bytes to null bytes, we should be able to mount the NTFS partition.
Inside we find a
message.png file containing a base32-encoded message.
Annoyingly this was an image instead of a text file...
import pytesseract
from PIL import Image
img = Image.open('message.png')
text = pytesseract.image_to_string(img)
print(text)
This decodes to
2.Thirsty for the flag? Go find the stream.After spending close to an hour guessing what this meant (PDF stream object?), I realised that since we are working with NTFS, this must have meant Alternate Data Streams (ADS). ADS are a way to store different streams of data within the same file, and can be used to hide information that would not be normally discovered through a simple directory listing.
A bit of googling later, I figured out how to mount the NTFS partition while preserving the ADS.
$ ntfs-3g -o streams_interface=windows PATIENT0.ntfs ./test
$ getfattr -n ntfs.streams.list message.png
# file: message.png
ntfs.streams.list="$RAND"
Opening up the
$RAND data stream of message.png, we are greeted with the next hint.
What I initially dismissed as bad grammar turned out to be crucial to this hint. The capitalized words spell TrueCrypt, which I doubt many people would have noticed if not for the following free hint that was released (showing the TrueCrypt logo).
At the end of the file was also the message
If you need a password, the original reading of the BPB was actually Checked and ReChecked 32 times!I downloaded TrueCrypt and decrypted the file (with the plaintext hints cut out) with the password
f76635ab as hinted by the challenge description. This yielded yet another message.
It turns out that TrueCrypt allows users to create hidden volumes. This is used in case a user is forced to reveal the password to a TrueCrypt volume, in which case they can provide the password to the standard volume while withholding the password to the hidden volume.
TrueCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored (i.e. bytes 65536–131071, which contain solely random data when there is no hidden volume within the volume) to RAM and attempts to decrypt it using the entered password.
The previous message gives us a hangman riddle of sorts - we know that the word in question is "collision", but it seems like we need a leetspeak version of it. The message found in the previous part now becomes relevant - the password is a variation of the word "collision" that yields a CRC value of
0xf76635ab.If you need a password, the original reading of the BPB was actually Checked and ReChecked 32 times!
After trying several failed variations, I just made
hashcat attempt all possible permutations of a 9-letter alphanumeric word starting with 'c' and ending with 'n'hashcat -a 3 -m 11500 -1 abcdefghijklmnopqrstuvwxyz0123456789 "f76635ab:00000000" 'c?1?1?1?1?1?1?1n' -o found.txt --keep-guessingThis gave many possible results, but
c01lis1on was the only viable one.After decoding the hidden volume, we find a
.ppsm file (a PowerPoint file with embedded macros). The one and only slide in the presentation told us the flag format.
There is an audio clip that was played when the slide enters presentation mode.
Since PowerPoint files were essentially zip archives, all we needed to do was unzip the
.ppsm file and look for a .mp3 file.$ find . -name '*mp3'
./ppt/media/media1.mp3
$ cat ./ppt/media/media1.mp3 | md5
f9fc54d767edc937fc24f7827bf91cfe
Last modified 8mo ago