FLOSS Weekly Episode 780: Zoneminder — Better Call Randal

This week Jonathan Bennett and Aaron Newcomb chat with Isaac Connor about Zoneminder! That’s the project that’s working to store and deliver all the bits from security cameras — but the CCTV world has changed a lot since Zoneminder first started, over 20 years ago. The project is working hard to keep up, with machine learning object detection, WebRTC, and more. Isaac talks a bit about developer burnout, and a case or two over the years where an aggressive contributor seems suspicious in retrospect. And when is the next stable version of Zoneminder coming out, anyway?

Continue reading “FLOSS Weekly Episode 780: Zoneminder — Better Call Randal”

Slicing And Dicing The Bits: CPU Design The Old Fashioned Way

Writing for Hackaday can be somewhat hazardous. Sure, we don’t often have to hide from angry spies or corporate thugs. But we do often write about something and then want to buy it. Expensive? Hard to find? Not needed? Doesn’t really matter. My latest experience with this effect was due to a recent article I wrote about the AM2900 bitslice family of chips. Many vintage computers and video games have them inside, and, as I explained before, they are like a building block you use to build a CPU with the capabilities you need. I had read about these back in the 1970s but never had a chance to work with them.

As I was writing, I wondered if there was anything left for sale with these chips. Turns out you can still get the chips — most of them — pretty readily. But I also found an eBay listing for an AM2900 “learning and evaluation kit.” How many people would want such a thing? Apparently enough that I had to bid a fair bit of coin to take possession of it, but I did. The board looked like it was probably never used. It had the warranty card and all the paperwork. It looked in pristine condition. Powering it up, it seemed to work well.

What Is It?

The board hardly looks at least 40  years old.

The board is a bit larger than a letter-sized sheet of paper. Along the top, there are three banks of four LEDs. The bottom edge has three banks of switches. One bank has three switches, and the other two each have four switches. Two more switches control the board’s operation, and two momentary pushbutton switches.

The heart of the device, though, is the AM2901, a 4-bit “slice.” It isn’t quite a CPU but more just the ALU for a CPU. There’s also an AM2909, which controls the microcode memory. In addition, there’s a small amount of memory spread out over several chips.

A real computer would probably have many slices that work together. It would also have a lot more microprogram memory and then more memory to store the actual program. Microcode is a very simple program that knows how to execute instructions for the CPU. Continue reading “Slicing And Dicing The Bits: CPU Design The Old Fashioned Way”

Hackaday Links Column Banner

Hackaday Links: April 21, 2024

Do humanoid robots dream of electric retirement? Who knows, but maybe we can ask Boston Dynamics’ Atlas HD, which was officially retired this week. The humanoid robot, notable for its warehouse Parkour and sweet dance moves, never went into production, at least not as far as we know. Atlas always seemed like it was intended to be an R&D platform, to see what was possible for a humanoid robot, and in that way it had a heck of a career. But it’s probably a good thing that fleets of Atlas robots aren’t wandering around shop floors or serving drinks, especially given the number of hydraulic blowouts the robot suffered. That also seems to be one of the lessons Boston Dynamics learned, since Atlas’ younger, nimbler replacement is said to be all-electric. From the thumbnail, the new kid already seems pretty scarred and battered, so here’s hoping we get to see some all-electric robot fails soon.

Continue reading “Hackaday Links: April 21, 2024”

The Long And The Short Of It

Last weekend was Hackaday Europe 2024, and it was great. Besides having some time to catch up with everyone, see some fun new badge hacks, and of course all the projects that folks brought along, I also had time to attend most all of the talks. And the talks were split into two distinct sections: long-format talks on Saturday and a two-hour session of seven-minute lightning talks on Sunday.

I don’t know if it’s our short attention spans, or the wide range of topics in a short period of time, but a number of people came up after the fact and said that they really appreciated the short-but-sweet format. One heretic even went so far as to suggest that we only have lightning talks in the future.

Well, we’ve done that before – the Hackaday Unconferences. One year, we even ran three of them simultaneously! I was at Hackaday’s London Unconference the year later, and it was a blast.

But I absolutely appreciate the longer talks too. Sometimes, you just have to give a speaker free rein to dig really deeply into a topic. When the scope of the project warrants it, there’s just no substitute for letting someone tell the whole story. So I see a place for both!

If you were at Hackaday Europe, or any other conference with a lightning talks track, what do you think? Long or short? Or a good mix?

Hackaday Podcast Episode 267: Metal Casting, Plasma Cutting, And A Spicy 555

What were some of the best posts on Hackaday last week? Elliot Williams and Al Williams decided there were too many to choose from, but they did take a sampling of the ones that caught their attention. This week’s picks were an eclectic mix of everything from metal casting and plasma cutters to radio astronomy and space telescope budgets. In between? Some basic circuit design, 3D printing, games, dogs, and software tools. Sound confusing? It won’t be, after you listen to this week’s podcast.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download an audiophile-quality oxygen-free MP3 file here.

Continue reading “Hackaday Podcast Episode 267: Metal Casting, Plasma Cutting, And A Spicy 555”

This Week In Security: Putty Keys, Libarchive, And Palo Alto

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto”

Human-Interfacing Devices: HID Over I2C

In the previous two HID articles, we talked about stealing HID descriptors, learned about a number of cool tools you can use for HID hacking on Linux, and created a touchscreen device. This time, let’s talk about an underappreciated HID standard, but one that you might be using right now as you’re reading this article – I2C-HID, or HID over I2C.

HID as a protocol can be tunneled over many different channels. If you’ve used a Bluetooth keyboard, for instance, you’ve used tunneled HID. For about ten years now, I2C-HID has been heavily present in laptop space, it was initially used in touchpads, later in touchscreens, and now also in sensor hubs. Yes, you can expose sensor data over HID, and if you have a clamshell (foldable) laptop, that’s how the rotation-determining accelerometer exposes its data to your OS.

This capacitive touchscreen controller is not I2C-HID, even though it is I2C. By [Raymond Spekking], CC-BY-SA 4.0
Not every I2C-connected input device is I2C-HID. For instance, if you’ve seen older tablets with I2C-connected touchscreens, don’t get your hopes up, as they likely don’t use HID – it’s just a complex-ish I2C device, with enough proprietary registers and commands to drive you crazy even if your logic analysis skills are on point. I2C-HID is nowhere near that, and it’s also way better than PS/2 we used before – an x86-only interface with limited capabilities, already almost extinct from even x86 boards, and further threatened in this increasingly RISCy world. I2C-HID is low-power, especially compared to USB, as capable as HID goes, compatible with existing HID software, and ubiquitous enough that you surely already have an I2C port available on your SBC.

In modern world of input devices, I2C-HID is spreading, and the coolest thing is that it’s standardized. The standardization means a lot of great things for us hackers. For one, unlike all of those I2C touchscreen controllers, HID-I2C devices are easier to reuse; as much as information on them might be lacking at the moment, that’s what we’re combating right now as we speak! If you are using a recent laptop, the touchpad is most likely I2C-HID. Today, let’s take a look at converting one of those touchpads to USB HID.

A Hackable Platform

Continue reading “Human-Interfacing Devices: HID Over I2C”