Although bash scripts are regularly maligned, they do have a certain simplicity and ease of creation that makes them hard to resist. But sometimes you really need to do some heavy lifting in another language. I’ll talk about Python, but actually, you can use many different languages with this technique, although you might need a little adaptation, depending on your language of choice.
Of course, you don’t have to do anything special to call another program from a bash script. After all, that’s what it’s mainly used for: calling other programs. However, it isn’t very handy to have your script spread out over multiple files. They can get out of sync and if you want to send it to someone or another machine, you have to remember what to get. It is nicer to have everything in one file.
These days, embedded systems often have networks and that can make them significantly more complex. Networks are usually pretty nondeterministic and there are a variety of oddball conditions. For example, when your public-access pick and place machine gets written up on Hackaday and you suddenly get a 50X surge in traffic, how does your network stack handle it? While there’s no silver bullet for network testing, there are some tricks that can make it easier and one of those is the tcpreplay utilities that allow you to record complex network traffic and then play it back in a variety of ways. This has many benefits, especially if you manage to capture that one thing that triggers bad behavior sporadically. Being able to play it back on demand can speed up diagnostics considerably.
General Idea
You probably know that tcpdump allows you to grab packet captures from a network interface and save them to a file. If you prefer a GUI, you probably use Wireshark, which uses the same underlying library (libpcap) to grab the data. In fact, you can capture data using tcpdump and look at it with Wireshark, although there are other tools like tcptrace or Ngrep that can work with the output, also.
While the output of the command can be a little cryptic without tool support, a program called tcpreplay can take that data and feed it back in a variety of ways. Of course, you can modify the file first — there are tools to make that easier and — if you need to — you can craft your own network traffic by hand or using one of a variety of tools. This process is often called “packet crafting.”
Embedded Linux devices are everywhere these days, and sooner or later, you’re going to want to poke around in one of them. But how? That’s where posts like this one from [Felipe Astroza] come in. While his work is focused on the Foscam C1 security camera, the techniques and tools he outlines here will work on all sorts of gadgets that have a tiny penguin at their core.
Rather than trying to go in through the front door, [Felipe] starts his assault with the nuclear option: removing the SPI MX25L12835F flash chip from the camera’s PCB and dumping its contents with a Raspberry Pi. From there he walks through the use of different tools to determine the partition scheme of the chip and eventually extract passwords and other interesting bits of information from the various file systems within.
Getting ready to remove the flash chip.
That alone would be worth the read, but things really get interesting once [Felipe] discovers the FirmwareUpgrade program. Since the Foscam’s software updates are encrypted, he reasons that reverse engineering this binary would uncover the key and allow for the creation of custom firmware images that can be flashed through the stock interface.
Further investigation with Ghidra and friends identifies an interesting shared library linked to the executable in question, which is then disassembled in an effort to figure out how the key is being obfuscated. We won’t ruin the surprise, but [Felipe] eventually gets what he’s after.
We are always envious of the Star Trek Enterprise computers. You can just sort of ask them a hazy question and they will — usually — figure out what you want. Even the automatic doors seemed to know the difference between someone walking into a turbolift versus someone being thrown into the door during a fight. [River] decided to try his new API keys for the private beta of an AI service to generate Linux commands based on a description. How does it work? Watch the video below and find out.
Some examples work fairly well. In response to “email the Rickroll video to Jeff Bezos,” the system produced a curl command and an e-mail to what we assume is the right place. “Find all files in the current directory bigger than 1 GB” works, too.
You need to package up a bunch of files, send them somewhere, and do something with them at the destination. It isn’t an uncommon scenario. The obvious answer is to create an archive — a zip or tar file, maybe — and include a shell script that you have to tell the user to run after unpacking.
That may be obvious, but it assumes a lot on the part of the remote user. They need to know how to unpack the file and they also need to know to run your magic script of commands after the unpack. However, you can easily create a shell script that contains a file — even an archive of many files — and then retrieve the file and act on it at run time. This is much simpler from the remote user’s point of view. You get one file, you execute it, and you are done.
In theory, this isn’t that hard to do, but there are a lot of details. Shell scripts are not compiled — at least, not typically — so the shell only reads what it needs to do the work. That means if your script is careful to exit, you can add as much “garbage” to the end of it as you like. The shell will never look at it, so it’s possible to store the payload there.
There’s little debate that Amazon’s Alexa ecosystem makes it easy to add voice control to your smart home, but not everyone is thrilled with how it works. The fact that all of your commands are bounced off of Amazon’s servers instead of staying internal to the network is an absolute no-go for the more privacy minded among us, and honestly, it’s hard to blame them. The whole thing is pretty creepy when you think about it.
Which is precisely why [André Hentschel] decided to look into replacing the firmware on his Amazon Echo with an open source alternative. The Linux-powered first generation Echo had been rooted years before thanks to the diagnostic port on the bottom of the device, and there were even a few firmware images floating around out there that he could poke around in. In theory, all he had to do was remove anything that called back to the Amazon servers and replace the proprietary bits with comparable free software libraries and tools.
Taping into the Echo’s debug port.
Of course, it ended up being a little trickier than that. The original Echo is running on a 2.6.x series Linux kernel, which even for a device released in 2014, is painfully outdated. With its similarly archaic version of glibc, newer Linux software would refuse to run. [André] found that building an up-to-date filesystem image for the Echo wasn’t a problem, but getting the niche device’s hardware working on a more modern kernel was another story.
He eventually got the microphone array working, but not the onboard digital signal processor (DSP). Without the DSP, the age of the Echo’s hardware really started to show, and it was clear the seven year old smart speaker would need some help to get the job done.
The solution [André] came up with is not unlike how the device worked originally: the Echo performs wake word detection locally, but then offloads the actual speech processing to a more powerful computer. Except in this case, the other computer is on the same network and not hidden away in Amazon’s cloud. The Porcupine project provides the wake word detection, speech samples are broken down into actionable intents with voice2json, and the responses are delivered by the venerable eSpeak speech synthesizer.
As you can see in the video below the overall experience is pretty similar to stock, complete with fancy LED ring action. In fact, since Porcupine allows for multiple wake words, you could even argue that the usability has been improved. While [André] says adding support for Mycroft would be a logical expansion, his immediate goal is to get everything documented and available on the project’s GitLab repository so others can start experimenting for themselves.
An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.
While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.
While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.
