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.

Dummies Guide To Reverse Engineering

[Juan Carlos Jiménez] has reverse engineered a router — specifically, a Huawei HG533. While that in itself may not sound substantial, what he has done is write a series of blog posts which can act as a great tutorial for anyone wanting to get started with sniffing hardware. Over the five part series, he walks through the details of identifying the hardware serial ports which open up the doors to the firmware and looking at what’s going on under the hood.

The first part deals with finding the one or several debug ports on the hardware and identifying the three important pins – Rx, Tx and GND. That’s when he shows novices his first trick – shining a flashlight from under the PCB to find the pins that have trace connections (most likely Rx and Tx), those that don’t have any connections (most likely CTS and DTR) and those that have connections to the copper pour planes (most likely VCC and GND). The Tx signal will be pulled up and transmitting data when the device is powered up, while the Rx signal will be floating, making it easy to identify them. Finding the Baud rate, though, will require either a logic analyser, or you’ll have to play a bit of a guessing game.

Once you have access to the serial port and know its baud rate, it’s time to hook it up to your computer and use any one of the several ways of looking at what’s coming out of there — minicom, PuTTY or TeraTerm, for example. With access to the devices CLI, and some luck with finding credentials to log in if required, things start getting interesting.

Over the next part, he discusses how to follow the data paths, in this case, looking at the SPI signals between the main processor and the flash memory, and explaining how to use the logic analyser effectively and decode the information it captures. Moving further, he shows how you can hook up a USB to SPI bridge, connect it to the flash memory, take a memory dump of the firmware and read the extracted data. He wraps it up by digging in to the firmware and trying to glean some useful information.

It’s a great series and the detailed analysis he does of this particular piece of hardware, along with providing a lot of general tips, makes it a perfect starting point for those who need some help when getting started on debugging hardware.

Thanks, [gnif] for posting this tip.

Continue reading “Dummies Guide To Reverse Engineering”

An Open Source 96 MSPS Logic Analyzer For $22

If you are in the market for an inexpensive USB logic analyser you have a several choices, but few of them deliver much in the way of performance. There are kits from China for a few dollars using microcontrollers at their heart, but they fail to deliver significant sample rates. If you require more, you will have to pay for it.

It is therefore rather interesting to see [kevinhub88]’s SUMP2 project, an open source logic analyser with a claimed 96 MSPS sample rate using an off-the-shelf Lattice iCEstick FPGA evaluation board that only costs about $20. It talks to a host computer via USB using the established SUMP protocol, so its software front-end comes from the sump.org logic analyser project. Edit: Since this post was published [Kevin] has contacted us to inform us that the project’s capabilities have now moved beyond SUMP’s capabilities and in fact it now uses his own software.

This project has the promise to add a very useful piece of test equipment to the armoury of the engineer on a budget, and to aid the cost-conscious reader he’s provided extensive documentation and installation instructions, as well as the code for the FPGA. Thanks to one of the more awesome hacks of 2015, there is an entirely open toolchain for this Lattice part, and our own [Al Williams] has written up a multi-part getting-started guide if you want to get your feet wet. You probably want one of these anyway, and now it’s a logic analyzer to boot.

We’ve covered quite a few inexpensive home-produced digital instruments here over the years, including this logic analyser with a slightly higher price tag, this inexpensive VNA, and this oscilloscope board. Maybe one day the bench of our dreams will all come on one open-source PCB for $100, who knows!

USB 2.0 FPGA Based 24 Channel Logic Analyzer


[lekernel] sent in his USB logic analyzer. I might just have to build this one for my work bench. It’s based on an Altera Cyclone 2 FPGA and he’s provided full schematics, source and a quick and dirty Linux driver to get things going. The board is nearly all surface mount, but he points out that the entire thing was soldered with a standard iron and de-soldering wick. If you’re looking for a good starter FPGA project, this looks like a good one.

I started writing for Hack-A-Day a little over a year ago. I’ve barely taken a break, but for the next week I’m going to be taking some serious time off on a Caribbean island. Thanks for a great year guys! While I’m gone, [fbz] has kindly consented to take over the reins. I’m looking forward to another year when I get back, but right now I’ve got to finish packing my dive gear.