Tuesday, February 12, 2013

Fix corrupted JPEGs made by the Samsung Galaxy S2

While organizing some of the pictures I took with my Samsung Galaxy S2, I've encountered one file that couldn't be opened. Being a nerd, I couldn't resist and had to investigate the issue. I think I've already spent more than two hours searching the not-so-all-knowing internet for solutions, but in the end it came down to using my brain and reading the EXIF specification (PDF).

tl;dr: The Samsung Galaxy S2 can occasionally create corrupted JPEGs, i.e., files that don't follow the specifications.

The Problem

Standard (linux) picture viewer applications would just say that they can't open the file. That's obviously not sufficient to get to the bottom of this, so I used GIMP and ImageMagicks convert, which both gave me the same information:
$ convert test.jpg out.jpg
convert: Corrupt JPEG data: 1072 extraneous bytes before marker 0xd8 `test.jpg' @ warning/jpeg.c/EmitMessage/231.
convert: Invalid JPEG file structure: two SOI markers `test.jpg' @ error/jpeg.c/EmitMessage/236.
convert: missing an image filename `out.jpg' @ error/convert.c/ConvertImageCommand/3011.
So, the two valuable information were:
1072 extraneous bytes before marker 0xd8
and
two SOI markers

The EXIF standard

The only helpful googling those error messages brought up was to use a hex editor. (Yeay!)
My corrupt file starts with
FF D8 FF E1  00 0E 45 78  69 66 00 00  49 49 2A 00 ...
What you see here, is a JPEG file (FF D8) followed by some EXIF information (FF E1). Using the EXIF specification (PDF), we learn that marks the start of an application segment 1 (APP1).
Offset (Hex)NameCode (Hex)
0000SOI (Start Of Image) MarkerFFD8
0002APP1 MarkerFFE1
0004APP1 Lengthxxxx
0006Identifier4578 6966 00 ("Exif"00)
000BPad00
000CAPP1 Body
Okay, so FFD8 is a SOI marker and the error message says that the file has two of them, which apparently is a bad thing. So I searched for another occurence of FFD8 and found one at 0x442 = 1090. It also said that it had 1072 extraneous bytes before marker 0xd8, which is only slightly smaller than the area between the APP1 header and the next SOI marker. So, is the SOI marker here wrong?

A valid JPEG file

Since I don't have the slightest idea of what exactly is wrong here, I opened another JPEG that works and was taken only minutes before the corrupt one. Comparing them by fast-switching between the console tabs (exploiting low-level visual processing and attention guidance of the brain is fun), I've noticed two things:
  1. FFD8 can be found at the same position in both files, so that is not the problem.
  2. The first difference is in the APP1 length.
  3. The difference is huge!
See for yourselves:

Corrupt file:
FF D8 FF E1  00 0E 45 78  69 66 00 00  49 49 2A 00 ...
Valid file:
FF D8 FF E1  E0 42 45 78  69 66 00 00  49 49 2A 00 ...
The length of the APP1 segment in the corrupt file is only 0xE = 14? That should be far too small.

I then started to increase the length in the corrupted file randomly and see what error messages convert would give me, but that's more like being in a completely dark room with a metal bucket and throwing rocks until I hear that I've hit the bucket.
But let's see what is at the end of the APP1 segment in the valid file:
0xE042: FD CF FF D9 FF DB 00 84
At 0xE044, which is 0xE042 plus the SOI marker before the APP1 segment, it says FFD9 and the EXIF specification tells us that this is the EOI (End Of Image) marker followed by FFDB, which is the DQT (Define Quantization Table) marker, see Table 40 of the specification. As far as I can tell, everything is where it should be.

Overflow

Now back in the corrupt file, I searched for FFD9FFDB and found it at 0x10010. Do you see it already?
Minus the two bytes for the SOI marker, the length of the APP1 segment should be 0x1000E, which unfortunately can't be stored in only two bytes. What CAN be stored in two bytes is the lower part, 0x000E, which we see as length in the APP1 segment header. A classic example of an integer overflow, the first one I've observed in the wild!

The EXIF specification is clear:
Interoperability, APP1 consists of the APP1 marker, Exif identifier code, and the attribute information itself. The size of APP1 including all these elements shall not exceed the 64 Kbytes specified in the JPEG standard.
Oops.

Solution

From my understanding, the APP1 segment contains the thumbnail at the end. I reckon that that can be recalculated and stored properly by most image processing applications, so let's try shorting the data there to get under 64 Kbytes. I removed 20 bytes directly before the FFD9FFDB, which yields a new APP1 segement length of 0x1000E - 0x14 = 0xFFFA, and store this new length at 0x0004.

It seems like this works! The JPEG can now be opened again without any errors, not even regarding the thumbnail, which I've truncated and is not so important to me.

This is the only time I've encountered this problem with pictures taken using my Samsung Galaxy S2, so this should be a one-time fix. If it happens again, I think I have write a little script to do that for me.

Friday, February 8, 2013

Compiling RetroShare for the Raspberry Pi, revisited

With my emulated Raspberry Pi set up, I wanted to compile the newest version of RetroShare to check both whether the pseudo-cross-compilation actually works and if my last how-to is still valid.

At the time of writing this, the RetroShare wiki gives these instructions:
sudo apt-get install -y g++ libbz2-dev libcunit1-dev libgnome-keyring-dev libgpg-error-dev libgpgme11-dev libprotobuf-dev libqt4-dev libssh-dev libssl-dev libupnp-dev libxss-dev qt4-qmake subversion
cd ~/
svn co svn://svn.code.sf.net/p/retroshare/code/trunk retroshare
cd ~/retroshare/libbitdht/src && qmake && make clean && make && \
cd ~/retroshare/openpgpsdk/src && qmake && make clean && make && \
cd ~/retroshare/libretroshare/src && qmake && make clean && \
cp ~/retroshare/libretroshare/src/Makefile ~/retroshare/libretroshare/src/Makefile.old &&\
cat ~/retroshare/libretroshare/src/Makefile | perl -pe 's/^(INCPATH[^\n].*)\n/$1 -I\/usr\/lib\/arm-linux-gnueabihf\/glib-2.0\/include\n/g' > ~/retroshare/libretroshare/src/Makefile.new &&\
mv ~/retroshare/libretroshare/src/Makefile.new ~/retroshare/libretroshare/src/Makefile &&\
make && \
cd ~/retroshare/retroshare-nogui/src && qmake && make clean && make && \
cd ~/retroshare/retroshare-gui/src && qmake && make clean && make
I want to play it safe and not use the latest version from svn, because the project is very active at the moment and I don't want to sit here and wonder whether the eventual compiler errors are my fault or a result of an incomplete commit there.

So, download the latest version: http://sourceforge.net/projects/retroshare/files/RetroShare/0.5.4d/RetroShare-v0.5.4d.tar.gz

Problems with architectural chroot

First of all, it seems like the chroot isn't perfect. For instance, I can get an internet connection, so wget fails, and I also can't sudo.

As a consequence of that, the installation of packages has to be done from within the QEMU environment. A lot has changed since version 0.5.4b, so I'll stick to what their wiki says about what we need to install.
sudo apt-get install -y g++ libbz2-dev libcunit1-dev libgnome-keyring-dev libgpg-error-dev libgpgme11-dev libprotobuf-dev libqt4-dev libssh-dev libssl-dev libupnp-dev libxss-dev qt4-qmake
I was about to say "Activate the swapfile", but we don't need it, because we have the RAM of our host linux machine.

Exit the QEMU environment now with sudo reboot.

Compiling RetroShare

Enter the architectural chroot like described in my last post.

Then, enter the development directory and start compiling. I've adapted the above given commands to fit my directory structure and increase the number of threads to make use of my i5's four cores.
cd ~/development/RetroShare-v0.5.4b/trunk/
cd libbitdht/src && qmake && make clean && make -j4 && \
cd ../../openpgpsdk/src && qmake && make clean && make -j4 && \
cd ../../libretroshare/src && qmake && make clean && \
cp Makefile Makefile.old &&\
cat Makefile | perl -pe 's/^(INCPATH[^\n].*)\n/$1 -I\/usr\/lib\/arm-linux-gnueabihf\/glib-2.0\/include\n/g' > Makefile.new &&\
mv Makefile.new Makefile &&\
make -j4 && \
cd ../../retroshare-nogui/src && qmake && make clean && make -j4 && \
cd ../../retroshare-gui/src && qmake && make clean && make -j4
Wow! That was incredibly fast! It worked like a charm and it only took 30 minutes. If this isn't a full-scale success, I don't know what is ;)

The only thing left to do now is to strip the executable
strip RetroShare
and copy it to the actual Raspberry Pi. It works like a charm!

A huge "Thank you" to the guys from RetroShare for making it easier and easier to compile this awesome piece of software for the Raspberry Pi!

Thursday, February 7, 2013

Faster compiling on an emulated Raspberry Pi on Linux

In my last article about RetroShare on the Raspberry Pi, I've written about my experiences ...

Unfortunately, the 256 MB RAM of my Raspi is barely enough to keep RetroShare running, but even a simple 'sudo apt-get update' can crash it. The RetroShare project itself is very active at the moment, bugs are constantly fixed and features added. But compiling RetroShare requires all resources, so I thought about alternatives.

"Simple", I thought, "Emulation!"

Spoiler alert: Emulating a Raspberry Pi using QEMU is slow.

I have no experience with emulation whatsoever, so there is no real reason for choosing QEMU over other emulators like VirtualBox, I just found instructions and information for this way first.

What we need to get started

The Emulator

My desktop PC is running Ubuntu 12.04, the rest of the system specifications shouldn't matter. (Yes, I know that this version is a bit outdated, but as a True Believer in Murphy's Law I tend to not change a running system.)

Installing QEMU

Install the package qemu-kvm-extras the way you usually install packages, e.g., using aptitude or
sudo apt-get install qemu-kvm-extras
This will also install some dependencies that are needed.

You will also need to download a QEMU-ready linux kernel for the Raspberry Pi, which you can do here: http://xecdesign.com/downloads/linux-qemu/kernel-qemu
Alternatively, you can compile your own kernel.

Preparing the environment

Create a directory in which our experiment will take place. I chose:
mkdir ~/development/raspberrypi-qemu

Raspbian Wheezy

I used newest version of Raspbian Wheezy currently available at http://www.raspberrypi.org/downloads:

Torrent2012-12-16-wheezy-raspbian.zip.torrent
Direct download2012-12-16-wheezy-raspbian.zip
SHA-1514974a5fcbbbea02151d79a715741c2159d4b0a
Default loginUsername: pi Password: raspberry

Download it and unpack the image file into the directory you prepared in the last step.

Plan A: Running an emulated Raspberry Pi

In the directory of the image, run the following command:
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1" -hda 2012-10-28-wheezy-raspbian.img
The parameters have the following functions:
-kernel kernel-qemu
the QEMU-ready kernel we just downloaded
-cpu arm1176
the CPU we want to emulate (ARM1176JZF-S (700 MHz))
-m 256
how much RAM should be available (in MB)
-M versatilepb
the machine type to emulate
-no-reboot
exit instead of rebooting
-serial stdio
redirects the serial port to the standard I/O
-append "root=/dev/sda2 panic=1"
where to find the root partition, depends on the image
-hda 2012-10-28-wheezy-raspbian.img
what should be used as hard drive, in this case our image
Now, you might be tempted to simply increase the amount of available RAM, but it doesn't work that way. I'm not sure why, but it only works with 256 MB RAM. On the other hand, we can circumvent the problems of creating a swap file on an SD card, because most likely the image is not located on one. Increasing the available memory is easy now, just add a sufficiently large swap file.

We also shouldn't forget to resize our image, because right now we only have about 200 MB of free space left. Again: There already are many articles on the net covering this, so I'll only quickly describe what I did.
  1. With QEMU not running, you can use qemu-img to resize an image:
    qemu-img resize 2012-12-16-wheezy-raspbian.img +1G
  2. For other reasons, raspian's built-in functionality of growing the partition to fill the SD card won't work here, so I did it the hard way.
  3. Boot your emulated Raspberry Pi again using QEMU
  4. Resize the partition using fdisk
    sudo fdisk /dev/sda
    It should look similar to this:
    Device Boot  Start       End    Blocks   Id  System
    /dev/sda1     8192    122879     57344    c  W95 FAT32 (LBA)
    /dev/sda2   122880   5885951   2881536   83  Linux
    You need to delete partition 2 and create it again with the same start, but this time with the highest allowed value for end.
  5. Resize the filesystem using
    sudo resize2fs /dev/sda2

It's too slow

Before we start compiling RetroShare again, let's check up on the speed. This is what I get from the QEMU Raspberry Pi:
pi@raspberrypi:~$ cat /proc/cpuinfo | grep MIPS
BogoMIPS        : 565.24
And this is from my actual Raspberry Pi
pi@raspberrypi:~$ cat /proc/cpuinfo | grep MIPS
BogoMIPS        : 697.95
So, my emulated raspi running on a Intel Core i5 is actually slower than the real raspi ... which is not what I wanted. I mean, okay, if I'd have the machine running for something else anyway, that wouldn't be a problem. But I still want it to be faster.

Plan B: Architectural chroot a.k.a. chroot Voodoo

Looking for solutions to speed up QEMU, I stumbled upon another approach: architectural chroot!

Now, I'm familiar with chroot (at least I though so) and I've used it hundreds of times when my Ubuntu got f*cked up because of an update or some other stuff. And I remember the difficulties when I tried to chroot into a 64 bit system from a 32 bit Live-CD. But it seems like there is a way around this. Coincidentally, we're already close to what we need: a static version of QEMU.

Install it via apt-get (or build it yourself)
sudo apt-get install qemu-user-static
We need to mount the image using loopback, but since the image contains multiple partitions, we require kpartx
$ sudo kpartx -a -v 2012-12-16-wheezy-raspbian.img 
add map loop0p1 (252:8): 0 114688 linear /dev/loop0 8192
add map loop0p2 (252:9): 0 5763072 linear /dev/loop0 122880

$ sudo mount /dev/mapper/loop0p2 /mnt/temp
Now, copy the static QEMU binary TODO and mount the special directories:
sudo cp /usr/bin/qemu-arm-static /mnt/temp/usr/bin
sudo mount -o bind /dev /mnt/temp/dev
sudo mount -o bind /proc /mnt/temp/proc
sudo mount -o bind /sys /mnt/temp/sys
Before we can enter the chroot environment, it's time for the magic! As root (simple sudo won't work), do this (all in one line):
echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' > /proc/sys/fs/binfmt_misc/register
This registers the static QEMU we copied as arm-interpreter to the kernel. The path specified needs to be the same on both your linux machine and the Raspberry Pi environment.

Now we can chroot:
sudo chroot /mnt/temp
Did it work?
$ uname -a
Linux localhost 2.6.32 #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013 armv7l GNU/Linux

Hooray! Welcome to your (much faster) Raspberry Pi environment! Now, let's do some compiling ;)

Cleaning up

To avoid inconsistencies, make sure you never use QEMU and chroot at the same time! Even more, you need to completely unmount the image before you start QEMU. Otherwise you might see some undesireable side effects.
sudo umount /mnt/temp/dev
sudo umount /mnt/temp/proc
sudo umount /mnt/temp/sys
sudo umount /mnt/temp
sudo kpartx -d -v 2012-12-16-wheezy-raspbian.img

Acknowledgements

I also want to give credit to the following articles that helped me doing this: