+49-172-3864525 (cell phone)
|Physical:||Nassauische Str. 50|
D – Germany
My PGP/GnuPG key is available here or at public key servers.
Jun 16 2010
One of my customers, a large dental practice, had a problem from time to time when reading Krankenversicherungskarten (German health insurance card, KVK). The insurance number got all garbled up, which led to problems when reading the patient's insurance data into the health care application. After their sysadmin and I analysed the situation it seemed that the application reading the data from the card and writing it to a file in a custom format was to blame. This program (KVKTool) was included with the Cherry card reader and had been modified by another consultant to write the read data to a file rather than displaying it on the screen.
This C++ program was a huge stinking pile. All card reading was done in a method called CKVKToolDlg::Onreadcard. The name CKVKToolDlg hints at it: This is the class responsible for showing the dialog. (Yes, it had been left in the program by the previous consultant. Only the dlg.DoModal() call had been commented out.) The method was a gigantic 837 lines long and features all kinds of goodies such as lots of copied-and-pasted code that had been modified in some instance to fix bugs, but not in others.
After a long refactoring session (which turned into a rewrite), I was able to spot the problem: a wrong workaround to bugs in a sizable amount of KVKs. Normally, the data on KVKs is structured into fields in an arbitrary order. These fields consist of a one-byte tag to identify the field, a one-byte length marker, and then n bytes of data, where n is the length. All KVK fields are identified by tags between 0x80 and 0x92. But all KVK fields are wrapped by a super-field called the "Versichten-Template" (insurant template, VT) with tag 0x60. Thus, data on a typical (non-buggy) KVK card would start like this:
|0x60||0x89||0x85||0x09||0x53 0x65 0x62 0x61 ...|
|VT tag||VT len||First name tag||First name length||Seba ...|
Now, buggy cards seem to insert a stray 0x81 byte after the 0x60 tag:
|0x60||0x81||0x89||0x85||0x09||0x53 0x65 0x62 0x61 ...|
|VT tag||???||VT len||First name tag||First name length||Seba ...|
This code in the KVKTool was supposed to handle this problem:
// skip tag 60 and length int i=2; // some cards seem to have a damaged tag 0x89 after 0x81 if (responsearray == 0x81) i++;
(Snipped the huge indention.)
responsearray is a buffer that contains the KVK data and
i is an index into that buffer. This code works fine in
most circumstances. It works around cards with the stray byte. But there
is one situation where it utterly fails: On correct cards where the
Versichten-Template is exactly 129 bytes long. In this case, the first
tag is skipped entirely, which usually is the insurant's number. Since it
was not, junk (random memory content) was written to the file in place of
the insurant's number. Not good, but hopefully fixed now.
Oct 11 2009
VirtualBox on i386 with amd64 Kernel
I have recently started to use an amd64 kernel on my i386 Debian unstable system. Unfortunately, VirtualBox OSE does not work with that setup. When I try to start a virtual machine, it fails with an oblique error message:
RTR3Init failed with rc=-1912 (rc=-1912)
The VirtualBox kernel modules do not fit to this version of VirtualBox. The installation of VirtualBox was apparently not successful. Executing
should fix that problem. Make sure that you don't mix the OSE version and the PUEL version of VirtualBox.
Debian bug #456391 explains the problem. In that report Michael Meskes alludes to running VirtualBox in an amd64 chroot jail, so I tried this myself. It works flawlessly, once I got it setup. Here is what I did (as root):
robinson:~# mkdir /srv/amd64 robinson:~# cdebootstrap --arch amd64 sid /srv/amd64 http://ftp.debian.org/debian/ [...] robinson:~# chroot /srv/amd64 robinson:/# apt-get update [...] robinson:/# apt-get upgrade [...] robinson:/# apt-get install virtualbox-ose # add more packages here if needed [...] robinson:/# adduser --uid 1000 --no-create-home --disabled-password --disabled-login srittau [...] robinson:/#
These commands install the base system and create a user account. Now I created a script called
#!/bin/sh CHROOT=/srv/amd64 if test ! -e $CHROOT/dev/.udev; then mount -t none /dev $CHROOT/dev/ -o bind fi if test `ls $CHROOT/proc | wc -l` = "0"; then mount -t proc none $CHROOT/proc fi if test `ls $CHROOT/sys | wc -l` = "0"; then mount -t sysfs none $CHROOT/sys fi if test `ls $CHROOT/home | wc -l` = "0"; then mount --bind /home $CHROOT/home fi chroot $CHROOT sh -c "su - srittau"
sudo amd64.sh will now enter the chroot environment as user srittau where I can start
Feb 26 2009
Helmar Fanselau dies aged 56
I just learned that one of my former teacher, Helmar Fanselau, died on January 13th, aged 56. He was a strange man. Many students liked him because of his antics and strange sense for humor. Others did not like him for his harsh and unforgiving marks in his subjects, Latin and History. I think he was always fair, though, even if that worked to my disadvantage, because he actually liked me, but I got bad marks nevertheless. I still fondly remember him balancing rulers on his nose and for his ability to speak several different German dialects. His "weather show" featured them all in a stand-up comedy-like routine.
He always was a controversial person, though. I just found an article I wrote back in '96 or '97 about a school mess held by him during which the school parson actually put out the candles in protest.
There were always various rumours about Mr. Fanselau floating around in the school. For example, he was well known for eating from student's lunch boxes. So, the story goes, a student prepared a special sandwich with tooth paste and put it on the teacher's desk. Mr. Fanselau entered, saw the sandwich and ate it. When I questioned him about the story, Mr. Fanselau confirmed it, but was quick to add: "Well, I didn't eat the whole sandwich."
Finally, the way I found out about Mr. Fanselau's death is as bizarre as was his personality: A rogue edit on Wikipedia. Goodbye, Helmar!