When using an Arduino, at least once you’ve made it past blinking LEDs, you might start making use of the serial connection to send and receive information from the microcontroller. Communicating with the board while it’s interacting with its environment is a crucial way to get information in real-time. Usually, that’s as far as it goes, but [Pieter] wanted to take it a step farther than that with his command line interpreter (CLI) for the Arduino.
The CLI allows the user to run Unix-like commands directly on the Arduino. This means control of GPIO and the rest of the features of the microcontroller via command line. The CLI communicates between the microcontroller and the ANSI/VT100 terminal emulator of your choosing on your computer, enabling a wealth of new methods of interacting with an Arduino.
The CLI requires a hex file to be loaded onto the Arduino that you can find at a separate site, also maintained by [Pieter]. Once that’s running, you can get all of that sweet command line goodness out of your Arduino. [Pieter] also has some examples on his project page, as well as the complete how-to to get this all set up and running. There’s a lot going on in the command line world, in Linux as well as windows. So there’s plenty to explore there as well.
Amazon might not be happy about it, but at least part of the success of their Fire TV Stick was due to the large hacking and modification scene that cropped up around the Android-powered device. A quick search on YouTube for “Fire Stick Hack” will bring up a seemingly endless array of videos, some with millions of views, which will show viewers how to install unofficial software on the little media dongle. Now it looks like their latest media device, the Fire TV Cube, is starting to attract the same kind of attention.
The team at [Exploitee.rs] has recently taken the wraps off their research which shows the new Fire TV Cube can be rooted with nothing more than an Arduino and an HDMI cable you’re willing to cut apart. Of course, it’s a bit more complicated than just that, but between the video they’ve provided and their WiKi, it looks like all the information is out there for anyone who wants to crack open their own Cube. Just don’t be surprised if it puts you on the Amazon Naughty List.
The process starts by putting the device’s Amlogic S905Z into Device Firmware Upgrade (DFU) mode, which is done by sending the string “boot@USB” to the board over the HDMI port’s I2C interface. That’s where the HDMI cable comes in: you can cut into one and wire it right up to your Arduino and run the sketch [Exploitee.rs] has provided to send the appropriate command. Of course, if you want to get fancy, you could use an HDMI breakout board instead.
With the board in DFU mode in you gain read and write access to the device’s eMMC flash, but that doesn’t exactly get you in because there’s still secure boot to contend with. But as these things tend to go, the team was able to identify a second exploit which could be used in conjunction with DFU mode to trick the device into disabling signature verification. Now with the ability to run unsigned code on the Fire TV Cube, [Exploitee.rs] implemented fastboot to make it easier to flash their custom rooted firmware images to the hardware.
Small I2C OLED displays are common nowadays, and thanks to the work of helpful developers, there are also a variety of graphics libraries for using them. Most of them work by using a RAM buffer, which means that anything one wants to draw gets written to a buffer representing the screen, and the contents of that buffer are copied out to the display whenever it is updated. The drawback is that for some microcontrollers, there simply isn’t enough RAM for this approach to work. For example, a 128×64 monochrome OLED requires a 1024 byte buffer, but that’s bad news if a microcontroller has only 512 bytes of RAM in total like the ATtiny85. [David Johnson-Davies] has two solutions: a Tiny Graphics Library that needs no RAM buffer and an even slimmer Tiny Function Plotter, which we’ll discuss in order.
[David]’s Tiny Graphics Library works by taking advantage of a feature of SH1106 driver-based displays: the ability to read the display over I2C as well as write to it. With the ability to perform read-modify-write on a section at a time, using a large RAM buffer can be avoided. The only catch is that the library only works with OLEDs using the SH1106, but the good news is that these are very common at the usual Chinese resellers. ([David] notes that SH1106 is sometimes misspelled as “SSH1106”, so keep that in mind when searching.)
What about all those other SSD1306-based OLED displays out there? Are they out of luck? Not quite. [David] has one more trick up his sleeve: his Tiny Function Plotter works on the SSD1306 and also requires no RAM buffer. It’s unable to write text, but it can easily handle drawing graphs plotting things like values over time while needing very little overhead.
Another approach we’ve seen for using OLEDs driven by microcontrollers with limited memory is the solution [Michael] used in Tiny Sideways Tetris, which was done in part by realizing the smallest screen element he needed was a 4×4 block, and using that premise as the basis of a simple compression scheme.
You’ve no doubt heard about the “hardware implants” which were supposedly found on some server motherboards, which has led to all sorts of hand-wringing online. There’s no end of debate about the capabilities of such devices, how large they would need to be, and quite frankly, if they even exist to begin with. We’re through the looking-glass now, and there’s understandably a mad rush to learn as much as possible about the threat these types of devices represent.
[Nicolas Oberli] of Kudelski Security wanted to do more than idly speculate, so he decided to come up with a model of how an implanted hardware espionage device could interact with the host system. He was able to do this with off the shelf hardware, meaning anyone who’s so inclined can recreate this “Hardware Implant Playset” in their own home lab for experimentation. Obviously this is not meant to portray a practical attack in terms of the hardware itself, but gives some valuable insight into how such a device might function.
One of the most obvious attack vectors for hardware implants is what’s known as the Baseboard Management Controller (BMC). This is a chip used on modern motherboards to allow for remote control and monitoring of the system’s hardware, and promises to be a ripe target for attackers. There are a few sideband channels which can be used by the BMC chip to talk to other chips. To keep things simple [Nicolas] focused on the older I2C-derived SMBus (rather than the newer and more complex NC-SI), demonstrating what can be done once you have control of that bus.
Only problem was, he didn’t have a motherboard with a BMC to experiment with. After a little research, the answer came in the form of the Intel EXPI9301CTBLK network card, which features the 82574L SMBus chip. This allows for experimenting with a subset of SMBus functionality on any machine with a PCI-E slot. Even better, the card has an SMBus header on the top to plug into. [Nicolas] describes in detail how he enabled the SMBus interface by modifying the card’s EEPROM, which then allowed him to detect it with his HydraBus.
With the hardware setup, the rest of the write-up focuses on what you can do with direct control of SMBus on the network card. [Nicolas] demonstrates not only creating and sending Ethernet packets, but also intercepting an incoming packet. In both cases, a running instance of tcpdump on the host computer fails to see the packets even exist.
He goes on to explain that since SMBus is very similar to I2C and only requires four wires, the techniques shown could easily be moved from the Hydrabus dev board used in the demo, to a small microcontroller like the ATtiny85. But you would still need to find a way to add that microcontroller directly onto the network card without it being obvious to the casual observer.
There are a few different ways of getting firmware onto one of AVR’s ATtiny85 microcontrollers, including bootloaders that allow for firmware to be updated without the need to plug the chip into a programmer. However, [casanovg] wasn’t satisfied with those so he sent us a tip letting us know he wrote an I2C bootloader for the ATtiny85 called Timonel. It takes into account a few particulars of the part, such as the fact that it lacks a protected memory area where a bootloader would normally reside, and it doesn’t have a native I2C interface, only the USI (Universal Serial Interface). He’s just released the first functional version for the ATtiny85, but there’s no reason it couldn’t be made to work with the ATtiny45 and ATtiny25 as well.
Timonel is designed for systems where there is a more powerful microcontroller or microprocessor running the show (such as an ESP8266, Arduino, or even a board like a Raspberry Pi.) In designs where the ATtinys are on an I2C bus performing peripheral functions such as running sensors, Timonel allows the firmware for these peripheral MCUs to be updated directly from the I2C bus master. Embedded below is a video demo of [casanovg] sending simple serial commands, showing a successful firmware update of an AVR ATtiny85 over I2C.
There’s a bunch of companies selling wireless Super Nintendo style controllers out there. You can go on Amazon and get any number of modern pads that at least kinda-sorta look like what came with Nintendo’s legendary 1990’s game console. They’ve got all kinds of bells and whistles, Bluetooth, USB-C, analog sticks, etc. But none of them are legitimate SNES controllers, and for some people that’s just not good enough.
A custom ATMEGA328P-powered board polls the controller’s SPI serial shift register in much the same way the original SNES would have. It then takes those button states and sends them out over UART with a HC-05 Bluetooth module. The controller is powered by a 330 mAh 3.7V battery, and a charging circuit allows for easily topping the controller off with a standard USB cable.
A particularly nice touch on the controller is the use of custom light pipes for the status LEDs. [sjm4306] made them by taking pieces of transparent PLA 3D printer filament, heating and flattening the end, and then sanding it smooth. This provides a diffusing effect on the light, and we’ve got to say it looks very good. Definitely a tip to file away for the future.
[Chordata] is making a motion capture system for everyone to build and so far the results are impressive, enough to have been a finalist in the Hackaday Human Computer Interface Challenge. It started a few years ago as one person’s desire to capture a digital performance of a dancer on a stage and has grown into a community of contributors. The board files and software have just been released as alpha along with some instructions for making it work, though more detailed documentation is on the way.
Fifteen sensor boards, called K-Ceptors, are attached to various points on the body, each containing an LSM9DS1 IMU (Inertial Measurement Unit). The K-Ceptors are wired together while still allowing plenty of freedom to move around. Communication is via I2C to a Raspberry Pi. The Pi then sends the collected data over WiFi to a desktop machine. As you move around, a 3D model of a human figure follows in realtime, displayed on the desktop’s screen using Blender, a popular, free 3D modeling software. Of course, you can do something else with the data if you want, perhaps make a robot move? Check out the overview and the performance by a clearly experienced dancer putting the system through its paces in the video below.
As a side note, the latest log entry on their Hackaday.io page points out that whenever changes are made to the K-Ceptor board, fifteen of them need to be made in order to try it out. To help with that, they show the testbed they made for troubleshooting boards as soon as they come out of the oven.