Linux Command Line Productivity With Tmux

May 1, 2020 by Al Williams 23 Comments

It is no secret that most Linux power users use the shell for many tasks, as for people who know what they are doing, it can be quite efficient. In addition, there are some tasks that can only be carried out from the command line, although their number shrinks every year. However, these days we are spoiled because you can have one X session running lots of terminals at once. If you log into a server, it might not have X. Or you might log into a computer over a slow connection where X is painful to use. What then? The modern answer is the tmux terminal multiplexer, and [zserge] has a thoughtful introduction to how you can use tmux for improved productivity at the command line.

In particular, he shares some configuration and offers sound advice. For example, do you really need a status bar that shows you CPU load at all times? Cool, yes, but not always a practical win.

Continue reading “Linux Command Line Productivity With Tmux” →

Beam Your Program To Another Computer

April 28, 2020 by Al Williams 53 Comments

If you’ve programmed much in Linux or Unix, you’ve probably run into the fork system call. A call to fork causes your existing process — everything about it — to suddenly split into two complete copies. But they run on the same CPU. [Tristan Hume] had an idea. He wanted to have a call, telefork, that would create the copy on a different machine in a Linux cluster. He couldn’t let the idea go, so he finally wrote the code to do it himself.

If you think about it, parts of the problem are easy while others are very difficult. For example, creating a copy of the process’s code and data isn’t that hard. Since the target is a cluster, the machines are mostly the same — it’s not as though you are trying to move a Linux process to a Windows machine.

Continue reading “Beam Your Program To Another Computer” →

Debugging For Sed — No Kidding

April 24, 2020 by Al Williams 13 Comments

If you do much Linux shell scripting, you’ve probably encountered sed — the stream editor — in an example. Maybe you’ve even used it yourself. If all you want to do is substitute text, it is easy and efficient. But if you try to do really elaborate editing, it is often difficult to get things right. The syntax is cryptic and the documentation is lacking. But thanks to [SoptikHa2] you can now debug sed scripts with a text-based GUI debugger. Seriously.

According to the author, the program has several notable features:

Preview variable values, both of them!
See how will a substitute command affect pattern space before it runs
Step through sed script – both forward and backward!
Place breakpoints and examine program state
Hot reload and see what changes as you edit source code
Its name is a palindrome

There’s only one word for that last feature: wow.

Continue reading “Debugging For Sed — No Kidding” →

Program Guesses Your Regular Expression

April 22, 2020 by Al Williams 12 Comments

We aren’t sure how we feel about [pemistahl’s] grex program. On the one hand, we applaud a program that can take some input samples and produce a regular expression. On the other hand, it might be just as hard to gather example data that produces the correct regular expression. Still, it is an interesting piece of code.

Even the author suggests not to use this as an excuse to not learn regular expressions, since you’ll need to check the program’s output. It is certain that the results will match your test cases, but it isn’t certain that it won’t accept things you didn’t expect. Bad regular expressions have been the source of some deeply buried bugs.

Continue reading “Program Guesses Your Regular Expression” →

Reverse Engineering An RGB Keyboard Under Linux

April 14, 2020 by Tom Nardi 5 Comments

Hardware support under Linux is far better than it ever has been in the past. These days, most things “just work” out of the box, and you probably won’t have to compile any custom kernel modules. Certainly a far cry from where things were a decade ago. But that doesn’t mean everything will work to 100% of its abilities. Take for example, the Duck keyboard that [Cynthia Revström] has. Sure it works as a basic keyboard under any OS, but getting those fancy RGB LEDs working is another story entirely.

Don’t get the wrong idea here, [Cynthia] isn’t just trying to get the keyboard to flash along to music; the goal was to use the RGB lighting of the Ducky keyboard for notifications that the user can’t possibly ignore. Even the most laser-focused among us would have a hard time not noticing that the entire keyboard is blinking red. But the “DuckyRGB” software that you need to do something like that is Windows-only and apparently distributed via a sketchy Google Drive link. Yikes.

The first step to creating an alternative was to spin up a Windows VM and install DuckyRGB. From there, Wireshark could listen in between the virtual computer and the Ducky keyboard to see what the software was sending over the wire. After identifying a version number being sent in the clear, [Cynthia] was able to isolate the LED commands by searching for the hex color codes. From there, it was a relatively simple matter of writing some glue code to connect it up to an alert service and get notifications going.

There was only one problem; the keyboard didn’t work anymore. Turns out the tool that [Cynthia] wrote to control the keyboard’s LEDs was claiming the device so the kernel couldn’t access it for normal input. It took a detour with HIDAPI to get everyone playing together nicely, and now changing the color of your Ducky keyboard on Linux doesn’t turn it into a paperweight.

Even if you don’t have a Ducky keyboard, or aren’t particularly interested in having its LEDs blinked at you if you do, this project is a phenomenal example of practical USB reverse engineering. [Cynthia] says the inspiration for this project came from friend [Ben Cox], who’s write-up on creating USB userspace drivers we covered last year. If you’ve got and old USB gadget with Windows-only drivers, maybe it’s time you take a crack at unlocking it.

Software-Defined Radio Made Easy

April 11, 2020 by Bryan Cockfield 25 Comments

Just a few decades ago, getting into hobby radio meant lots of specialty hardware, and making changes to your setup to work on various frequencies wasn’t particularly easy. Since software-defined radio (SDR) came onto the scene in an accessible way for most of us, this barrier to entry was reduced significantly and made the process of getting on the air a lot easier. It goes without saying that it does require some software, but [Aaron]’s latest project makes even getting that software extremely simple.

What he has done is created a custom Linux distribution based on Debian, called DragonOS, with the entire suite of SDR programs needed to get up and running. Out of the box, it supports RTL-SDR, HackRF and LimeSDR packages and even includes other fun tools you’ll need like Kismet. There are several video demonstrations of his distribution, including using RTL-SDR for ADS-B reception, and also shows off several custom implementations of the OS in various scenarios on his YouTube channel. The video linked below also shows how to set up the distribution in a virtual machine, so you can run this even if you don’t have a computer to dedicate to SDR.

Getting into SDR has never been easier, and the odds of having something floating around in the junk drawer that you can use to get started are pretty high. The process is exceptionally streamlined with [Aaron]’s software suite. If you’re a little short on hardware, though, there’s no better place to get started than with the classic TV-tuner-to-SDR hack from a few years back.

Continue reading “Software-Defined Radio Made Easy” →

Linux Fu: Tracing System Calls

April 7, 2020 by Al Williams 11 Comments

One of the nice things about Linux and similar operating systems is that you can investigate something to any level you wish. If a program has a problem you can decompile it, debug it, trace it, and — if necessary — even dig into the source code for the kernel and most of the libraries the program is probably using. However, the tools to do this aren’t ones you use every day. One very interesting tool is strace. Using it you can see what system calls any program makes and that can sometimes give you important clues about how the program works or, probably more often, why it doesn’t work.

Let’s consider the least complex use of the command. Suppose you want to make symlink from testxmit.grc to the /tmp directory. That command is simple:

ln -sf testxmit.grc /tmp

But if you tell strace to run it, the command becomes:

strace ln -sf testxmit.grc /tmp

You might want to redirect the output to a file using the shell or the -o option, though. Some commands generate a lot and often the first page or two of output isn’t really what you care about anyway. Continue reading “Linux Fu: Tracing System Calls” →