--- title: "Decrypting cryptolocked partition | EXTerminated @ FCSC 2022" date: "2022-05-08 19:00:00" author: "Juju" tags: ["Reverse", "Writeup", "fcsc"] toc: true --- # Intro EXTerminated is a malware reversing challenge. You are handed an EXT4 partition that has been encrypted by a malware, your goal is to recover the original unencrypted files. The description of the challenge tells us that the malware does not use any known cryptosystem to encrypt data, let's find this out. {{< image src="/EXTerminated/panik.png" style="border-radius: 8px;" >}} ## Challenge description `reverse` | `472 pts` `12 solves` :star::star: ``` Un client a détecté un seveur compromis sur son parc. Ce serveur semble avoir perdu l'ensemble de ses données suite à une infection. Il nous indique que les attaquants exigent une rançon et affirment pouvoir récupérer les fichiers disparus. Une analyse rapide du virus indique que ce dernier ne disposerait à première vue d'aucun algorithme cryptographique connu. On vous demande d'analyser ce disque, et de récupérer les fichiers originaux. SHA256(disk.img) = a9e7891224868af43e2aa134152beaa2a83f43cde21af8038d138001377157dc. ``` Author: `Nofix` ## Given files [disk.img](/EXTerminated/disk.img) # Writeup ## Overview So we can see we are given an EXT4 partition. ```console $ file disk.img disk.img: Linux rev 1.0 ext4 filesystem data, UUID=c26167b3-e0b9-441d-ab4d-a5f4b5b1fcd0 (extents) (64bit) (large files) (huge files) ``` Let's try to mount it. We can see that there are multiple pictures, a pdf and an executable called `wannaweep`, which is probably our malware. ```console $ sudo mount -o loop ./disk.img mnt/ $ tree mnt/ mnt/ ├── Documents │   └── anssi-guide-ransomware_attacks_all_concerned-v1.0.pdf ├── Images │   ├── accident.png │   ├── disk.jpg │   ├── flag.jpg │   ├── martine.jpg │   ├── smile.png │   ├── tintin.jpeg │   └── valide.png ├── lost+found [error opening dir] └── wannaweep 3 directories, 9 files ``` By further investigating we can see that all data of the files have been erased except for wannaweep, which definitely is the malware, an x64 stripped and dinamically linked ELF. ```console $ file mnt/Images/flag.jpg mnt/Images/flag.jpg: data $ xxd mnt/Images/flag.jpg | head 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ $ file mnt/wannaweep mnt/wannaweep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=590a9f68cde37ffceb8e7441db343742e4032f47, for GNU/Linux 3.2.0, stripped ``` We can see that the binary links to `libext2fs.so.2`, a library for EXT file system parsing and manipulation. Since it is dinamically linked we will still have the corresponding symbols so I'm guessing I won't have too much trouble understanding what the malware does even though I do not know the EXT specification. ```console $ ldd mnt/wannaweep linux-vdso.so.1 (0x00007ffccb2b3000) libext2fs.so.2 => /usr/lib/libext2fs.so.2 (0x00007f8059117000) libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007f8059111000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f8058f07000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f80591ad000) ``` ## Main It is now the perfect time for me to absolutely not launch this program, I could have setup a sandboxed environment but it turned out it wasn't necessary, the code was really straight forward. So I start my favorite decompiler and I download the source code of libext2fs. A small fast forward in time as the main function is really straight forward, The program takes the path to the device to encrypt as argument, calls a bunch of function that are mostly wrappers around libext2fs functions to initialize some global variables holding structures of the EXT filesystem. It also checks that some flags are set in the structures of libext2fs, I do not know if these flags are implementation specific or are standard EXT flags but I did not bother too much with this. The interesting stuff is at the end, I can see that it calls a function that I called `encrypt_folder` after reversing it. It then flushes the filesystem to disk and write the inode bitmap. {{< code file="/static/EXTerminated/main.c" language="c" >}} ## Encrypt folder Alright so let's take a look at the `encrypt_folder` to understand why I called it this way. I could clearly see from `main` that this function was called with the string `.` to reference the current directory, and a function pointer that was still unkown to me at the time but that I renamed `encrypt_file`. How I knew that the function was encrypting folders and that the parameter was a callback to encrypt files is really simple, you can clearly see the libc symbols calling `opendir` on the path given as argument (`.`), reading all the entries of the directory and calling the callback if the entry is a file. If it is not a file, it will `chdir` in the said directory, before recursively calling itself with the same arguments. {{< code file="/static/EXTerminated/encrypt_folder.c" language="c" >}} ## Encrypt file Let's now look at the `encrypt_file` we guessed. Again, mostly wrapper functions so I did not bother to show you why I named them this way, the code basically reads the content of the file to encrypt, encrypts it in a dedicated block, puts it in the file system before deleting the original content of the file. {{< code file="/static/EXTerminated/encrypt_file.c" language="c" >}} ## Encrypt block Well, I was scared of custom cryptography but this seems simple enough for me. To encrypt a plain text block, the malware starts at the last byte of the block and xor it with the previous one until it reaches the start. Actually this function does a heap buffer underflow when xoring the first byte of the block, since it will xor it with the byte right before the block in the heap. Reversing the encryption is trivial, the only undefined behaviours is with the underflow because we cannot know the value of the byte preceding the block. However, I assumed it would really likely be 0. {{< code file="/static/EXTerminated/encrypt_block.c" language="c" >}} ## Decrypting So to decrypt a block, we simply need to know the value of the byte preceding the buffer. Let's assume it is 0 since it is the most likely. I will xor this byte with the first byte of cipher text and that will give me the first byte of plain text, I then repeat the operation, xoring the first byte of plain text with the second byte of cipher text and I do this for the whole block to recover the entire block. ## Solve So know I know how to decrypt a block, let's decrypt the whole filesystem. I could do something really smart and overengineered to recover a valid decrypted EXT filesystem that I could mount to recover the original files. However I'm not familiar with the EXT specification and their are still small shadow zones in the malware code for me, so I try a naive solution. I'm guessing that data blocks of files or all alligned on `0x1000`, it would be kind of weird otherwise for me. So if I just cut the whole filesystem in `0x1000` sized blocks without any consideration of the semantic of those blocks in the EXT structure, I could just decrypt each of these blocks individually, and prey that I recover some files whose blocks were contiguous in the EXT structure. Obviously that will corrupt all the EXT metadata but it doesn't really matter as long as I can recover the files. {{< code file="/static/EXTerminated/decrypt.py" language="py" >}} Now let's try to output the result and see if we find any file signatures: ```console $ ./decrypt.py > decrypted.img $ binwalk decrypted.img DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 9289728 0x8DC000 PNG image, 473 x 306, 8-bit/color RGB, non-interlaced 9531392 0x917000 JPEG image data, JFIF standard 1.01 9625600 0x92E000 PNG image, 500 x 564, 8-bit/color RGBA, non-interlaced 10125312 0x9A8000 JPEG image data, JFIF standard 1.01 10212833 0x9BD5E1 bix header, header size: 64 bytes, header CRC: 0x6003083D, created: 2004-01-10 13:39:36, image size: 2097152 bytes, Data Address: 0x22120000, Entry Point: 0x1E040003, data CRC: 0xD2100008, CPU: IA64, image name: "" 10231808 0x9C2000 JPEG image data, EXIF standard 10231820 0x9C200C TIFF image data, big-endian, offset of first image directory: 8 10330112 0x9DA000 JPEG image data, EXIF standard 10330124 0x9DA00C TIFF image data, big-endian, offset of first image directory: 8 10403840 0x9EC000 PNG image, 482 x 367, 8-bit/color RGB, non-interlaced 10403902 0x9EC03E Zlib compressed data, default compression 34263365 0x20AD145 Cisco IOS experimental microcode, for "" 46640306 0x2C7ACB2 MySQL ISAM compressed data file Version 9 46691658 0x2C8754A GIF image data 15531 x ``` We do! So let's try to extract them ```console $ binwalk --dd='.*' decrypted.img DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 9289728 0x8DC000 PNG image, 473 x 306, 8-bit/color RGB, non-interlaced 9531392 0x917000 JPEG image data, JFIF standard 1.01 9625600 0x92E000 PNG image, 500 x 564, 8-bit/color RGBA, non-interlaced 10125312 0x9A8000 JPEG image data, JFIF standard 1.01 10212833 0x9BD5E1 bix header, header size: 64 bytes, header CRC: 0x6003083D, created: 2004-01-10 13:39:36, image size: 2097152 bytes, Data Address: 0x22120000, Entry Point: 0x1E040003, data CRC: 0xD2100008, CPU: IA64, image name: "" 10231808 0x9C2000 JPEG image data, EXIF standard 10231820 0x9C200C TIFF image data, big-endian, offset of first image directory: 8 10330112 0x9DA000 JPEG image data, EXIF standard 10330124 0x9DA00C TIFF image data, big-endian, offset of first image directory: 8 10403840 0x9EC000 PNG image, 482 x 367, 8-bit/color RGB, non-interlaced 10403902 0x9EC03E Zlib compressed data, default compression 34263365 0x20AD145 Cisco IOS experimental microcode, for "" 46640306 0x2C7ACB2 MySQL ISAM compressed data file Version 9 46691658 0x2C8754A GIF image data 15531 x $ file _decrypted.img.extracted/* _decrypted.img.extracted/2C7ACB2: MySQL ISAM compressed data file Version 9 _decrypted.img.extracted/2C8754A: GIF image data 15531 x _decrypted.img.extracted/8DC000: PNG image data, 473 x 306, 8-bit/color RGB, non-interlaced _decrypted.img.extracted/9A8000: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, progressive, precision 8, 660x424, components 3 _decrypted.img.extracted/9BD5E1: data _decrypted.img.extracted/9C200C: TIFF image data, big-endian, direntries=0 _decrypted.img.extracted/9C2000: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=0], comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 90", baseline, precision 8, 481x600, components 3 _decrypted.img.extracted/9DA000: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=0], baseline, precision 8, 683x500, components 3 _decrypted.img.extracted/9DA00C: TIFF image data, big-endian, direntries=0 _decrypted.img.extracted/9EC000: PNG image data, 482 x 367, 8-bit/color RGB, non-interlaced _decrypted.img.extracted/9EC03E: empty _decrypted.img.extracted/9EC03E-0: zlib compressed data _decrypted.img.extracted/20AD145: cisco IOS experimental microcode for '' _decrypted.img.extracted/92E000: PNG image data, 500 x 564, 8-bit/color RGBA, non-interlaced _decrypted.img.extracted/917000: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 495x669, components 3 ``` Displaying the images we just extracted, we find the following one, giving us the flag. {{< image src="/EXTerminated/flag.png" style="border-radius: 8px;" >}}