As more and more electric vehicles penetrate the market, there’s going to have to be a proportional rise in the number of charging stations that are built into parking garages, apartment complexes, and even private homes. And the more that happens, the more chargers we’re going to start seeing where security is at best an afterthought in their design.
But as this EV charger teardown and reverse engineering shows, it doesn’t necessarily have to be that way. The charger is a Zaptec Pro station that can do up to 22 kW, and the analysis was done by [Harrison Sand] and [Andreas Claesson]. These are just the kinds of chargers that will likely be widely installed over the next decade, and there’s surprisingly little to them. [Harrison] and [Andreas] found a pair of PCBs, one for the power electronics and one for the control circuits. The latter supports a number of connectivity options, like 4G, WiFi, and Bluetooth, plus some RFID and powerline communications. There are two microcontrollers, a PIC and an ARM Cortex-A7.
Despite the ARM chip, the board seemed to lack an obvious JTAG port, and while some unpopulated pads did end up having a UART line, there was no shell access possible. An on-board micro SD card slot seemed an obvious target for attack, and some of the Linux images they tried yielded at least a partial boot-up, but without knowing the specific hardware configuration on the board, that’s just shooting in the dark. That’s when the NAND flash chip was popped off the board to dump the firmware, which allowed them to extract the devicetree and build a custom bootloader to finally own root.
The article has a lot of fascinating details on the exploit and what they discovered after getting in, like the fact that even if you had the factory-set Bluetooth PIN, you wouldn’t be able to get free charging. So overall, a pretty good security setup, even if they were able to get in by dumping the firmware. This all reminds us a little of the smart meter reverse engineering our friend [Hash] has been doing, in terms of both methodology and results.
Thanks to [Thinkerer] for the tip.
[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” →
Teaching people efficiently isn’t limited to transmitting material from one head to another — it’s also about conveying the principles that got us there. [Mara Bos] shows us a toolkit (Twitter,
nitter link) that you can arm your students with, creating a small playground where, given a set of constraints, they can invent and figure communication protocols out on their own.
This tool is aimed to teach digital communication protocols from a different direction. We all know that UART, I2C, SPI and such have different use cases, but why? Why are baud rates important? When are clock or chip select lines useful? What’s the deal with the start bit? We kinda sorta figure out the answers to these on our own by mental reverse-engineering, but these things can be taught better, and [Mara] shows us how.
Gently guided by your observations and insights, your students will go through defining new and old communication standards from the ground up, rediscovering concepts like acknowledge bits, bus contention, or even DDR. And, as you point out that the tricks they just discovered have real-world counterparts, you will see the light bulb go on in their head — realizing that they, too, could be part of the next generation of engineers that design the technologies of tomorrow.
Continue reading “Boards For Playful Exploration Of Digital Protocols” →
We ran an article this week about RS-485, a noise resistant differential serial multidrop bus architecture. (Tell me where else you’re going to read articles like that!) I’ve had my fun with RS-485 in the past, and reading this piece reminded me of those days.
You see, RS-485 lets you connect a whole slew of devices up to a single bundle of Cat5 cable, and if you combine it with the Modbus protocol, you can have them work together in a network. Dedicate a couple of those Cat5 lines to power, and it’s the perfect recipe for a home, or hackerspace, small-device network — the kind of things that you, and I, would do with WiFi and an ESP8266 today.
Wired is more reliable, has fewer moving parts, and can solve the “how do I get power to these things” problem. It’s intrinsically simpler: no radios, just serial data running as voltage over wires. But nobody likes running cable, and there’s just so much more demo code out there for an ESP solution. There’s an undeniable ease of development and cross-device compatibility with WiFi. Your devices can speak directly to a computer, or to the whole Internet. And that’s been the death of wired.
Still, some part of me admires the purpose-built simplicity and the bombproof nature of the wired bus. It feels somehow retro, but maybe I’ll break out some old Cat5 and run it around the office just for old times’ sake.
The hobbyists of the early days of the home computer era worked wonders with the comparatively primitive chips of the day, and what couldn’t be accomplished with a Z80 or a 6502 was often relegated to complex designs based on logic chips and discrete components. One wonders what these hackers could have accomplished with the modern components we take for granted.
Perhaps it would be something like this minimal serial terminal for the current crop of homebrew retrocomputers. The board is by [Augusto Baffa] and is used in his Baffa-2 homebrew microcomputer, an RC2014-esque Z80 machine that runs CP/M. This terminal board is one of many peripheral boards that plug into the Baffa-2’s backplane, but it’s one of the few that seems to have taken the shortcut of using modern microcontrollers to get its job done. The board sports a pair of ATmega328s; one handles serial communication with the Baffa-2 backplane, while the other takes care of running the VGA interface. The card also has a PS/2 keyboard interface, and supports VT-100 ANSI escapes. The video below shows it in action with a 17″ LCD monitor in the old 4:3 aspect ratio.
We like the way this terminal card gets the job done simply and easily, and we really like the look of the Baffa-2 itself. We also spied an IMSAI 8080 and an Altair 8800 in the background of the video. We’d love to know more about those.
Continue reading “Retro Serial Terminal Uses Modern Chips To Get CP/M Machine Talking” →
The Musical Instrument Digital Interface has a great acronym that is both nice to say and cleanly descriptive. The standard for talking to musical instruments relies on a serial signal at 31250 bps, which makes it easy to transmit using any old microcontroller UART with a settable baud rate. However, [Kevin] has dived into explore the utility of sending MIDI signals over I2C instead.
With a bit of hacking at the Arduino MIDI library, [Kevin] was able to get the microcontroller outputting MIDI data over the I2C interface, and developed a useful generic I2C MIDI transport for the platform. His first tests involved using this technique in concert with Gravity dual UART modules. After he successfully got one running, [Kevin] realised that four could be hooked up to a single Arduino, giving it 8 serial UARTS, or, in another way of thinking, 8 MIDI outputs.
At its greatest level of development, [Kevin] shows off his I2C MIDI chops by getting a single Raspberry Pi Pico delivering MIDI signals to 8 Arduinos, all over I2C. All the Arduinos are daisy-chained with their 5V and I2C lines wired together, and the system basically swaps out traditional MIDI channels for I2C addresses instead.
There’s not a whole lot of obvious killer applications for this, but if you want to send MIDI data to a bunch of microcontrollers, you might find it easier daisy-chaining I2C rather than hopping around with a serial line in the classic MIDI-IN/MIDI-THRU fashion.
We’ve seen [Kevin]’s work before too, like the wonderful Lo-Fi Orchestra. Video after the break.
Continue reading “You Can Send MIDI Over I2C If You Really Need To” →
We’ve gotten used to the GPIO-available functions of Raspberry Pi computers remaining largely the same over the years, which is why it might have flown a little bit under the radar: the Raspberry Pi 4 has six SPI controllers, six I2C controllers, and six UARTs – all on its 40-pin header. You can’t make use of all of these at once, but with up to four different connections wired to a single pin you can carve out a pretty powerful combination of peripherals for your next robotics, automation or cat herding project.
The datasheet for these peripherals is pleasant to go through, with all the register maps nicely laid out – even if you don’t plan to work with the register mappings yourself, the maintainers of your preferred hardware enablement libraries will have an easier time! And, of course, these peripherals are present on the Compute Module 4, too. It might feel like such a deluge of interfaces is excessive, however, it lets you achieve some pretty cool stuff that wouldn’t be possible otherwise.
Having multiple I2C interfaces helps deal with various I2C-specific problems, such as address conflicts, throughput issues, and mixing devices that support different maximum speeds, which means you no longer need fancy mux chips to run five low-resolution Melexis thermal camera sensors at once. (Oh, and the I2C clock stretching bug has been fixed!) SPI interfaces are used for devices with high bandwidth, and with a few separate SPI ports, you could run multiple relatively high-resolution displays at once, No-Nixie Nixie clock style.
As for UARTs, the Raspberry Pi’s one-and-a-half UART interface has long been an issue in robotics and home automation applications. With a slew of devices like radio receivers/transmitters, LIDARs and resilient RS485 multi-drop interfaces available in UART form, it’s nice that you no longer have to sacrifice Bluetooth or a debug console to get some fancy sensors wired up to your robot’s brain. You can enable up to six UARTs. Continue reading “Did You Know That The Raspberry Pi 4 Has More SPI, I2C, UART Ports?” →