Some thoughts on motivation…

It’s been a while since my last quality shitpost, and it is time I shitposted again. The past year has been a time of growth for me, both in terms of pushing my technical boundaries and in terms of professional character resilience. I’d like to share my thoughts, both to help me gather them, and just incase someone might find them useful.

Without further ado…

Altruism Is Terrible

Over the past year, the Platypus Initiative has been in a state of steady decline. Activity is near-zero, and while there are countless reasons for this, I think the biggest is that we began to switch from wanting to do things for ourselves, to wanting to do things for what we thought was “altruism”.

The old adage, “you can lead a horse to water but you can’t make it drink”, holds true: some people are content-creators, but the overwhelming majority are not – and that’s fine. I recall with a certain fondness the times when a few of us would get together and CTF in the dark – when I thought we communally reached for the metaphorical stars and pushed our own technical limits.

While this was fantastic at the time, this is over – this isn’t remotely sustainable, and our time is better spent doing things we’re genuinely interested in.

That’s not to say there’s no room for collaboration – I spent last Saturday sitting together with someone working through some power analysis work – there’s plenty, but it must be organic for it to be truly meaningful, and in terms of holding events, for it to be something more than an excuse to get together and drink.

Row, Row, Row Your Boat

In a corporate environment, it is easy enough to “give up”, rest on your laurels and pretend to know about security, lording over the rest of the organisation with arcane proclamations no-one dares challenge. Whether it is in my day-to-day work or at general infosec social get-togethers, I see this everywhere.

This is base betrayal, of both professional ethics and general sensibilities.

Still entire industries have sprouted up among this concept, and it is not my place to be offended at their chosen livelihood (of fraudster), and more than I can be offended by the respected fisherman or master blacksmith.

Instead, our time is better spent focusing inwards, and taking the opportunity to make the best of our own situation, because if we don’t, no-one else will. In line with the “Altruism Is Terrible” concept, it’s great if we can make our own lives better and do the same for others, but charity starts at home and we should look after ourselves first – you can’t help anyone if you’re not motivated yourself.

To this point, here is (part of – I’ve now moved the oscilloscope to the left side of my laptop to improve my feng shui) my desk at work now, a fortress of quality posting among a tide of business excellence.

Great success.

For anyone thinking of working with my employer, know that I am the exception to the rule, though I hope that one blessed day, more people will be able to pursue interesting technical content as part of their day job, and I will work towards this.

Nothing Is Beyond Our Reach

The most difficult part of the last year has been to remain consistently motivated, and in this, I haven’t been 100% successful. There’s been days where I’ve just given up and played videogames – and this is ultimately fine. LiveOverflow deals with this quite well:

Still, I am not LiveOverflow.

I’ve found the trickiest part is to get started – once I open IDA and load that massive memory blob, or heat my soldering iron, things are easy form there – but some days, it is particularly difficult to begin. I’ve found the trick is twofold:

  • Surround yourself with people that value actions over words. If you don’t know any, then email the authors of good papers and ask them questions, and get that conversation started.
  • Keep a diary with a to-do list, and don’t go to sleep until you’ve updated it. Even if all you do is shift everything to tomorrow’s to-do list, at least make the effort to recognize you’ve done nothing, and tomorrow, seek improvement.

If you can combine the above two somehow – perhaps by finding a group of similarly minded people, all the better.

Remember Your Roots

A year ago, I could barely hardware – but now, I have some experiencing tampering with embedded systems, and know enough to Google what I don’t know. Two years ago, I was stumbling my way through CTF challenges – now, after deliberate practice, I know enough to meaningfully contribute and can comfortably solve things on my own.

Still, it is difficult to look at the achievements of others and not feel a sense of despair that we’re not there. To this, I refer to Ange Albertini’s talk at hack.lu:

It is important to keep in mind that at the end of the day, there’s always someone smarter out there, and someone who knows things we will never practically come across. It’s almost a matter of prioritization – of picking the things you want to be good at, and throwing your heart and soul into it, and doing the bare minimum for everything else.

Surprisingly, the most difficult part of this is to let go of things (and people) that don’t positively contribute to where you want to be: it is far better to strive for excellence alone, than to accept mediocrity with company.

See you in TJCTF (again).

Posted in Bards, Jesting | Leave a comment

Differential Power Analysis vs AES

This post is a follow-up to my last post regarding correlation power analysis (CPA). A second technique, differential power analysis (DPA), can also be used to analyze power traces to extract information.

The specific attack I will illustrate below is the “difference of means” attack. The code is again available at https://github.com/CreateRemoteThread/fuckshitfuck.

Distinguishing Function

Unlike CPA, DPA relies on a mechanism called the distinguishing function. Put simply, this is a true-false hypothesis, used to separate power traces into two groups (i.e. the two groups are somehow distinguishable by power). For example, a distinguishing function might be

“during the first round of AES, the last bit of the s-box output / intermediate value is 1. at some time-point in the first round of AES. this causes a different amount of power to be consumed than if the value is 0.”

Now, using the power traces we have gathered, and knowing the plaintexts, we run the distinguishing function to separate power traces into two “buckets” for each given possible key[0].

Difference of Means

We then take the mean trace of each bucket, and subtract them from one another (and make all points of this “difference of means” trace an absolute value). Let’s pretend we’ve done this for all possible key[0] values across 10000 traces. At this point, there are two outcomes:

  • If our hypothesis for key[0] is correct, there will be X traces in Group 1 where the distinguishing function is true, and Y traces in Group 2 where the distinguishing function is false.
    • The mean of Group 1 will, at a time-point, consume more or less power than the mean of Group 2, representing the power used to move the final bit of the intermediate value into memory / register / etc.
    • The “difference of means” will have a spike, representing the above time point.
  • If our hypothesis for key[0] is incorrect, the distinguishing function is effectively a random sorting function.
    • The mean of Group 1 will be similar to the mean of Group 2
    • The “difference of means” will not have a distinguishable spike.

We can then easily plot the greatest difference of means for a given distinguishing function, for each key hypothesis:

(The label on the Y axis is incorrect, it should be the “Maximum Difference of Means”). Each line in the plot represents a given byte position in the key – the x-axis represents the actual key guess from 0 to 255, and the y hypothesis represents the maximum point in the difference of means, when the distinguishing function is run for that key hypothesis.

It is clear that both of these attacks are incredibly powerful, and can extract information from minute differences in power consumption through statistical trickery. I look forward to exploring more of these attacks and related attack scenarios.

Posted in Bards, Computers, Jesting | Leave a comment

Correlation Power Analysis vs AES

Recently, I spent some time learning about power analysis attacks. This has been an interesting journey with many interesting applications. The theory behind this is simple – that different operations (or – crucially – the same operation with different data) consume differing amounts of power, and that by measuring power consumption of a device over time, we can determine (with the help of some statistical trickery) what the device is doing.

All the code for the below, as well as the targets, are downloadable from github.com/CreateRemoteThread/fuckshitfuck. This code is provided as-is, and is a working copy – it may break unexpectedly.

Setup / Acquiring Traces

The first step of our journey is to acquire power traces across a target device. To do this, I built a simple ATMega328p target board:

This is a standard ATMega328p with a voltage regulator running at 3.3v, and a bypass cap to help stabilize the power supply (this realistically didn’t do shit). UART is broken out for communications, and an debug header is present for editing firmware quickly. Two extra debug wires are present, used to trigger the oscilloscope (or simply provide a second informational channel).

Crucially, a 1.5 Ohm shunt resistor is present from the ground pins of the target to the power supply ground. This is used to measure current consumption by the microcontroller.

The board runs a very simple AES target – you can load a key with ‘k’, and encrypt data with ‘e’. When the ‘e’ command is sent, the following steps are taken in order:

  1. a trigger line is increased to a logical high
  2. AES encryption is performed with the currently loaded key
  3. the trigger line is set to logical low
  4. the result is printed to uart out

A single power trace looks something like this:

Along with the trace, we should optimally record the plaintext for the next step of this attack.

Power Consumption Modelling

Our attack targets the power consumption of the first round, exploiting two fundamental properties (in the lack of mitigating factors):

  • The first operation of AES is to xor the plaintext with the key, then use the result to index a known array (the s-box), forming an intermediate value. Therefore, as we known the plaintext, we can know this intermediate value for every possible key byte.
  • We assume that more “1”‘s in the intermediate value means very slightly more power is consumed during the first round.

In isolation, this information is not immediately helpful – our measurement is not accruate enough to extract the key byte through analysis of a single trace. However, if we take, hypothetically, 3 traces, we can begin forming a hypothesis:

  • The plaintext is assumed known
  • If key[0] is byte 1,
    • the intermediate value of key[0] for trace[0] is 0x01
    • the intermediate value of key[0] for trace[1] is 0x11
    • the intermediate value of key[0] for trace[2] is 0xFF
    • Trace 2 will consume more power than trace 1, which consumes more power than trace 0
  • If key[0] is byte 2,
    • the intermediate value of key[0] for trace[0] is 0xFF
    • the intermediate value of key[0] for trace[1] is 0x11
    • the intermediate value of key[0] for trace[2] is 0x01
    • Trace 0 will consume more power than trace 1, which consumes more power than trace 2
  • A similar model is performed for every key[0] from 0 to 255
  • We have taken 3 traces of the target with an unknown key. Whichever key guess’s hypothesis most strongly corresponds with the 3 actual traces with unknown key, is the key guess.
  • This is inherently resistant to noise, as it’s a statistical attack – it’s not realistic to expect 100% correlation strength, but 60% correlation where everything else is 4% is an extremely strong indicator of correctness

This approach scales infinitely, limited only by time (and memory): the attacker may capture as many traces as he or she pleases.

Correlating Traces

A mathematical tool, known as Pearson’s Correlation Coefficient, can be used to quantify how similar one set of traces is (or rather, it’s delta from the mean of all traces) to a hypothesized key byte’s set of traces. This is well expressed by Wikipedia:

It is quite simple to understand once expressed in code. With a little bit of Matplotlib, it is possible to graphically represent Pearson’s correlation coefficient:

Each line in the plot represents a byte of the key, with clear spikes, representing strong correlation, for one byte value (the correct guess) for each position of the key. Even from a low number of noise-tainted initial captures, the results are extremely clear: it is possible to use this method to extract an AES key from a set of power traces, having an encryption oracle.

The same technique is possible against the final round of AES (i.e. only requiring a known ciphertext), but I have not demonstrated this. This may be possible to execute against AES decryption, but I also have not demonstrated this – this may be useful in attacking MAC implementations.

In conclusion, this was a very interesting attack to be able to demonstrate, and the practical applications of this attack method are limitless. I will follow up with a post on a related attack, differential power analysis.

Posted in Bards, Computers, Jesting | Leave a comment

Atredis BH Ticket 2018 Challenge Writeup

Earlier this year, I completed a binary reverse engineering challenge from Atredis Partners. This was interesting, so I will present the writeup below, for posterity. The challenge began with a Slack message from a comrade, who mentioned there was a binary-style challenge available at arkos.atredis.com, port 4444.

Upon connecting, I was greeted with the prompt shown above. A bit of manual testing revealed that I could use the “help” and “read” commands – the “read” command would consistently produce a single byte from a specified location in memory:

Here, I built a memory dumping script which called read in a loop to give me an extract from memory. I extracted according to the memory map, until I hit contiguous blocks of zero (which I assumed to be the end of real data in a mapped section). Immediately, a few interesting tidbits jump out at me.

We can immediately note that in the PROM section starting at 0x4000, there is a reference to “write” and “call”, which appear to be commands:

At this point, I decided to try the “write” and “call” commands – the “write” command seems to allow a single byte to be written with the syntax “write <addr> <byte>”. I couldn’t make the “call” command do anything at this point, but it always printed “JSR <addr>”.

I did some Google, and I found that JSR could stand for Jump Subroutine, an assembly language thing for MOS 6502 microcontrollers. Cool!

With this, I could now fully disassemble the program at 0x8000 in IDA. After some learning about 6502 and some manual effort (the program took 16-bit addresses, which were loaded in two operations of single byte chunks, which was annoying to deal with), I was able to reconstruct some basic application logic flow:

  • There are two points in the application which seem to seek a file from disk: displaying /etc/motd (0x8270), and displaying /var/mail/spool/atredis (0x82a2).
  • Both called “fopen” at 0x8059, after loading a pointer to the filename at $95 and $96
  • “fopen” is a strange loop – it sets an “id” in $99, then calls “disk_read_sector” at 0x8034. It then compares the filename to what was initially entered, and exits the loop if it’s what we’re looking for, or continues the loop if no match.

After a little experimentation, I found that RAM was executable, and I could write shellcode via the “write” command and “call” it successfully. I initially attempted to build a stub which called fopen with a controlled filename, but this didn’t work.

I then wondered if I could simply patch the program – it turns out I could. I then patched the byte at 0x8060, to modify the initial “fopen id”, and 0x8084, to pass the filename check at the end of fopen, and presto, the flag:

This was a fun challenge, and well thought out. Thanks to the Atredis folks for putting this together.

Posted in Bards, Computers, Jesting | Leave a comment

Karma on ESP8266

Earlier this year, I had wondered whether it was feasible to implement the Karma attack on a low-powered device, such as the ESP8266. It turns out this was quite simple, and you can now find a template for this on Github here.

The code is not a complete WiFi pineapple on an ESP – by design, this only implements part of the attack, it is up to the user to provide the “rogue AP host” and network back-end (but on the low-power theme, you might be able to forge this via another ESP8266). No preferred network list functionality is provided here either, but this isn’t too difficult to implement – the ESP is fairly generous in terms of resources for this.

If you want to play around this, the following video is well worth watching. The concepts discussed here are all relevant, no matter the hardware platform (though against modern devices, they have varying degrees of effectiveness – the most effective seems to be preferred network list based trickery, or good old fashioned fake beacons).

Have fun!

Posted in Bards, Computers, Jesting | Leave a comment