Manta project logo - a manta ray, with cursive 'manta' written next to it

Manta: An Open On-FPGA Debug Interface

We always can use more tools for FPGA debugging, and the Manta project by [Fischer Moseley] delivers without a shadow of a doubt. Manta lets you add a debug and data transfer channel between your computer and your FPGA, that you can easily access with helpfully included Python libraries.

With just a short configuration file as input, it gives you cores you add into your FPGA design, tapping the signals of interest as an FPGA-embedded logic analyzer, interacting with registers, and even letting you quickly transfer tons of data if you so desire.

Manta is easy to install, is developer-friendly, has been designed in Amaranth, and is fully open source as you would expect. At the moment, Manta supports both UART and Ethernet interfaces for data transfer. As for embedding the Manta cores into your project, they can be exported to both Amaranth and Verilog. You should check out the documentation website — it contains everything you might want to know to get started quick.

The Manta project has started out as our hacker’s MIT thesis, and we’re happy that we can cover it for you all. FPGA-embedded logic analyzers are a fascinating and much-needed tool, and we’ve had our own [Al Williams] tell you about his on-FPGA logic analysis journey!

Logic Analyzers: Tapping Into Raspberry Pi Secrets

Today, I’d like to highlight a tool that brings your hacking skills to a whole new level, and does that without breaking the bank – in fact, given just how much debugging time you can save, how many fun pursuits you can unlock, and the numerous features you can add, this might be one of the cheapest tools you will get. Whether it’s debugging weird problems, optimizing your code, probing around a gadget you’re reverse-engineering, or maybe trying to understand someone’s open-source library, you are likely missing out a lot if you don’t have a logic analyzer on hand!

It’s heartbreaking to me that some hackers still don’t know the value that a logic analyzer brings. Over and over again, tactical application of a logic analyzer has helped me see an entirely different perspective on something I was hacking on, and that’s just the thing I’d like to demonstrate today.

Diving In

A logic analyzer has a number of digital inputs, and it continuously reads the state of these digital inputs, sending them to your computer or showing them on a screen – it’s like a logic-level-only oscilloscope. If you have an I2C bus with one MCU controlling a sensor, connect a logic analyzer to the clock and data pins, wire up the ground, launch the logic analyzer software on your computer, and see what’s actually happening.

For instance, have you ever noticed the ID_SC and ID_SD pins on the Raspberry Pi GPIO connector? Are you wondering what they’re for? Don’t you want to check what actually happens on these pins? Let’s do that right now! Continue reading “Logic Analyzers: Tapping Into Raspberry Pi Secrets”

Bypassing Bitlocker With A Logic Analzyer

Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer and has pointed out and successfully exploited a rather obvious weakness in the BitLocker full volume encryption system, which as the linked article says, allows one to simply sniff the traffic between the discrete TPM chip and CPU via an SPI bus. The way Bitlocker works is to use a private key stored in the TPM chip to encrypt the full volume key that in turn was used to encrypt the volume data. This is all done by low-level device drivers in the Windows kernel and is transparent to the user.

TPM chip pins too small? Just find something else on the bus!

The whole point of BitLocker was to prevent access to data on the secured volume in the event of a physical device theft or loss. Simply pulling the drive and dropping it into a non-secured machine or some other adaptor would not provide any data without the key stored by the TPM. However, since that key must pass as plaintext from the TPM to the CPU during the boot sequence, [Guillaume] shows that it is quite straightforward — with very low-cost tools and free software — to simply locate and sniff out this TPM-to-CPU transaction and decode the datastream and locate the key. Using little more than a cheapo logic analyser hooked up to some conveniently large pins on a nearby flash chip (because the SCK, MISO, and MOSI pins are shared with the TPM) the simple TIS was decoded enough to lock onto the bytes of the TPM frame. This could then be decoded with a TPM stream decoder web app, courtesy of the TPM2-software community group. The command to look for is the TPM_CC.Unseal which is the request from the CPU to the TPM to send over that key we’re interested in. After that just grabbing and decoding the TPM response frame will immediately reveal the goods.

Continue reading “Bypassing Bitlocker With A Logic Analzyer”

Mis-captured signal transitions shown on the screen of the LA104, with problematic parts circled in red.

When Your Logic Analyzer Can’t Tell Good And Bad Signals Apart

[Avian] has picked up a Miniware LA104 – a small battery-powered logic analyzer with builtin protocol decoders. Such analyzers are handy tools for when you quickly need to see what really is happening with a certain signal, and they’re cheap enough to be sacrificial when it comes to risky repairs. Sadly, he stumbled upon a peculiar problem – the analyzer would show the signal glitching every now and then, even at very low bitrates. Even more surprisingly, the glitches didn’t occur in the signal traces when exported and viewed on a laptop.

A Pulseview window showing that the problem is not present in the exported capturesHe dug into the problem, as [Avian] does. Going through the problem-ridden capture files helped him realize that the glitch would always happen when one of the signal edges would be delayed by a few microseconds relative to other signal edges — a regular occurrence when it comes to digital logic. This seems to stem from compression being used by the FPGA-powered “capture samples and send them” part of the analyzer. This bug only relates to the signal as it’s being displayed on the analyzer’s screen, and turned out that while most of this analyzer’s interface is drawn by the STM32 CPU, the trace drawing part specifically was done by the FPGA using a separate LCD interface.

It would appear Miniware didn’t do enough testing, and it’s impossible to distinguish a good signal from a faulty one when using a LA104 – arguably, the primary function of a logic analyzer. In the best of Miniware traditions, going as far as being hostile to open-source firmware at times, the FPGA bistream source code is proprietary. Thus, this bug is not something we can easily fix ourselves, unless Miniware steps up and releases a gateware update. Until then, if you bought a LA104, you can’t rely on the signal it shows on the screen.

When it comes to Miniware problems, we’ve recently covered a Miniware tweezer repair, requiring a redesign of the shell originally held together with copious amount of glue. At times, it feels like there’s something in common between glue-filled unrepairable gadgets and faulty proprietary firmware. If this bug ruins the LA104 for you, hey, at least you can reflash it to work as an electronics interfacing multitool.

A light blue marker with a two-pin header replacing the tip, being pressed against the back of the keypad baord that's removed from the safe

Anyone Can Be The Master Of This Master Lock Safe

[Etienne Sellan] got one of these lovely $5 logic analyzers. As with any shiny new tool, he started looking for things to investigate with it, and his gaze fell on a Sentry Safe (produced by Master Lock). On the surface level, this keypad-equipped safe is designed decently when it comes to privilege separation. You can take the keypad board off and access its backside, but the keypad doesn’t make any decisions, it merely sends the digits to a different board embedded behind the safe’s door. The solenoid-connected board receives the PIN, verifies it, and then controls the solenoid that unlocks the safe.

[Etienne] hooked up a logic analyzer to the communication wire, which turned out to be a UART channel, and logged the keypad communication packets — both for password entry and for password change. Then, he wrote some Arduino code to send the same packets manually, which worked wonders. Bruteforcing wasn’t viable, however, due to rate limitation in the solenoid controller. Something drew his attention from there – if you want to change the password, the keypad requires you enter the factory code, unique to each safe and supplied in the instruction manual. That code entry is a separate kind of packet from the “change password” one.

More after the break…

Continue reading “Anyone Can Be The Master Of This Master Lock Safe”

A Gaggle Of Boards Makes For An I2C Playground

It’s not much of a stretch to assume that the majority of Hackaday readers are at least familiar with I2C. In fact, there’s an excellent chance that anyone who’s ever done more with an Arduino than blink the onboard LED has at one time or another used the serial communication protocol to talk to a sensor, display, or other external gadget. Of course, just because most of us have used it in a few projects doesn’t mean we truly understand it.

If you’re looking to brush up on your I2C knowledge, you could do worse than to follow the guide [András Tevesz] recently wrote up. With a title like Hardware Hacking 101: E01 I2C Sniffing, How to Listen to Your Arduino’s I2C Bus, you know you’re in for a good time. While the document is arguably geared more towards security researchers than electronic hobbyists, the concepts presented can be useful even if you’re just trying to debug your own projects. Continue reading “A Gaggle Of Boards Makes For An I2C Playground”

Analyzing The 6502 With Python And Cheap Dev Boards

The Before Times were full of fancy logic analyzers. Connect the leads on these analyzers to a system, find that super special ROM cartridge, and you could look at the bus of a computer system in real time. We’ve come a long way since then. Now we have fast, cheap bits of hardware that can look at multiple inputs simultaneously, and there are Open Source solutions for displaying and interpreting the ones and zeros on a data bus. [hoglet] has built a very clever 6502 protocol decoder using Sigrok and a cheap 16-channel logic analyzer.

This protocol decoder is capable of looking at the ones and zeros on the data bus of a 6502-based computer. Right now, [hoglet] able to stream two million 6502 cycles directly to memory, so he’s able to capture the entire startup sequence of a BBC Micro. The hardware for this build was at first an Open Bench Logic Sniffer on a Papilio One FPGA board. This hardware was changed to an impressively inexpensive Cypress FX2 development board that was reconfigured to a 16 channel logic analyzer.

The software stack is where this really shines, and here [hoglet] documented most of the build over on the stardot forums. The basic capture is done with Sigrok, the Open Source signal analysis toolchain. This project goes a bit further than simply logging ones and zeros to a file. [hoglet] designed an entire 6502 protocol decoder with Python. Here’s something fantastic: this was [hoglet]’s first major Python project.

To capture the ones and zeros coming out of a 6502, the only connections are the eight pins on the data bus, RnW, Sync, Rdy, and Phy2. That’s only twelve pins, and no connections to the address bus, but the protocol decoder quickly starts to predict what the current program counter should be. This is a really fantastic piece of work, enabling an entire stack trace on any 6502 computer for less than $20 in parts.