The MD87050 has a RS323 connection on the processor board close to the hard disk USB B socket. The labelling of the pins seems to be switched, at least in my version.


The MD87050 has a telnet server running which is accessible from its own WLAN and the WLAN it is connected to if any.


The root credentials are as follows:

  • User name: root
  • Password: 20080826

Boot message

MTD layout

 cat /proc/mtd
 dev:    size   erasesize  name
 mtd0: 00800000 00010000 "ALL"
 mtd1: 00030000 00010000 "Bootloader"
 mtd2: 00010000 00010000 "Config"
 mtd3: 00010000 00010000 "Factory"
 mtd4: 00180000 00010000 "Kernel_RootFS"
 mtd5: 00010000 00010000 "params"
 mtd6: 00010000 00010000 "user_backup"
 mtd7: 00010000 00010000 "user"
 mtd8: 00600000 00010000 "Rootfs"

To back up all the devices insert a fat formatted SD card in the slot and run the following commands.

   # dd if=/dev/mtd0 of=/data/UsbDisk1/Volume1/mtd0.img
   16384+0 records in
   16384+0 records out
   # dd if=/dev/mtd1 of=/data/UsbDisk1/Volume1/mtd1.img
   384+0 records in
   384+0 records out
   # dd if=/dev/mtd2 of=/data/UsbDisk1/Volume1/mtd2.img
   128+0 records in
   128+0 records out
   # dd if=/dev/mtd3 of=/data/UsbDisk1/Volume1/mtd3.img
   128+0 records in
   128+0 records out
   # dd if=/dev/mtd4 of=/data/UsbDisk1/Volume1/mtd4.img
   3072+0 records in
   3072+0 records out
   # dd if=/dev/mtd5 of=/data/UsbDisk1/Volume1/mtd5.img
   128+0 records in
   128+0 records out
   # dd if=/dev/mtd6 of=/data/UsbDisk1/Volume1/mtd6.img
   128+0 records in
   128+0 records out
   # dd if=/dev/mtd7 of=/data/UsbDisk1/Volume1/mtd7.img
   128+0 records in
   128+0 records out
   # dd if=/dev/mtd8 of=/data/UsbDisk1/Volume1/mtd8.img
   12288+0 records in
   12288+0 records out

As seen in the list of MTD devices above mtd0 contains all data. Analysing mtd0.img with binwalk confirms this:

binwalk mtd0.img

0             0x0             uImage header, header size: 64 bytes, header CRC: 0x72E03075, created: 2013-10-22 01:51:02, image size: 127844 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0xEEE7DEAB, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: none, image name: "SPI Flash Image"
104496        0x19830         U-Boot version string, "U-Boot 1.1.3 (Oct 22 2013 - 09:50:58)"
104976        0x19A10         CRC32 polynomial table, little endian
327680        0x50000         uImage header, header size: 64 bytes, header CRC: 0x65E07CA2, created: 2013-11-01 05:36:56, image size: 1442332 bytes, Data Address: 0x80000000, Entry Point: 0x80441000, data CRC: 0x8EFB6500, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744        0x50040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4608121 bytes
2031632       0x1F0010        gzip compressed data, maximum compression, from Unix, last modified: 2017-06-06 09:44:49
2097152       0x200000        Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 4736074 bytes, 1168 inodes, blocksize: 65536 bytes, created: 2013-12-10 09:54:46

A dump of the MTD devices and an extraction of recognisable data using binwalk is available in md87050-mtd-dump.tar.bz2


Debian on the Intenso Memory 2 Move

I have made a gist with a script I am using to deploy Flask applications to VirtualBox:

I used the following beep sequence to remotely play "Happy birthday" for a friend at his office through VPN.

beep -f 261.6 -n -f 261.6 -n -f 293.7 -n -f 261.6 -n -f 349.2 \
     -n -l 500 -f 329.6 -n -f 1 -n -f 261.6 -n -f 261.6 -n -f 293.7 \
     -n -f 261.6 -n -f 392.0 -n -l 500 -f 349.2 -n -f 1 -n -f 261.6 \
     -n -f 261.6 -n -f 523.2 -n -f 440.0 -n -f 349.2 -n -f 329.6 \
     -l 200 -n -f 293.7 -n -f 1 -n -f 523.2 -n -f 523.2 -n -f 440.0 \
     -n -f 349.2 -n -f 392.0 -n -f 349.2

Since I first learned of rsync, copying files have not been the same. If you do not know rsync, you should read up on it now.

Though I like rsync I have always been a little bothered that there was seemingly no way of forcing rsync to count the total number of files before transferring them, thus making the --progress option partially useless. This time I did some research, and found that if your rsync is newer than version 3.1.0 there is an --info option.

From the rsync manual page:

This option lets you have fine-grained control over the information output you want to see. An individual flag name may be followed by a level number, with 0 meaning to silence that output, 1 being the default output level, and higher numbers increasing the output of that flag (for those that support higher levels). Use --info=help to see all the available flag names, what they output, and what flag names are added for each increase in the verbose level. Some examples:

    rsync -a --info=progress2 src/ dest/
    rsync -avv --info=stats2,misc1,flist0 src/ dest/

Note that --info=name's output is affected by the --out-format and --itemize-changes (-i) options. See those options for more information on what is output and when.

This option was added to 3.1.0, so an older rsync on the server side might reject your attempts at fine-grained control (if one or more flags needed to be send to the server and the server was too old to understand them). See also the "max verbosity" caveat above when dealing with a daemon.

With the --info=progress2 i get the following kind of output:

receiving incremental file list
            0   0%    0.00kB/s    0:00:00 (xfr#0, ir-chk=1001/71529)
            0   0%    0.00kB/s    0:00:00 (xfr#0, ir-chk=1000/71612)
            0   0%    0.00kB/s    0:00:00 (xfr#0, ir-chk=1000/73443)
Documents/ebooks/Humble bundle/
            0   0%    0.00kB/s    0:00:00 (xfr#0, ir-chk=1014/73485)

Which seem what I have wished for.

Sometimes you end up with a system having files modified in the future. At one time this happened to my Raspberry Pi, who was set up to sent me an email when something was wrong. After a friendly reminder every hour, I set out to find the files, and change their date to something sane.

Using find, this give a list of the files:

find . -newermt "5 days" -ls

Combine it with touch , to change the date to the current.

find . -newermt "5 days" -ls -exec touch -c {} \;

My Acer Aspire One D250, kept going into suspend every minute or so, whenever I was not logged in to a window manager. I run Debian testing and had my first real interaction with systemd (except for systemctl).

Turns out there are some settings in /etc/systemd/logind.conf that configures some of the power management features.

#  This file is part of systemd.
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
# See logind.conf(5) for details


First I asked systemd to ignore everything but the power button, and as I somewhat expected this didn't do the trick. Then I set the IdleActionSec to the actual amount of second (1800), that didn't work either. In the end completely disabling idling, stopped the suspend.


A friend of mine had an iPhone 3 that was getting really flaky, it was still running IOS 3.1.2 as she was afraid to update, things could go wrong, she could lose all her texts. What she wanted was essentially a PDF with her messages.

I went searching and found some tools ranging in price from $5 to $20, but I was stubborn and cheap, and wanted another solution. There are some free services where you upload a file from an iTunes backup to some web application and it'll extract the texts for you. Neither I, nor my friend wanted all her texts uploaded to a service on the net.

From there I found out the file, that the web app uses, is actually an SQL database file. If you ask iTunes to make an unencrypted backup to your local drive, most of the backup files are actually in easily understandable formats like SQL and jpeg. The location of these files are:

  • Windows XP: \Documents and Settings\USERNAME\Application Data\Apple Computer\MobileSyncBackup\
  • Windows Vista, 7 or 8: \Users\USERNAME\AppData\Roaming\Apple Computer\MobileSync\Backup\
  • MacOS X: \~/Library/Application Support/MobileSync/Backup/

It turns out the file named 3d0d7e5fb2ce288813306e4d4636395e047a3d28.mddata is in fact an SQL database file with all text messages in the backup. After eyeballing the file with SQLite Database Browser, exporting it to a CSV file, importing it in LibreOffice Calc, I found it hard to manage the more than 30,000 messages that way.

In the end I made a python script that saves the messages to text files, each having the address (phone nr.) of the person you were conversing with. I am unsure how it handles MMS messages, I know that the multimedia content is lost, and I think the text is lost aswell, but I don't know. The result is here:

GitHub link

I will walk through copying a bootable Windows 7 installation from a VirtualBox VM to real iron.

  • Insert an external hard drive in the USB port and share it with your Windows 7 VM.
  • Ask windows to make a system image "Control Panel -> Back up your computer -> Create system image", and save it to the external hard drive.
  • Boot the Windows 7 install disk, click through, and select "Repair windows installation". The drives that you do not put on the exclude list, will be repartitioned and formatted, so make sure to exclude everything you want to keep.
  • Let it chew on your backup, and when done, boot Windows.

Felt like doing a demo effect, I have done this once before in C and asm. The year was something like 1996, and the processor a Cyrix/IBM 6x86 120+. This is slooow, not only because it is written in Python, but because it isn't optimised.

Source: fdtunnel.tar.bz2

I have found this tool indespensible, when finding unforseen errors in complex makefiles.


I had an installation of Lunar Linux, that I wanted to move from VirtualBox to KVM, and therefore had to convert the imagefile. I searched high and low, but found no up to date instructions on how to do this. | In the old days there seem to have existed a tool called "vditool", but now "VBoxManager" will do the trick of converting a VirtualBox .vdi image into raw format. Here are the steps that I took:

  • Find the UUID of the VirtualBox disk image:

    oblivion@mastermind ~/.VirtualBox/VDI $ VBoxManage list hdds 
    VirtualBox Command Line Management Interface Version 2.1.2
    (C) 2005-2009 Sun Microsystems, Inc.
    All rights reserved.
    UUID:         e4e316cb-ad9f-46ae-b15c-164b893371cb
    Format:       VDI
    Location:     /home/oblivion/.VirtualBox/VDI/lunar.vdi
    Accessible:   yes
    Usage:        Lunar (UUID: d249a972-f112-4cbc-91ce-389ce75e4fac)

  • Convert the .vdi file to raw format, using the UUID just found. Using VBoxManage's clonehd function the .vdi file is cloned into a raw image, in this case called lunar.img:

    oblivion@mastermind ~/.VirtualBox/VDI $ VBoxManage clonehd e4e316cb-ad9f-46ae-b15c-164b893371cb lunar.img -format RAW
    VirtualBox Command Line Management Interface Version 2.1.2
    (C) 2005-2009 Sun Microsystems, Inc. All rights reserved.
    Clone hard disk created in format 'RAW'. UUID: 5106c566-7188-4513-a416-73eb7a4e44a9

  • On my Gentoo Linux system, the converted image was saved in ~/.VirtualBox/HardDisks.

  • Convert the image to QEMU qcow2 format using qemu-img:

    oblivion@mastermind ~/.VirtualBox/HardDisks $ qemu-img convert ~/.VirtualBox/HardDisks/lunar.img -O qcow2 lunar.qcow2

From the utter silence of this command springs lunar.qcow2, ready for KVM!

For a couple of weeks now my backspace key has only been working sporadicly, being frightened that I might hammer they key to atoms, I decided to try and clean it. First I found the service manual of my Dell Inspiron 1300, and pulled out the whole keyboard, only to realize, that I was unable to tear it apart like a normal keyboard. The plastic parts had some pins going through the metal baseplate, these had then been melted flat to keep the thing together. If I pulled these "weldings" apart, I would never be able to assemble the thing again.

In this case google wasn't a friend, since it was only concerned with "sticky" keys, and I do not use sugar in my coffee.

In the end I took the button off, like I had done once before to make sure I hadn't missed anything.

I proceeded to take of the plastic piece over the rubber that contains the conducting "drop" in the middle.

I thought it seemed like there were two holes on the rubber, and began thinking of using what I call "contact clean". I tried spraying a little onto the rubber, and I could see it underneath. I then massaged it gently with a finger, through the rubber (still talking about my keyboard), for a while.

I had an editor running, so that I could see the key, slowly began working. I then replaced the plastic part, and the button, and it is working again!

Generated on 2018-05-03 01:14:21.848058