Late Writeup – SimpleMachine (Codegate 2020 Teaser)

This weekend, I participated in the Codegate 2020 Teaser CTF. I started late – in my defence, ctftime’s time reporting was inaccurate, and I was able to solve the SimpleMachine challenge, though far too late to get points. The writeup is presented below.

SimpleMachine

This challenge was presented as an executable and a “target” file, which you can download here. You can also download a copy of my working notes here.

The binary is a stripped Linux executable, but the challenge name indicates it’s some kind of virtual machine. Fortunately, the executable is not obfuscated, making reverse engineering relatively simple. Moving through the disassembly (i.e. following the call flow from main()), we can note the opcode processor at 0x17C0:

Looking at the function, we can make a few key observations:

  • The byte at $rdi + 0x30 holds the opcode.
  • The word at $rdi + 0x34 holds argument 1
  • The word at $rdi + 0x34 holds argument 2
  • The return value is held in $rdi + 0x3E. We don’t know where it goes for now.
  • 8 total operations exist – read, write, load, xor, multiply (without carry), add, compare, jump-if-zero (I intially mistakenly thought this was “exit”).

Next, we instrument the application with GDB to observe this in action. We can see it load the first opcode, a “read” opcode, corresponding to the first 8 bytes in the “target” file (the xxd options reverse the byte endianness, and groups bytes into pairs):

Matching this to the disassembly, this is the “read” opcode, reading ox24 bytes into address {base} + 0x4000. By following the read call itself, base is defined by the first qword pointer at $rdi[0] within the opcode processor function.

Further tracing of the application, correlating application behaviour with disassembly listing, sheds light on the instruction format (little endian):

AABB XXXX YYYY ZZZZ 
AA: Addressing mode (controls behaviour of XYZ)
BB: opcode
XXXX: where the result is stored.
YYYY: arg1
ZZZZ: arg2

Spending a bit more time debugging the executable, we can observe the following behavior:

  • Firstly, the program reads a flag (the 06 opcode)
  • The program compares the first part of the flag to CODEGATE2020 through static compares. If any bytes don’t match, the program is exited through the use of opcode 5, with an argument of 0x1a0 (which leads to opcode 8, exit).
  • The program then loads a number of constants into memory, for an unknown purpose. Let’s call this the “key material”.

At this point, we are at 0xf8 in the “target” file. The program continues:

  • We load the constant 0xdead into a virtual register
  • We load the constant 0x1 into a virtual register
  • We double 0xdead, and save the result in a register. This is at address 0x108 – this is important later.
  • We xor 0xdead with the doubled 0xdead, and save the result in a register. The result is 0x63f7.
  • I’m not sure what the next instruction is for. We multiply 2 by 0 and save the result?
  • We load 0xf974, a part of the key material loaded earlier, into 0x154. Note that 0x154 is part of the initial code, 0xFFFF in the “target” file – the program has now become self-modifying. Let’s press on.
  • We save the constant 0x400c, after “CODEGAT2020”, into 0x14c. This is also self-modifying. Note that 0x400c points to the next bytes of the flag after “CODEGATE2020”.

At this point, we can monitor the executable with gdb, using the “rwatch” command:

rwatch <address>
  • Three “nops” are executed, consisting of 0000 0000 0000 0000 instructions.
  • We xor the two bytes of the input flag with 0x63f7
  • We add the result to the first two bytes of the key material, 0xf974
  • We compare the above result to 0.

We can represent the above operation as thus:

input_flag ^ 0x63f7 + 0xf974 =0x10000
input_flag = (0x10000 - 0xf974) ^ 0x63f7

We can quickly check this in Python:

Great, this looks pretty sane. Let’s move forward:

  • If the last result was not zero (i.e. if the flag was incorrect), jump to 0x1a0
  • The next three operations appear to be a loop counter, checking if we’ve hit 0xc iterations, and if not, jumping to 0x108.

At this point, instead of doubling 0xdead, it doubled the 0x63f7. Going through the loop a few times, we note the following repeating cycle occuring:

From here, it is a simple matter to derive the key manually, and confirm it via the simple_machine executable:

My solving methodology for this challenge was particularly haphazard, with a half-hearted attempt at writing an emulator and many, many failures at tracing the program, mostly due to my own fuckups in patching virtual compare operations. A shortcut I learned was that gdb can skip X iterations of a breakpoint, with the following command:

ignore 1 15
(ignores breakpoint 1 the next 15 times)

I disagree with the assessment that it is “ezpz”, but in another light, it is a humbling reminder of how much more I have to learn, and what a challenge it is to keep my skills up to date, while also expanding into other areas.

Thankyou to the Codegate 2020 CTF organisers for putting together these challenges. See you in Aero CTF.

Posted in Bards, Computers, Jesting | Leave a comment

The Z80 Adventure Part III

In my last post on this topic, I discussed improvements to my Z80 computer, which allowed the use of peripherals from within the Z80 OS. I recently rebuilt this computer, to allow for a bit more extensibility (and eventually, LED debugging).

Conceptually, this is similar to the last iteration, with an ATMega32A acting as a custom I/O port to the Z80, it’s gateway to the outside world. The address bus accessible to the ATMega has been reduced to 8 bits – the upper 4 bits weren’t being used, except for debugging (and we can debug with LED’s and a manual clock input).

To add wifi and disk support, I used the ESP-01 module: this acts as a WiFi bridge, so you can connect to it via netcat. It also supports a series of specially formatted (but human readable, for debugging) UART commands, which allow disk access:

The actual protocol is fairly simple:

  • !xx!yy!zz\r\n:
    • xx is set to 0xFF for read operations
    • yy is set to the low byte of the address bus.
    • zz is the data bus
    • This will wait for one byte – if it’s a “write-only” operation, like selecting the disk number, the byte will be treated as an “ack” and ignored. If it’s a read operation, like reading a byte from disk, the byte will be placed on the data bus (or routed as the ATMega sees fit).
  • !!! means an actual “!” is being printed over UART.

To correctly support replies, a change had to be made to the way the ATMega handled UART input. Previously, when the ATMega was simply bridging for the Z80, an asynchronous interrupt-based UART was fine – this was the way the Z80’s BASIC rom BIOS expected input. Here, we need to temporarily disable interrupts every time we want to wait for a response from the ESP-01 as part of a I/O operation, otherwise, your interrupt routine will consume your input:

char async_getchar()
{
	char tempByte;
	cli();
	while(!(UCSRA & (1 << RXC)));
	tempByte = UDR;
	sei();
}

Given the static nature of the Z80, all this occurs in one clock cycle – the clock is simply held, while the ATMega waits for a reply from the ESP module.

Finally, to connect to this system, we need to disable line buffering (stty -icanon; nc 192.168.1.1 23) before we use netcat, for characters to be sent correctly to the CP/M OS:

With this in place, the next step is to implement a working CP/M disk structure – but this can be fully implemented on the ESP side (which is, incidentally, a lot easier to program). I’m setting aside this project temporarily, to spend my time elsewhere. The code can be found on Github as usual.

Posted in Bards, Computers, Jesting | Leave a comment

Notes on RF Retroreflectors

Over the past few weeks, I’ve been spending some time learning about RF retroreflectors. The goal of this is to improve my understanding of the theory and application of RF in general.

An RF retroreflector is a device which takes a target signal, and when illuminated by a continuous wave of RF energy, amplitude modulates the wave as it’s reflected back:

The primary advantage of this device is that it doesn’t need power, and doesn’t “transmit” unless it’s actively illuminated.

Three primary resources exist for playing with RF Retroreflectors.

  • GBBPR2’s Youtubes, here
  • Mike Ossmann’s work, here
  • The Wakabayashi paper, here

All three are worth reviewing, and the entirety of GBBPR’s internet contributes are well worth watching. If you’re still out there, I hope you’re carrying out your good work still.

The concept of a RF retroreflector is simple: a piece of wire is used as a passive reflecting antenna, and a MOSFET controls it’s capacitance by connecting and disconnecting it to a ground plane. The device is trivial, and can be made as follows:

The MOSFET is flexible: I used a BSS138, but a standard 2N7000 works too. Select this based on the rise time, corresponding to the source signal you want to exfiltrate. A finished device looks like this:

The antenna can be any length, but a quarter-wavelength monopole is recommended from experimentation. More on this below.

We can use gnuradio to generate the illuminator wave, as follows:

Theoretically, the antenna should best modulate at it’s resonant frequency. In practice, we can observe a very wide frequency envelope in which we can successfully recover signal (subject to noise – I’m waiting for some nice log-periodic antennas to ship). Here is a 10khz square wave reflected at approximately 2.41 GHz:

And the same, at 2.47:

Through expeirmentation, the impact of frequency is eclipsed by the impact of illuminator strength – no wonder the NSA used a dedicated unit, all praise to the unblinking eye watching us all.

Recovering the target signal can be done with a simple moving average and a threshold filter:

To provide a reference for relative amplitude, here’s the same code running, with the retroreflector disabled:

Nevertheless, this is useless unless we can recover actual logical data. My initial attempt with a knock-off Arduino failed for reasons unknown, so I made a new PIC firmware to constantly transmit a stream of the character 0xAA (for timing clarity) over UART in a loop. To begin with, let’s confirm that we can “see” the signal:

This waveform can be downsampled and pushed out to file, all in GNURadio (it’s possible to stream it to a custom Python block, but it means your Python block needs to implement a USART receiver – example code for the streaming is in the Github below).

You can download the source code here. Have fun!

Posted in Bards, Computers, Jesting | Leave a comment

Writeups – LowDeep, Kaboom (Insomnihack Teaser)

This weekend, I participated for a few hours in the Insomnihack Teaser CTF. Due to poor time management (specifically, my inability to correctly convert UTC time), I was only able to play for a little while, but I solved two challenges.

The writeups are presented below.

LowDeep

Lowdeep was presented as a web challenge, and was a nice warmup challenge for my renewed efforts this year:

A simple command injection reveals the presence of the print-flag binary, and strings gets the flag:

What a classic.

Kaboom

Kaboom was presented as a Windows executable. You can download the original here.

Upon initial investigation, this was a UPX packed executable, so I ran upx -d. Searching around the executable only revealed a troll flag:

Given the size of the executable, I was initially convinced that a hidden “unlock” function had been secreted somewhere in the application, perhaps hidden behind the facade of a standard library call. Unfortunately, searching for this was fruitless: it did not exist in the executable, and was not in the memory.

The other possibility I considered was that the UPX packer was not unpacking the flag correctly. Manual inspection of the packed executable revealed a clue – that there appeared to be two different packed flags. Firstly, the decoy flag:

Then, an actual flag:

Going through the UPX packer implementation (in hindsight, bindiff would have helped here), we could see the following code:

This simply overwrites the “correct” key with the troll key, so we never see the correct key unpacked.

A stronger internet wizard than me might have implemented a UPX unpacker stub and unpacked the correct key, but with my limited powers, I proceeded down the route of simply overwriting a chunk of the executable with the correct key.

Depending on how this is done, this can cause the UPX unpacker to experience a fault, but as long as this is after the key is packed into memory, it doesn’t matter:

Thankyou to the Insomnihack team for putting together yet another great CTF – this event has consistently been enlightening and fun. I look forward to solving the other challenges I downloaded.

A special mention should be made of the thoughtfully put together welcome challenge, which includes the following hilarious line:

I wonder how many people simply ran this without looking 🙂

Posted in Bards, Computers, Jesting | 2 Comments

Thoughts on 2019 / 2020

As we sit on the cusp of a new year, it is appropriate that we consider the year just gone, and the path ahead. In 2016, I began a push to use deliberate practice to improve my own skills in things that I was interested in. Since then, much has been accomplished:

  • I’ve gotten somewhat better at exploitation, mostly through practice. I’m not at the point where I can reliably search for and weaponize remote exploits in unknown IoT firmware in a given time-frame, but this is a goal for 2020.
  • I’ve gotten better at regular people “hardware hacking”, primarily because the increase from zero to anything is “a lot”. I’m able to identify attack paths into a device, and bypass some countermeasures. I can identify and use common debugging interfaces, I’ve some experience in writing payloads for MIPS/ARM (and know enough to Google the rest).
  • I’ve gotten better at actual hardware hacking. I understand the theory of side channel and fault injection attacks, have experience doing this with commodity and custom hardware, and have my own toolchains for experimenting with this tooling.
  • I’ve gotten somewhat better at digital hardware design. I can use COTS components to implement basic hardware design – the other day, I thought about a laser microphone, tried to implement one with ESP8266 (it didn’t work), and made a fake ADC out of a PIC microcontroller. You can see the result here.

I am rather proud of my small menagerie of gadgets I’ve made over the past year – but more so of the fact that I now know enough to imagine a concept, evaluate it’s viability and get on with making it, without needing someone to copy off:

The biggest challenge at this point is where to find those dark orange bakelite prototyping boards that are “soft” to cut, not like the new ones from Jaycar that crumble when you cut them.

Not everything has been sunshine and roses – as with anything, there are inevitable setbacks:

  • Side channel analysis of SIM cards, with the goal of obtaining cryptographic secrets, was somewhat unsuccessful. I suspect this is down to countermeasures implemented in the SIM card itself, but it’s difficult to confirm this as I can’t call up my provider and ask for source.
    • On the bright side, attacking a production system led to several major steps forward in trace preprocessing and alignment – I can’t complain too much about this.
  • I still suck at heap exploitation. With most forms of exploitation, I can visualise the process in my head, but once a heap allocator gets involved, there’s still a process of “trial and error” to make sure I’ve got the offsets right, and I’m predicting the behaviour of the heap allocator correctly. I have no idea how to exploit heap structures on modern systems.
  • have no idea how to uncover and weaponize a browser exploit (remotely triggerable via watering hole). I have some experience using JS payloads to attack web apps, but I don’t know how to move from a browser to a desktop (or more specifically, to an Android device).
  • have no experience at fabricating high-frequency circuits. I want to be able to make my own PCIe interfaces and NAND Flash interposer boads, but I haven’t committed time and resources to this – my fault.
  • distinctly lack education in electronics theory. In the age of search engines, this isn’t necessarily a downside per se, but often I find myself following rabbit-holes of “why is a dipole antenna the way it is”. That said, I taught myself all I know of electronics, so this is fixable.

As I tread further and further into the less-explored hinterlands of hardware security, it is increasingly difficult to maintain focus. Between the incessant demands of day-to-day life, and the general lack of fellow Internet Explorers in Australia, it is a challenge to remain committed to reaching the goals above; it’s worth having a think about what I’m going to do for the next five or so years to make myself learn faster.

Nevertheless, in an effort to make next year’s shitposting a little easier, my new goals for 2020 are as follows:

  • I want to rebuild my skillset with software. This involves doing things like Hack the Box, CTF’s and simply creating exploits for existing software – my subscription fee for HTB needs to be worthwhile.
  • I want to practice building high-frequency circuits. By the end of 2020, I want to have built at least one FPGA board (similar to the playstation modchip boards), acting as a custom PCIe interface.
  • I want to learn emissions security. Attacks such as TEMPEST have always been of interest, and I want to know enough to independently implement TEMPEST (both passive and active) against a simple signal by the end of 2020, as well as a few other key attacks. This links to the goal above.
  • I want to practice “universal backdoors” against Android. I want to be able to desolder a BGA NAND Flash chip, insert a backdoor (e.g. editing fstab), and replace it on the device. This vastly improves my ability to gain an initial foothold on completely closed systems.

I should also mention the part that my work at UNSW plays: as some of you know, I teach web application security, which isn’t my area of focus – but this is truly an opportunity I’ve failed to capitalize on. 2020 presents a renewed opportunity to truly take ownership of the course and reset it – I look forward to teaching an actually good course with consistent content quality, and then using this as a launchpad to further pursue my core interests by working with academically-minded folks I otherwise would not have contact with.

To top everything off, I can’t help but feel an all-consuming sense of desperation: I’m not getting any younger, but I’m far off from achieving what others have achieved (take a look at Yifan Lu’s work with the PS Vita, windytan’s work on HDMI side channeling, the successes so far on extracting SIM secrets – the examples are endless). Humanity has always been a few bright flames amidst a sea of flickering sparks, and few things fill me with bitter contempt like the thought of settling into a white picket fence life.

As we look forward into the new year, let us archive our accomplishments, grit our teeth and steel our resolve for the challenges ahead.

Posted in Bards, Jesting | Leave a comment