If you ever need to write a binary file from a traditional language like C, it isn’t all that hard to do. About the worst thing you might have to deal with is attempts to fake line endings across Windows and Linux, but there’s usually a way to turn that off if it is on by default. However, if you are using some type of scripting language, binary file support might be a bit more difficult. One answer is to use a tool like xxd or t2b (text-to-binary) to handle the details. You can find the code for t2b on GitHub including prebuilt binaries for many platforms. You should be able to install xxd from your system repository.
These tools take very different approaches. You might be familiar with tools like od or hexdump for producing readable representations of binary files. The xxd tool can actually do the same thing — although it is not as flexible. What xxd can even reverse itself so that it can rebuild a binary file from a hex dump it creates (something other tools can’t do). The t2b tool takes a much different approach. You issue commands to it that causes it to write an original hex file.
Both of these approaches have some merit. If you are editing a binary file in a scripting language, xxd makes perfect sense. You can convert the file to text, process it, and then roll it back to binary using one program. On the other hand, if you are creating a binary file from scratch, the t2b program has some advantages, too.
I decided to write a few test scripts using bash to show how it all works. These aren’t production scripts so they won’t be as hardened as they could be, but there is no reason they couldn’t be made as robust as you were willing to make them.
Continue reading “Linux Fu: Scripting for Binary Files”
Over the years, Linux (well, the operating system that is commonly known as Linux which is the Linux kernel and the GNU tools) has become much more complicated than its Unix roots. That’s inevitable, of course. However, it means old-timers get to slowly grow into new features while new people have to learn all in one gulp. A good example of this is how software is typically built on a Linux system. Fundamentally, most projects use
make — a program that tries to be smart about running compiles. This was especially important when your 100 MHz CPU connected to a very slow disk drive would take a day to build a significant piece of software. On the face of it, make is pretty simple. But today, looking at a typical makefile will give you a headache, and many projects use an abstraction over make that further obscures things.
In this article, I want to show you how simple a makefile can be. If you can build a simple makefile, you’ll find they have more uses than you might think. I’m going to focus on C, but only because that’s sort of the least common denominator. A make file can build just about anything from a shell prompt.
Continue reading “Linux Fu: The Great Power of Make”
When we say “hack” here we most often mean either modifying something to do something different or building something out of parts. But as we build more Internet-connected things, it is worthwhile to think about the other kind of hack where people gain unauthorized access to a system. For example, you wouldn’t think a remote control would be a big deal for hackers. But the Logitech Harmony Hub connects to the Internet and runs Linux. What’s more is it can control smart devices like door locks and thermostats, so hacking it could cause problems. FireEye’s Mandian Red Team set out to hack the Harmony and found it had a lot of huge security problems.
The remote didn’t check Logitech’s SSL certificate for validity. It didn’t have a secure update process. There were developer tools (an SSH server) left inactive in the production firmware and — surprisingly — the root password was blank! The team shared their findings with Logitech before publishing the report and the latest patch from the company fixes these problems. But it is instructive to think about how your Raspberry Pi project would fare under the same scrutiny.
In fact, that’s the most interesting part of the story is the blow-by-blow description of the attack. We won’t spoil the details, but the approach was to feed the device a fake update package that turned on a dormant ssh server. Although they started by trying to solder wires to a serial port, that wasn’t productive and the final attack didn’t require any of that.
We’ve looked at some ways to harden Linux systems like the Raspberry Pi before, but honestly, it is an ongoing battle. We’ve seen plenty of devices with cybersecurity holes in them — some not found by good guy hackers first.
Frustrated by the glut of unsecured IoT devices? So are Microsoft. And they’re using custom Linux and hardware to do something about it.
Microsoft have announced a new ecosystem for secure IoT devices called “Azure Sphere.” This system is threefold: Hardware, Software, and Cloud. The hardware component is a Microsoft-certified microcontroller which contains Microsoft Pluton, a hardware security subsystem. The first Microsoft-certified Azure Sphere chip will be the MediaTek MT3620, launching this year. The software layer is a custom Linux-based Operating System (OS) that is more capable than the average Real-Time OS (RTOS) common to low-powered IoT devices. Yes, that’s right. Microsoft is shipping a product with Linux built-in by default (as opposed to Windows Subsystem for Linux). Finally, the cloud layer is billed as a “turnkey” solution, which makes cloud-based functions such as updating, failure reporting, and authentication simpler.
Continue reading “Microsoft Secures IoT from the Microcontroller Up”
During the early years of cell phones, lifespan was mainly limited by hardware (buttons wearing out, dropping phones, or water damage), software is a primary reason that phones are replaced today. Upgrades are often prompted by dissatisfaction with a slow phone, or manufacturers simply stopping updates to phone software after a few years at best. [Oliver Smith] and the postmarketOS project are working to fix the update problem, and have begun making progress on loading custom software onto cellphone processors and controlling their cellular modems. Continue reading “Unlock & Talk: Open Source Bootloader & Modem”
Many of us could use a general-purpose portable workstation, something small enough to pocket but still be ready for a quick troubleshooting session. Terminal apps on a smartphone will usually do the job fine, but they lack the panache of this pocketable pop-top Raspberry Pi workstation.
It doesn’t appear that [Michael Horne] has a specific mission in mind for his tiny Linux machine, but that’s OK — we respect art for art’s sake. The star of the show is the case itself, a unit intended for dashboard use with a mobile DVD player or backup camera. The screen is a 4.3″ TFT with a relatively low-resolution, so [Michael] wasn’t expecting too much from it. And he faced some challenges, like dealing with the different voltage needs for the display and the Raspberry Pi Zero W he intended to stuff into the base. Luckily, the display regulates the 12-volt supply internally to 3.3-volts, so he just tapped into the 3.3-volt pin on the Pi and powered everything from a USB charger. The display also has some smarts built in, blanking until composite video is applied, which caused a bit of confusion at first. A few case mods to bring connectors out, a wireless keyboard, and he had a nice little machine for whatever.
No interest in a GUI machine? Need a text-only serial terminal? We’ve seen that before too. And here’s one with a nice slide-out keyboard built in.
Continue reading “Pocket-Sized Workstation Sports Pi Zero, Pop-Up Screen”
Did you ever wonder what your monitor and your computer are talking about behind your back? As it turns out, there’s quite a conversation going on while the monitor and the computer decide how to get along, and sniffing out VGA communications can reveal some pretty fascinating stuff about the I²C protocol.
To reverse engineer the configuration information exchanged between a VGA monitor and a video card, [Ken Shirriff] began by lopping a VGA cable in two. The inside of such cables is surprisingly complex, with separate shielding wires for each color and sync channel and a host of control wires, all bundled in multiple layers of shielding foil and braid to reduce EMI. [Ken] identified the clock and data lines used for the I²C interface and broke those out into a PocketBeagle for analysis using the tiny Linux machine’s I²C tools.
With a Python script to help decode the monitor’s Extended Display Identification Data (EDID) data, [Ken] was able to see everything the monitor knows about itself — manufacturer, serial number, all the supported resolution modes, and even deprecated timing and signal information left over from the days when CRTs ruled the desktop. Particularly interesting are the surprisingly limited capabilities of a VGA display in terms of color reproduction, as well as [Ken]’s detailed discussion on the I²C bus in general and how it works.
We always enjoy these looks under the hood that [Ken] is so good at, and we look forward to his reverse engineering write-ups. His recent efforts include a look at core memory from a 50-year old mainframe and reverse engineering at the silicon level.