Author Archives: Nick Price

Be careful when using global variables in AWS Lambda!

I discovered some unexpected behavior with AWS Lambda that I thought was worth pointing out.  Each time a Lambda function executes, there is no guarantee that it will execute in a new interpreter or context – what this means in practice is that if you are using global variables within your Lambda functions, they may contain data from previous Lambda executions.  As such,you should always reinitialize them at the beginning of your Lambda entry point.

I had been using Lambdas triggered from Kinesis streams, and they seemed to be a lot less lightweight than I’d expected.  Turns out I was processing and shipping around 50,000,000 records per minute whereas the actual figure should’ve been somewhere around 20,000,000 per minute, and with each Lambda execution within the same interpreter, the number of records processed roughly doubled, as did the execution time.  Whoops!

This behavior does make sense because I’m sure it’s super expensive to spin up new interpreters for functions that might execute 10,000 or more times per second, but for some reason I had wrongly assumed that the environment would be fresh for each execution.

The really interesting thing here is that, knowing this behavior allows us to have a shared state between multiple Lambda executions with a single interpreter (albeit unpredictably with regards to what data will be processed or how many cycles will execute before the interpreter is respawned).  For fun, I implemented some basic hash-based log deduplication making use of this behavior.  I wonder what else would be interesting to do using this shared state.

Telephreak 11 Badge Update – BUGS!

Hey everybody, just wanted to give a quick status update on the Telephreak badges.


If your badge has a white screen, there’s probably either a hardware issue, or (more likely), it hasn’t downloaded an image from another badge yet.

The software is buggy, and radio transmissions can be garbled when downloading images with multiple badges in the area. I thought I had this sorted out, but apparently not.

I’ve put the source code for everything at – you can build these using the Arduino IDE (with libraries in the ‘libs’ folder) or using PlatformIO (which is way cooler) – Please don’t judge my code, I wrote this in a couple days with minimal sleep, and I’m sure there are a ton of obvious errors along the way 😛

Badges are reprogrammable via ICSP, using the labeled pins and PC6 as “reset” – to do so you must connect CS on the display, nSS on the radio, and CS on the flash chip ALL to VCC lines.


The badges in the Telephreak swag box are unassembled badge kits. They should be easy to assemble.

Battery packs are connected to H4 on the board, with the red wire connected to the square solder pad. The rotation of the SAO connector at the top left doesn’t matter.


Badge Delivery

I have 20 working badge kits to assemble for people I’ve promised them to, and another 15 badge boards that failed hardware tests yesterday. Gonna try and get these sorted today, and that should give me enough assembled units to give to everyone I’ve promised one to if everything works out.

If not, I have more boards at home, and I’d be glad to assemble and ship yours to you after DEFCON.

Telephreak 11 Badge Release Notes

Welcome to the Telephreak 11 badge!

This was a very hasty project, with just over six weeks from concept to “finished” product. It was stressful, but I had fun and learned a TON. Expect bugs and all sorts of weird behavior.

Nine total PCB revisions were actually fabbed, and the final one still had a couple of bugs. This was my first time designing or building electronics, and I had to dive into a lot of stuff I didn’t expect. I understand digital logic fairly well, but I didn’t realize that I would have to modify the SPI Flash library I used to send extra raw bytes down the SPI bus because the Flash chips I ordered had a secondary write-protect mode that I needed to toggle a couple bits for. That was a fun day. There are also a few scenarios I can think of that might send the badges into an inifite loop or one that might take a very long time to complete, but fortunately there’s a reset button on the front. I wrote fixes for a few of them but they broke some other things and I didn’t have any time left to debug further.

The basic way these communicate is a store-and-forward implementation – each badge will beacon out periodically with a token signifying the image it’s currently displaying. If a badge sees another unit with a newer image, it will send a request for that image, and after a handshake the image will be sent over. This can take a couple minutes to complete. This is due to write speeds on the SPI flash itself, also because some of the mods I made to the SPI Flash library were horribly inefficient, but this gives other radios a chance to communicate with each other in a congested environment.

When an image is received, it is stored in a temporary section of the Flash, and if enough CRC-correct, SEQ-correct packets are received from the correct source node, the badge assumes it’s gotten a complete and valid image, and it will be copied to the primary store of the Flash and then displayed. There is no input validation AT ALL for images received (and other things), so bugs and unexpected corruption and interference can make all sorts of cool glitchy things happen.

There’s an output-only serial console:
TX PD1, 115200 8n1

and ICSP:
MOSI, MISO, SCK0, PC6 = Reset (Be sure to tie nSS on the radio, CS on the display, and CS on the Flash chip all to VCC before using)

** After a reset, if you see the serial console output “No! I don’t want that!” after it brings up any hardware, it means that component probably needs to be resoldered. Shoot me a message. **

These should be fun to hack on, and I think the hardware is way more solid than the software. I’ll be releasing full schematics and source code after DEFCON to make it easier for everyone to use these as a hackable packet radio platform.

Enjoy, be patient with them, and please don’t brick everyone’s badges with Goatse on the first day!

Rucas (@DominoTree)

Using the XGecu TL866II Plus Under Linux with Wine

Fortunately, thanks to the work of radiomanV, it’s very easy to get your XGecu TL866II working under Linux with Wine.

After installing Wine, use it to run the Xgpro setup tool.  Afterwards, there are only two things to do.

First, run the following command:
sudo echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="a466", ATTRS{idProduct}=="0a53", GROUP="plugdev", MODE="0666"' > /etc/udev/rules.d/51-minipro.rules && sudo udevadm trigger
This will change how Linux handles the USB device when it’s plugged into your machine.

Second, download and place it in the directory that Xgpro was installed to.

You should now be able to start Xgpro with Wine, and it should be able to interact with your TL866II as expected.  I’ve been using this method for a few days and haven’t had any issues, and it’s a lot more convenient than having to fire up a VM and transfer files to/from it.

If you have an older device, there are also similar instructions to get the TL866 working under Wine in the same repository.

Why your new ATmega328P is Acting Strangely When You Run Arduino Binaries

I was recently working on a project based on the ubiquitous ATmega328P microcontroller from Atmel.  I decided that to make it easy for other people to work with, I would write the software for the microcontroller in the Arduino IDE.

Once I had a basic image prepared and loaded onto the microcontroller using a device programmer, I found that it seemed to run very slowly, and output from the serial ports was mangled.  Here’s the basic circuit implementation I used:

After some Googling, I found that, by default, the ATmega328 uses some internal circuitry and will run at a clockspeed of 1MHz rather than using the external crystal clocked at 16MHz.  I verified this by reading from the serial port at 600 baud (1/16th of the 9600 baud rate I specified) and sure enough, I got valid output.  The Arduino IDE, configured for an Arduino Uno (ATmega328P) board, assumes that the device will be running at 16MHz, and if that clock rate is deviated from, all of the calculated bus speeds and time delays will be thrown off.

With the basic circuit above, there are some internal fuses on the ATmega328 that must be set appropriately to use the external crystal oscillator.  Additionally, when running at clock speeds above 8MHz, there’s an additional bit that must be unset to ensure device stability.

The fuse low byte of the device must be 0xF7, the high byte must be 0xDE, and the extended fuse byte must be 0xFF.  In the settings for my device programmer, this is controlled by setting certain bits to 0, as they all default to 1.

If you’ve purchased a default ATmega328 microcontroller and are experiencing strange behavior when trying to run binaries built in the Arduino environment, make sure your fuse settings match the image below.

Scaling Network Security Technologies by Decoupling Traffic Ingestion from Analysis using Open-Source

Thanks to my good friend Marc Uchniat for helping develop this idea

As networks grow larger and faster, monitoring technologies have a difficult time scaling. Most times, solutions involve splitting traffic into smaller and smaller feeds from network tap infrastructure, and running analysis tools at line-rate on that traffic. If the traffic volume exceeds the processing capabilities of the machine, frames are dropped, flows cannot be properly analyzed, and threats may go undetected.

This proposal allows analysis to occur asynchronously, allowing it to be scaled arbitrarily between any number of nodes running various software, with guaranteed delivery and processing of all observed flows. I’ve been writing the necessary components for this pipeline in Rust over the past few weeks, and as things come together they will be open-sourced under the GPL.

The first step is an extremely lightweight TCP flow re-assembler using bindings to AF_PACKET. It can handle traffic far more efficiently than systems that also handle analysis of that traffic. Once flows are reassembled, they are sent to an Apache Kafka pipeline on a topic that is subscribed to by various clients doing traffic analysis. As part of the pipeline, Elasticsearch or Stenographer might be used as a rolling buffer to retain a few hours of full packet data. This would be useful, for example, if an IDS system generates an alert, the rolling buffer could be queried to generate a pcap containing the flow that generated the alert, as well as related traffic, with an arbitrary granularity. That pcap could then be sent to long-term storage for an analyst to look at, without having to store more network traffic than necessary.

Essentially, the Kafka infrastructure becomes a giant buffer for network traffic, providing guaranteed delivery, and an arbitrary number of clients and Kafka nodes can be added to accommodate the necessary workload, instead of building larger and larger individual systems that are tasked with analyzing traffic at line-rate.

Related repositories (these are all VERY early-stage): (Rust bindings for the Linux kernel AF_PACKET API) (Very basic TCP flow reassembler) (Application to tie the previous two libraries together and send data to Kafka) (Replays TCP flows from Kafka on a virtual network interface at an arbitrarily-specified rate)

Getting into the Pace 5268AC Router, part 3: Sacrifices Must be Made (to the JTAG gods)

After several unsuccessful attempts to figure out how the password for the PKCS12 archives is generated, I decided to build a jig to interface with the diagnostic port on the front to see if I could find a JTAG interface.  Unfortunately, the connector used had a 1mm pin pitch that was difficult to find an off-the-shelf board to solder to.  This was going to take some Dremel work.

Here’s where we started…

And this is what we ended up with.

Hey, it may be ugly, but it worked.  The next step was to do some bit-banging and other horrible stuff to look for any useful interfaces on these pins.

After a ton of attempts, I came up empty-handed other than the serial console I’d already found. At least this jig makes the console a lot more reliable.

Thanks to the OpenWRT project, I did have a pinout of the particular SoC used in this device.  The next step was to remove the SoC from the board and use a multimeter to find test pads tied to the pins I cared about.

Time to get my hands dirty. After some less-than-precise work with a hot air gun, I got the SoC off of the board and cleaned everything up.

I took photos of both sides of the board to document what I found, and after some time, I managed to find test pads on the board that corresponded to each JTAG pin on the Broadcom SoC. This was a huge pain because the pins on the SoC are 0.4mm wide and 0.4mm apart, so tying into individual ones was pretty frustrating.

The next step is to figure out how to set up a generic MIPS JTAG toolchain using OpenOCD.

Let’s Repair an Ancient Macintosh SE/30, part 2: What the Hell is a Simasimac?

After the previous post, the first order of business was to get the capacitors and battery replaced. I used tantalum capacitors instead of electrolytics to prevent the same thing from happening again down the road. This presented some challenges, as some of the larger electrolytics had very different footprints from their tantalum counterparts.

I simply ran some wire from the leads on the capacitors to the holes on the board, and that seemed to work well.

The next order of business was to figure out what was going on with the display.

It looked like one of the driver coils was not working. After checking out the analog board, the issue was pretty obvious.

I resoldered all four connections that went to the horizontal and vertical coils on the CRT, and then fired the system up to see where we’d gotten.

This is where we ended up:

After some research, this is known as a “Simasimac” screen.  Interestingly, it seems that when there is basically *any* failure of address or data lines between the CPU, ROMs, and RAM, this exact pattern is displayed. I was disappointed that it didn’t fire right up, however, it seems that if I take the time to test continuity between all of the CPU, ROM, and RAM pins and reconnect any broken ones using rework wire, I’ll probably end up with a functioning Mac.  It’s going to be a pain to work through, but fortunately schematics of these computers are available, so that should eliminate a lot of the guesswork involved.

Bitwise Operations and Common Uses: Decoding TCP and IPv4 Headers using AND and Bitwise Shifts

Wrapping your head around the use of bitwise operators can be daunting in the beginning. In my next few posts, I’m going to attempt to walk through some common use cases for bitwise operators that I’ve encountered.

The first use case I’m going to discuss is protocol decoding. Data is stored in bytes, each of which is comprised of eight bits, with a total of 256 possible values per byte (0 to 255). Many common protocols, especially long-lived ones like IPv4, pack multiple values into a single byte to save space. Here’s an example.

Source: Wikipedia

Several of the values here do not line up directly on octet (byte) boundaries. From this chart, how would we get the version, which takes up only the first half of the first byte? To begin, we need to get the whole byte.  A common value here would be 69 in decimal representation.  Let’s take a look at what that actually looks like in binary.

Bitwise Right-Shift

A bitwise right-shift simply moves all the bits in a value one position to the right, dropping the rightmost bit and filling the leftmost bit with zero each time the values are moved.

To obtain our value, we will shift those top four bits to the bottom four bits of the byte by doing a right shift (>>). It will fill in the previous four bits with zeroes.

Let’s take a look at the bit pattern.

This is an IPv4 header, so 4 is the correct value. 

Bitwise AND

AND takes two operands and returns a value with only the bits set to 1 that were set to 1 in both operands. If either operand has a zero for a bit in a position, it will be zero in that position in the result.
Let’s try to get the IHL number.  We start back with 69.

We then mask the bits we care about.

This is equal to the decimal number 15.  Next, we do our AND operation.

Since the bits were already in the correct position, we didn’t need to perform any shifts. The default value of the IHL field in an IPv4 header is 5, so we’ve got the correct answer! Let’s look at the bit pattern.

AND with Flags

It’s common to see single bits in a byte used as flags. TCP is a good example.

Source: Wikipedia

In the 13th octet, you will see that all eight bits are used for individual flags. Let’s say that the SYN and ACK flags are set.

The easiest way to deal with this is an AND. Let’s take a look at the SYN and ACK flags. The ACK flag is in the second position. Let’s mask it off.

To check for the individual flag, we simply use an AND, and then confirm that the result is equal to the value of the mask.

We can also use this technique to check for multiple bits at once. Let’s make a mask to check for three bits being set.

Since the result was 18 but our mask was 19, not all three flags were set.

Combining Right-Shift with AND

Sometimes you’ll want to get a multi-bit value that’s in the middle of a byte. We can combine these two operators to get the data we want, and what’s more, we can do them in any order. Let’s take a look at octet 12 of the TCP header. What if we want to take a look and see if there’s data in the reserved section? We’ll need to mask those bits and then shift them to the right (or shift them to the right and mask them second). Here’s some random data.

Let’s do a shift first and see what happens.

And here’s the bit pattern

Now we’ll mask the last three bits

And we’ll do an AND

Which has the bit pattern of

Let’s try in the other order.

We start with our original value.

Now we mask the three bits we want

We perform our AND

Which has a bit pattern of

Which we then shift right one place

Which gives us the same bit pattern of

AF_PACKET bindings for Rust

I’ve finally gotten my AF_PACKET bindings in Rust working properly – this should allow people to start developing network sniffers, monitoring tools, and security-related software using Rust.  There’s a lot of clean-up ahead and I want to make the interface more controllable, but for now, it’s still pretty simple to use.  I need to write a bunch of documentation as well.

The Linux kernel will balance flows based on hash so you shouldn’t need to do any cross-thread communication to reassemble flows.

The project is on GitLab and and packages are available on  I’ve pasted a dead-simple example below.