You’ve probably heard about Google Chromebooks. Like Android, Chrome OS is based on some variant of Linux, but it is targeted at the “cloud first” strategy so Chromebooks typically don’t have a huge amount of storage or compute power. If you have a real Chromebook, you can also use it to run certain other kinds of programs via virtualization. However, Google has recently pushed out Chrome OS Flex which is meant to install on a spare laptop you might happen to have hanging around. Seems attractive to take that only Windows 7 laptop and repurpose it to run Chrome OS, especially if you can run Linux apps on it. Unfortunately, Chrome OS Flex has a very different use case and I would only recommend installing it if you meet the exact use case it addresses.
The other option, of course, is to just install Linux on that old hardware. There are several distributions that are made for that purpose and, honestly, even most of the major distributions will work fine on older hardware with a little tweaking to turn off some of the more resource-costly features. That assumes you know how to install, tweak, and maintain Linux.
I’ve tried a lot of the “newer” languages and, somehow, I’m always happiest when I go back to C++ or even C. However, there is one thing that gets a little on my nerves when I go back: the need to have header files with a declaration and then a separate file with almost the same information duplicated. I constantly make a change and forget to update the header, and many other languages take care of that for you. So I went looking for a way to automate things. Sure, some IDEs will automatically insert declarations but I’ve never been very happy with those for a variety of reasons. I wanted something lightweight that I could use in lots of different toolsets.
I found an older tool, however, that does a pretty good job, although there are a few limitations. The tool seems to be a little obscure, so I thought I’d show you what makeheaders — part of the Fossil software configuration management system. The program dates back to 1993 when [Dwayne Richard Hipp] — the same guy that wrote SQLite — created it for his own use. It isn’t very complex — the whole thing lives in one fairly large C source file but it can scan a directory and create header files for everything. In some cases, you won’t need to make big changes to your source code, but if you are willing, there are several things you can do.
I once asked a software developer at work how many times we called fork() in our code. I’ll admit, it was a very large project, but I expected the answer to be — at most — two digits. The developer came back and read off some number from a piece of paper that was in the millions. I told them there was no way we had millions of calls to fork() and, of course, we didn’t. The problem was the developer wasn’t clear on the difference between a regular expression and a glob.
Tools like grep use regular expressions to create search patterns. I might write [Hh]ack ?a ?[Dd]ay as a regular expression to match things like “HackaDay” and “Hack a day” and, even, “Hackaday” using a tool like grep, awk, or many programming languages.
One of the nice things about the Unix philosophy that Linux inherited is that the filesystem is very modular. That’s good, too, because a typical system might want a choice of filesystems like ext4, reiserfs, btrfs, and even network systems like nfs. Besides that, there are fake file systems like /sys and /dev that help Linux make everything look like a file. The downside is that building a filesystem required changing the kernel or, at least, writing a loadable module. That’s not as hard as it sounds, but it is a little more difficult than writing a normal program. Then came FUSE — file system in user space. This is a single file system module that allows you to create new file systems by writing ordinary code.
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.
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.”
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.