K3RN3LCTF 2021 Writeup

This page has been machine-translated from the original page.

I participated in K3RN3LCTF, which ran from November 13, 2021, with team 0neP@dding (though I actually competed solo).

I only solved 2 Rev challenges this time, but I still managed to finish 139th out of 501 teams — which might mean the competition was tougher than I expected.

This was an eccentric CTF that did not hesitate to distribute real malware in its Rev challenges. Here is a brief writeup.

Table of Contents

• Zabomb (Rev)
• WiRE (Rev)
• Summary

Zabomb (Rev)

Description
You received a suspicious file from the k3rn3l4rmy hacking group, the title says 'Not a Zip Bomb, Please Open', you decide NOT to open it and instead try to reverse it.

It is recommended that you do NOT open this, it will fill your entire disk.

I was handed a genuine malware Zip Bomb.

Reference: New Zip Bomb Packs 4.5 PB of Data into a 46 MB File

Looking at the contents of the ZIP file, I found that it contained two types of compressed files: one with an enormous size and one with a small size.

Using 7-ZIP or similar to extract only the specific file was all that was needed.

7za.exe x -y -oC:\output\ -ir!filename bomb.zip
# flag{w0w_c0mpres51on_&_d3comp53ssi0N_!s_s0_c3wl_ju5t_d0n7_gO_b0OM}

Reference: Extracting Only Specific Files from a ZIP on the Command Line (Windows)

WiRE (Rev)

Description

We wire an encryption message that contains flag from remote server and dumped it out to kernelCTF_dump.pcapng file, i'm pretty sure that client has implementation of algorithm to decrypt data and get flag, will you take up the challenge?

I was given a mysterious pcap file and a PE binary.

It turned out that the PE binary was a client program that encrypts and transmits messages, and the pcap file was a recording of the encrypted FLAG being exchanged.

Decompiling the binary revealed that the client operates in the following sequence:

• Attempts a TCP connection to local port 9905
• If the TCP connection succeeds, encrypts a message and sends it
• Receives the encrypted FLAG data from the connected server
• Closes the connection

Analyzing the packets in the pcap file according to this flow, I found that the encrypted FLAG data d33411044a6202726302656e6901636e637462017d6702756e760101756e7b0173104c0a was received.

Here is the encryption logic:

void main.safeWrapMessage(void)

{
  byte *pbVar1;
  byte *pbVar2;
  code *pcVar3;
  byte *pbVar4;
  byte **local_res8;
  
  pbVar1 = *local_res8;
  pbVar2 = local_res8[1];
  for (pbVar4 = (byte *)0x0; (longlong)pbVar4 < (longlong)pbVar2; pbVar4 = pbVar4 + 1) {
    if (local_res8[1] <= pbVar4) goto LAB_004dbf48;
    (*local_res8)[(longlong)pbVar4] = pbVar1[(longlong)pbVar4] ^ 0x31;
  }
  if ((longlong)local_res8[1] < 5) {
    return;
  }
  **local_res8 = **local_res8 ^ 0x84;
  if ((byte *)0x1 < local_res8[1]) {
    (*local_res8)[1] = (*local_res8)[1] ^ 0x69;
    if ((byte *)0x2 < local_res8[1]) {
      (*local_res8)[2] = (*local_res8)[2] ^ 0x41;
      if ((byte *)0x3 < local_res8[1]) {
        (*local_res8)[3] = (*local_res8)[3] ^ 0x52;
        return;
      }
      runtime.panicIndex();
    }
    runtime.panicIndex();
  }
  runtime.panicIndex();
LAB_004dbf48:
  runtime.panicIndex();
  pcVar3 = (code *)swi(3);
  (*pcVar3)();
  return;
}

The entire FLAG is XOR-encrypted with 0x31, and then the first 4 characters are XOR-encrypted again.

So, XORing d33411044a6202726302656e6901636e637462017d6702756e760101756e7b0173104c0a with 0x31 and then replacing the first 4 characters with the known “flag” prefix yielded the FLAG.

Summary

With WiRE, Ghidra’s decompiled output was not great, and I had trouble reaching the Flag.

When I tried IDA Free for decompilation, I found that the output was more readable and useful for understanding the program’s behavior compared to Ghidra, which allowed me to solve it.

It seems that readability of decompiler output can vary depending on the binary, so when I cannot solve something, it is worth trying both Ghidra and IDA going forward.