Challenge overview

BrunnerCorp needed a new secret vault for their various needs, but license fees are too expensive nowadays! Thankfully, the intern had a ChatGPT Plus subscription, which is all they needed. Unfortunately the pentesters found the source code on a public GitHub along with an encrypted vault export, but that shouldn’t be a problem… right? Oh and they phished one of the users. Here’s their creds:

maya.chen@brunnercorp.tld:Odense2026!

We’re given a web application for some kind of “secrets manager” application, along with an exported secrets vault. One of the exported secrets is, of course, the encrypted flag.

My first instinct was to look at the encrypt and decrypt helper functions that are used for the bulk of the cryptography in this challenge. Unusually for a crypto challenge, though, the algorithm is pretty standard.

def encrypt(value: str, key: bytes, associated_data: str) -> str:
    nonce = os.urandom(12)
    ciphertext = AESGCM(key).encrypt(nonce, value.encode(), associated_data.encode())
    return base64.urlsafe_b64encode(nonce + ciphertext).decode()


def decrypt(token: str, key: bytes, associated_data: str) -> str:
    try:
        raw = base64.urlsafe_b64decode(token.encode())
        return (
            AESGCM(key).decrypt(raw[:12], raw[12:], associated_data.encode()).decode()
        )
    except (ValueError, InvalidTag, UnicodeDecodeError) as exc:
        raise ValueError("ciphertext authentication failed") from exc

The encryption uses AES-GCM with a random nonce, and the tag is validated on decryption. AES-GCM is a standard and secure encryption algorithm, so we can’t solve the challenge by breaking it. Instead, we’ll have to look for some kind of implementation mistake that we can use to trick the server into decrypting the flag for us.

The most promising-looking function for this is import_vault. We have an exported vault, so it would make sense for us to be able to import the vault and have the server decrypt the flag with its key.

@api.post("/api/v1/vault/import")
@role_required("admin")
def import_vault():
    body = request.get_json(silent=True) or {}
    if body.get("format") != "vault-export-v1" or not isinstance(
        body.get("secrets"), list
    ):
# [...]

However, there are two problems with this:

• import_vault can only be called by an admin, which we aren’t.
• import_vault expects us to supply our own key for the vault decryption, rather than using the key known to the server.

Getting admin

When we log into the site, a cookie called secret_storage_session is used to save our login session. The cookie data is a long base64 string, presumably encrypted.

Looking at the open_session function of the EncryptedSessionInterface class, we can see how the session cookie is used. The cookie is encrypted and decrypted using the same encrypt and decrypt helper functions that are used for the secrets, with the hard-coded AAD string secret/session/v1.

def open_session(self, app, request):
	token = request.cookies.get(app.config["SESSION_COOKIE_NAME"])
	if not token:
		return self.session_class()
	try:
		payload = decrypt(token, self.key, "secret/session/v1")
		return self.session_class(json.loads(payload))
	except (ValueError, json.JSONDecodeError):
		return self.session_class()

This is a pretty standard way for login sessions to work. The server encrypts the user’s session information using some kind of authenticated encryption scheme and sends back the ciphertext. Then, each time the user accesses the site, the cookie is sent to the server, where it’s decrypted on the server side. Since the user doesn’t know the key, the server knows the cookie could only have been issued by the server itself.

So, what key is being used in our EncryptedSessionInterface instance? It turns out to be the same SECRET_ENCRYPTION_KEY that’s being used to encrypt and decrypt the secrets:

def create_app(config_class=Config):
    app = Flask(__name__)
    app.config.from_object(config_class)
    app.session_interface = EncryptedSessionInterface(
        app.config["SECRET_ENCRYPTION_KEY"]
    )
    app.teardown_appcontext(close_db)
    app.register_blueprint(api)

    with app.app_context():
        init_db()

    return app

Since we have the ability to create new secrets, we can take advantage of this to get the server to encrypt an admin session cookie for us. This is how secrets are encrypted in the create_secret function.

ciphertext = encrypt(
	body["value"],
	current_app.config["SECRET_ENCRYPTION_KEY"],
	f"secret/{body['name']}",
)

The AAD string for the encrypted secret is the string secret/ followed by the name of the secret. If we name a secret session/v1, then we can encrypt the text of the secret with the secret/session/v1 AAD string that is used to validate the session cookie.

To get an idea of the format of the session cookie, I started up a local instance of the challenge using a known SECRET_ENCRYPTION_KEY of all zeroes, then decrypted the cookie for my own session as maya.chen:

{"user_id":3,"role":"editor"}

In init_db, the admin account’s information is inserted before the accounts of the three normal users, so we’ll want to set our user_id to 1 . (The role information for each user is actually checked against the roles in the database, not the role in the session cookie JSON, so simply setting "role":"admin" in the cookie without changing our user ID doesn’t help us.)

def init_db():
    db_path = current_app.config["DB_PATH"]
    db_path.parent.mkdir(parents=True, exist_ok=True)
    db = get_db()
    db.executescript(SCHEMA)
    db.commit()
    if current_app.config.get("BOOTSTRAP_ADMIN_PASSWORD"):
        email = current_app.config["BOOTSTRAP_ADMIN_EMAIL"].lower()
        db.execute(
            "INSERT OR IGNORE INTO users(email,password_hash,role) VALUES(?,?,?)",
            (
                email,
                generate_password_hash(current_app.config["BOOTSTRAP_ADMIN_PASSWORD"]),
                "admin",
            ),
        )
        db.commit()
    seed_data()

We can then create the secret:

Exporting the vault, we obtain the ciphertext fof the session cookie.

{
	"ciphertext": "fUzmLWhoCazUgGLUkaA0YvBW0G70YCQ0t9ZgiyGUDK-4t_46vbiXzszt6vS0SUnNrKUpAXgXl9M=",
	"created_at": "2026-08-22 17:31:29",
	"description": "",
	"id": 5,
	"name": "session/v1",
	"owner_id": 3,
	"updated_at": "2026-08-22 17:31:29"
}

Setting the text of the secret_storage_session cookie to the exported ciphertext, we’re now logged in as admin.

Decrypting the flag

import_vault

We can now call import_vault, but we still need to figure out how to use it to decrypt our flag. import_vault expects us to pass in the key to the imported vault, which of course we don’t have.

Specifically, import_vault does the following:

nonce, encrypted = raw[:12], raw[12:]
value = (
	AESGCM(source_key)
	.decrypt(nonce, encrypted, f"secret/{name}".encode())
	.decode()
)

destination = AESGCM(current_app.config["SECRET_ENCRYPTION_KEY"]).encrypt(
	nonce, value.encode(), f"secret/{name}".encode()
)

• The entry read from the vault is split into the prepended nonce and the actual ciphertext.
• The ciphertext is decrypted using the nonce and the user-supplied key.
• The ciphertext is re-encrypted using the nonce and the new key.

The issue here is that the nonce that is being used when the secret is re-imported into the vault is the same nonce that was used to encrypt the flag originally. (In retrospect, I should have noticed this a lot sooner since this is basically the only way to screw up AES-GCM.) We can use this to encrypt a plaintext of our choice using the same key and nonce as the flag, which gets us the keystream that was used to encrypt the flag originally.

Nonce reuse

AES-GCM is a stream cipher. It uses the key and nonce to generate a keystream, then XORs the keystream with the plaintext to produce the ciphertext.

The keystream that gets generated for a given key and nonce is always the same, which means that the same key and nonce should never be used to encrypt more than one plaintext. If an attacker knows one plaintext-ciphertext pair, they can use that to decrypt other ciphertexts encrypted with the same plaintext:

Message ^ Keystream = Ciphertext
KnownPlaintext ^ Keystream = EncryptedKnownPlaintext

Ciphertext ^ EncryptedKnownPlaintext = (Message ^ Keystream) ^ (KnownPlaintext ^ Keystream) = Message ^ KnownPlaintext
Message = KnownPlaintext ^ Ciphertext ^ EncryptedKnownPlaintext

This is exactly what we can use the import_vault function to do. We can create our own fake secrets, then add that secret to an export JSON file with the same nonce prepended to it as the flag. Then, we can export the vault with the new secret added, and it will be encrypted with the flag’s keystream.

EncFlag = Keystream ^ Flag
FakeEncSecret = Keystream ^ FakeSecret

EncFlag ^ FakeEncSecret = (Keystream ^ Flag) ^ (Keystream ^ FakeSecret) = Flag ^ FakeSecret

Flag = EncFlag ^ FakeSecret ^ FakeEncSecret

The solve script

First we need to create the fake secret to import. (I used a string of a’s, but any string would work). The fake secret will be decrypted using a key of our choice before it gets re-encrypted by the challenge’s key, so we can use an arbitrary key to encrypt it (I used a key of all 1s). The AAD is also validated by the challenge instance, so we have to make sure to supply the correct AAD string of secret/Flag.

import base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

enc_flag = base64.urlsafe_b64decode("w0nG9y0JrT1WmR8Zo_wj0P-e6kMfsytriqclB0PY5cgzp4d00ADBFe1YQyRskKJAOYlBa9nqMZh4xtTX6IGwX6QbXw==")
nonce, data, tag = enc_flag[:12], enc_flag[12:-16], enc_flag[-16:]

aad = b'secret/Flag'

fake_secret = AESGCM(b'\x01'*32).encrypt(nonce, b'a'*len(data), aad)

print(base64.urlsafe_b64encode(nonce + fake_secret))

This prints out the string w0nG9y0JrT1WmR8ZiaMR5F_0H2HZbSUoY3j0c_xr4B6ZzE1EJa27eLFPCKlH0UE9IJleqprAUsLh-4TK2EmBVaGiCA==, which we can add to the vault export file which we’re going to supply to the challenge.

{
    "format": "vault-export-v1",
    "secrets": [
        {
            "ciphertext": "w0nG9y0JrT1WmR8ZiaMR5F_0H2HZbSUoY3j0c_xr4B6ZzE1EJa27eLFPCKlH0UE9IJleqprAUsLh-4TK2EmBVaGiCA==",
            "created_at": "2026-07-30 08:14:02",
            "description": "The CTF flag for the challenge",
            "id": 5,
            "name": "Flag",
            "owner_id": 1,
            "updated_at": "2026-07-30 08:14:02"
        }
    ]
}

Then, we can import and re-export the vault, which gets us the fake secret encrypted with the flag’s keystream.

{
	"ciphertext": "w0nG9y0JrT1WmR8ZoO833_Ca-Vkcpz5Vn653OWOI29pm94JKgBX_A7gMfSM8n_AeZ9dd5cwdKampUdk8_mGLorTifA==",
	"created_at": "2026-08-22 19:42:46",
	"description": "The CTF flag for the challenge",
	"id": 5,
	"name": "Flag",
	"owner_id": 1,
	"updated_at": "2026-08-22 19:42:46"
}

Now we just have to XOR the original exported flag with the recovered keystream and the string of a’s that make up the fake secret.

from pwn import xor

orig = base64.urlsafe_b64decode('w0nG9y0JrT1WmR8Zo_wj0P-e6kMfsytriqclB0PY5cgzp4d00ADBFe1YQyRskKJAOYlBa9nqMZh4xtTX6IGwX6QbXw==')[12:-16]
returned = base64.urlsafe_b64decode('w0nG9y0JrT1WmR8ZoO833_Ca-Vkcpz5Vn653OWOI29pm94JKgBX_A7gMfSM8n_AeZ9dd5cwdKampUdk8_mGLorTifA==')[12:-16]

print(xor(xor(orig, returned), b'a'*len(orig)))

This gets us the flag: brunner{but_th3_A1_s41d_1t_w45_f1n3???}

Overall, I thought this was a pretty good challenge. Most CTF crypto challenges tend to be pretty academic, but the vulnerabilities in this challenge are plausible implementation errors that I could easily imagine showing up in a real application.

The focus of this blog post is an embedded eBPF ELF binary that deps loads using a call to bpf_object__open_mem. When I looked at this binary, I immediately noticed that the strings contained a great deal of debug information. Specifically, I saw what looked like full lines of source code, complete with comments:

20 20 20 20 20 20 20 20 20 20 20 63 2d 3e 70 72  |           c->pr|
65 76 5f 6f 66 66 20 20 3d 20 63 2d 3e 6f 66 66  |ev_off  = c->off|
3b 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20  |;.              |
20 20 63 2d 3e 70 72 65 76 5f 72 6c 65 6e 20 3d  |  c->prev_rlen =|
20 6d 65 72 67 65 64 3b 00 20 20 20 20 20 20 20  | merged;.       |
20 20 20 20 20 20 20 20 20 63 2d 3e 6f 66 66 20  |         c->off |
20 20 20 20 20 2b 3d 20 6e 65 78 74 5f 72 6c 65  |     += next_rle|
6e 3b 20 2f 2f 20 62 6f 74 74 6f 6d 20 61 64 64  |n; // bottom add|
73 20 72 6c 65 6e 20 e2 86 92 20 74 6f 74 61 6c  |s rlen â.. total|

I decided to investigate how these strings might have gotten there and how much of the source code was actually present, which turned out to be a bit of a rabbit hole. This writeup is focused on the debug info itself and doesn’t really go into the malicious functionality of the code.

Initial investigations

At first glance, if we print out all the strings from this region of the code in order, it really does look like the malware is embedding its full source code. For instance, this almost looks like a reasonable implementation of a function to convert a string to an integer.

static __attribute__((noinline)) u32 name_to_pid(const char *name)
        u8 c = (u8)name[i];
        if (c == 0) break;
        if (c < '0' || c > '9') return 0;
        n = n * 10 + (c - '0');

However, what we’re seeing clearly isn’t the exact source code. Some lines are missing, like the initialization of the loop and the opening bracket after the function name.

There are also lines that occasionally appear out of order: the line (void *)(c->buf + c->off + 16)) < 0 || rlen == 0) here should come after if (bpf_probe_read_user(&rlen, sizeof(rlen),, not before.

    u16 rlen = 0;
                            (void *)(c->buf + c->off + 16)) < 0 || rlen == 0)
    if (bpf_probe_read_user(&rlen, sizeof(rlen),
    char name[16] = {};

In order to ensure the lines were correctly ordered and get an idea of how many lines were missing, I would need to figure out how to parse the file format where the debug strings were stored.

DWARF

I initially assumed this was DWARF info and went on a wild goose chase trying to use various DWARF parsing tools to read it. It turns out it isn’t DWARF, but I’ll document what I looked for anyway in the hopes that it’s helpful to somebody.

The thing that threw me off initially is that DWARF does allow source embedding. In DWARF 5, the DW_LNCT_source field was introduced, which stores the full source code of the binary as a string. Clang supports it with the -gembed-source flag.

When I compiled a test binary with -gembed-source, though, the format didn’t match. The AUR malware stores each line as its own null-terminated string, but the DWARF info stored the source code as a single string with newlines included. Additionally, while llvm-dwarfdump didn’t show any source information for the malware, it did for the test binary:

file_names[  0]:  
          name:  .debug_line_str[0x0000002a] = "embedded_source.c"  
     dir_index: 0  
  md5_checksum: 22f3183556b123a4d647cadec6ef7675  
        source:  .debug_line_str[0x0000003c] = "#include <stdio.h>\n\nint main(int argc, char** argv) {\n    pri  
ntf(\"test embedded source\\n\");\n    return 0;\n}\n"

Evidently, the malware strings had nothing to do with the DWARF feature. (In retrospect, it’s unlikely a malware developer would ever go out of their way to compile with -gembed-source, a compiler flag most people have never heard of.)

BTF

After googling a bunch of variations of “ebpf debug info”, I eventually caught on that BPF has its own debug info format called BTF. I compiled a debug build of a test BPF binary (clang -target bpf -g -c test.c -o test.o), and sure enough, source code strings appeared in the binary.

000001d0: 7374 2e63 0069 6e74 2066 756e 6328 2920  st.c.int func()    
000001e0: 7b00 2020 2020 7265 7475 726e 2030 3b00  {.    return 0;.

Unfortunately, I wasn’t able to find a tool to display these strings. bpftool btf dump prints out a lot of type info, but it ignores the source code lines entirely.

[1] PTR '(anon)' type_id=3
[2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[3] ARRAY '(anon)' type_id=2 index_type_id=4 nr_elems=1
[4] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)

// [...]

[98] DATASEC 'license' size=0 vlen=1
	type_id=96 offset=0 size=4 (VAR 'LICENSE')

llvm-objdump understands the BTF format in theory, but llvm-objdump -S ignores the embedded source strings. Instead, it searches for the source file on disk and complains about not being able to find it.

0000000000000000 <walk_dirent>:  
llvm-objdump: warning: 'bpf.elf': failed to find source /cloud/scales/agent/../ebpf/scales.bpf.c

The BTF format

Eventually I gave up on finding a tool and decided to analyze the file format to see if I could write a parser script myself. Luckily, the Linux kernel’s documentation of the format is pretty good. (All of the struct definitions referenced here are taken from this documentation.)

.BTF and .BTF.ext

The BTF information is split up into two sections of the ELF: .BTF and .BTF.ext. The table of source code strings is stored in .BTF, and the corresponding line numbers are stored in .BTF.ext.

The .BTF section starts with the following header:

struct btf_header {
    __u16   magic;
    __u8    version;
    __u8    flags;
    __u32   hdr_len;

    /* All offsets are in bytes relative to the end of this header */
    __u32   type_off;       /* offset of type section       */
    __u32   type_len;       /* length of type section       */
    __u32   str_off;        /* offset of string section     */
    __u32   str_len;        /* length of string section     */
};

str_off and str_len tell us the offset and length of the string table, which is just an array of null-terminated strings. This table stores the source code lines as well as any other strings that are relevant to the debug info, such as filenames, function names, and type names.

The.BTF.ext function isn’t nearly as straightforward. It starts with this header:

struct btf_ext_header {
    __u16   magic;
    __u8    version;
    __u8    flags;
    __u32   hdr_len;

    /* All offsets are in bytes relative to the end of this header */
    __u32   func_info_off;
    __u32   func_info_len;
    __u32   line_info_off;
    __u32   line_info_len;

    /* optional part of .BTF.ext header */
    __u32   core_relo_off;
    __u32   core_relo_len;
};

The relevant fields here are line_info_off and line_info_len, which point to the part of the debug info that stores the source line numbers.

The Linux kernel docs give us the following definition for line_info:

The line_info is organized as below.:

line_info_rec_size              /* __u32 value */
btf_ext_info_sec for section #1 /* line_info for section #1 */
btf_ext_info_sec for section #2 /* line_info for section #2 */
...

Unfortunately, the btf_ext_info_sec struct is more mysterious, and it’s not obvious what it has to do with line numbers.

struct btf_ext_info_sec {
   __u32   sec_name_off; /* offset to section name */
   __u32   num_info;
   /* Followed by num_info * record_size number of bytes */
   __u8    data[0];
};

The example disassembly makes this a little clearer. We can see that the information for each line number is stored as a set of four values, and that an array of these structures appear after the metadata at the start of the line_info section.

.long   16                      # LineInfo
.long   1                       # LineInfo section string offset=1
.long   2
.long   .Ltmp0
.long   7
.long   33
.long   7182                    # Line 7 Col 14
.long   .Ltmp3
.long   7
.long   58
.long   8206                    # Line 8 Col 14

As it turns out, the structures are bpf_line_info structures, which are defined in the following way:

struct bpf_line_info {
    __u32   insn_off; /* [0, insn_cnt - 1] */
    __u32   file_name_off; /* offset to string table for the filename */
    __u32   line_off; /* offset to string table for the source line */
    __u32   line_col; /* line number and column number */
};

The only non-obvious field here is line_col, which stores the column in the low 10 bits and the line number in the high 12 bits.

#define BPF_LINE_INFO_LINE_NUM(line_col)        ((line_col) >> 10)
#define BPF_LINE_INFO_LINE_COL(line_col)        ((line_col) & 0x3ff)

I think what’s going on here is that the btf_ext_info_sec structure can store arbitrary structures in the data field, and in this case it happens to store bpf_line_info structures. In this case, line_info_rec_size is sizeof(bpf_line_info) = 16, so a btf_ext_info_sec struct stores 16 * num_info bytes in its data field.

This is the example line_info with every value annotated according to its field:

 .long   16                      # line_info_rec_size
 .long   1                       # btf_ext_info_sec.sec_name_off
 .long   2                       # btf_ext_info_sec.num_info
 .long   .Ltmp0                  # 1st line info - bpf_line_info.insn_off
 .long   7                       # 1st line info - bpf_line_info.file_name_off
 .long   33                      # 1st line info - bpf_line_info.line_off
 .long   7182                    # 1st line info - bpf_line_info.line_col
 .long   .Ltmp3                  # 2nd line info - bpf_line_info.insn_off
 .long   7                       # 2nd line info - bpf_line_info.file_name_off
 .long   58                      # 2nd line info - bpf_line_info.line_off
 .long   8206                    # 2nd line info - bpf_line_info.line_col

In this example there’s only one btf_ext_info_sec structure, but the malware had one for each function. I guess that’s what a “section” means in this context.

Parser script

Ultimately, to figure out which source lines go where, the only things we need to extract are the line number and string table offset. This script reads the line_off value from each of the bpf_line_info structures and retrieves the null-terminated string at that offset in the string table. It then matches that to the line number extracted from the line_col value of the bpf_line_info.

from ctypes import *
import lief
import io

class btf_header(Structure):
    _fields_ = [
        ('magic', c_uint16),
        ('version', c_uint8),
        ('flags', c_uint8),
        ('hdr_len', c_uint32),
        ('type_off', c_uint32),
        ('type_len', c_uint32),
        ('str_off', c_uint32),
        ('str_len', c_uint32)
    ]

class btf_ext_header(Structure):
    _fields_ = [
        ('magic', c_uint16),
        ('version', c_uint8),
        ('flags', c_uint8),
        ('func_info_off', c_uint32),
        ('func_info_len', c_uint32),
        ('line_info_off', c_uint32),
        ('line_info_len', c_uint32),
        ('core_relo_off', c_uint32),
        ('core_relo_len', c_uint32)
    ]

class bpf_line_info(Structure):
    _fields_ = [
        ('insn_off', c_uint32),
        ('file_name_off', c_uint32),
        ('line_off', c_uint32),
        ('line_col', c_uint32)
    ]

elf: lief.ELF.Binary = lief.ELF.parse('bpf.elf')

for section in elf.sections:
    if section.name == '.BTF':
        btf = section.content.tobytes()
    if section.name == '.BTF.ext':
        btf_ext = section.content.tobytes()

header = btf_header.from_buffer_copy(btf)

type_offset = header.type_off + sizeof(btf_header)
str_offset = header.str_off + sizeof(btf_header)

string_table = btf[str_offset:str_offset + header.str_len]

ext_header = btf_ext_header.from_buffer_copy(btf_ext)
line_info_offset = ext_header.line_info_off + sizeof(btf_ext_header)

# this should really go from line_info_offset - line_info_offset + ext_header.line_info_len, but the value of line_info_len is wrong for some reason
line_stream = io.BytesIO(btf_ext[line_info_offset:])

unknown = line_stream.read(8)

lines = {}
max_line = 0

while True:
    unknown2 = line_stream.read(4)
    num_infos = int.from_bytes(line_stream.read(4), 'little')
    
    # this is a hack to stop reading once we hit the end of line_info, since line_info_len is wrong
    if num_infos == 0:
        break

    for i in range(num_infos):
        buf = line_stream.read(sizeof(bpf_line_info))
        if len(buf) < sizeof(bpf_line_info):
            break

        info = bpf_line_info.from_buffer_copy(buf)
        line_no = info.line_col >> 10
        if line_no > max_line:
            max_line = line_no

        # read a null terminated string from the string table
        line_str = string_table[info.line_off:string_table.find(b'\x00', info.line_off)]
        lines[line_no] = line_str
        print(line_str)

for i in range(max_line):
    if i in lines:
        print(lines[i].decode('utf-8'))
    else:
        print('/* missing line */')

The full output of the script can be found here.

The reassembled source lines

Unfortunately, the debug info doesn’t contain as much of the source code as I would’ve hoped. In a couple of places, there are gaps consisting of more than a hundred lines, suggesting that entire functions may be missing debug info. However, it may still be useful for analysis, especially when compared against the disassembly or decompilation of the eBPF bytecode. Some functions are nearly complete, except for the lines that contain things like whitespace or single curly braces.

int net_exit_openat(struct sys_exit_ctx *ctx)
/* missing line */
    u64 id = bpf_get_current_pid_tgid();
    if (!bpf_map_lookup_elem(&net_open_temp, &id)) return 0;
    bpf_map_delete_elem(&net_open_temp, &id);
    long fd = ctx->ret;
    if (fd < 0) return 0;
    u32 tgid = (u32)(id >> 32);
    u64 key  = ((u64)tgid << 32) | (u32)fd;
    u8 val = 1;
    bpf_map_update_elem(&net_fds, &key, &val, BPF_ANY);
/* missing line */
}

I plan on doing some follow-up posts describing what the eBPF binary actually does, along with some analysis of the main malware executable.

As usual, we’re given a prompt to enter a serial number. Tracing through the function that checks the serial, we can see a call to a function at the address 0x40a000. This address is not part of the .text section of the PE file; instead, it occurs at the start of a nonstandard section called .pc. Looking at a hex dump of the .pc section, it was obviously encrypted.

99 ae 95 d7 80 31 f7 5c 3b c9 38 6e 9a 11 56 06  .....1.\;.8n..V.
16 81 d5 0c eb 59 b4 fa fe da 10 89 de 78 32 6b  .....Y.......x2k
87 bb fb e6 09 19 77 a9 84 33 4a dc 91 7b 8b 5a  ......w..3J..{.Z
6d 5c 4a 94 ed ee cd 5e d8 5e f5 c2 8b bc 35 15  m\J....^.^....5.
39 7c 1b 08 bd 76 29 5d 66 13 0c 14 c1 f3 93 c6  9|...v)]f.......
98 71 b1 26 83 bf c7 20 b9 a6 8b 91 cc 05 7f 20  .q.&... ....... 
b7 74 0c 6d ea 66 b3 34 aa 03 18 25 23 4f 45 26  .t.m.f.4...%#OE&
84 4a 2e 47 db 99 9d 97 6c 37 3a d3 84 ac 17 67  .J.G....l7:....g

Initial deobfuscation steps

API resolution

I started off by setting breakpoints on commonly used APIs like VirtualAlloc and VirtualProtect. Tracing through the calls, I found that the APIs were being resolved through some kind of indirect lookup function.

0040112c    int32_t do_VirtualProtect()

0040112f        sub_401367()
0040113c        jump(sub_401ad3(&data_40d1a8))

As usual for this type of challenge, the APIs were being called based on their hash, in this case 0x10066f2f for VirtualProtect.

00401ad3    int32_t __fastcall sub_401ad3(int32_t* arg1)

00401ae6        if (arg1[5] != 0)
00401aeb            return arg1[5]
00401aeb        
00401b20        void* var_14
00401b20        arg1[5] = sub_401175(sub_401ca2(*arg1, &var_14, 0x10066f2f))
00401b26        return arg1[5]

Looking at the hash function at sub_401ba9, it turned out to just be unmodified CRC32:

00401ba9    uint32_t __stdcall sub_401ba9(char* arg1, int32_t arg2)

00401bad        int32_t esi = 0
00401baf        uint32_t edx = 0xffffffff
00401bb3        char* edi = arg1
00401bb3        
00401bb9        if (arg2 u> 0)
00401bbb            int32_t ebx
00401bbb            int32_t var_10_1 = ebx
00401bbb            
00401be6            do
00401bbc                ebx.b = edi[esi]
00401bc1                int32_t i_1 = 8
00401bdd                int32_t i
00401bdd                
00401bdd                do
00401bc7                    uint32_t ecx_2 = edx u>> 1
00401bc9                    char eax_2 = ebx.b ^ edx.b
00401bcd                    edx = ecx_2 ^ 0xedb88320
00401bcd                    
00401bd5                    if ((eax_2 & 1) == 0)
00401bd5                        edx = ecx_2
00401bd5                    
00401bd8                    ebx.b u>>= 1
00401bda                    i = i_1
00401bda                    i_1 -= 1
00401bdd                while (i != 1)
00401bdf                edi = arg1
00401be2                esi += 1
00401be6            while (esi u< arg2)
00401be6        
00401bf0        return not.d(edx)

Since CRC32 is such a widely used algorithm, we can use HashDB to look up the API names that go with each checksum. In fact, there’s a Binary Ninja plugin that pulls data from HashDB to define an enum mapping all the API names to their checksums.

enum hashdb_strings_crc32 : uint32_t
{
    FlushInstructionCache = 0xe9258e7a,
    RtlMoveMemory = 0x1c0cd35c,
    GlobalUnWire = 0x2c82f5fb,
    MapUserPhysicalPages = 0xafd472a5,
    // [...]
    RtlUniform = 0xd09d867b,
    RtlNewSecurityObjectEx = 0x8733c5dd,
    WinSqmSetEscalationInfo = 0x648930f1
};

Normally I’d write a script to rename all the API hashing functions to their respective API names, but in this case there weren’t that many of them so I just renamed them all by hand.

Breakpoints

When left to run under a debugger, the binary runs until it hits an int3 breakpoint at 0x4037c6. I’d seen things like this before where exceptions are used to obfuscate control flow, but the binary seemed to be “getting stuck”, never progressing past the breakpoint location.

004037c2    void __fastcall do_breakpoint(void* arg1)

004037c2  c6410101           mov     byte [ecx+0x1], 0x1
004037c6  cc                 int3    

When I was resolving the API hashes, I saw that KiUserExceptionDispatcher was one of the hashed APIs, so I looked at how that was being used. It looked like the binary was supposed to overwrite the entry point of KiUserExceptionDispatcher with an exception handler of its own. However, for whatever reason the overwrite function wasn’t being called, so the real KiUserExceptionDispatcher was being called instead.

00402ce0    void __fastcall overwrite_KiUserExceptionDispatcher(char* hook)

00402ce6        if (*hook == 0)
00402ce6            return 
00402ce6        
00402cef        int32_t KiUserExceptionDispatcher
00402cef        int80_t st0_1
00402cef        st0_1, KiUserExceptionDispatcher =
00402cef            get_KiUserExceptionDispatcher(&kernel32_addr, get_kernel32_baseaddr())
00402cfd        _memcpy_s(KiUserExceptionDispatcher, 6, &hook[1], 6)
00402d05        *hook = 0

It turned out the KiUserExceptionDispatcher overwrite was only called if an anti-debug check was passed. The check used NtQueryInformationProcess, which I had thought could be bypassed with ScyllaHide, but for whatever reason that didn’t work in this case. Ultimately, I just patched out the check entirely.

00402b6d    int32_t __fastcall check_ProcessDebugPort(int32_t* arg1)

00402b77        if (sub_402bc7(arg1) != 0)
00402b7c            return 1
00402b7c        
00402b88        int32_t* ProcessInformation = arg1
00402b89        int32_t esi
00402b89        int32_t var_c = esi
00402b8a        ProcessInformation = nullptr
00402b91        get_dll_baseaddr()
00402b98        HANDLE ProcessHandle = do_GetCurrentProcess()
00402b9f        get_dll_baseaddr()
00402bb1        NTSTATUS result = do_NtQueryInformationProcess(ProcessHandle, 
00402bb1            ProcessInformationClass: ProcessDebugPort, &ProcessInformation, 
00402bb1            ProcessInformationLength: 4, ReturnLength: nullptr)
00402bb1        
00402bb9        if (result != STATUS_SUCCESS)
00402bc3            result.b = 0
00402bc6            return result
00402bc6        
00402bbe        result.b = ProcessInformation != result
00402bc2        return result

At that point, the custom exception handler was being called, but the binary still crashed soon after with mysterious access violation exceptions. It seemed like it was trying to decrypt and run the .pc section, but the decryption was incorrect.

00402e1c    void decrypt_and_ntcontinue(PCONTEXT arg1) __noreturn

00402e20        context_record = arg1
00402e28        exception = __return_addr
00402e2d        get_cipher_ctx()
00402e40        decrypt_from_exception(ctx: &cipher_ctx, exception: exception, 
00402e40            context: context_record)
00402e45        get_dll_baseaddr()
00402e54        do_NtContinue(ContextRecord: context_record, TestAlert: 0)
00402e59        breakpoint

The .pc section

Decrypting the code

At some point in the reversing process I got pretty stuck, and I was just kind of clicking around the decompilation for a while looking for something comprehensible. I eventually found something I recognized at sub_401e67:

00401e67    uint32_t* __thiscall sub_401e67(uint32_t* arg1, char* arg2, char* arg3)

00401e72        int32_t var_14 = 0xb979379e
00401e7c        int32_t var_10 = 0x157c4a7f
00401e83        int32_t var_c = 0x60c09cf3
00401e8a        int32_t var_8 = 0x34c8ed5c
00401e96        *arg1 = bytes_to_int(&var_14)
00401ea1        arg1[1] = bytes_to_int(&var_10)
00401ead        arg1[2] = bytes_to_int(&var_c)
00401ebd        arg1[3] = bytes_to_int(&var_8)
00401ec5        arg1[4] = bytes_to_int(arg2)
00401ed1        arg1[5] = bytes_to_int(&arg2[4])
00401edd        arg1[6] = bytes_to_int(&arg2[8])
00401ee9        arg1[7] = bytes_to_int(&arg2[0xc])
00401ef5        arg1[8] = bytes_to_int(&arg2[0x10])
00401f01        arg1[9] = bytes_to_int(&arg2[0x14])
00401f0d        arg1[0xa] = bytes_to_int(&arg2[0x18])
00401f1d        arg1[0xb] = bytes_to_int(&arg2[0x1c])
00401f20        arg1[0xc] = 0
00401f27        arg1[0xd] = 0
00401f33        arg1[0xe] = bytes_to_int(arg3)
00401f42        arg1[0xf] = bytes_to_int(&arg3[4])
00401f4a        return arg1

This function takes a 32-byte array and an 8-byte array, and uses them alongside a 16-byte constant to initialize an array of 64 bytes. If you’ve reversed enough cryptography code before, you’ll likely recognize this as the initialization of a ChaCha20 matrix. Normally the constant used in ChaCha20 is the string expand 32-byte k, but I guess the challenge author thought that would be too easy to search for, so here it’s replaced by the custom constant 0xb979379e, 0x157c4a7f, 0x60c09cf3, 0x34c8ed5c.

Looking at where the ChaCha20 matrix is initialized, the nonce is hard-coded as 0a 0b 0c 0d 0e 0f 10 11, but the key is retrieved from a global variable.

00404059    char* __thiscall do_chacha_with_hprov_key(struct cipher_ctx* ctx, int32_t ciphertext)

00404069        char* ciphertext_buf = do_malloc(ctx->len)
00404077        memcpy(dest: ciphertext_buf, src: ciphertext, count: ctx->len)
00404087        int32_t counter_1 = ciphertext - *ctx->pc_ptr
0040408c        int64_t nonce
0040408c        nonce.d = 0xd0c0b0a
00404093        nonce:4.d = 0x11100f0e
0040409a        get_crypt_context()
004040ad        struct matrix matrix
004040ad        init_chacha_matrix_with_counter(&matrix, key: get_key_from_hprov(&hprov), &nonce, 
004040ad            counter0: 0, counter1: 0)
004040ba        chacha_rotated_counter(&matrix, counter_1, counter_2: 0)
004040c8        do_chacha_encrypt(&matrix, ciphertext: ciphertext_buf, len: 0x10)
004040d3        return ciphertext_buf

I found that the key was being stored alongside an HCRYPTPROV handle obtained from CryptAcquireContextA, and that other Crypto API functions were being called to generate the key itself.

00403388    BOOL __convention("regparm") hash_something_for_chacha_key(int32_t arg1, int32_t* arg2 @ ebp, char* arg3 @ esi, char* arg4 @ edi)

00403388        *0xff45c6 = arg1
00403395        arg2[-3] = 0
004033a5        get_dll_baseaddr()
004033aa        arg2[-5] = 0x40d1a0
004033b2        arg2[-4] = *arg2[-2]
004033c5        arg2[-5]
004033c8        BOOL result = do_CryptCreateHash(hProv: arg2[-4], Algid: 0x800c, hKey: 0, 
004033c8            dwFlags: 0, phHash: &arg2[-3])
004033c8        
004033cf        if (result != 0)
004033de            get_dll_baseaddr()
004033e3            arg2[-9] = 0x40d1a0
004033e9            arg2[-8] = arg2[-3]
004033f7            arg2[-9]
004033f7            
00403401            if (do_CryptHashData(hHash: arg2[-8], pbData: arg2[-7], dwDataLen: arg2[-6], 
00403401                    dwFlags: 0) != 0)
0040340c                arg2[-0xa] = 0x20
00403420                get_dll_baseaddr()
00403425                arg2[-0xc] = 0x40d1a0
0040342b                arg2[-0xb] = arg2[-3]
00403440                arg2[-0xc]
00403443                do_CryptGetHashParam(arg2[-0xb], 2, arg2[-2] + 4, &arg2[-0xa], 0)
00403443            
00403456            get_dll_baseaddr()
0040345b            arg2[-0xe] = 0x40d1a0
00403461            arg2[-0xd] = arg2[-3]
00403467            arg2[-0xe]
0040346a            result = do_CryptDestroyHash(arg2[-0xd])
0040346a        
00403473        *arg2
00403474        return result

Setting a breakpoint on CryptHashData, it turned out the ChaCha20 key was the SHA-256 hash of the .text section of the executable. This is an anti-debug measure, as setting software breakpoints changes the contents of .text.

When I tried dumping the .text section from the binary and hashing it, the resulting hash didn’t result in a valid decryption. Looking more closely in x64dbg at the data that was being hashed, I found that the last byte of the section had been changed from 0x00 to 0x90. Making the same change to my copy of the .text section, I got the correct key F630AA38D57297375D645559C334FD50D55CA1D177D2655A042351CF69244BF2. (For the actual decryption step, I used CryptoTester, which supports custom-constant ChaCha20 out of the box.)

Running the code

Single stepping

Now that I had the right key, I could see how the program tried to run the decrypted code. The program obtains the ChaCha20 key with a call to CryptGetHashParam, so I set a breakpoint on CryptGetHashParam’s return to patch in the correct hash. To make things easier, I eventually figured out that I could set the breakpoint to run a command to write to the hash address, so that I wouldn’t have to manually do the patch on every run. The syntax to do this in x64dbg is:

set 0x40d268,#F630AA38D57297375D645559C334FD50D55CA1D177D2655A042351CF69244BF2#

However, even with the correct key, the program didn’t decrypt and run the .pc section all at once. Instead, it only decrypted it 16 bytes at a time, and wrote only those few instructions to the buffer it had allocated for running shellcode.

004040ad        init_chacha_matrix_with_counter(&matrix, key: get_key_from_hprov(&hprov), &nonce, 
004040ad            counter0: 0, counter1: 0)
004040ba        chacha_rotated_counter(&matrix, counter_1, counter_2: 0)
004040c8        do_chacha_encrypt(&matrix, ciphertext: ciphertext_buf, len: 0x10)
004040d3        return ciphertext_buf

Moreover, the program seemed to only be running one instruction at a time before allocating a new shellcode buffer with VirtualAlloc. For example, out of the first 16 bytes that are decrypted, only the instruction mov eax,ecx is run at first.

3E4C0006 | 8BC1                     | mov eax,ecx                             |
3E4C0008 | C741 04 90B16E0A         | mov dword ptr ds:[ecx+4],A6EB190        |
3E4C000F | C700 00000000            | mov dword ptr ds:[eax],0                |
3E4C0015 | 0000                     | add byte ptr ds:[eax],al                |
3E4C0017 | 0000                     | add byte ptr ds:[eax],al                |
3E4C0019 | 0000                     | add byte ptr ds:[eax],al                |

Then, a new buffer is allocated to run the next instruction mov dword ptr ds:[ecx+4],A6EB190, and so on.

17100002 | C741 04 90B16E0A         | mov dword ptr ds:[ecx+4],A6EB190        |
17100009 | C741 08 336C4720         | mov dword ptr ds:[ecx+8],20476C33       |
17100010 | 0000                     | add byte ptr ds:[eax],al                |
17100012 | 0000                     | add byte ptr ds:[eax],al                |
17100014 | 0000                     | add byte ptr ds:[eax],al                |

In order to run a single instruction at a time before stopping execution, the program uses the same mechanisms that debuggers use to perform single steps. The CPU has a flag called the trap flag that tells it to execute a single instruction before raising an exception of type EXCEPTION_SINGLE_STEP. (You can see an example of how a debugger might use this flag here.) Sure enough, the trap flag is set before each run of the decrypted shellcode.

004037fa    uint32_t __stdcall set_context_flags(CONTEXT* arg1)

00403804        *(arg1->ContextFlags + 0x18) = 0
00403809        *(arg1->ContextFlags + 0x14) = 0
0040380e        *(arg1->ContextFlags + 4) = 0
00403811        uint32_t ContextFlags = arg1->ContextFlags
00403813        *(ContextFlags + 0xc0) |= 0x100
0040381e        return ContextFlags

Control flow obfuscation

Even after decryption, the decompilation of the .pc section didn’t make much sense. The code was full of int3 breakpoints, which were usually followed by nonsensical disassembly.

0040a0cb  mov     eax, dword [ebp-0x8]
0040a0ce  and     eax, 0x80000003
0040a0d3  int3    
0040a0d4  fisttp  dword [eax-0x7d], st0
0040a0d7  enter   0x40fc, 0x85
0040a0db  ror     ah, 0x38

Upon closer inspection in x64dbg, several bytes were being skipped each time the program executed an int3 breakpoint. For instance, after the breakpoint at 0x40a035 was executed, the next instruction to be run was the push dword ptr [ebp+8] instruction at 0x40a037, with the address 0x40a036 being skipped over entirely.

Looking at the exception handler code again, there were different functions for retrieving the next .pc instruction depending on whether the exception was an int3 breakpoint or a single step.

00404562    void __thiscall decrypt_from_exception(struct cipher_ctx* ctx, int32_t* exception, CONTEXT* context)

00404569        if (ctx->field_8 != 0)
00404569            return 
00404569        
00404574        if (*exception == STATUS_BREAKPOINT)
00404579            chacha_breakpoint(ctx, context)
00404574        else if (*exception == STATUS_SINGLE_STEP)
0040458b            chacha_single_step(ctx, context)
00404586        else if (*exception == STATUS_GUARD_PAGE_VIOLATION)
0040459a            CONTEXT* context_1 = context
0040459e            chacha_guard_page_violation(ctx, exception)

Unlike the single-step handler, which just set context->Eip to the next instruction before returning, the breakpoint handler called another function to determine the next instruction pointer before returning.

004042ec    int32_t __thiscall chacha_breakpoint(struct cipher_ctx* ctx, CONTEXT* context)

004042fe        if (sub_4037b2(ctx->field_24) == 0)
00404318            CONTEXT* exception_context = context
00404318            
00404328            if (check_context_eip_in_range(ctx, eip: exception_context->Eip) != 0)
0040432d                breakpoint_set_eip(ctx, exception_context)
00404332                CONTEXT* context_1 = context
00404335                uint32_t Eip = context_1->Eip
0040433b                uint32_t Eip_1 = Eip
0040433f                ctx->Eip = Eip
00404342                chacha_and_flush_cache(ctx, context: context_1)
004042fe        else
00404304            flush_instruction_cache(ctx, &context)
00404309            ctx->field_24
00404310            set_context_flags(&context)
00404310        
0040434d        return 0xffffffff

Looking at the breakpoint_set_eip function at 0x4045f3, it was retrieving a value from a map, then setting the next instruction to one of two locations pulled from that map.

004045f3    struct map_val* __thiscall breakpoint_set_eip(struct cipher_ctx* ctx, CONTEXT* exception_context)

004045f7        CONTEXT* exception_context_1 = exception_context
00404608        struct map_val* result =
00404608            get_map_data(ctx, key: (exception_context_1->Eip).w - (ctx->baseaddr).w)
00404608        
00404611        if (result != 0)
00404622            int32_t offset
00404622            
00404622            if (check_eflags(result, exception_context_1) == 0)
0040462c                offset = result->offset_2
00404622            else
00404627                offset = result->offset_1 + result->offset_2
00404627            
0040463c            flush_process_cache(ctx, &exception_context, offset + exception_context_1->Eip)
00404641            result.b = 1
00404611        else
00404613            result.b = 0
00404613        
00404647        return result

Dumping the map data from the debugger, it contained a long list of structures of four integer values. The first integer was the map key, corresponding to the address of the .pc instruction currently being executed (minus the base address of 0x400000). The third and fourth integers were the two choices of addresses to jump to.

00 A0 00 00 01 00 00 00 2F 00 00 00 02 00 00 00 
01 A0 00 00 12 00 00 00 49 00 00 00 02 00 00 00 
02 A0 00 00 0A 00 00 00 72 00 00 00 02 00 00 00 
03 A0 00 00 0A 00 00 00 43 00 00 00 02 00 00 00 
04 A0 00 00 05 00 00 00 5A 00 00 00 02 00 00 00 

The second integer, which was always a value between 1 and 18, was used for deciding which of the two offsets to jump to. Depending on its value, different combinations of the flags in the eflags register were checked, and the decision for where to jump was made based on the value of those flags.

00404166    uint32_t __stdcall check_eflags(struct map_val* arg1, CONTEXT* arg2)

00404172        uint32_t EFlags = arg2->EFlags
00404178        uint32_t choice = arg1->field_4 - 1
00404178        
0040417c        if (choice u> 0x11)
00404238            choice.b = 0
0040417c        else
00404182            switch (choice)
004041ea                case 0
004041ea                    EFlags u>>= 6  // ~ZF
004041ed                    goto get_negated_flag
00404234                case 1
00404234                    choice.b = 1
00404189                case 2
0040418c                    EFlags.b = (EFlags u>> 7).b & 1  // SF
0040418f                    choice.b = EFlags.b

// [...]

004041a2                case 0x10
004041a5                    if ((1 & (EFlags u>> 6).b) != 0)  // ZF
004041b7                        choice.b = 0
004041a5                    else
004041af                        // ~ (OF ^ SF)
004041af                        choice.b = (EFlags u>> 0xb).b ^ (EFlags u>> 7).b
004041af                        
004041b3                        if ((1 & choice.b) == 0)
004041b7                            choice.b = 1
004041b3                        else
004041b7                            choice.b = 0
0040418c                case 0x11
0040418c                    EFlags.b &= 1
0040418f                    choice.b = EFlags.b
0040418f        
0040423b        return choice

The combinations of flags that were being checked were, in fact, the exact combinations of flags that are checked in ordinary x86 branch instructions. For example, in the switch case above, case 0 corresponds to the condition ZF = 0, which is used in the conditional branch instruction JNZ. Similarly, case 0x10 corresponds to the condition ZF = 0 and SF = OF, which is the conditional JG.

Essentially, every single branch instruction in the .pc section had been replaced with a breakpoint, and the branch logic was being handled in the exception handler. Since this is a one-to-one replacement of one assembly instruction with another, the most logical way to deal with it would’ve been to patch the original branch instructions back in, except that the branch instructions were longer than the breakpoint instructions replacing them.

Reversing the check algorithm

Emulating with Unicorn

Since I couldn’t think of a good way to patch the binary in a way that would get me a reasonable-looking decompilation, I decided to try to emulate the .pc section in Unicorn, adding a hook to intercept the breakpoint instructions and resolve the branches. I had to hook a couple of external functions like strlen, but luckily there weren’t too many of those, so I didn’t have to do much extra work other than the usual boilerplate that comes with setting up Unicorn.

from unicorn import *
from unicorn.x86_const import *
from capstone import *
import struct

def to_int(b):
    return hex(int.from_bytes(b, 'little'))

jumps = { 0: 'jnz', 1: 'jmp', 2: 'js', 3: 'jae', 4: 'jle', 5: 'ja', 6: 'jge', 7: 'jp', 8: 'jo', 9: 'jbe', 10: 'jecxz', 11: 'jnp', 12: 'jz', 13: 'jl', 14: 'jns', 15: 'jno', 16: 'jg', 17: 'jb' }

def get_bit(val, bit):
    return (val >> bit) & 1

def get_branch_cond(cond, flags, ecx):
    if cond == 0: # jnz
        return get_bit(flags, 6) == 0
    elif cond == 1: # jmp
        return True
    elif cond == 2: # js
        return get_bit(flags, 7) != 0
    elif cond == 3: # jae
        return get_bit(flags, 0) == 0
    elif cond == 4: # jle
        return get_bit(flags, 6) == 0 or (get_bit(flags, 0xb) != get_bit(flags, 0x7))
    elif cond == 5: # ja
        return get_bit(flags, 6) == 0 and get_bit(flags, 0) == 0
    elif cond == 6: # jge
        return get_bit(flags, 7) == get_bit(flags, 0xb)
    elif cond == 7: # jp
        return get_bit(flags, 2) != 0
    elif cond == 8: # jo
        return get_bit(flags, 0xb) != 0
    elif(cond == 9): # jbe
        return get_bit(flags, 6) != 0 or get_bit(flags, 0) != 0
    elif(cond == 10): # jecxz
        return ecx == 0
    elif(cond == 11): # jnp
        return get_bit(flags, 2) == 0
    elif(cond == 12): # jz
        return get_bit(flags, 6) != 0
    elif(cond == 13): # jl
        return get_bit(flags, 0xb) != get_bit(flags, 0x7)
    elif(cond == 14): # jns
        return get_bit(flags, 7) == 0
    elif(cond == 15): # jno
        return get_bit(flags, 0xb) == 0
    elif(cond == 16): # jg
        return get_bit(flags, 6) == 0 and (get_bit(flags, 0xb) == get_bit(flags, 0x7))
    elif(cond == 17): # jb
        return get_bit(flags, 0) != 0
    else:
        raise ValueError("invalid condition", cond)

offsets = {}
f = open('data.bin', 'rb').read()
for i in range(0, len(f), 0x10):
    data = f[i:i+0x10]
    key, cond, jump, base = struct.unpack('<4i', data)
    offsets[key + 0x400000] = (cond, jump, base)

def emu_push(mu: Uc, val):
    esp = mu.reg_read(UC_X86_REG_ESP)
    mu.mem_write(esp - 4, val.to_bytes(4, 'little'))
    mu.reg_write(UC_X86_REG_ESP, esp - 4)

def emu_pop(mu: Uc):
    esp = mu.reg_read(UC_X86_REG_ESP)
    val = mu.mem_read(esp, 4)
    mu.reg_write(UC_X86_REG_ESP, esp + 4)
    return int.from_bytes(val, 'little')

def emu_return(mu: Uc):
    ret_addr = emu_pop(mu)
    mu.reg_write(UC_X86_REG_EIP, ret_addr)

def hook_strlen(uc):
    print('Skipping strlen function')
    uc.reg_write(UC_X86_REG_EAX, 0x13)

def hook_crypt(uc):
    #print('Skipping crypto setup')
    uc.reg_write(UC_X86_REG_EAX, HPROV)

def hook_hash(uc):
    #print('Skipping hash function')
    uc.reg_write(UC_X86_REG_EAX, MEM)

def hook_pass(uc):
    pass

def hook_mem_write(mu: Uc, access, address, size, value, user_data):
        data_bytes = value.to_bytes(size, 'little')
        print(f'[{hex(mu.reg_read(UC_X86_REG_EIP))}] Address {hex(address)}: Wrote {data_bytes.hex()}')

def hook_mem_read(mu: Uc, access, address, size, value, user_data):
    if address >= MEM and address < MEM + 0x10:
        data_bytes = mu.mem_read(address, size)
        print(f'[{hex(mu.reg_read(UC_X86_REG_EIP))}] Address {hex(address)}: Read {data_bytes.hex()}')

def hook_code(mu: Uc, address, size, user_data):
    for i in md.disasm(mu.mem_read(address, size), address):
        print("0x%x:\t%s\t%s" % (i.address, i.mnemonic, i.op_str))
        print('\teax:', hex(mu.reg_read(UC_X86_REG_EAX)))
        print('\tebx:', hex(mu.reg_read(UC_X86_REG_EBX)))
        print('\tecx:', hex(mu.reg_read(UC_X86_REG_ECX)))
        print('\tedx:', hex(mu.reg_read(UC_X86_REG_EDX)))
        ebp = mu.reg_read(UC_X86_REG_EBP)
        esp = mu.reg_read(UC_X86_REG_ESP)
        print(f'\tebp: {to_int(mu.mem_read(ebp, 4))}  ebp - 4: {to_int(mu.mem_read(ebp - 4, 4))}    ebp - 8: {to_int(mu.mem_read(ebp - 8, 4))}    ebp - c: {to_int(mu.mem_read(ebp - 0xc, 4))}    ebp - 10: {to_int(mu.mem_read(ebp - 0x10, 4))}    ebp - 0x14: {to_int(mu.mem_read(ebp - 0x14, 4))}')
        print(f'\tstack: +0: {to_int(mu.mem_read(esp, 4))}    +4: {to_int(mu.mem_read(esp + 4, 4))}    +8:  {to_int(mu.mem_read(esp + 8, 4))}     +c: {to_int(mu.mem_read(ebp + 0xc, 4))} ')

        if i.mnemonic == 'call': # skip external function calls
            target = i.operands[0].imm
            if target in hooks:
                hooks[target](mu)
                mu.reg_write(UC_X86_REG_EIP, i.address + i.size)

def hook_interrupt(mu: Uc, intno, user_data):
    if intno == 3:
        eip = mu.reg_read(UC_X86_REG_EIP) - 1
        cond, jump, base = offsets[eip]
        not_taken_addr = eip + base
        taken_addr = eip + base + jump
        #print(hex(eip), hex(not_taken_addr), hex(taken_addr))

        ecx = mu.reg_read(UC_X86_REG_ECX)
        flags = mu.reg_read(UC_X86_REG_EFLAGS)

        should_branch = get_branch_cond(cond - 1, flags, ecx)
        if should_branch:
            print(f'Branch {jumps[cond - 1]} taken: {hex(taken_addr)}')
            mu.reg_write(UC_X86_REG_EIP, taken_addr)
        else:
            print(f'Branch {jumps[cond - 1]} not taken: {hex(not_taken_addr)}')
            mu.reg_write(UC_X86_REG_EIP, not_taken_addr)


sc = open('shellcode.bin', 'rb').read()

md = Cs(CS_ARCH_X86, CS_MODE_32)
md.detail = True

hooks = {
    0x409731: hook_strlen,
    0x403477: hook_crypt,
    0x40a4b5: hook_hash
}

BASE = 0x40a000
BASE_SIZE = 1024*1024
STACK_ADDR = 0x40000000
STACK_SIZE = 1024*1024

MEM = 0x60000000
MEM_SIZE = 1024*1024

HPROV = MEM + 0x100
CONSTS = MEM + 0x2000

def emu(start):
    mu = Uc(UC_ARCH_X86, UC_MODE_32)

    mu.mem_map(STACK_ADDR, STACK_SIZE)
    mu.reg_write(UC_X86_REG_ESP, STACK_ADDR + STACK_SIZE // 2)
    mu.reg_write(UC_X86_REG_EBP, STACK_ADDR + STACK_SIZE // 2 - 0x1000)

    mu.mem_map(MEM, MEM_SIZE)
    mu.mem_write(MEM, b'ABCD-4567-89ab-cdef')
    mu.mem_write(STACK_ADDR + STACK_SIZE // 2 + 4, MEM.to_bytes(4, 'little'))

    KEY = bytes.fromhex('F630AA38D57297375D645559C334FD50D55CA1D177D2655A042351CF69244BF2')
    mu.mem_write(HPROV + 4, KEY)
    mu.mem_write(HPROV + 0x24, (MEM+0x1000).to_bytes(4, 'little'))
    mu.mem_write(HPROV + 0x28, b'\x00\x8a\x00\x00')

    mu.mem_write(CONSTS, bytes.fromhex('47bb5d8690b16e0a336c472093768a1cfbbdfe59'))
    mu.reg_write(UC_X86_REG_ECX, CONSTS)

    mu.mem_map(BASE, BASE_SIZE)
    mu.mem_write(BASE, sc)

    mu.hook_add(UC_HOOK_CODE, hook_code)
    mu.hook_add(UC_HOOK_INTR, hook_interrupt)

    mu.hook_add(UC_HOOK_MEM_READ, hook_mem_read)

    mu.emu_start(start, BASE+BASE_SIZE)

emu(0x40a025)

Unfortunately, this approach turned out to be largely unhelpful. I could tell that the serial was supposed to be 19 characters long (consistent with something of the format XXXX-XXXX-XXXX-XXXX), and that the characters were being hashed in groups of four, but the hash algorithm didn’t match up with anything I recognized.

I did notice that the .pc section started with a function that loaded five random-looking values, though, so I figured those were the target values for the hash.

0040a000    int32_t* __convention("fastcall") sub_40a000(int32_t* arg1)

0040a000  c70147bb5d86       mov     dword [ecx], 0x865dbb47  {0x865dbb47}
0040a006  8bc1               mov     eax, ecx
0040a008  c7410490b16e0a     mov     dword [ecx+0x4], 0xa6eb190
0040a00f  c74108336c4720     mov     dword [ecx+0x8], 0x20476c33
0040a016  c7410c93768a1c     mov     dword [ecx+0xc], 0x1c8a7693
0040a01d  c74110fbbdfe59     mov     dword [ecx+0x10], 0x59febdfb
0040a024  c3                 retn     {__return_addr}

Fixing the decompilation

After a while I gave up on emulation and came back to the idea of trying to decompile the code again. I couldn’t figure out a way to patch in the branch instructions without overwriting too many other instructions, so instead I decided to see if I could modify the Binary Ninja IL somehow.

In Binary Ninja, the code to be decompiled is lifted through several different forms of IL as it’s being processed. In theory, there are APIs to edit IL instructions at any stage of the analysis process. Since the modification I wanted to make was supposed to be equivalent to a simple binary patch, I thought it would make the most sense to modify the lowest level of IL, called Lifted IL. However, when I looked through the documentation on how to do so, I found that it explicitly advised against it:

You probably do not want to modify Lifted IL with a Workflow. Instead, consider modifying the Architecture directly (most of which are Open Source on our GitHub) or making your Activity modify Low Level IL.

“Modifying the Architecture directly” sounded promising, so I looked at how the x86 architecture plugin generated IL instructions.

The code for how breakpoints were handled turned out to be very straightforward: for each INT3 breakpoint instruction, a single IL breakpoint instruction is emitted. To fix it, I would need to modify that line to emit an IL branch instruction instead.

case XED_ICLASS_INT3:
	il.AddInstruction(il.Breakpoint());
	break;

Conveniently, the code for handling branch instructions is right next to the breakpoint code, and it includes a convenient switch case listing all the ways to construct an IL conditional branch from its corresponding x86 branch.

case XED_ICLASS_JO:
	ConditionalJump(arch, il, il.FlagCondition(LLFC_O), addrSize, branchDestination, addr + instLen);
	return false;

case XED_ICLASS_JNO:
	ConditionalJump(arch, il, il.FlagCondition(LLFC_NO), addrSize, branchDestination, addr + instLen);
	return false;
	
// [...]

case XED_ICLASS_JECXZ:
	ConditionalJump(arch, il, il.CompareEqual(4, il.Register(4, XED_REG_ECX), il.Const(4, 0)), addrSize, branchDestination, addr + instLen);
	return false;

case XED_ICLASS_JRCXZ:
	ConditionalJump(arch, il, il.CompareEqual(8, il.Register(8, XED_REG_RCX), il.Const(8, 0)), addrSize, branchDestination, addr + instLen);
	return false;

To generate the branch instructions, I started by adding a hard-coded map of all the breakpoint addresses in the .pc section and their corresponding branch types, as well as an enum containing all the conditions.

#include <map>
#include <cstdint>

struct CrackmeCond {
    int cond;
    int not_taken;
    int taken;
};

const uint64_t CRACKME_SC_START = 0x40a000;
const uint64_t CRACKME_SC_END = 0x40a5ff;

enum class JumpCond: int {
    JNZ = 0,
    JMP,
    JS,
    JAE,
    JLE,
    JA,
    JGE,
    JP,
    JO,
    JBE,
    JECXZ,
    JNP,
    JZ,
    JL,
    JNS,
    JNO,
    JG,
    JB
};

std::map<int, CrackmeCond> conds = {
    { 0x40a000, { 1, 2, 49 } },
    { 0x40a001, { 18, 2, 75 } },
    { 0x40a002, { 10, 2, 116 } },
    { 0x40a003, { 10, 2, 69 } },
    { 0x40a004, { 5, 2, 92 } },
    { 0x40a005, { 3, 2, 34 } },
    { 0x40a006, { 18, 2, 161 } },
    // [...]
    { 0x40a5fd, { 7, 2, 130 } },
    { 0x40a5fe, { 13, 2, 52 } },
    { 0x40a5ff, { 13, 2, 46 } },
};

I then modified the breakpoint handling code to add a switch case modeled after Binary Ninja’s own code for handling x86 conditional branch instructions, calling ConditionalJump with the arguments I had parsed out of the map whenever a breakpoint fell within the range of addresses in the .pc section.

case XED_ICLASS_INT3:
	if(addr >= CRACKME_SC_START && addr < CRACKME_SC_END)
	{
		const auto cond_struct = conds[addr];
		const auto cond = static_cast<JumpCond>(cond_struct.cond - 1);
		const auto taken_addr = addr + cond_struct.taken;
		const auto not_taken_addr = addr + cond_struct.not_taken;

		switch(cond) 
		{
			case JumpCond::JMP:
				il.AddInstruction(il.Jump(il.ConstPointer(addrSize, taken_addr)));
				break;

			case JumpCond::JO:
				ConditionalJump(arch, il, il.FlagCondition(LLFC_O), addrSize, taken_addr, not_taken_addr);
				break;

				// [...]

			case JumpCond::JECXZ:
				ConditionalJump(arch, il, il.CompareEqual(4, il.Register(4, XED_REG_ECX), il.Const(4, 0)), addrSize, taken_addr, not_taken_addr);
				break;

			default:
				il.AddInstruction(il.Breakpoint());	
		}
	}
	else
	{
		il.AddInstruction(il.Breakpoint());	
	}

	break;

After making this modification, the LLIL breakpoint instructions were replaced with LLIL branches, which repaired the control flow of the binary.

6 @ 0040a02e  [ebp - 0x14 {var_18}].d = ecx
7 @ 0040a031  [ebp + 8 {serial}].d
8 @ 0040a035  breakpoint

6 @ 0040a02e  [ebp - 0x14 {var_18}].d = ecx
7 @ 0040a035  if ([ebp + 8 {serial}].d == 0) then 8 @ 0x40a045 else 10 @ 0x40a037

This worked far better than I expected it to, resulting in coherent decompilation! It wasn’t perfect by any means, but it was good enough for me to reimplement the algorithm. The trace I’d printed out from Unicorn turned out to be helpful after all, as it gave me values to test against in the steps where the decompilation was ambiguous.

0040a025    int32_t __stdcall do_check(int32_t arg1 @ ecx, int32_t serial)

0040a025        int32_t ebp
0040a025        int32_t var_4 = ebp
0040a026        struct struct_1* ebp_1 = &var_4
0040a02b        void* entry_ebx
0040a02b        void* var_28 = entry_ebx
0040a02c        int32_t entry_esi
0040a02c        int32_t var_2c = entry_esi
0040a02d        int32_t edi
0040a02d        int32_t var_30 = edi
0040a02d        int32_t* esp_1 = &var_30
0040a02e        int32_t var_18 = arg1
0040a035        int32_t result
0040a035        
0040a035        if (serial == 0)
0040a045            result.b = 0
0040a035        else
0040a03f            esp_1 = &var_30
0040a03f            
0040a043            if (0x409731(serial) == 0x13)
0040a04c                int32_t var_8_1 = 0
0040a053                int32_t var_c_1 = 0
0040a05a                int32_t var_14_1 = 0
0040a061                int32_t var_10_1 = 0xcafebabe
0040a061                
0040a06f                while (true)
0040a06f                    sub_40a4b5(0x403477())
0040a06f                    
0040a080                    if (ebp_1->serial_char == 0)
0040a08a                        ebp_1->serial_char = 1
0040a080                    else if (ebp_1->serial_char == 1)
0040a0ae                        *(esp_1 - 4) = zx.d(*(ebp_1->acc + ebp_1->count))
0040a0af                        *(esp_1 - 8) = ebp_1->i
0040a0ba                        ebp_1->i = do_char_hash(ebp_1->field_c)
0040a0c1                        ebp_1->count += 1
0040a0ce                        int32_t done_yet = ebp_1->count & 0x80000003
0040a0ce                        
0040a0d3                        if (done_yet s< 0)
0040a0d9                            done_yet = ((done_yet - 1) | 0xfffffffc) + 1
0040a0d9                        
0040a0dc                        if (done_yet == 0)
0040a0e6                            // go to compare-and-multiply
0040a0e6                            ebp_1->serial_char = 2
0040a0dc                        else if (ebp_1->count != 0x13)
0040a10f                            // if not all chars hashed, resume loop
0040a10f                            ebp_1->serial_char = 1
0040a0f3                        else
0040a0fe                            ebp_1->serial_char = 3
0040a09a                    else if (ebp_1->serial_char != 2)  // state 3: check
0040a178                        if (ebp_1->serial_char != 3)
0040a178                            break
0040a178                        
0040a17a                        *(esp_1 - 4) = 4
0040a186                        ebp_1->field_0 = ebp_1->field_c[*(esp_1 - 4)]
0040a199                        int32_t check_result = ebp_1->field_10 | (ebp_1->i ^ ebp_1->field_0)
0040a19b                        ebp_1->field_10 = check_result
0040a19b                        
0040a19e                        if (check_result != 0)
0040a1a9                            ebp_1->serial_char = 5  // wrong
0040a19e                        else
0040a1a0                            ebp_1->serial_char = 4  // right
0040a11f                    else  // state 2: get compare val and multiply
0040a124                        void* eax_11
0040a124                        int32_t edx_1
0040a124                        edx_1:eax_11 = sx.q(ebp_1->count)
0040a12a                        unimplemented  {sar eax, 0x2}
0040a12e                        ebp_1->field_8 = ((eax_11 + (edx_1 & 3)) s>> 2) - 1
0040a13a                        // save compare_val into ebp_1 - 0x1c?
0040a13a                        ebp_1->field_4 = *(ebp_1->field_c + (ebp_1->field_8 << 2))
0040a151                        ebp_1->field_10 |= ebp_1->i ^ ebp_1->field_4
0040a168                        ebp_1->i = ebp_1->count * 0x112233 - 0x35014542
0040a16b                        ebp_1->serial_char = 1
0040a16b                
0040a1b6                if (ebp_1->serial_char != 4)
0040a1be                    result.b = 0
0040a1b6                else
0040a1b8                    result.b = 1
0040a043            else
0040a045                result.b = 0
0040a045        
0040a1c7        *esp_1
0040a1c7        esp_1[1]
0040a1c8        esp_1[2]
0040a1ca        ebp_1->field_20
0040a1cb        return result

Reimplementation

The hash was a weird ad-hoc algorithm that made different decisions about how to process each character depending on certain ranges of values that it fell into. This means that the initial approach I took with Unicorn would never have worked very well on its own, as the flow of execution is completely different depending on whether each of the characters in the serial are letters, numbers, special characters and so on. There’s even a special case that specifically handles the character 0x30.

The presence of all the weird conditionals also means that the hash can’t be cracked using constraint solvers. (My initial reimplementation of the algorithm was in Python with the intent of solving it with z3, which resulted in confusing error statements like Symbolic expressions cannot be cast to concrete Boolean values.) Luckily, only 4 characters are hashed at a time, so I rewrote my implementation in C and bruteforced each group of characters.

#include <stdio.h>
#include <stdint.h>

uint32_t hash_round(uint32_t acc, uint32_t c) {
    if((acc & 1) != 0) {
        if((acc ^ c) <= 0x80000000) {
            if((c >= 0x61) && (c <= (0x61 + 26))) {
                acc -= c;
            }
            else if((c < 0x41) || (c > (0x41 + 26))) {
                acc *= 9;
            }
            else {
                acc += c;
                if((acc & 0x100) != 0) {
                    acc ^= 0x13371337;
                }
            }
        }
        else if(c > 0x60) {
            acc = (c * 0x21) ^ (acc + 0xdeadbeef);
        }
        else {
            acc += 0xdeadbeef;
        }
    }
    else {
        if(c >= 0x40) {
            if(c % 2 != 0) {
                acc = ((acc >> 5) | (acc << 0x1b)) ^ 0x87654321;
            }
            else {
                acc = ((acc << 3) | (acc >> 0x1d)) + 0x12345678;
            }
        }
        else if((c & 2) == 0) {
            acc -= (c << 4);
            if(c == 0x30) {
                acc |= 0xf0f0f0f0;
            }
        }
        else {
            acc ^= 0x55aa55aa;
            acc += c;
        }
    }

    uint32_t mod_5 = (c % 5) + 2;
    for(uint32_t i = 0; i < mod_5; i++) {
        if((acc & 0x80000000) == 0) {
            acc <<= 1;
        }
        else {
            acc = (acc << 1) ^ 0x4c11db7;
        }

        uint32_t mask = i & 0x80000001;
        if(mask != 0) {
            acc += i * 0xa;
        }
        else {
            acc ^= c;
        }
    }

    uint32_t count = acc;
    count ^= (count >> 0x10);
    count ^= (count >> 0x8);

    if((count & 0xf) > 7) {
        acc = ~acc;
    }

   return acc;
}

uint32_t hash(char* data, uint32_t pos, uint32_t len) {
    uint32_t acc = 0xcafebabe + 0x112233 * 4 * pos;
    for(uint32_t i = 0; i < len; i++) {
        acc = hash_round(acc, data[i]);
    }

    return acc;
}

int check_val(uint32_t expected, uint32_t pos, uint32_t len) {
    for(char i = 0x20; i < 0x7f; i++) {
        //printf("trying %x\n", i);
        for(char j = 0x20; j < 0x7f; j++) {
            for(char k = 0x20; k < 0x7f; k++) {
                for(char l = 0x20; l < 0x7f; l++) {
                    char to_try[4] = {i, j, k, l};
                    uint32_t acc = hash(to_try, pos, len);
                    if(acc == expected) {
                        printf("%c%c%c%c", i, j, k, l);
                        return 0;
                    }
                }
            }
        }
    }

    return -1;
}

int main() {
    uint32_t compares[5] = {0x865dbb47, 0xa6eb190, 0x20476c33, 0x1c8a7693, 0x59febdfb};

    for(int i = 0; i < 4; i++) {
        if(check_val(compares[i], i, 4) == -1) {
            return -1;
        }
    }

    if(check_val(compares[4], 4, 3) == -1) {
        return -1;
    }

    return 0;
}

This gets us the serial: D3FE-A7ED-BAAD-C0D3. Entering it into the crackme, we finally have our flag!

CMO{byp4ss3d_f4tm1k3_2o26}

Note: After the CTF, I found out that the control flow obfuscation came from an obfuscator called Nanomites, the source code of which was on the challenge author’s GitHub long before the CTF started. I’ll have to remember to check for that next time.

The crackme I used was The Obfuscator’s Riddle, an obfuscated binary of medium difficulty. My goal was to solve the crackme entirely statically by using IL modification to produce a clean decompilation. Unfortunately, I didn’t succeed at doing this, but there are so few writeups on IL modification that it’s still probably helpful to document everything that I tried. Also, I want to come back to this project at some point, and if I write it all down in a blog post I’ll at least have a prayer of remembering what I was doing.

I did manage to deobfuscate the binary, but it was through binary patching, not IL modification. The patching script and the solution to the crackme are included at the end ofthe writeup.

Challenge Overview

As usual for these types of challenges, we’re prompted for a password:

140001081        write_console("Enter password: ", 0x10)
140001091        int128_t buffer = zx.o(0)
140001099        uint32_t numberOfCharsRead[0x6]
140001099        numberOfCharsRead[0] = 0
1400010ad        uint64_t rbx = 0x10
1400010c1        ReadConsoleA(hConsoleInput: GetStdHandle(nStdHandle: STD_INPUT_HANDLE), 
1400010c1            lpBuffer: &buffer, nNumberOfCharsToRead: 0x10, 
1400010c1            lpNumberOfCharsRead: &numberOfCharsRead, pInputControl: nullptr)

However, after the password prompt we’re faced with a long switch statement that has 0xef different cases. At the end of each case, the variable rax_2 is set to a different value between 0 and 0xef, followed by a jump to a “dispatcher” block at 0x31b8. Weirdly, Binary Ninja didn’t decompile the switch case at first, but rebasing to a base address of 0 fixed it.

0000119d            switch (rcx_5)
000011ca                case 1
000011ca                    rax_2.b = 0xbe
000011cc                    goto label_31b8
0000211b                case 3
0000211b                    rax_2.b = 0xb5
0000211d                    goto label_31b8
00001d9c                case 4
00001d9c                    rax_2.b = 0xe7
00001d9e                    goto label_31b8
00002d8e                case 5
00002d8e                    rax_2.b = 0x2b
00002d90                    goto label_31b8
000015e8                case 6
000015e8                    rax_2.b = 0x15
000015ea                    goto label_31b8

This is a classic case of control flow flattening. rax_2 stores a state variable that’s used as an offset into a jump table, and the dispatcher at 0x31b8 jumps to the address stored at [jumptable base address] + 4 * rax_2. Since the decompiler doesn’t understand how the state variable is used by the dispatcher to calculate where to jump next, it can’t reconstruct the control flow graph of the binary, leading to a “flattened” view where every basic block ends with a jump to the dispatcher. (If you’re unfamiliar with control flow flattening, there are a lot of detailed writeups on different forms of it, like this one from OLLVM or this one from Tigress.)

Binary Ninja IL Modification

Patching with JUMP instructions

My first thought was to look through the MLIL for jumps to the dispatcher block, then replace them with direct jumps to the target address that would be calculated within the dispatcher block based on the state variable. Finding the jumps was easy, as the jumps to the dispatcher block followed a predictable pattern of setting the al register to the next state value, followed by a jump to the dispatcher:

70 @ 000011b5  rax_2.al = 0x2c
71 @ 000011b7  goto 1026 @ 0x31b8

This made it relatively easy to write a function to check whether a set of two MLIL instructions corresponded to a CFF-obfuscated jump.

def is_cff(first, second):
    if len(first.operands) < 3 or len(second.operands) < 1:
        return False
    if second.operands[0] != DISPATCHER_LOC:
        return False
    if type(first) != MediumLevelILSetVarField or type(second) != MediumLevelILGoto:
        return False
    if type(first.operands[0]) != Variable or type(first.operands[2]) != MediumLevelILConst:
        return False
    return True

I then tried searching through the MLIL to find all instances of the CFF pattern, using the replace_expr function to replace the jumps to the dispatcher with jumps to the target address. (Like a lot of the other IL modification functions, the instruction to be replaced by replace_expr is specified by its “expression index”. Notably, the expression index of an instruction is not the index where the instruction appears in the IL: the first MLIL instruction in the crackme binary has expression index 4, not 0. The expression indices 0 through 3 are actually assigned to the the operands of the first instruction, which are themselves expressions.)

for block in analysis_context.mlil.basic_blocks:
    for i in range(len(block) - 1):
        first = block[i]
        second = block[i + 1]

        if is_cff(first, second):
            idx = first.operands[2]
            jump_target = JUMPTABLE_ADDR + bv.read_int(JUMPTABLE_ADDR + 4 * idx.value.value, 4)
            log_info(f'Found jump offset {hex(idx.value.value)} at address {hex(first.address)}')

            analysis_context.mlil.replace_expr(second.expr_index, analysis_context.mlil.jump(analysis_context.mlil.const(8, jump_target)))
            log_info(f'Replaced jump at {hex(second.address)} with jump to {hex(jump_target)}')

I then added the modification function as a step in the analysis workflow so that it would be called whenever a function was analyzed. Most of the examples of MLIL modification suggest inserting the modification step right after core.function.generateMediumLevelIL, but when I tried to do this, I got an exception in core.function.analyzeIndirectBranches step with the message invalid access to LLIL instruction. I’m not sure why this happened, but I’m guessing it’s because the new MLIL instructions inserted into the function aren’t actually backed by any underlying LLIL instructions. Inserting the modification function after core.function.analyzeIndirectBranches fixed the issue.

wf = Workflow("core.function.metaAnalysis").clone("core.function.metaAnalysis")

wf.register_activity(Activity(
    configuration=json.dumps({
        "name": "extension.fix_cff",
        "title": "Fix CFF",
        "description": "Replace control flow flattening instructions with direct jumps.",
        "eligibility": {
            "auto": {
                "default": True
            }
        }
    }),
    action=fix_cff
))

wf.insert_after("core.function.analyzeIndirectBranches", [
    "extension.fix_cff"
])

wf.register()

In general, it seems like IL modification is somewhat experimental, with very little error handling when things go wrong. I ran into some difficult-to-diagnose errors, especially when I tried modifying LLIL rather than MLIL - sometimes Binary Ninja would segfault, and other times the analysis workflow appeared to get stuck in an infinite loop of analyzing and reanalyzing. My guess is a lot of these problems have to do with the fact that my IL modifications resulted in major changes to the control flow, and that IL modification might work better if I used it to clean up data-level obfuscation (e.g., opaque constants) as opposed to control flow obfuscation.

This was the working script that I ended up with:

DISPATCHER_LOC = 380
JUMPTABLE_ADDR = 0x418c

def is_cff(first, second):
    if len(first.operands) < 3 or len(second.operands) < 1:
        return False
    if second.operands[0] != DISPATCHER_LOC:
        return False
    if type(first) != MediumLevelILSetVarField or type(second) != MediumLevelILGoto:
        return False
    if type(first.operands[0]) != Variable or type(first.operands[2]) != MediumLevelILConst:
        return False
    return True
 
def fix_cff(analysis_context: AnalysisContext):
    log_info(f"Starting CFF replacement for function {analysis_context.function}")

    for block in analysis_context.mlil.basic_blocks:
        for i in range(len(block) - 1):
            first = block[i]
            second = block[i + 1]

            if is_cff(first, second):
                idx = first.operands[2]
                jump_target = JUMPTABLE_ADDR + bv.read_int(JUMPTABLE_ADDR + 4 * idx.value.value, 4)
                log_info(f'Found jump offset {hex(idx.value.value)} at address {hex(first.address)}')

                analysis_context.mlil.replace_expr(second.expr_index, analysis_context.mlil.jump(analysis_context.mlil.const(8, jump_target)))
                log_info(f'Replaced jump at {hex(second.address)} with jump to {hex(jump_target)}')

    analysis_context.mlil.finalize()
    analysis_context.mlil.generate_ssa_form()


wf = Workflow("core.function.metaAnalysis").clone("core.function.metaAnalysis")

wf.register_activity(Activity(
    configuration=json.dumps({
        "name": "extension.fix_cff",
        "title": "Fix CFF",
        "description": "Replace control flow flattening instructions with direct jumps.",
        "eligibility": {
            "auto": {
                "default": True
            }
        }
    }),
    action=fix_cff
))

wf.insert_after("core.function.analyzeIndirectBranches", [
    "extension.fix_cff"
])

wf.register()