Autodetection of hardware was a major part of making computers more usable for the average user. The Amiga had AutoConfig on its Zorro bus, Microsoft developed Plug And Play, and Apple used NuBus, developed by MIT. It’s something we’ve come to take for granted in the modern age, but it doesn’t always work correctly. [Evan] ran into just this problem with a video capture card that wouldn’t autodetect properly under Linux.
The video capture card consisted of four PCI capture cards with four inputs each, wired through a PCI to PCI-E bus chip for a total of sixteen inputs. Finding the cause of the problem wasn’t too difficult – the driver was detecting the card as a different model with eight inputs, instead of the sixteen inputs actually present on the card. The driver detects the device plugged in by a unique identifier reported by the card. The code on the card was identical to the code for a different model of card with different hardware, causing the issue.
As a quick test, [Evan] tried fudging the driver selection, forcing the use of a driver for a sixteen-input model. This was successful – all sixteen inputs could now be used. But it wasn’t a portable solution, and [Evan] would have to remember this hack every time the card needed to be reinstalled or moved to a different computer.
Looking further at the hardware, [Evan] discovered the card had four 24c02 EEPROM chips on board – one for each PCI card on board. Dumping the contents, they recognised the unique identifier the driver was using to determine the card’s model. It was then a simple job to change this value to one that corresponded with a sixteen-input card to enable functional autodetection by burning a new value to the EEPROM. [Evan] then published the findings to the LinuxTVWiki page. Continue reading “EEPROM Hack to Fix Autodetection Issues”
Usually, you think of solid state storage as faster than a rotating hard drive. However, in the case of the Raspberry Pi, the solid state “disk drive” is a memory card that uses a serial interface. So while a 7200 RPM SATA drive might get speeds in excess of 100MB/s, the Pi’s performance is significantly less.
[Rusher] uses the Gluster distributed file system and Docker on his Raspberry Pi. He measured write performance to be a sluggish 1MB/s (and the root file system was clocking in at just over 40MB/s).
There are an endless number of settings you could tweak, but [Rusher] heuristically picked a few he thought would have an impact. After some experimentation, he managed 5MB/s on Gluster and increased the normal file system to 46 MB/s.
Continue reading “Improving Raspberry Pi Disk Performance”
The Raspberry Pi Foundation has put a lot of work into their software stack. You need only look at a few of the Allwinnner-based Pi clones for the best evidence of this, but the Pi Foundation’s dedication to a clean and smooth software setup can also be found in Noobs, their support for the Pi Hardware, and to a more limited extent, their open source GPU driver offerings.
Now the Pi Foundation is doing something a bit weird. They’re offering their default Raspberry Pi installation for the Mac and PC. Instead of Flashing an SD card, you can burn a DVD and try out the latest the Pi ecosystem has to offer.
A few months ago, PIXEL became default distribution for the Raspberry Pi. This very lightweight distribution is effectively the Knoppix of 2016 – it doesn’t take up a lot of resources, it provides enough software to do basic productivity tasks, and it’s easy to use.
Now PIXEL is available as a live CD for anything that has i386 written somewhere under the hood. The PC/Mac distribution is the same as the Pi version; Minecraft and Wolfram Mathematica aren’t included due to licensing constraints. Other than that, this is the full Pi experience running on x86 hardware.
One feature that hasn’t been overlooked by a singular decade-old laptop in the Pi Foundation is Pixel’s ability to run on really old hardware. This is, after all, a lightweight distribution for the Raspberry Pi, so you shouldn’t be surprised to see this run on a Pentium II machine. This is great for a school in need of upgrading a lab, but the most interesting thing is that we now have a new standard in Linux live CDs and Flash drives.
[Donncha O’Cearbhaill] has successfully exploited two flaws in Apport, the crash report mechanism in Ubuntu. Apport is installed by default in all Ubuntu Desktop installations >= 12.10 (Quantal). Inspired by [Chris Evan] work on exploiting 6502 processor opcodes on the NES, [Donncha] describes the whole process of finding and exploiting a 0-day on a modern linux system.
One of the flaws, tracked as CVE-2016-9949, relies on a python code injection in the crash file. Apport blindly uses the python eval() function on an unsanitized field (CrashDB) inside the .crash file. This leads directly to arbitrary python code execution. The other flaw, tracked as CVE-2016-9950, takes advantage of a path traversal attack and the execution of arbitrary Python scripts outside the system hook_dirs. The problem arises when another field (Package) from the crash report file is used without sanitizing when building a path to the package hook files.
CVE-2016-9949 is easily exploitable, if an attacker can trick a user into opening a specially crafted file (apport .crash file), the attacker can execute the python code of his/her choice. Two details make it a very interesting exploit.
The first thing to note is the exploit’s reliability. Given that it is pure python code execution, an attacker doesn’t have to worry about ASLR, Non-Exec Memory, Stack Canaries and other security features that Ubuntu ships by default. As the author notes:
“There are lots of bugs out there which don’t need hardcore memory corruption exploitation skills. Logic bugs can be much more reliable than any ROP chain.”
Another interesting detail is that the exploit file doesn’t need to have the .crash extension, as long as its content starts with the string “ProblemType: ” and the file extension is not associated already with other software, Ubuntu considers it being of mime-type type=”text/x-apport” (for example, .ZlP or .0DF). This significantly improves the chances of an unsuspecting user being fooled into open the file.
Continue reading “Reliably Exploiting Apport in Ubuntu”
We’ve often heard that you don’t need to know how an engine works to drive a car, but you can bet that professional race car drivers know. By analogy, you can build lots of systems with off-the-shelf boards like Raspberry Pis and program that using Python or some other high-level abstraction. The most competent hackers, though, know what’s going on inside that Pi and what Python is doing under the hood down to some low level.
If you’ve been using Linux “under the hood” often means understanding what happens inside the kernel–the heart of the Linux OS that manages and controls everything. It can be a bit daunting; the kernel is simple in concept, but has grown over the years and is now a big chunk of software to approach.
Your first embedded system project probably shouldn’t be a real time 3D gamma ray scanner. A blinking LED is a better start. If you are approaching the kernel, you need a similar entry level project. [Stephen Brennan] has just the project for you: add your own system call to a custom Linux kernel.
Continue reading “Under the (Linux) Hood”
With so many systems depending on Linux, the secure shell SSH has become a staple for many developers. If you are connected to your Raspberry Pi via a cable or a wireless router a few feet away, SSH can provide you with an encrypted connection straight to the box. However, if you have a system out in a swamp somewhere with intermittent slow network access, SSH can be a real pain. When your IP address can change (for example, roaming on a cellular network), SSH has problems, too.
To combat these and other problems, you might consider an open source program called Mosh (mobile shell). There’s two parts to Mosh. One part works as a server while the other is the client application. Neither of these require root access. You can see a video about Mosh below.
Continue reading “SSH Enters the Mosh Pit”
If you are a certain age, you probably remember writing software (or playing Adventure) bathed in an amber or green light from an old CRT terminal. If you are even older, you might have found it way better than punching cards, but that’s another story. [Tobi] wanted to relive those days (well, sounds like he is too young to have lived them to start with) so he hooked up a VT220 terminal to his Linux box.
This isn’t that surprising. Linux’s forefather, Unix, expected these kind of terminals (or a hard copy TeleType) and all the trappings for working with a glass terminal are still in there. You do have to deal with a few configuration items that [Tobi] works through.
In fact, it appears that he wrote his blog post using vi on that very VT220 using a text-based Web browser to research the links. He has a lot of resources for connecting a terminal of any sort (or even a terminal emulator) to a Linux computer.
There’s been a lot of interest in old terminals lately. You see a lot of old VT100s lying around. I personally have an ADDS Regent 100 that occasionally connects to several of my computers. You can see it in the video below.
Continue reading “By the Glow of the CRT”