PostMarketOS Saves Old Smartphones

Modern smartphones, even the budget models, are extremely impressive pieces of technology. Powerful ARM processors, plenty of RAM, and an incredible number of sensors and radios are packed into a device that in some cases are literally given away for free when you sign up for a service plan. Unfortunately manufacturers are not obligated to keep up with software updates, and while the hardware may be willing to keep on fighting, the user is often pushed to upgrade due to perennially outdated software. Even if you aren’t the kind of person to be put off by using a phone that doesn’t have the latest and greatest OS, the lack of software security updates pose a clear threat in a world where mobile devices are increasingly targeted by attackers.

But what if the operating system on your phone worked more like the on one your computer? That’s the dream of postmarketOS, a Linux distribution created by [Oliver Smith] that is designed to be installed on outdated (mostly Android) smartphones and tablets. He’s recently made a comprehensive blog post about the state of the project a little over 6 months since it started, and we have to say things are looking very impressive so far.

One of the key goals of postmarketOS is to avoid the fragmented nature of previous attempts at replacing Android with a community-developed operated system. By avoiding binary blobs and focusing on getting the mainline Linux kernel running on as much as the hardware as possible, there’s no need to make different forks and releases for each supported device. By unifying the OS as much as far as it can be, an upstream update can be pushed to all devices running postmarketOS regardless of their make and model, just like with traditional Linux distributions.

The blog post shows two things very clearly: that the community is extremely excited and dedicated to the prospect of running what is essentially desktop Linux on old smartphones and tablets, and that postmarketOS still has a long way to go. In these early days, many devices aren’t what could be considered “daily drivers” by most standards. In fact, the blog post mentions that they’ve decided to abandon the term “supported” when talking about devices, and make no claims beyond the fact that they will boot.

Still, incredible progress is being made on everything from mainline kernel development to getting standard Linux desktops such as Gnome, MATE and XFCE4 running. Work has also been done on the backend process of compiling and packaging up components of the operating system itself, promising to speed up development times even for those who don’t have a beefy machine they can dedicate to compiling. The blog post ends with a helpful list of things the reader can do to help support postmarketOS, ranging from making your own t-shirts to porting to new hardware.

At Hackaday we’ve seen our fair share of hackers and makers re-purposing old smartphones and tablets, keeping them out of the landfills they would almost certainly end up in otherwise. A project that aims to make it even easier to hack these cheap and incredibly useful devices is music to our ears.

Go Retro To Build A Spectre And Meltdown-Proof X86 Desktop

[Yeo Kheng Meng] had a question: what is the oldest x86 processor that is still supported by a modern Linux kernel? Furthermore, is it actually possible to use modern software with this processor? It’s a question that surely involves experimentation, staring into the bluescreen abyss of BIOS configurations, and compiling your own kernel. Considering Linux dropped support for the 386 in 2012, the obvious answer is a 486. This supposition was tested, and the results are fantastic. You can, indeed, install a modern Linux on an ancient desktop.

This project got its start last month at a Super Silly Hackathon where [Yeo] and [Hui Jing] installed Damn Small Linux on an ancient IBM PS/1 desktop of 1993 vintage. The hardware consists of an AMD 486 clone running at 133MHz, 64 MB of RAM, a 48x IDE CDROM drive (wow!), a floppy emulator, a Sound Blaster, 10Mbps Ethernet card, and a CompactFlash to IDE adapter. By any account, this is a pimped-out rig for 1993 that would have cost more than a car at the time. The hardware works, but can you run a modern Linux kernel on it?

[Yeo] decided to install the Gentoo x86 minimal installation, but sanity and time constraints meant compiling a kernel on a 486 wasn’t happening. That was done on a modern Thinkpad after partitioning all the drives, verifying all the compilation parameters, and configuring the kernel itself. The bootloader is LILO (Grub2 didn’t work), but for the most part, this is entirely modern software running on a 25-year-old machine. The step-by-step instructions for becoming a /g/entooman on a 486 are available on GitHub.

The entire (boring) boot process can be seen in the video below. One interesting application of this build is that the 486 does not support out-of-order execution, making this completely safe from Meltdown and Spectre attacks. It’s an impressive retrocomputing achievement that right now could not be more timely.

Continue reading “Go Retro To Build A Spectre And Meltdown-Proof X86 Desktop”

Learn To Reverse Engineer X86_64 Binaries

Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.

While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leonora Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, she ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.

All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.

Fixing Linux Audio One Chipset At A Time

Linux audio may be confusing for the uninitiated. As a system that has evolved and spawned at least two independent branches over time it tends to produce results that surprise or irritate the user. On the other hand it is open source software and thus can be fixed if you know what you do.

Over at reddit [rener2] was annoyed by the fact that listening to music on his laptop was a significantly worse experience under Linux than under Windows. Running Windows the output of  the headphone jack covered the whole spectrum while his Linux set up cut off the low end resulting in a tinny sound. The culprit in this is the sound card: it has two different output paths for the internal speakers and the headphone jack. The signal for the internal speakers is routed through a high pass filter to spare them the embarrassment of failure to reproduce low frequencies.

When headphones are plugged in, the sound card driver is supposed to make the sound card bypass the filter and deliver the full spectrum. The authors of the Windows driver knew this and had it taken care of. In his video [rener2] runs us through the process of patching the ALSA driver while referencing the documentation of a sound card that he deems ‘similar enough’ to his Realtek ALC288.

Continue reading “Fixing Linux Audio One Chipset At A Time”

Turn Command Lines Into Web Apps

Even if you like using a graphical user interface, you can probably agree that writing a graphical program is usually harder than writing an old-fashioned text-based program. Putting that GUI into an online format means even more to think about. [Adam Kewley] has the answer to that problem: Jobson. As you can see in the video below, the program is a web server that runs command line programs as jobs.

Simply write a YAML file to describe the program’s inputs and outputs and Jobson will create input fields for arguments and display the output in a web page. Any files the program creates are available to download. Basically any command line program can be quickly and easily pulled into one web interface to rule them.

If a program takes a long time to run, Jobson will let you switch away and then later resume looking at the output. You can also abort a job or look at the arguments it received. Jobson can also authenticate users with several different methods to prevent just anyone from executing jobs.

If you really want to write a graphical program, try QTCreator. Or, you can get a shell in a web browser if you want to go that route. But this is the smoothest method we’ve seen for gathering command line programs into one place for monitoring and control. Neat!

Continue reading “Turn Command Lines Into Web Apps”

Linux Fu: System Administration Made Easier

Linux can have a somewhat split personality. If you use it as a desktop OS, it has a lot of GUI tools, although sometimes you still need to access the command line. If you use it as a headless server, though, you probably ought to know your way around the command line pretty well. This is especially true if you don’t want to litter up your hard drive (and CPU) with X servers and other peculiarities of the graphical user interface.

Personally, I like the command line, but I am realistic enough to know that not everyone shares that feeling. I’ll also admit that for some tasks — especially those you don’t do very often — it is nice to have some helpful buttons and menus. There are several administration tools that you might be interested in using to handle administration tasks on your Linux machines. I’m going to look at two of them you might want to experiment with that both use a Web browser to provide their interface.

Continue reading “Linux Fu: System Administration Made Easier”

What Is Entropy And How Do I Get More Of It?

Let’s start off with one of my favorite quotes from John von Neumann: “Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number — there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method.”

What von Neumann is getting at is that the “pseudo” in pseudorandom number generator (PRNG) is really a synonym for “not at all”. Granted, if you come in the middle of a good PRNG sequence, guessing the next number is nearly impossible. But if you know, or can guess, the seed that started the PRNG off, you know all past and future values nearly instantly; it’s a purely deterministic mathematical function. This shouldn’t be taken as a rant against PRNGs, but merely as a reminder that when you use one, the un-guessability of the numbers that it spits out is only as un-guessable as the seed. And while “un-guessability” isn’t a well-defined mathematical concept, or even a real word, entropy is.

That’s why entropy matters to you. Almost anything that your computer wants to keep secret will require the generation of a secret random number at some point, and any series of “random” numbers that a computer generates will have only as much entropy, and thus un-guessability, as the seed used. So how does a computer, a deterministic machine, harvest entropy for that seed in the first place? And how can you make sure you’ve got enough? And did you know that your Raspberry Pi can be turned into a heavy-duty source of entropy? Read on!

Continue reading “What Is Entropy And How Do I Get More Of It?”