Archive for February, 2012


It seems to be Valentine’s Day today, a “holiday” which has been successfully commercialised in my country in the mid 90’s.

My dear people, you can’t buy love. Stop this rubbish. If you want to give some present, please, give something hand made.

And besides that, why love only one day per year?

Het schijnt zo te zijn dat het vandaag Valentijnsdag is. Een “feestdag” die midden jaren negentig hier in Nederland met succes vercommercialiseerd is.

Dames en heren, liefde is niet te koop, Als je toch een cadeau wil geven, pleit ik ervoor een zelf gemaakt cadeau te geven. Dit heeft veel meer betekenis, de tijd, de voorbereiding die je erin steekt, met liefde gemaakt, dat is toch veel mooier dan een iets gekocht ik een winkel?

Daarnaast, laat ons lief hebben heel het jaar door, en niet slechts een dag per jaar.

Since Dropbox is a closed source program, we must live with the binaries provided by dropbox. They only supply i386 and i386_64 binaries, and so ARM binaries, so it’s impossible to run it on, for example, my BeagleBoard.

But I was thinking, isn’t it possible to emulate an i386 CPU? I mean, there is a CPU emulator like Qemu, right? Even though it mentions

QEMU runs on x86 systems running Linux, Microsoft Windows, and some UNIX platforms, and can host target systems from a range of different microprocessors as detailed on the QEMU website

on http://en.wikibooks.org/wiki/QEMU, I attempted to compile it on my BeagleBoard. To save some time, I only compiled the i386 emulator for running ELF binaries. As it runs on an ArchLinux, which uses Python3 as default, I had to supply the path to the python executable as well.

./configure –python=/usr/bin/python2.7 –target-list=i386-linux-user

 And after a while it finished compiling.

[andre@beagle ~]$ uname -a
Linux beagle 3.1.6-1-ARCH #1 SMP PREEMPT Tue Jan 3 03:26:01 UTC 2012 armv7l ARMv7 Processor rev 3 (v7l) OMAP3 Beagle Board GNU/Linux
[andre@beagle ~]$ file ./hello.i386.static
./hello.i386.static: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=0x212eb3065d14823d2eb5d686604631b25201ff6e, not stripped
[andre@beagle ~]$ ./hello.i386.static
-bash: ./hello.i386.static: cannot execute binary file
[andre@beagle ~]$ qemu-i386 ./hello.i386.static
Hello World
[andre@beagle ~]$

Since I have no i386 libraries on the system yet, I have created a static executable on my i386 machine, and transferred it to my BeagleBoard. And it appears to work…

So…. let’s look at dropbox. What are the libraries it required?

[andre@myhost dropbox]$ ldd dropbox
    linux-gate.so.1 =>  (0xb771e000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb76e8000)
    libdl.so.2 => /lib/libdl.so.2 (0xb76e3000)
    libutil.so.1 => /lib/libutil.so.1 (0xb76df000)
    libm.so.6 => /lib/libm.so.6 (0xb76b3000)
    libssl.so.0.9.8 => /opt/dropbox/libssl.so.0.9.8 (0xb7671000)
    libcrypto.so.0.9.8 => /opt/dropbox/libcrypto.so.0.9.8 (0xb752e000)
    libc.so.6 => /lib/libc.so.6 (0xb738d000)
    /lib/ld-linux.so.2 (0xb771f000)
    libz.so.1 => /opt/dropbox/libz.so.1 (0xb7378000)
 

Well… just to make life simple for testing, I just copied the libraries from my running i386 system to the BeagleBoard. So we’re ready to go? Let’s see what happens?

[andre@beagle .dropbox-dist]$ qemu-i386 ./dropbox
/lib/ld-linux.so.2: No such file or directory

How to I tell Qemu where the libraries are. I have looked at the example here https://wiki.edubuntu.org/UbuntuDevelopment/Ports, and verified it with a dynamic version of the hello world executable, which seems to run fine

[andre@beagle ~]$ qemu-i386 libs-for-dropbox/ld-linux.so.2 –library-path libs-for-dropbox ./hello-i386-dynamic
Hello World

By placing the libraries in the .dropbox-dist directory, and using that path as library path, I also solved the issue where dropbox uses a script to use it’s own libraries. Are we ready to run?

[andre@beagle ~]$ qemu-i386 libs-for-dropbox/ld-linux.so.2 –library-path .dropbox-dist/  ./.dropbox-dist/dropbox
Traceback (most recent call last):
  File ““, line 5, in
zipimport.ZipImportError: not a Zip file

I think I should run it in it’s own directory

[andre@beagle .dropbox-dist]$ qemu-i386 ld-linux.so.2 –library-path /home/andre/.dropbox-dist/ ./dropbox
qemu: Unsupported syscall: 240
Traceback (most recent call last):
  File “__main__dropbox__.py”, line 27, in
  File “client_api/dropbox_connection.py”, line 22, in

  File “common_util/functions.py”, line 29, in

  File “common_util/dirtraverse.py”, line 303, in

  File “ctypes/util.py”, line 132, in find_library
  File “ctypes/util.py”, line 122, in _findLib_ldconfig
OSError: [Errno 22] Invalid argument

The Unsuppported syscall already made me think it won’t work… and a few seconds later, this was confirmed. The error messages also reveal something pythony is going on.  Apart from that snake, and the fact it’s not running, it appears some more library problems. Whether is is related to the unsupported syscall or missing libraries, as I see a find_library in there, I cannot tell yet.

So far for playing with my BeagleBoard (over the internet)

So it seems, starting today, XS4ALL is blocking ThePirateBay (due the lawsuit by BREIN)

Since they’re also blocking IP addresses, the hosts file is no solution. I was already making some plans, which involve making an entry in the routing table to my server, and enable routing ip forwarding on my server…. however, how is traffic supposed to go back. Let’s hope they’re only blocking it on the outgoing direction….

But the solution is much simpler… looking at the screenshot…. it doesn’t list all mirrors of ThePirateBay…. so… ThePirateBay still works… You just have to use a different url.

However, today is still a black day in the history of the internet. The internet in my country is being censored. Even though, I pointed out BREINs attempt wasn’t successful, that doesn’t matter. The internet is being censored in my country. Welcome to the new China.