Writeups – Diary, Isoar (Midnight Sun CTF Quals)

This weekend, I attended the BSides Australia 2018 conference. This was another iteration on an already excellent con, with numbers expanding year on year. It is always good to have the opportunity to meet up with people I haven’t seen in a long time: I probably had more productive meetings on the second day of the con than one entire week at my day job.

On Sunday, I participated in the Midnight Sun CTF Quals. This was a well-structured CTF, with a good variety of challenges leaning towards the difficult end. Unfortunately, I was only able to solve a few challenges: here are the writeups for them:


The Diary challenge was presented as an archive, containing a Git repository, which you can download here.

In this archive, there is “diary.txt” and “wishlist.txt”. Opening up “diary.txt” reveals the following:

Unfortunately, the Git repository seems to be corrupted:

A little bit of Google reveals a way around this: we run “git fsck”, revealing an interesting dangling commit:

We can directly check out the dangling commit despite the git log being broken, and then git checkout to the entry pointing to April 11th, revealing the flag:


The Isoar challenge was presented as a web application, allowing users to check the strength of their password against a list of 1001 passwords, one of which is the administrator’s password.

When a password is submitted, the page returns one “fact” about the password, and a score:

The goal was to obtain the administrator’s password. Inspecting the page source, we can see some interesting files:

The “app.js” file shows us how to check for a user’s password and how to log in, while “pwmeter.js” is an obfuscated JavaScript file which shows us how to generate a proof of work for these actions (based off a randomly salted SHA hash of the password you want to test).

A little bit of further exploration reveals 1000 of the passwords, in the file “/public.password.list”.

From here, we have enough to execute the attack: we simply generate “test” requests for a given character, say “a”, until it tells us how many passwords (from the list of 1001) are suffixed with “a”: we then check this against the list of known passwords. We repeat this for each character, until one of the results does not match our own generated results – we instantly know that this is the suffix of the administrator’s password.

Two hours of brute forcing later, and we know the administrator’s password ends with “rHolyP4ssw0rd”. Some guesswork later, and we get the flag by submitting a login request with “H3rHolyP4ssw0rd”:

You can find the Python scripts I used for this solution here and here.

Thankyou to the organisers of this CTF – I enjoyed this experience. That said, I grow weary of competing by myself once more – it is my intention to restart farmingsimulator2015 (in one form or another). More thoughts on this later – the clock ticks on for WPICTF, and my projects won’t complete themselves.

See you in WPICTF.

Posted in Bards, Computers, Jesting | Leave a comment

Writeups – Hastad, Triptych (UIUCTF)

This weekend, I participated in the UIU CTF. This was a challenging but well-crafted CTF with a good range of challenges: disappointingly, I was only able to solve two challenges in the time allocated. Without further ado, writeups.


This challenge was presented as two text files, with a note which mentions that “e=3”. This is a dead give-away that this is some twist on Hastad’s broadcast attack, where you can recover a plaintext if the same message is sent with 3 or more keys, and ‘e’ is small.

I had a look for public implementations of this attack, and many existed – but all of them needed a number of ciphertexts and a number of public key moduli – we had 3 moduli, but a large number of ciphertexts.

A few moments of brute force, courtesy if Python’s excellent itertools, and we have our solution.


This challenge was presented as an ELF executable, which you can download here.

Opening this up in IDA pro, we are greeted with our first sign of the type of trolling to be inflicted in this challenge:

Right, self-modifying code it is. If we follow the code down a bit further, we can see the self-decrypting code in the_first:

Following this a bit further, we can see the mangled original code in the_second:

This looks like it’d be a hassle to decrypt manually, but it doesn’t take any input from the user or the environment – so it’s a safe bet to simply let the program run, breakpoint at this instruction, and decrypt, breaking at 0x400ACD (the call to the_second, instead of the_second: if gdb implements breakpoints by placing 0xCC in the broken function, a decryption loop will erase the breakpoint).

This yields our decrypted version:

We can see that this is likely a repeat of the first function. We can use IDA’s “Load Additional Binary” feature to patch the application and create a new disassembly of the_second:

This repeats an additional time, until we call validate at 0x4006A6. At this time, I thought it would be a good idea to dump a patched executable and solve it with angr: I attempted to patch the call at 0x400B40 (in main) to directly call a decrypted validate at 0x4006A6, and use “Apply patches to input file” (Edit -> Patch Program) to write a new executable which directly called validate with no funny business, but I discovered that the decrypted functions, loaded via “Load Additional Binary”, didn’t count as patches, and therefore, weren’t written to disk.

At this point, I reviewed the validate function in IDA. At a high level, it looked like a three-layer character substitution cipher, something like the following:

The simple solve for this is to create a lookup table. We can do this by breakpointing the character compare function at 0x4007CE: we pass in a string of “a-z”, and we see what it comes out with. We should be able to determine what ciphertext corresponds to each character, and using this, derive the original key the validate function is checking for.

You can find the solution here.

As always, thankyou to the UIU CTF organisers for putting together this event. While it’s disappointing that I was only able to solve so few challenges, it is only through being humbled that we continue to grow.

For those of you attending BSides, see you all at BSides next week. For everyone else, see you in WPI CTF.

Posted in Bards, Computers, Jesting | 5 Comments

Writeups – So_Stealthy, Rescue Shell (Nuit Du Hack Quals)

Yesterday, I participated in the Nuit Du Hack Quals. In hindsight, I should’ve played this all day – this was a good CTF quality-wise, with a good variety of challenges and infrastructure which seemed to remain online.

I will present two writeups below, for posterity.


This challenge was presented as a PCAP file, which you can download here. The objective was to reverse engineer some malware included in the pcap. At a glance in wireshark, most data is HTTP or HTTPS traffic: so we start by extracting all the HTTP/HTTPS objects:

I don’t have an consistent way to attempt these “needle-in-a-haystack” style problems (is there one?), so I went with a manual approach, running “strings” across each of the extracted objects.

Eventually, I identified an odd-looking favicon(1).ico, comprised of obfuscated JS:

I quickly extracted the base64, which turned out to be a binary file, containing a .NET executable at a non-zero offset. We then extract the file and pop it into ILSpy to determine what it does:

It looks like this is a reasonably simple XOR cipher, but I couldn’t find the key initialization anywhere. Going back to the JS, we find our culprit:

We can then match this up with our disassembly, to note that the “Aa6b…” function takes the last 22 characters of it’s argument as the xor key:

Knowing this, a quick python script gives us the flag:

Rescue Shell

This challenge was presented as a Linux binary, which you can download here. This was ostensibly a shell in itself, but was disabled (and infact, did not import any shell-executing functions).

Popping this into IDA pro, I quickly got the sense that this was a classic stack overflow vulnerability, conveniently using read (so null bytes were safe).

A quick test later, and this is confirmed, with the return address from check_passphrase being controlled:

Controlling the stack to this extent makes the rest of the challenge trivial: we then wrangle a rop chain to leak the address of one of the elements in the GOT (using 0x40099a as a “leak” gadget, taking an argument from the stack) and then from there, bounce to a libc magic gadget to give us shell:

You can download the python script I used here.

As always, thanks to the NDH organisers for putting together another quality CTF event. There’s quite a number of CTF events next weeked to participate in, so I’ll likely see you all in UIUCTF next weekend.

Posted in Bards, Computers, Jesting | 7 Comments

Fun with Flash Memory (and Accidental Memory Leaks)

Today, I played around with tampering with Flash memory. The target of my attack is a generously donated Netcomm N300 router – I was able to wrangle a hilarious web server memory leak in the unauthenticated web interface by tampering with Flash read operations. I will now describe how to do this.

Update: now with 100% more demo!

The target uses a Macronix MX15L12835FMI flash memory chip, in 16-pin SOP form.

I began my investigation in the morning by monitoring the regular operation of the chip. Broadly speaking, I noted that his flash memory wasn’t actually used too much: it was used during boot (presumably loading the entire OS), and then once again when the web admin panel is used (but only once, indicating it’s cached).

The Flash chip appeared to be used in single SPI mode, with a typical read command looking like this:

(This would be preceded by an 05 FF command – according to the datasheet, this reads out a status register, let’s set this aside for the sake of this attack). My initial goal was to tamper with a Flash read command to read something else from disk.

Given that the SPI commands are synchronous to a clock signal, my attack could also be synchronized to the same clock signal: I would count a number of rising edges on the clock, and at a given number, I would short the Slave In pin of the flash chip (pin 15 on the diagram above) to ground, modifying the Flash read command to read something else.

Zooming in for a closer look, we can see that data changes only occur on the falling edge of the clock signal, so this attack should work:

I started off at the device’s serial console, using cat /dev/mtdblock0 to trigger a Flash read. Without tampering it looks something like this:

For comparison, I also did cat /dev/mtdblock2:

I then wired up a transistor and an FPGA, which read the clock signal and controlled the transistor’s gate, grounding pin 15 temporarily for a number of clock cycles to corrupt only the address of a single read instruction:

I wrote a quick script to wait some clock cycles and ground the flash read operation, then ran cat /dev/mtdblock2 and monitored the resulting Flash commands via oscilloscope:

If you look closely, you can see the remnants of the original flash read operation to the right (the original command for /dev/mtdblock2 was 03 01 00 00). This was confirmed by the results of the cat /dev/mtdblock2 command:

Note that the command worked as intended, but the first block of /dev/mtdblock2 is the same as /dev/mtdblock0 above, indicating success.

From here, I attempted to repeat the work against the web server interface – if I could corrupt the loading of a resource from disk, I could theoretically make it read anything I wanted, leaking the firmware via web requests.

I quickly stumbled upon a setback in the form of SquashFS:

While I could read any block from physical Flash, I could not guarantee the stream would decompress correctly. Still, the web server seemed to work, but one of the images did not load correctly. Opening the web application in burp, I found the culprit:

This was the response to a valid request for /wireless_1.gif. I knew that this was not a valid GIF, but I didn’t know what it was: my hypothesis was that this is either memory from the web server, or a block from disk, with the first being more likely.

To test this, I idly browsed around the web application, and then sent a new request for /wireless_1.gif:

Lo and behold, the gif had magically changed itself whilst no further SPI traffic was observed, indicating that I had a memory leak (or more likely, a use after free?). No, “Ducky” was unfortunately not a part of the password for this system.

You can find the code I used for this attack here.

While this isn’t so useful against an IoT device with more holes than Swiss cheese, the impact of this is apparent – being able to arbitrarily load stored data from flash, without regard to OS-level access control (as it doesn’t know about the tampering), is a rather useful trick imo.

Posted in Bards, Computers, Jesting | Leave a comment

Quick Notes on the PSoC

Updated at the end, to include how2play programming.

Today, I spent some time tinkering with the PSoC 5 LP prototyping kit. This prototyping kit is physically very portable, and contains some very surprising features for it’s price point (~$10-20, depending on supplier). Unfortunately, I had horrendous trouble navigating the documentation, so I write this blog post both as a note to myself, and hopefully to assist anyone else trying to work out how to use PSoC Creator.

The uniqueness of PSoC comes from a number of analog components which are directly accessible from the MCU itself, and the flexbility of the microcontroller pins. Think of it as a microcontroller on top of an FPGA on top of a stack of analog components (for the princely sum of $16) and you’re there. I think this is extremely cool, and hope you do to.

To start, let’s try driving a status LED from the firmware. After creating a new project and selecting the correct development kit, we are presented with a blank schematic. We begin by using the Component Catalog tab on the right to add a Digital Output Pin (under Ports and Pins). We drag this to our schematic:

Think of this pin as an arbitrary “slot” – this isn’t connected to anything yet. We double click the pin on the schematic, and untick “HW Connection”. Leave the rest as-is (strong drive, we’re driving a LED).

Our next step is to map this to a physical pin. Click the components tab on the left hand side, to bring up a tab which looks like a square microcontroller:

On the right, you’ll have a window which allows you to assign Pin_1 to a port. The “port” corresponds to the port numbers printed on the prototyping kit’s silk screen. For this example, we inspect the physical LED element, and we note it says “2.1” underneath the LED. We select “P2[1]” for the “Port”, and leave the rest as-is. The middle picture should change, with P2[1] becoming blue to denote the change:

This is enough to begin programming on the microcontroller. Click the “Sources” tab on the left, and open “main.c”.

The code generation is unfortunately a bit strange. You’ll need to use a few Cypress functions to do things. A LED blink looks like this:

#include "project.h"

int main(void)
 CyGlobalIntEnable; /* Enable global interrupts. */

/* Place your initialization/startup code here (e.g. MyInst_Start()) */


Now, save your work, compile your project then program this to your dev kit (the board comes with a KitProg programmer built in, similar to the STMicroelectronics boards), you should get a blinking LED.

Note that I had problems getting the PSoC4 equivalent (CY8CKIT-049) working, and I ended up resorting to an external MiniProg programmer to make this work. YMMV, this may just be hardware damage on my end.

Now, let’s replicate the functionality in programmable logic and reroute the output. Firstly, go to the Components tab on the left, and right click the “Project ‘Design01′” row (or whatever you named it), and click “Add Component Item”. Do not use this while TopDesign is selected, or you can unfuck your project later.

Now, use the Symbol Wizard to define a clock input and a simple digital output:

You should be presented with another schematic-looking thingy. Right click the blank space, and select “Generate Verilog”. Now, use the following code to create a blinker:

reg [32:0] ctr;
reg led_out_r;
assign led_out = ctr[27];

ctr <= 0;

always @(posedge clk_in)
 ctr <= ctr + 1;

Note that this is a bit stricter than Xilinx’s Vivado: we need an explicit initial block instead of just assigning variables at the start. Enter this in the body section of your Verilog, and save your work.

Our next step is to add a clock input, and connect it to our LED. Select the “TopDesign.cysch” tab up the top, and modify our pin to enable “HW Connection”. Now, use the Component Catalog’s “Default” tab on the right to add one instance of our new component:

Now, connect the two components, using this tool to the left of your schematic:

Note that this tool is a “clicking only” tool, and does wierd things if you attempt to drag like a normal person. Instead, click once and only once on the starting component’s “connector box”, and click once and only once on the end component’s connector box. A successful connection looks like the above.

Now, use the Component Catalog on the left to add a Clock (under the “Cypress” tab, in “System”). Leave this at whatever the frequency is, and wire it up:

Now, go to main.c, and delete the code we added (so leave it as an empty main function). Build your project, and program it, for a very slowly blinking LED.

You can easily redirect ythe output to another pin – simply open Design01.cydwr (the MCU square thing), and select a new port (P2.0 is an excellent choice for testing – it’s right in the corner), rebuild and reflash your project.

I look forward to working more with this interesting hardware.

Appendix – Programming with MiniProg 3

I have also done some experimentation with the MiniProg programming adapter – I’m a huge fan of having seperate debug hardware, instead of relying on on-board debug (which seems a bit too much like having a process report on it’s own integrity). Unfortunately, the “PSoC Programmer” standalone application is a flaming pile of shit.

To program a PSoC device using the external programmer, go into PSoC Creator. Select “Debug / Select Target and Program”. You should see a window like this:

Now, right click the MiniProg 3 entry, and select “configure”. Select the correct options for your kit – ensure that you select the correct voltage, connector and acquisition mode (for a PSoC5LP kit, this was 5V, Reset and 5-Pin Connector (replacing the KitProg connector effectively). Click OK, and hit Port Acquire, and your target should show up.

This works, despite the device never being acquired under the PSoC Programmer standalone application (why?).

If you can’t find your programmer on your desk (in fairness, it looks like a USB stick), no problem – just hit the “Visual Identification” button and all the LED’s will cycle. Hooray!

Posted in Bards, Computers, Jesting | Leave a comment