Text-based Linux and Unix systems are easy to manipulate. The way the Unix I/O system works you can always fake keyboard input to another program and intercept its output. The whole system is made to work that way. Graphical X11 programs are another matter, though. Is there a way to control X11 programs like you control text programs? The answer to that question depends on exactly what you want to do, but the general answer is yes.
As usual for Linux and Unix, though, there are many ways to get to that answer. If you really want fine-grained control over programs, some programs offer control via a special mechanism known as D-Bus. This allows programs to expose data and methods that other programs can use. In a perfect world your target program will use D-Bus but that is now always the case. So today we’ll look more for control of arbitrary programs.
There are several programs that can control X windows in some way or another. There’s a tool called xdo that you don’t hear much about. More common is xdotool and I’ll show you an example of that. Also, wmctrl can perform some similar functions. There’s also autokey which is a subset of the popular Windows program AutoHotKey.
Continue reading “Linux Fu: X Command”
There was a time when embedded system developers didn’t need to worry about graphics. When you have a PIC processor and two-line LCD, there isn’t much to learn. But if you are deploying Linux-based systems today, graphics are a real possibility. There are many options for doing Linux graphics including Wayland, X11, and frame buffers. Confused? This tutorial can help. The sections on Wayland and Mir are under construction, but that’s probably not what you are going to be using on a typical hacker project for the foreseeable future, anyway.
Of course, even inside those broad categories, you have multiple choices. If you are doing X11, for example, you can go low-level or pick any of a number of high-level libraries.
Continue reading “Linux Graphics Programming”
What can you do with an IR remote? How about anything? Maybe not. We’ll settle for issuing arbitrary commands and controlling tasks on our computer.
The first step in [Fungus]’s hack is straightforward: buy an IR receiver for a buck, plug it into an Arduino, and load up some IR-decoding code. If you haven’t done this before, you owe it to yourself to take some time now. Old IR remotes are very useful, and dead simple, to integrate into your projects.
But here comes the computer-control part. Rather than interpret the codes on the Arduino, the micro just sends them across the USB serial to a laptop. A relatively straightforward X11 program on the (Linux) computer listens for codes and does essentially anything a user with a mouse and keyboard could — that is to say, anything. Press keys, run programs, open webpages, anything. This is great for use with a laptop or desktop, but it’d also be a natural for an embedded Raspberry Pi setup as well.
Hacking the code to do your particular biddings is a simple exercise in monkey-patching. It’s like a minimal, hacked-together, USB version of LIRC, and we like it.
Thanks [CoolerVoid] for the tip!
The old saying is if your data isn’t backed up at least twice, it’s not backed up at all. For those not wise enough to heed this adage, there are a number of options available to you if you wish your data to be recovered. Assuming the drive itself is just corrupted somehow (maybe a malicious attack, maybe a user error) and not damaged beyond physical repair, the first step is to connect the drive to another computer. If that fails, it might be time to break out the computer forensics skills.
[Luis]’s guide is focused on Linux-specific drives and recovery tools, so this isn’t necessarily a general-purpose how-to. That being said, there is a lot of information in this guide such as how to mount the target drive’s partitions, how to set up various timelines, and which of the Linux system’s logs are important for the forensic analysis. This specific example in the guide also goes into detail about noticing which of the recent files had been accessed, what they might have done, and different approaches to piecing the mystery of this corrupted drive together.
[Luis] points out that the world of Linux forensics is much different from that of Windows, but for anyone looking to get started he suggests starting with a clean Linux install and going from there. There are many other avenues of digital forensics, as well; the field has as many avenues of exploration as there are different types of computers.
It is easy to dismiss bash — the typical Linux shell program — as just a command prompt that allows scripting. Bash, however, is a full-blown programming language. I wouldn’t presume to tell you that it is as fast as a compiled C program, but that’s not why it exists. While a lot of people use shell scripts as an analog to a batch file in MSDOS, it can do so much more than that. Contrary to what you might think after a casual glance, it is entirely possible to write scripts that are reliable and robust enough to use in many embedded systems on a Raspberry Pi or similar computer.
I say that because sometimes bash gets a bad reputation. For one thing, it emphasizes ease-of-use. So while it has features that can promote making a robust script, you have to know to turn those features on. Another issue is that a lot of the functionality you’ll use in writing a bash script doesn’t come from bash, it comes from Linux commands (or whatever environment you are using; I’m going to assume some Linux distribution). If those programs do bad things, that isn’t a problem specific to bash.
One other limiting issue to bash is that many people (and I’m one of them) tend to write scripts using constructs that are compatible with older shells. Often times bash can do things better or neater, but we still use the older ways. For example:
Continue reading “Linux Fu: Better Bash Scripting”
One of the things that makes Linux and Unix-like systems both powerful and frustrating is that there are many ways to accomplish any particular goal. Take something simple like running a bunch of commands in sequence as an example. The obvious way is to write a shell script which offers a tremendous amount of flexibility. But what if you just want some set of commands to run? It sounds simple, but there are a lot of ways to issue a sequence of commands ranging from just typing them in, to scheduling them, to monitoring them the way a mainframe computer might monitor batch jobs.
Let’s jump in and take a look at a few ways you can execute sequences from bash (and many other Linux shells). This is cover the
at commands along with a batch processing system called task spooler. Like most things in Linux, this isn’t even close to a complete list, but it should give you some ideas on ways to control sequences of execution.
Continue reading “Linux-Fu: Running Commands”
Whenever there’s a new Windows virus out there wreaking global havoc, the Linux types get smug. “That’ll never happen in our open operating system,” they say. “There are many eyes looking over the source code.” But then there’s a Heartbleed vulnerability that keeps them humble for a little while. Anyway, at least patches are propagated faster in the Linux world, right?
While the Linuxers are holier-than-thou, the Windows folks get defensive. They say that the problem isn’t with Windows, it’s just that it’s the number one target because it’s the most popular OS. Wrong, that’d be Android for the last few years, or Linux since forever in the server space. Then they say it’s a failure to apply patches and upgrade their systems, because their users are just less savvy, but that some new update system will solve the problem.
There’s some truth to the viruses and the patching, but when WannaCry is taking over hospitals’ IT systems or the radiation monitoring network at Chernobyl, it’s not likely to be the fault of the stereotypical naive users, and any automatic patch system is only likely to help around the margins.
So why is WannaCry, and variants, hitting unpatched XP machines, managed by professionals, all over the world? Why are there still XP machines in professional environments anyway? And what does any of this have to do with free software? The answer to all of these questions can be found in the ancient root of all evil, the want of money. Linux is more secure, ironically, at least partly because it’s free as in beer, and upgrading to a newer version is simply cheaper.
Continue reading “Free as in Beer, or the Story of Windows Viruses”