According to reports from Android Police and ZDNet, you may soon have a new operating system from Google to run on your Raspberry Pi. Details are still extremely sparse, the only description on the GitHub page is “Pink + Purple == Fuchsia (a new Operating System)”. But, here’s what we do know:
The new OS, called Fuchsia, will be based on Magenta, which is in turn built on LittleKernel. That means that, surprisingly, Google will not be using a Linux kernel for the new OS but something more like an embedded RTOS. Although Google is targeting embedded systems, the possibility of being able to run it on a desktop has been mentioned, so it may not be too minimalistic.
Google’s Travis Geiselbrecht has named the Raspberry Pi 3 specifically as one system it will run on, and said that it’ll be available soon. But, it seems Google is aiming to make it run on a variety of ARM devices (both 32 bit and 64 bit), as well as 64 bit PCs. This is a direct effort to compete against other commercial embedded operating systems that are currently available, and especially on IoT devices.
If you’re eager to see what this is all about, you can follow Google’s quick start recipes and see what you can come up with, although details are still sketchy enough that we’re just going to wait a bit.
Step one was to make sure that the thing works. Normally, you’d hook up a wired serial terminal and start hacking. [Ncrmnt] took it one step further and wired in a HC-05 Bluetooth serial module, so he can pull up the debug terminal wirelessly. The rest of the hackery was just crafting a bootable SD card and poking around in the Android system that was still resident in the flash memory of the system.
Once the board was proven workable, [Ncrmnt] designed and printed a sweet custom case using Solvespace, a constraint-based 3D CAD modeler that was new to us until recently. The case (after three prints) was a perfect fit for the irregularly shaped system board, a 3.7 V LiIon battery, and a speaker. He then added some nice mounting tabs. All in all, this is a nice-looking and functional mini-computer made out of stuff that was destined for the trash. It’s fast, it’s open-source, and it’s powerful. Best of all, it’s not in the dumpster.
If you don’t have root, you don’t own a device, despite what hundreds of Internet of Things manufacturers would tell you. Being able to access and write to that embedded Linux system in your new flashy gadget is what you need to truly own a device, and unfortunately this is a relatively uncommon feature. At this year’s DEF CON, [Brad Dixon] unveiled a technique that pwns a device using only a sewing needle, multimeter probe, or a paperclip. No, it won’t work on every device, and the devices this technique will work with are poorly designed. That doesn’t mean it doesn’t work, and that doesn’t mean the Pin2Pwn technique isn’t useful, though.
The attack relies on how an embedded Linux device boots. All the software needed to load Linux and the rest of the peripheral magic is usually stored on a bit of Flash somewhere on the board. By using a pin, probe, or paperclip to short two data pins, or two of the latch pins on this memory chip, the bootloader will fail, and when that happens, it may fall back to a uboot prompt. This pwns the device.
There are a few qualifications for this Pwn using a pin. If the device has JTAG, it doesn’t matter – you can already own the device. If, however, a device has a locked-down JTAG, unresponsive serial ports, or even their own secure boot solution, this technique might work.
This exploit works on the property of the bootloader. This bit of code first looks at a piece of Flash or other memory separate from the CPU and loads whatever is there. [Brad] found a few devices (mostly LTE routers) that would try to load Linux from the Flash, fail, try to load Linux again, fail, and finally drop to a uboot prompt.
As with any successful exploit, an equally effective mitigation strategy must be devised. There are two ways to go about this, and in this case, the software side is much better at getting rid of this attack than the hardware side.
Since this attack relies on the software falling back to uboot after an unsuccessful attempt at whatever it should be booting, the simplest and most effective mitigation technique is simply rebooting the device if the proper firmware can’t be found. Having a silent serial console is great, but if the attack relies on falling back to uboot, simply not doing that will effectively prevent this attack.
The hardware side is a little simpler than writing good firmware. Instead of using TSSOP and SOIC packages for storing the device firmware, use BGAs. Hide the pins and traces on an inner layer of the board. While this isn’t a foolproof way of preventing the attack – there will always be someone with a hot air gun, magnet wire, and a steadier hand than you – it’s hard to glitch a data line with a sewing needle if you can’t see the data line.
We toss together our own PCB designs, throwing in a microcontroller here or there. Anything more demanding than that, and we reach for a Raspberry Pi or BeagleBone (or an old Linksys router). Why don’t we just whip together a PCB for a small Linux computer? Because we don’t know how…but [Jonas] apparently does. And when we asked him why he did it, he replied “because I can!”
His Ethernet-to-6LoWPAN gateway project is a small, OpenWRT-capable Linux computer in disguise. Rather than yet another Raspberry Pi project, he designed around an Atmel AT91SAM9G25 400 MHz CPU, and added some memory, Ethernet, and a CC2520 radio chip to handle the wireless side. It’s all done on a four-layer board, and hotplate/skillet reflowed. This seems temptingly like something within our reach. [Jonas] had access to X-ray machines to double-check his reflow work, which probably isn’t necessary, although it looks really cool.
When finished, the project will link together a 6LoWPAN network (probably home automation) and his home wired network. That makes this device a rival to something like Philips’ Hue Bridge, which was the subject of some controversy when they locked out other devices for a few days until they recanted. Indeed, in response to this, there’s been quite a lot of effort at hacking the firmware of the Hue device, just to stay on the safe side in case Philips plays shenanigans again.
Soon, that’s not going to be necessary. [Jonas]’s design is open from the ground up, and coupled with open software running on top of the OpenWRT router operating system, that’s the full stack. And that’s great news for folks who are thinking about investing in a home automation technology, but afraid of what happens then the faceless corporations decide to pull the plug on their devices.
As a rule, I try hard not to get sucked into religious wars. You know, Coke vs Pepsi. C++ vs Java. Chrome vs Firefox. There are two I can’t help but jump into: PC vs Mac (although, now that Mac has turned into Unix, that’s almost more habit than anything else) and–the big one–Emacs vs vi.
If you use Linux, Unix, or anything similar, you are probably at least aware of the violence surrounding this argument. Windows users aren’t immune, although fewer of them know the details. If you aren’t familiar with these two programs, they are–in a way–text editors. However, that’s like calling a shopping mall “a store.” Technically, that’s correct, but the connotation is all wrong.
Like most religious wars, this one is partly based on history that might not be as relevant as it used to be. Full disclosure: I’m firmly in the Emacs camp. Many of my friends are fans of vi–I try not to hold it against them. I’ll try to be balanced and fair in my discussion, unless I’m talking about my preference. I don’t have to be fair when it comes to my opinions. Just to be clear: I know how to use vi. My preference isn’t based out of not wanting to learn something new.
Sure, you’re a hardcore superuser, but that doesn’t mean you don’t enjoy the finer things in life — like shiny squircles and getting every new app first. But, what’s an OS-indiscriminate person like yourself going to do when it comes time to purchase music? That’s where the recover_itunes tool shines, and if you’re a Linux user with an iPhone, it might just be your new best friend.
Sometimes the journey is as interesting as the destination, and that’s certainly the case with [Marc]’s pursuit of measuring his sleep apnea (PDF, talk slides. Video embedded below.). Sleep apnea involves periods of time when you don’t breathe or breathe shallowly for as long as a few minutes and affects 5-10% of middle-aged men (half that for women.) [Marc]’s efforts are still a work-in-progress but along the way he’s tried a multitude of things, all involving different technology and bugs to work out. It’s surprising how many ways there are to monitor breathing.
His attempts started out using a MobSenDat Kit, which includes an Arduino compatible board, and an accelerometer to see just what his sleeping positions were. That was followed by measuring blood O2 saturation using a cheap SPO2 sensor that didn’t work out, and one with Bluetooth that did work but gave results as a graph and not raw data.
Next came measuring breathing by detecting airflow from his nose using a Wind Sensor, but the tubes for getting the “wind” from his nose to the sensor were problematic, though the approach was workable. In parallel with the Wind Sensor he also tried the Zeo bedside sleep manager which involves wearing a headband that uses electrical signals from your brain to tell you what sleep state you’re in. He particularly liked this one as it gave access to the data and even offered some code.
And his last approach we know of was to monitor breathing by putting some form of band around his chest/belly to measure expansion and contraction. He tried a few bands and an Eeonyx conductive textile/yarn turned out to be the best. He did run into noise issues with the Xbee, as well as voltage regulator problems, and a diode that had to be bypassed.