svchost_1337

Overview

An ELF process coredump from a suspicious process. The flag is hidden in a four-stage encoding chain, with the keys and ordering hinted at through deliberately corrupted metadata in the file itself. strings finds the encoded blob immediately, decoding it correctly is the challenge.

Step 1: Read the notes

readelf -n svchost_1337.core

Two things stand out:

CORE   0x0000007d   NT_PRPSINFO (prpsinfo structure)
...
/rot/x13_64-linux-gnu/libc.so.6

0x7d is the data size of NT_PRPSINFO. That's an unusual value to notice, but 0x7d = 125 = ASCII }: the closing brace of every flag.
/rot/x13_64-linux-gnu/libc.so.6 is not a real path. It's ROT13 with the library name mangled in. The file is telling you something.

Write both down: ROT13 is involved, and 0x7d is probably a key.

Step 2: Find the blob

strings svchost_1337.core

At the bottom of the heap strings:

ZmxmBQAwZmxlMwZlZzDjAwOzZGtkLmR5ZGtkZGSvZwVkZmVlZJZkZmR5ZwVjBGR1ZGDkZmR2ZwVkAGSwZTLkBGR4ZTL=

Looks like base64. Try decoding it directly:

echo 'ZmxmBQAw...' | base64 -d
# flf0fle3eg0��dkd.dydkddd�...  garbage

Not plaintext. The naive path doesn't work.

Step 3: Apply ROT13 first

The /rot/x13 hint told you the order: ROT13 before base64.

echo 'ZmxmBQAwZmxlMwZlZzDjAwOzZGtkLmR5ZGtkZGSvZwVkZmVlZJZkZmR5ZwVjBGR1ZGDkZmR2ZwVkAGSwZTLkBGR4ZTL=' \
  | tr 'A-Za-z' 'N-ZA-Mn-za-m'
# MzkzODNjMzkyZjMyMmQwNjBmMTgxYzE5MTgxMTFiMjIxMzIyMWMxMzE5MjIwOTE1MTQxMzE2MjIxNTFjMGYxOTE4MGY=

Now base64-decode that result:

echo 'MzkzODNj...' | base64 -d
# 39383c392f322d060f181c1918111b2213221c131922091514131622151c0f19180f

A hex string. Decode it:

echo '39383c392f322d...' | xxd -r -p | xxd
# 98<9/2-"""    "...

Still not readable.

Step 4: XOR with 0x7d

Apply the key from the NT_PRPSINFO size field:

key = 0x7d
raw_hex = '39383c392f322d060f181c1918111b2213221c131922091514131622151c0f19180f'
data = bytes.fromhex(raw_hex)
result = bytes(b ^ key for b in data)
print(result)

Or as a pipeline:

python3 -c "
import codecs
blob = 'ZmxmBQAwZmxlMwZlZzDjAwOzZGtkLmR5ZGtkZGSvZwVkZmVlZJZkZmR5ZwVjBGR1ZGDkZmR2ZwVkAGSwZTLkBGR4ZTL='
rot13 = codecs.decode(blob, 'rot13')
b64 = __import__('base64').b64decode(rot13)
hexraw = bytes.fromhex(b64.decode())
flag = bytes(x ^ 0x7d for x in hexraw)
print(flag)
"

The Encoding Chain (summary)

blob
  → ROT13
  → base64 decode
  → hex decode
  → XOR 0x7d
  → DEADROP{readelf_n_and_think_harder}

Flag: DEADROP{readelf_n_and_think_harder}

Note on the closing brace

} is ASCII 0x7d, the same value as the XOR key. So the closing brace XORs to 0x00, a null byte. Depending on how you handle the output you may see DEADROP{readelf_n_and_think_harder (string truncated at null) or a trailing ] or garbage character. If your result looks right but is missing the }, that's why, just append it.

Key Takeaway

The hints were in the file the whole time: a corrupted library path announcing ROT13, and a data size field whose hex value is the ASCII closing brace. Reading the metadata carefully, not just strings, is exactly what the flag says to do.