Saturday, August 28, 2021

Recover boot sector from floppy disks with Parity Boot Virus

I recently found some old floppies, back from the times when I was young, was using Microsoft DOS and didn’t have any real clue about computers. As a result, almost all of my floppy disks were infected with the Parity Boot Virus.

The Parity Boot Virus had the habit of overwriting the complete boot sector, i.e. the first sector of the floppy disk (if it wasn’t write protected at least). BUT it was also fair enough to create a backup copy of the boot sector and - on 3,5′’ floppy disks - put it into sector 32. See the Parity Boot Virus page on the Malware Wiki for more information.

25 years later I wanted to mount one of my floppy disk images I had backed up back then on my Linux machine and was surprised to see a lot garbage files like |úI|ë?K|.╕ - certainly not a valid file name. It turned out that sector 32 is the last sector to contain the root directory¹. And it also turned out that Linux reads all clusters and scans them for directory entries, while Windows seems to stop earlier, probably as soon as it encounters an empty file entry.

So how can you restore the original boot sector and get a clean root directory again? Simple, just call

dd if=$file count=1 skip=31 of=$file conv=notrunc seek=0
dd if=/dev/zero count=1 of=$file conv=notrunc seek=31

myfloppy can either be a physical floppy drive (e.g. /dev/fd0) or the file name of an image.

Please just make sure that sector 32 really does contain a valid boot sector - you can view the disk’s contents with hexdump -C myfloppy, check the contents between 00003e00 - 00004000. It should at least contain the label and the file system (e.g. NO NAME FAT12 in lines 3 and 4.

¹ usually, on a 3,5′’ HD floppy disk at least - see this website for an excellent disassembly of the FAT12 file system (German) and this Wikipedia article about the actual default sector size for the directory on a given floppy type if you want to know more.

Thursday, December 10, 2020

Konverting Kopete chat history to libpurple (Pidgin)

When I recently migrated from KDE4 to KDE5 (yes, Slackware did that update just a few days ago ;-)) I had to discover that no migration was done for my Kopete profile. And not only that, I suddenly had to suffer from various display errors - which had happened a few years ago already, but I forgot the solution to fix this. To make things short: I decided to finally migrate to Pidgin.

Now of course I didn’t want to loose all my chat history, but import it into Pidgin.

Fortunately Kopete is storing the log files as plain XML files, though very strange ones - who thought it was a good idea to safe something like “11 9:5:0” as a time field? Also guessing what that is supposed to say? That’s nine o’ clock and five minutes on the eleventh day of a month. Which month you ask? That’s stored in a dedicated field of course ;-)
Anyway: I’ve just written an XSLT converter again. This time it will also include a small Bash script wrapper for creating the correct directories.

Note that it will only convert Jabber and ICQ out of the box - those were the only protocols I’ve been using with Kopete. It should be trivial to add other protocols though - basically you’ll just have to find out the correct source and target directory names.

The script including a small README file can be found on

Thursday, December 5, 2019

Getting SimCity 3000 for Linux run on modern systems

SimCity 3000 was originally ported by Loki Games to Linux, but over time the original binaries became incompatible with modern systems. For that purpose the Loki Compatibility Libraries were introduced, the linked site also contains tons of information to get other Loki to run again. Another option are the Linux Installers for Linux Gamers, which provide updated installers for a lot of old games, and - like in the case of SimCity 3000 - include all the necessary compatibility libraries already.

With SimCity I had one problem additional though. It still wouldn’t start with the following message:

Graphic System: Could not init SDL: No available video device

The problem

After some debugging with strace I noticed that the old version of SDL tries to connect to the local X server via TCP, a feature that was disabled on most distributions in the last few years; if you type ps aux | grep Xorg you will most likely see -nolisten tcp somewhere in the options, which will prevent opening that TCP port.

The solution

If you are using the LIFLG installer from above you can find a very useful helper script that allows you to play the game in a separate X server instead. Just open the file in your installation directory and uncomment all the XSERVER, XSERVER_OPTIONS and XSERVER_DISPLAY lines, and in the XSERVER_OPTIONS line change -nolisten tcp to -listen tcp. You will probably also have to create a file called /etc/X11/Xwrapper.config with a line allowed_users = anybody to be able to start the X server as a user (see man Xwrapper.config for details).

Otherwise you could explicitly start your X server with -listen tcp instead. How that is done depends on your display manager. For KDM for example you can find the X options in /etc/kde/kdm/kdmrc[X-:*-Core]ServerArgsLocal, other display managers should have similar configuration files. This may not be the best option for security reasons though.

Saturday, January 5, 2019

Importing Android SMS on your Jolla / Sailfish device

Short version:
Just visit the project’s website and follow the 5 simple instructions (sounds like clickbait, doesn’t it? ;-)) in the file


When I accidentally messed up my installation of Sailfish OS on my Gemini phone I had to use Android as a backup until I found the time to fix the issue. In the meantime several SMS arrived, which I obviously also wanted to see in Sailfish OS. So I started to investigate the possible options.


My naive attempts to just export the database from the Android partition failed miserably due to Android’s security mechanisms. In the end I settled by using SMS Backup & Restore to get a backup of my messages. Not only does this app seem to be the de-facto standard for SMS backups, but it also provides good documentation on the format of the generated XML file.

I already used commhistory-tool to import my SMS history from Firefox OS, so commhistory-tool’s JSON format was set as the target format. And with an XML file as the source: What would be suited better for conversion than an XSL Transformations (XSLT)?

Already preinstalled on my (Linux) system is one of the most commonly used XSLT processors - xsltproc, so I decided to use that one. Unfortunately I had to find out this processor only supports XSLT 1.0, so is missing a lot of convenience functions. On the positive side it supports several EXSLT commands instead, e.g. for dates, strings and functions, which are used extensively.

I later found out that using xsltproc also has another advantage: It is also preinstalled on Sailfish OS! This completely eliminates the need for a separate PC to convert the files - you can do that directly on your Jolla / Sailfish OS phone. In the case of the Gemini I was able to just export the file to the memory card in Android, reboot into Sailfish, generate the JSON file and import it. Could this be any easier?

The XSLT file can be found on, the project’s file contains detailed instructions on how to use this file.

Monday, March 21, 2016

Exporting Firefox OS SMS or other data (Firefox OS migration part 2)


Welcome back to the second part of the Firefox OS migration guide. Last time we migrated the Firefox OS Offline Calendar data, this time we will take a more general approach to export any kind of data, e.g. your SMS history.


This article assumes you retrieved your user data from your Firefox OS device already - if you didn’t, please follow the guide in the article Exporting the Firefox OS Offline Calendar (Firefox OS migration part 1) up to step 5 first.

Checking what data is available

In the last article you may have been wondering what that Database name: field is for: It’s for getting the contents of any kind of data. The default value of b2g-calendar will get you the IndexedDB database containing the calendar data.

So let’s check which other databases exist. Unfortunately a website can’t access that data, but Firefox itself can:

  1. Open the website like in the previous article (if you created a separate profile please use that profile to open the website!)
  2. Open the Firefox menu by clicking on the Open menu button at the top right of your browser.
  3. Click on DeveloperToggle Tools.
  4. A toolbar will open on the bottom of the browser. At the top right of that bar click on the gear icon (Toolbox Options).
  5. In the section Default Firefox Developer Tools check Storage.
  6. A new tab called Storage has appeared on the top of the toolbar now - click on it.
  7. You will find a section Indexed DB on the left. Click on it and also click on the entry.
  8. You will get a list of all databases you migrated initially.

If this guide was too confusing see the Mozilla manual on how to open the Storage Inspector.

Importing more data

You have probably backed up your complete device’s user data, so let’s see what else is there. Open the backup with your file manager and navigate to the directory containing several directories named like - those are the applications that used IndexedDB databases to store their data. You will also notice the folder called chrome: This one contains the data of the core Firefox OS applications like your SMS storage.

Now repeat Step 5 of the original tutorial, but this time copy the (complete) contents of the idb directories of the applications you are interested in into your newly created directory. Unfortunately several applications have files of the same name, so you cannot use them at the same time (you have to repeat Step 5 for each one your are interested in).

Working with the data

Now you can just check which databases are available using the Firefox Storage Inspector view from above. If you want to export any of those databases enter the name of the database in the Database name field and click on Export to get the contents as JSON output. There are numerous tools available on the web to transform JSON data into other formats (or you can write one yourself if a converter to your format is not available :-P).

Wait - what about my SMS data?

You will find those in the chrome directory of your backup. When you import those into Firefox you have to export the sms database, the required Object Store is also called sms.

If you own a Jolla phone or any other device based on Mer you can simply select Convert SMS data to commhistory-tools JSON file, save the file to your phone and import it with the command commhistory-tool import-json sms.json (Note: MMS messages are not supported by this tool unfortunately).

If you have an Android phone there seem to be several tools available to import SMS data from CSV files, so one simple solution would be to convert the JSON data into CSV. There are various converters for that available, but looks very promising because it also processes all data locally on your PC (i.e. no data is sent to the server as of 2016-03-21).


This concludes my series of the Firefox OS migration guide. I hope you found it useful, and don’t hesitate to ask if you have any questions. (The Comments section is currently locked due to the massive spam amount, I hope I will be able to unlock it soon again with a better filter.)