Category Archives: Raspberry Pi

Raspi Bplus-1

Fixing bash Shellshock vulnerability on Raspberry Pi

The recent bash vulnerability, a.k.a. “Shellshock”, is pretty bad, considering it might actually have been around for a very long time, maybe even dating back to the predecessor of bash. Not good.

So what about Raspberry Pi’s?
Are they vulnerable?

Turns out they are, but there is already a fix available for them and patching a Raspi is very simple. Whether your actual Raspi is vulnerable depends on what distribution you are using, and how recently you upgraded the software in it.
The Raspi used below is running IPE-R1, which is a blackout-proof version of Raspian.

First let’s find out what bash version we have:

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1
root@raspi-2:~#

You can also run this little script to determine whether your Raspi is vulnerable to Shellshock

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;
WARNING: SHELLSHOCK DETECTED
root@raspi-2:~#

Let’s fix this. Just refresh the repos and upgrade bash (the patched version is available in the main repos).

root@raspi-2:~# apt-get update && apt-get install --only-upgrade bash
Get:1 http://archive.raspberrypi.org wheezy Release.gpg [490 B]
Get:2 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
Get:3 http://archive.raspberrypi.org wheezy Release [10.2 kB]
...
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
 bash-doc
The following packages will be upgraded:
 bash
1 upgraded, 0 newly installed, 0 to remove and 54 not upgraded.
Need to get 1,443 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main bash armhf 4.2+dfsg-0.1+deb7u3 [1,443 kB]
Fetched 1,443 kB in 1s (1,386 kB/s)
(Reading database ... 29754 files and directories currently installed.)
Preparing to replace bash 4.2+dfsg-0.1 (using .../bash_4.2+dfsg-0.1+deb7u3_armhf.deb) ...
Unpacking replacement bash ...
Processing triggers for man-db ...
Setting up bash (4.2+dfsg-0.1+deb7u3) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
root@raspi1:~#

The installed version of bash is now +deb7u3

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1+deb7u3
root@raspi-2:~#

The short test script above also returns nothing:

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;
root@raspi-2:~#

You could of course also just do an “apt-get upgrade” to upgrade all packages on your Raspi, would take a bit longer but will work just as well.
Also, if you are not logged in as root you need to do a “sudo apt-get update”, of course.

Raspberry Pi won’t boot – only red power light comes on – SD card corrupt? Not so fast…

After having problems with SD cards failing after a few months in a Raspi that was supposed to be always-on, it was time to look for options.

The IPE distribution seemed like a perfect match – it effectively makes the Raspi only use a ramdisk, except possibly during boot. When needed the SD card file system can be made writeable, meaning that apt-get etc can be used as usual to install apps.

This worked great for ca 3 weeks, then this setup ALSO failed, with the same symptoms as before: at boot only the red power light would come on – nothing else. A fresh SD card with a fresh copy of IPE worked fine in the same Raspi hardware, thus not the Raspi itself that had fried (the cabinet where it lives is kind of warm, nothing too crazy though).

Now the weirdness starts for real. The failing SD card works perfectly fine when inserted in both an iMac and a Windows laptop. I spent hours and hours reformatting the card with various low-level tools, then writing the standard Raspian image to the card. Just for reference I did the same to a third SD card too, that card was identical to the failing one.

Still the same issue: that one card would still prevent the Raspi from booting.

The card in question is a Kingston 16 GB microSDHC card marked SDC4/16GB 081. It comes with an adapter that makes it usable also in large SD card connectors.

Photo on 11-09-14 at 06.52 #2

Finally, and I of course should have thought of this sooner, I tried swapping the two different microSD to SD adaptors. And of course… the solution was simple. It was not the SD card that had failed, it was the adapter. For some reason (heat? just poor quality?) the adapter had a small crack in its plastic housing, and as a result most likely some poor connection inside, between the microSD card itself and the surrounding adapter. When inserted into a proper computer, there was probably enough pressure on the adapter to squeeze it against the actual microSD card, while the SD card holder on the Raspi is kind of flimsy, and did not provide the needed pressure. When using a working adapter all three microSD cards work flawlessly in the Raspi.

Note to self: Use full sized SD cards in Rasperry Pis….

 

 

 

 

Reverse engineering Macbook Air FaceTime camera, part 1

A severely cracked 13″ Macbook Air display came my way some time back. The LCD panel was obviously damaged, but it would be interesting to see what makes such a great display tick, and maybe parts of it could still be used? I believe the display came from a Late 2010 Macbook Air (which would indicate an A1369 type construction), but can’t be sure. Anyway – ideas included

  • Keeping the back lighting (assuming it works) and camera, mounting the whole display on a flexible arm next to the work bench. Given the high intensity of the back lighting, it could then (maybe) provide ambient lighting AND video recording of whatever was being worked on. Maybe with a LED light and camera on a separate flexible arms.
  • If the LED backlighting drivers were toast, there should still be some nice white LEDs in there for scavenging.
  • Same thing for the camera, I believe it to be a 640×480 pixel device, nothing too exiting but could still be useful.

Turns out it’s not entirely easy to disassemble these displays. They are sealed together with very strong tape. Heating the bezel helps a lot, but it’s still a fair amount of work – and given the delicate components beneath the bezel, you might want to think twice before doing this on a laptop you care about.. Some good instructions found here, btw. Results so far:

2013-02-19_10-41-22_smallPrying the bezel open…

…before applying heat with a hot-air SMD rework station (regular heat gun would probably also work, if you are careful):
2013-02-19_10-44-38_small

Voila! Bezel is free:
2013-02-19_10-56-14_small

Now the tricky part. The cable from the cable is a thin wire with some kind of textile cover, for strengths I assume. It goes through the hinges and there is no way (as far as I can tell) to get the cable through there, without cutting off the (very small) connector that normally connects to the computers Left I/O (a.k.a. LIO) board. Cut.

Now the whole camera assembly can be removed. It also includes the ambient light sensor, which communicates over I2C. Unknown protocol for that one though – one for the future to investigate..

2013-02-23_22-55-38_small
Very tiny 6-pin connector, normally going to the LIO board.
2013-02-19_13-11-34_smallCamera module exposed in the top part of the screen. Held in place with 2 small screws.


2013-02-23_22-32-08_smallCamera board. 

2013-02-19_13-17-59_smallThese things are small – fingers included for scale reference.

With six wires in the cable it’s pretty clear that 4 are for USB (+5V, Gnd, Data+, Data-) and 2 for I2C. That cable is however crazy small – it’s about 2 mm diameter. Once the outer layer is off, you see 6 even thinner cables. 2 are black, 4 transparent. Which ones are which?

Google is your friend. Turns out there are schematics to be found if you Google long enough. Turns out you need schematics for the LIO board though, in order to get the pinout of the camera/ALS cable, and it’s nowhere to be found for the A1369. Did find a schematic for the A1370 model though (same computer but 11″ screen), with a bit of luck that cable is the same between models.

The 2 black ones are prime candidates for +5V and Gnd. Cutting away the insulation revealed that the cables are shielded, with a center wire that is barely visible to the eye. It took several attempts before I had separated the wires from the sheilding, and then done the same with the other 4 wires. Soldering these onto an old USB cable was then easy (but ugly!!):

2013-02-28_14-09-48_small

Still, it doesn’t work. The camera is not recognised on an iMac with latest OSX, nor on a Windows 8 laptop. Happened to have a Raspberry Pi lying on the work bench, tried it too with same result: nothing.

But wait… doing a “tail -f /var/log/messages” on the RPi showed that it DID recognise the camera, but that the camera wanted more power than a non-powered USB hub could provide! Placing the camera into the RPi’s regular USB port made it appear nicely when doing a “lsusb” command.

Still, it didn’t work when I connected the camera to the Windows or iMac machines – strange.

Also, the RPi loose contact with the camera after a while – no idea why. Could maybe be a bad USB cable (it’s from an old mouse using USB 1.1 – maybe that’s a problem??), or is there too much noise introduced by the ugly splicing of cables that I’ve done? No idea… More investigation needed. Anyway, the camera enumerates with USB id 05ac:850a, which indeed is an Apple FaceTime camera – nice!