Probleme bereitete die Installation und Nutzung des VMware-Players, den ich gerne als recht flexible Virtualisierungslösung einsetze.

Das Installationsproblem

Die Installation ist eigentlich simpel: Man setzt das *.bundle auf executable und startet das Paket dann mit Rootrechten. Doch ein Erfolg wollte sich nicht einstellen. Irgendwo auf halber Strecke hängt der Installer und bewegt sich weder vor noch zurück. Greppt man die Ausgabe von ps waux nach gcc-Prozessen durch, wird man schlafende oder wartende Kompilationsvorgänge finden.

Warum das? Die Kompilierung der VMware-Module verursacht viele Warnungen über fehlende Symbole. Daran verschluckt sich nun der umgebende Python-Prozess und nichts geht voran. Die Lösung hat das VMware-Forum parat:

• Man startet die Installation in zwei Fenstern (je mit Rootrechten)
• In einem der Fenster startet man das Bundle mit dem Parameter --ignore-errors
• Im zweiten Fenster tötet man gnadenlos alle Modul-Bauprozesse:
  while true; do killall -9 vmware-modconfig-console; sleep 1; done
  Die Schleife mit Strg+C abbrechen, wenn die Installation durch ist.
• Am Ende hat man zwar eine VMware, aber keine Kernelmodule, die baut man hinterher mit
  vmware-modconfig --console --install-all
• Nun noch den VMware-Dienst neu starten und der Player lässt sich nutzen

Das Mausproblem

Schnell werdet Ihr feststellen, dass die Maus in der VMware hüpft und immer wieder aus der VMware raus oder in sie rein wechselt. Ein vernünftiges Arbeiten ist so nicht möglich.

Die Lösung des Problems hat Rootloot.de herausgefunden: Eine Inkompatibilität, zwischen Ubuntus Gtk+ und dem Gtk, das die VMware erwartet. Der Trick: Einfach die VMware zwingen, das mitgelieferte Gtk+ zu nutzen, auch wenn die Darstellung nicht zu 100% mit dem Rest des Desktops kongruent sein sollte. Am besten per Export einer Umgebungsvariable. Da ich die VMware eh immer aus einer Shell starte, habe ich mich mit

export VMWARE_USE_SHIPPED_GTK=force

beholfen. Bingo, klappt alles!

• Starke Verschlüsselung: Das Backup muss sicherer sein als diese unsägliche ZIP-Verschlüsselung hinreichend sicher sein und ein statistischer Angriff soll keinen Erfolg versprechen.

• Gute Komprimierung: Ich möchte in kurzer Zeit das Backup klein eindampfen können und beim Zugriff effizient entpacken, also nur die Dateien, die ich benötige.

• Mountbares Backup: Ganz ohne vorheriges Entpacken soll ein sofortiger Zugriff auf alle Dateien im Backup möglich sein.

• Keine unverschlüsselten temporären Dateien: Weder beim Packen noch beim Entpacken sollen unverschlüsselte temporäre Dateien anfallen, einerseits aus Sicherheitsgründen, andererseits weil eine temporäre Datei auf einem zufällig verschlüsselten Dateisystem Prozessorlast erzeugt.

Bis vor kurzem habe ich einfach Archive mit Tarballs mit Twofish verschlüsselt (openssl bietet ein komfortables Subkommando) und diese auf DVD gebrannt. Neben den oben genannten Nachteilen kam das Problem dazu, dass auf einem ISO-9660-Dateisystem die Dateigrößengrenze bei 2GB lag.

Meine Lösung sah eine Kombination aus bekannten Technologien vor: Eine Containerdatei sollte per losetup zum blockorientierten Gerät mutieren, dort wiederum sollte mit cryptsetup ein verschlüsselter Datenträger entstehen, der wiederum ein komprimiertes Squashfs-Dateisystem aufnehmen sollte. Klingt kompliziert? Ist es aber nicht:

Benötigt werden die im Tutorial /home reisetauglich verschlüsselt erwähnten Pakete und die squashfs-tools sowie SquashFS-Module für den laufenden Kernel.

Anlegen des Containers und Befüllen mit Daten

Zuerst wird ein Container angelegt, verschlüsselt und dann mit Daten gefüllt

• Erstellen des Containers: Ein Sparse-File mit der maximal zulässigen Größe einer DVD5 (4700372992 Bytes oder 2295104 Blöcke — bei einer DVD9 müssten es 4150388 Blöcke sein) entsteht mit dem folgenden Befehl. Die Datei belegt am Anfang nur 2048 Byte, angezeigt wird dennoch die maximale Größe:

  dd if=/dev/zero bs=2048 count=1 seek=2295103 of=crypt_squash.data

• Erstellen eines Loop-Devices: Mittels losetup entsteht jetzt eine der Datei zugeordnete Blockdevice:

  losetup /dev/loop0 crypt_squash.data

  Sollte /dev/loop0 bereits besetzt sein, zeigt losetup -f freie Loop-Devices.

• Erstellen des Containers: Auf der Loop-Datei wird nun das verschlüsselte Blockgerät vorbereitet:

  cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/loop0

• Öffnen des verschlüsselten Gerätes: Nun wird die verschlüsselte Gerätedatei geöffnent. Das Resultat ist ein Blockdevide /dev/mapper/cryptdvd auf das geschrieben werden und von dem gelesen werden kann. Die Verschlüsselung erfogt hier komplett transparent:

  sudo cryptsetup luksOpen /dev/loop0 cryptdvd

• Erstellen des komprimierten Dateisystems: In /dev/mapper/cryptdvd entsteht nun das komprimierte Dateisystem SquashFS. Weil wir in eine Gerätedatei schreiben, muss explizit -noappend angegeben werden, um diese zu überschreiben. Die restlichen Parameter sind Kosmetik: Ich bevorzuge noch aus Kompatibilitätsgründen Komprimierung mit gzip und möchte nur einen Prozessor einspannen.

  mksquashfs Projekte WichtigeDaten /dev/mapper/cryptdvd  -nolzma -check_data -noappend -processors 1

Test des Containers

Nun ist der Test des Containers dran. Funktioniert das Backup so, wie wir es uns vorgestellt haben?

• Mounten des Containers: Das Cryptdevice existiert ja noch, mounten wir es einfach:

  mkdir /tmp/cryptdvd
  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

  Falls ein unbekanntes Dateisystem angegeben wird, sollten Sie sicherstellen, dass das SquashFS-Modul geladen ist und gegebenenfalls den Dateisystemtyp angeben:

  mount -t squashfs /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten:

  umount /dev/mapper/cryptdvd

• Auflösen des Cryptdevices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices: So stellen wir sicher, dass auch alle Daten im Container gelandet sind und wir gefahrlos brennen können:

  losetup -d /dev/loop0

Brennen der DVD

• Brennen der DVD: cdrecord ist es herzlich egal, was für Daten da gebrannt werden, es bannt unseren Container 1:1 auf den optischen Datenträger:

  cdrecord -v -speed=4 -dev=/dev/scd1 crypt_squash.data

Test der gebrannten DVD — Mounten und Unmounten des Backups

• Loop-Device erstellen: Zunächst entsteht ein Loopdevice auf der gebrannten DVD. Es könnte eigentlich auch ohne funktionieren:

  losetup /dev/loop1 /dev/scd1

• Öffnen des Crypt-Devices: Jetzt wird die Datei /dev/mapper/cryptdvd erzeugt, welche die Entschlüsselung transparent macht. Hier ist die Eingabe des Passwortes erforderlich:

  sudo cryptsetup luksOpen /dev/loop1 cryptdvd

• Mounten des Dateisystems: Möglicherweise ist die Angabe des Dateisystemtyps erforderlich:

  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten wie oben:

  umount /dev/mapper/cryptdvd

• Lösen des Crypt-Devices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices:

  losetup -d /dev/loop1

  Nun kann die DVD entnommen werden.

Die meisten der angegebenen Schritte lassen sich leicht automatisieren, so dass sichere Backups sehr einfach durchgeführt werden können und der Zugriff genauso einfach möglich ist. Ein Manko bleibt: Für das Hinzufügen neuer LUKS-Schlüssel muss der Container natürlich mit dd auf Festplatte transferiert und in ein Loop-Device überführt werden, bevor er neu gebrannt wird.

Nachtrag I: Ich stelle diesen Artikel hiermit unter BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki (oder andere Wikis) übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird. Viel Spaß damit! creativecommons.org/licenses/by-sa/3.0/de/

Nachtrag II: Da einige Community-Wikis NC-BY-SA verwenden und BY-SA nicht nach NC-BY-SA überführt werden kann, zusätzliche Bereitstellung unter NC-BY-SA. Viel Spaß damit! creativecommons.org/licenses/by-nc-sa/3.0/de/

Wer Windows in der von Microsoft vorgesehenen Reihenfolge — erst XP, dann Vista, dann 7 — installiert, wird selten Probleme bekommen: Jedes Windows erkennt seine Vorgänger und bindet diese in den eigenen Bootloader ein. Trickserei ist aber gefragt, wenn kein Windows vom anderen Kenntnis haben soll oder man zu jeder Zeit ein beliebiges Windows durch eine Neuinstallation ersetzen möchte. Der Standard-Bootmanager von Windows scheitert hieran, Abhilfe schafft der kostenlose und von Linux-Distributionen bekannte GRUB. Netter Nebeneffekt meiner Lösung: Jedes Windows hat den Laufwerksbuchstaben C: für die Systempartition.

Im folgenden b eschreibe ich, wie man Windows XP, Windows Vista und Windows 7 unabhängig voneinnader installiert. Je nach Bedarf können Sie auch zweimal XP und einmal 7 installieren oder die Reihenfolge variieren. Einzige Einschränkung ist die Limitation bootfähiger Windows-Versionen auf drei, was durch die maximale Anzahl an primären Partitionen bedingt ist. Wer GRUB auf eine zweite Festplatte, Diskette, USB-Stick oder CD auslagert, kommt auf vier.

Als Werkzeugkiste kommt eine Sidux-Live-CD in Version 2008-04 zum Einsatz. Im Prinzip sollte es jede Live-CD tun, die Gparted und fdisk mitbringt. Schlimmstenfalls sind auf Grund anderer Mountpoints etc. einige Parameter anders einzugeben.

Vorbereitung der Festplatte

Die Partitionierung der Festplatte nehmen wir unter Sidux vor. Rufen Sie in einem Terminalfenster sudo gparted auf, um den Partitionseditor zu starten. Hier legen Sie nun eine primäre Partition mit NTFS-Dateisystem für die erste Windows-Installation, zwei weitere primäre Partitionen ohne Dateisystem und eine kleine (alles ab 30MB aufwärts genügt) primäre FAT16- oder FAT32-Partition für den Bootloader an. Schreiben Sie die Änderungen der Partitionstabelle und ändern Sie anschließend die Flags: Die NTFS-Partition muss das Bootflag gesetzt haben, damit sich Windows problemlos installieren und starten lässt. Bei dieser Gelegenheit können Sie sich gleich mit der Notation für Laufwerke unter Linux vertraut machen: /dev/sda ist die erste Festplatte, die enthaltenen Partitionen sind nummeriert: eins bis vier für primäre, respektive erweiterte und fünf bis unendlich für logische Partitionen.

Installation von Windows XP

Nun ist die Installation von XP an der Reihe. Hier gibt es wenig Spektakuläres zu vermelden: Bei der Installation ist auf die Auswahl der richtigen Partition zu achten, führen Sie eine Schnellformatierung durch, damit sichergestellt ist, dass XP mit der Version des Dateisystems klarkommt.

Sicherung der XP-Installation und Aktivierung einer weiteren Partition

Wir booten nun erneut das Live-Linux-System. Allerdings ist jetzt etwas Kommandozeilen-Voodoo nötig. Achten Sie auf die Details: ein # kennzeichnet einen Root-Prompt, den wir zuvor mit sudo su angefordert haben. Da wir unsere XP-Installation sichern und dann mutwillig beschädigen (!!!) werden, benötigen Sie bspw. einen USB-Stick. In unserem Beispiel dient eine 16GB-Festplatte (es handelt sich um eine VMware) mit einer einzigen FAT32-Partition als Sicherungsmedium. Sie wird als /dev/sdb erkannt.

1. Mounten Sie das Laufwerk, welches zur Sicherung dient, indem Sie es im Bereich “Speichermedien” auf dem Desktop einfach anklicken. Der Befehl “mount” oder “df” verrät dann Mountpoint, also Ordner, unter dem der Datenträger verfügbar ist. In unseren Fall ist dies /media/disk2part1.

   

2. Öffnen Sie ein Terminalfenster, in dem Sie mit sudo su Rootrechte erlangen. Dort lassen Sie dich mit fdisk die aktuelle Partitionierung anzeigen — die XP-Partition wird meist /dev/sda1 sein. Nun sichern Sie mit dd die ersten 16MB der Partition auf die zweite Festplatte oder den USB-Stick: if=... kennzeichnet dabei die als Eingabedatei verwendete Windows-Partition. Anschließend überschreiben Sie die ersten 16MB mit Nullen (Eingabedatei /dev/zero). Sie verhindern so, dass die nächste Windows-Installation das Dateisystem findet und versucht, einzubinden.

   

3. Mit fdisk /dev/sda starten Sie nun den Partitionseditor auf der ersten Platte. Den Typ der ersten Partition ändern Sie mit t auf da (Data), den Typ der zweiten Partition auf NTFS (7). Schließlich entziehen Sie /dev/sda1 mit a das Bootable-Flag und setzen es ebenfalls mit a auf /dev/sda2. Wenn p das gewünschte Ergenis anzeigt, sichern Sie die Partitionstabelle mit w.

   

4. Starten Sie nun den Rechner neu, beispielsweise durch Eingabe des Kommandos reboot.

Installation von Windows Vista

Nun ist die Installation von Vista an der Reihe. Hier gibt es wenig Spektakuläres zu vermelden: Bei der Installation ist auf die Auswahl der richtigen Partition zu achten, führen Sie eine Schnellformatierung durch, damit sichergestellt ist, dass Vista mit der Version des Dateisystems klarkommt.

Sicherung der Vista-Installation und Aktivierung einer weiteren Partition

Wir booten nun erneut das Live-Linux-System. Wieder ist etwas Kommandozeilen-Voodoo nötig. Wir sichern und beschädigen die Vista-Partition so, wie wir es zuvor mit der XP-Partition getan haben. Vergessen Sie das Einbinden des Laufwerks, auf dem Sie die Sicherung ablegen, nicht!

1. Öffnen Sie ein Terminalfenster, indem Sie mit sudo su Rootrechte erlangen. Dort lassen Sie dich mit fdisk die aktuelle Partitionierung anzeigen — die Vista-Partition wird meist /dev/sda2 sein. Auch hier sichern Sie mit dd die ersten 16MB der Partition auf die zweite Festplatte oder den USB-Stick: if=... kennzeichnet dabei die als Eingabedatei verwendete Windows-Partition. Anschließend überschreiben Sie die ersten 16MB mit Nullen (Eingabedatei /dev/zero). Sie verhindern so, dass die nächste Windows-Installation das Dateisystem findet und versucht, einzubinden.

   

2. Mit fdisk /dev/sda starten Sie nun den Partitionseditor auf der ersten Platte. Den Typ der zweiten Partition ändern Sie mit t auf da (Data), den Typ der dritten Partition auf NTFS (7). Schließlich entziehen Sie /dev/sda2 mit a das Bootable-Flag und setzen es ebenfalls mit a auf /dev/sda3. Wenn p das gewünschte Ergenis anzeigt, sichern Sie die Partitionstabelle mit w.

   

3. Starten Sie nun den Rechner neu, beispielsweise durch Eingabe des Kommandos reboot.

Installation von Windows 7

Nun ist die Installation von Windows 7 an der Reihe. Sie verläuft wie die von Vista. Formatieren Sie die vorgesehene Partition und fahren Sie wie gewohnt fort.

Schreiben des Bootloaders

Jetzt muss der GRUB-Bootloader geschrieben werden. Mounten Sie hierfür die Partition, die GRUB später aufnehmen wird (im Beispiel /dev/sda4, gemountet unter /media/disk1part4) und die Partition, welche die gesicherten Partitionsanfänge enthält (im Beispiel /dev/sdb1, gemountet unter /media/disk2part1).

1. Prüfen Sie zunächst mit df | grep sd, ob die beiden benötigten Partitionen wirklich eingehängt sind. Anschließend schreiben Sie GRUB mit den auf dem Screenshot erkennbaren Parametern: --root-directory=/media/disk1part4 kennzeichnet die Partition, auf der die Konfiguration abgelegt ist, /dev/sda ist die Zielplatte.

   

2. GRUB benötigt nun noch eine Konfigurationsdatei /boot/grub/menu.lst auf der Installationspartition, hier also /media/disk1part4/boot/grub/menu.lst. Verwenden Sie den Befehl sudo kate /media/disk1part4/boot/grub/menu.lst um die Konfigurationsdatei anzulegen.

   

   Hier die vollständige Konfiguration für Copy&Paste:

   default 1
   timeout 10
   
   title Windows XP
   root (hd0,0)
   hide (hd0,1)
   hide (hd0,2)
   unhide (hd0,0)
   savedefault
   makeactive
   chainloader +1
   
   title Windows Vista
   root (hd0,1)
   hide (hd0,0)
   hide (hd0,2)
   unhide (hd0,1)
   savedefault
   makeactive
   chainloader +1
   
   title Windows 7
   root (hd0,2)
   hide (hd0,0)
   hide (hd0,1)
   unhide (hd0,2)
   savedefault
   makeactive
   chainloader +1

   Zu bemerken ist, dass GRUB Laufwerke anders kennzeichnet als Linux selbst: Zunächst fängt die Zählung bei Null an, zudem verwenden Platten keine Buchstaben. (hd0,0) ist also die erste Partition der ersten Festplatte. Unsere GRUB-Konfiguration versteckt bei jedem Start einer Windows-Installation die anderen (hide) und holt die eigene hervor (unhide). Übrigens: Um immer den zuletzt gewählten Eintrag zu starten, verwenden Sie default saved.

Anpassung der Partitionstypen

Nun müssen die mutwillig beschädigten Installation von XP und Vista repariert werden und die Partitionstypen wieder korrigiert werden:

1. Verwenden Sie wieder dd, um die gesicherten Partitionsanfänge zurückzuschreiben. Blockgröße und -anzahl sind jetzt nicht nötig:

   

2. Mit fdisk setzen Sie die Typen der als Datenpartition markierten Partitionen sda1 und sda2 jetzt wieder auf NTFS (7):

   

Der erste Start

Und so sieht GRUB dann aus:

Sollten Sie eine Windows-Installation neu installieren müssen, ist dies ganz einfach: Sichern Sie mit dd die Partitionsanfänge der beiden anderen, überschreiben Sie diese mit Nullbytes und ändern Sie den Partitionstyp auf da. Dann installieren Sie das Windows erneut. Nach abgeschlossener Installation setzen Sie die Partititionstypen zurück und spielen die gesicherten Partitionsanfänge zurück. Unter Umständen müssen Sie GRUB erneut installieren, wobei jedoch die Konfiguration erhalten bleibt.

1. SSL-Verbindungen testen

Relativ nah am üblichen Einsatzzweck liegt die Möglichkeit, mit einem simplen Client zu testen, ob ein Server korrekt SSL anbietet oder in den TLS-Modus umschaltet, wenn dies angefordert wird. Am einfachsten geht dies bei einem SSL-gesicherten Webserver, der auf dem Standard-Port 443 lauscht:

openssl s_client -connect mail.rootserverexperiment.de:443

Der s_client wird nun das Zertifikat anzeigen und gegebenenfalls auf Probleme hinweisen, ein “Verify return code” zeigt gegebenenfalls selbst signierte Zertifikate an. Ist das Zertifikat durch, besteht die Möglichkeit, beispielsweise GET-Sequenzen abzusetzen um Webseiten anzufordern.

Ein wenig aufwendiger ist die Kontaktaufnahme mit einem SMTP-Server. Mit diesem wird zunächst Klartext gesprochen, bevor die Anweisung zur Verwendung einer verschlüsselten Verbindung gegeben wird. Auch den Schritt, TLS zu starten, übernimmt openssl mit einem zusätzlichen Schalter:

openssl s_client -connect mail.rootserverexperiment.de:25 -starttls smtp

Nachdem man die Zertifikate betrachtet hat, kann man hier — wie bei Telnet oder Netcat bei unverschlüsselten Verbindungen üblich, die Kommunikation mit SMTP-Befehlen fortsetzen:

EHLO whitehouse.gov
MAIL FROM: george@whitehouse.gov
RCPT TO: mattias@rootserverexperiment.de
...

Der geneigte Admin erkennt schnell: Mit diesem Test ist sichergestellt, dass nicht nur das Zertifikat selbst in Ordnung ist, sondern dieses auch richtig in die Konfiguration des Servers eingebunden wurde (Zugriffsrechte, Pfade). Schlampigkeiten bei der Installation des Zertifikates werden so flott identifiziert.

2. Prüfsummen erstellen

Nicht auf jedem Rechner, auf dem man gerade unterwegs ist, stehen die gängigen Werkzeuge zum Erstellen und Checken von Prüfsummen bereit. Ist OpenSSL installiert, kann dieses verwendet werden um praktisch alle gängigen “Message Digests” zu erstellen. Die (kollisionsfreudige) MD5 zum Beispiel

openssl md5 /tmp/test.bin

oder den eher exotischen RMD160:

openssl rmd160 /tmp/test.bin

3. Dateien verschlüsseln

Verschlüsselung auf die Schnelle? Kein Problem mit OpenSSL! Zumindest symetrische Algorithmen beherrscht das Kommandozeilenwerkzeug perfekt. Das reicht, um eine Datei mit einem Passwort zu versehen und weiterzugeben. Das Passwort kann auf der Kommandozeile übergeben werden. Lässt man es weg, öffnet OpenSSL einen Passwort-Prompt — hier die Verschlüsselung mit 256Bit-AES:

openssl enc -aes256 -k 'Ganz geheimes Passwort' -in datei.txt -out datei.crypt

Der Empfänger (welcher das Passwort auf einem sicheren Weg erhalten hat) kann dann mit dem zusätzlichen Schalter -d die Entschlüsselung starten:

openssl enc -aes256 -d -in datei.crypt -out datei.txt

Diese Form der symetrischen Verschlüsselung hat natürlich den Nachteil, dass der Schlüssel auf Sender- und Empfängerseite bekannt sein muss. Sie taugt daher nicht dazu, bspw. auf einem Server die Logdateien täglich zu verschlüsseln und sie so für Angreifer unbrauchbar zu machen — schließlich ist das Passwort irgendwo im Klartext gespeichert oder es lässt sich schlimmstenfalls über die Prozessliste auslesen. Dafür eignet sich die symetrische Verschlüsselung dafür, Dateien für den Versand an Linux nutzende Empfänger vorzubereiten, die sonst mit Verschlüsselung wenig am Hut haben: OpenSSL ist immer installiert, das Passwort kann am Telefon übergeben werden und die Entschlüsselung ist leicht zu verstehen.

4. Dateien Base64-kodieren

Ganz praktisch ist auch die Möglichkeit, Dateien für dem Versand per Email oder den Einbau in selbst extrahierende Shell-Scripte Base64 zu kodieren. Die Umwandlung einer unverschlüsselten Datei Datei in eine Base64 kodierte entspricht weitgehend der Verschlüsselung, weshalb ich auf auf die Dekodierung nicht weiter eingehe:

openssl base64 -in test.bin -out test.b64

Ein sehr schönes Feature ist jedoch die Möglichkeit, eine Datei zu verschlüsseln und anschließend Base64 zu kodieren, hierbei ist bei der Verschlüsselung und Entschlüsselung der zusätzliche Schalter -a notwendig:

openssl enc -aes256 -k 'Ganz geheimes Passwort' -a -in datei.txt -out datei.crypt.b64

Wofür Sie diese Funktion verwenden, ist Ihnen überlassen — Sinn macht sie beispielsweise beim direkten Versand per Pipeline einer Datei via Mail (einfach den Parameter -out weglassen) oder beim Einbetten binärer und verschlüsselter Daten in Shellscripte.

5. Passwort-Hashes generieren

Haben Sie schoneinmal mit einer 32Bit-Rettungs-CD oder einem 32Bit-Rettungssystem einen Rechner zu reparieren versucht, auf dem ein 64Bit-Linux läuft. Spätestens beim chroot in die gemountete Festplatte des havarierten Systems wird klar, dass die übliche Methode, das Rootpasswort mit passwd zu setzen fehlschlägt. Hier hilft openssl. Mit dem Subkommando passwd entsteht ein Passwort-Hash, der in die Datei /etc/shadow eingetragen werden kann. Der bei Linux übliche MD5-Hash erfordert einen zusätzlichen Parameter:

openssl passwd -1

Passwort-Hashes werden auch bei anderen Anwendungen benötigt: Viele Blogsysteme speichern Hashes für Zugangspasswörter in der Datenbank und Apache vertraut in seinen .htpasswd-Dateien ebenfalls auf MD5-Hashes. opensslbeherrscht natürlich noch andere Hashes, im Zweifel hilft nur ausprobieren.

Alle hier gezeigten Beispiele stammen mehr oder weniger unverändert aus der Manual-Page von openssl beziehungsweise den separaten Manualpages von enc und s_client. Sollten diese auf Ihrem System nicht installiert sein, verwenden Sie die Links um direkt zu den Original-Manualpages zu gelangen.

-rw-r--r--  1 mattias mattias     553 2008-04-09 13:57 Changes in firmware version 3_10.txt
-rw-r--r--  1 mattias mattias 4194304 2008-04-03 18:06 lacinema_premier_fw.bin
-rw-r--r--  1 mattias mattias 4194304 2008-02-19 15:00 ntd00fw.bin
-rw-r--r--  1 mattias mattias    7065 2008-04-09 12:02 Update_Procedure.txt

Interessant sind natürlich besonders die beiden Bin-Dateien. Der Befehl “strings” verschafft schonmal einen Überblick, was drin stecken könnte, da recht viel ausgegeben wird, ist es sinnvoll, nach Begriffen, wie Kernel oder Linux zu greppen. Und bingo:

...
linux.c
/work/iamm35_lacie/uClinux-2.4/include/linux/dcache.h
/work/iamm35_lacie/uClinux-2.4/include/linux/sched.h
/work/iamm35_lacie/uClinux-2.4/include/linux/highmem.h
/work/iamm35_lacie/uClinux-2.4/include/linux/dcache.h
/work/iamm35_lacie/uClinux-2.4/include/linux/dcache.h
/work/iamm35_lacie/uClinux-2.4/include/linux/dcache.h
linux.bin.gz
linux.bin

Das sieht bereits nach den Resten eines Dateisystems (linux.bin.gz und linux.bin) und nach den in Kernelmodulen hinterlassenen Pfade der Include-Dateien aus. Schöner wäre es aber Zugriff auf ein Dateisystem zu erhalten. Doch der Befehl “file” sorgt zunächst für Ernüchterung:

lacinema_premier_fw.bin: data

Image-Offset aufgespürt

Doch wenn Strings so sauber drüberlaufen, kann es kein verschlüsseltes Image sein. Das eigentliche Dateisystem muss also mit einem gewissen Offset beginnen. Eine kurze Google-Recherche liefert, dass das häufig verwendete romfs mit dem Magic -rom1fs- beginnt. Die Zeichenkette wandeln wir zunächst nach Hex:

echo -n '-rom1fs-' | hexdump

0000000 722d 6d6f 6631 2d73 000a

Nun können wir einen Hexdump des Images machen und per Grep den Offset feststellen:

hexdump lacinema_premier_fw.bin | grep '722d 6d6f 6631 2d73'

Bingo!

00009c0 722d 6d6f 6631 2d73 4030 e92d 4000 e1a0
0040000 722d 6d6f 6631 2d73 3700 e0ec 5815 4b36

Mit Offset 0×40000 beginnt also ein RomFS-Image. Das sollte sich auf einem halbwegs aktuellen Desktop-Linux nun mounten lassen:

modprobe romfs
mount -t romfs -o loop,offset=0x40000 lacinema_premier_fw.bin /tmp/firmware

Und was steckt drin?

Nachdem sich das Image so problemlos mounten lies, ist es natürlich schön zu wissen, was drin steckt:

drwxr-xr-x  1 root root   32 1970-01-01 01:00 .
drwxrwxrwt 16 root root  820 2008-06-19 19:26 ..
drwxr-xr-x  1 root root   32 1970-01-01 01:00 bin
drwxr-xr-x  1 root root   32 1970-01-01 01:00 cdrom
drwxr-xr-x  1 root root   32 1970-01-01 01:00 dev
drwxr-xr-x  1 root root   32 1970-01-01 01:00 etc
drwxr-xr-x  1 root root   32 1970-01-01 01:00 hd1
drwxr-xr-x  1 root root   32 1970-01-01 01:00 hd2
drwxr-xr-x  1 root root   32 1970-01-01 01:00 img
-rwxr-xr-x  1 root root 6,5K 1970-01-01 01:00 irdrv.o
-rwxr-xr-x  1 root root  30K 1970-01-01 01:00 irdrvtest.bin
-rwxr-xr-x  1 root root 341K 1970-01-01 01:00 khwl.o
-rwxr-xr-x  1 root root 342K 1970-01-01 01:00 linux.bin.gz
-rwxr-xr-x  1 root root 507K 1970-01-01 01:00 loading.yuv
-rwxr-xr-x  1 root root  55K 1970-01-01 01:00 minimod
drwxr-xr-x  1 root root   32 1970-01-01 01:00 nova
-rwxr-xr-x  1 root root  11K 1970-01-01 01:00 piodrv.o

Das sieht doch schon ziemlich nach einem recht gewöhnlichen — wenn auch sehr kompakten — Linux-Dateisystem aus. Den Beweis liefert schließlich erneut “strings”, dieses Mal auf dem entpackten Kernel linux.bin.gz:

Linux version 2.4.17-uc0 (root@localhost.localdomain) (gcc version 2.95.3 20010315 (release)) #44 2008. 04. 02.

Der Kernel alleine reicht nicht für ein Linux-System. Wenigstens eine Anwendung benötigt man, die als “init” — als Prozess 1 — gestartet wird. Üblich sind Programmnamen wie init oder linuxrc, letztlich kann der Name des zuerst gestarteten Programmes aber auch vom Bootloader übergeben werden. Dennoch, ein /bin/init ist präsent, nicht einmal als Softlink, sondern als recht fette Datei mit 1,7MB. Hier wird offenbar die Hauptanwendung — der Medienplayer — beim Boot gestartet, stürzt diese ab, wird einfach rebootet. Strings auf /bin/init scheint diese Vermutung zu bestätigen, liefert der Befehl doch allerlei Hinweise auf Foto- und Videoplayer.

Doch gegen Ende fallen einige verdächtige Zeilen auf:

Connection timed out
Connection refused
Host is down
No route to host
Operation already in progress
Operation now in progress
Stale NFS file handle
Structure needs cleaning
Not a XENIX named type file
No XENIX semaphores available
Is a named type file
Remote I/O error
Disk quota exceeded

Ich hatte den Verdacht, diese schon gesehen zu haben, bastle ich doch viel mit der BusyBox herum. In einer BusyBox 1.9.2 fand ich:

Connection timed out
Connection refused
Host is down
No route to host
Operation already in progress
Operation now in progress
Stale NFS file handle
Structure needs cleaning
Not a XENIX named type file
No XENIX semaphores available
Is a named type file
Remote I/O error
Disk quota exceeded

Diese Zeilen entsprechen im Wortlaut und Reihenfolge der BusyBox. Natürlich könnte dies Zufall sein. Gar nicht abwegig wäre es, wenn jemand — um die GPL zu umgehen — einfach einen Programmierer in Indien oder China beauftragt, den gesamten Code der Mountfunktionen nachzuprogrammieren, gleiche Übergabeparameter, gleiche Rückgabewerte und gleiche Strings inclusive. Allerdings würde hier wahrscheinlich jeder vernünftige Mensch darauf bestehen, dass nur relevante Fehler Eingang in den Code finden (haben XENIX-bezogene Funktionen heute noch Bestand?) und es wäre fraglich, ob die Strings des sauber neu implementierten Codes im Objekt wieder die gleiche Anordnung hätten.

Conclusio

Auch wenn der 100%ige Beweis noch aussteht wiegen die Indizien bereits schwer: Es deutet viel auf einen Kernel und wenigstens eine Anwendung unter GPL, die nicht als Sourcecode erhältlich sind. Vielleicht kann sich einer der “Objektcode-Kenner” da draußen die Binaries einmal genauer vornehmen und meine Vermutungen bestätigen oder widerlegen. Eine Freigabe unter GPL dürfte LaCie oder deren Zulieferer nicht leicht fallen, schließlich sind die Chancen groß, dass “das fette Binary” auch Code von Dritten enthält. Doch gerade im Fall der Busybox sollte die Vorgehensweise einfach sein: Einfach die BusyBox als externes Binary ausführen und dessen Code freigeben. Damit sind alle zufrieden: GPL-Apologeten und kommerzielle Nutzer.

Natürlich ist fraglich, ob LaCie die alleinige Schuld trifft: Es deutet viel darauf hin, dass neben der Standardhardware von Sigma Electronics eben auch Standardsoftware modifiziert und eingesetzt wurde. Während Sigma die Referenz-Implementierung vorbildlich zum Download anbietet, schaut es mit den modifizierten Versionen düster aus.

Und das Tool der Woche?

Die Moral von der Geschicht: Mit dem richtigen Offset mountet man Images oder auch nicht.

Nachtrag, 20. Oktober 2008: Golem berichtet über eine umfassende Anleitung zum Aufspüren von GPL-Verletzungen.

tar xvjf archiv.tar.bz2

Oder wenn stattdessen ein oder mehrere Ordner oder Dateien zu einem Archiv zusammengefasst werden sollen:

tar cvjf archiv.tar.bz2 ordner/

Doch tar kann einiges mehr. Als erster Einsatzbereich sei da das Archivieren auf Bandlaufwerke zu nennen. Statt dem Archivnamen gibt man einfach den Namen der Gerätedatei an, auf dem die Sicherung landen soll. Im Zeitalter der Sicherung auf optische Datenträger oder des Off-Site-Backups auf irgendwelche Remote-Server schwindet der Nutzen dieser Funktion von tar aber immer mehr und Tools wie rsync, auf das ich später eingehen möchte oder mksquashfs (für’s Backup auf optische Medien) gewinnen an Bedeutung. Dennoch gibt es genügend Einstzbereiche für tar:

Kopieren von Verzeichnisstrukturen

tar lässt sich wunderbar als relativ effizientes Kopierwerkzeug einsetzen. Für diesen Einsatzbereich kommt uns entgegen, dass tar wie fast alle Unix-Programme seine Ausgabe auf die Standardausgabe schreiben kann und so die Verwendung in Pipelines zulässt. Wollen Sie beispielsweise den Inhalt einer unter /media/hdc1 gemounteten Platte auf die Platte unter /media/sda1 schreiben, nutzen Sie dafür:

tar -C /media/hdc1 -cf - . | tar -C /media/sda1 -xvf -

In diesem Fall weist das große -C (change directory) an, zunächst das Arbeitsverzeichnis zu wechseln. Dort wird dann der gesamte Inhalt des aktuellen Verzeichnisses (“.”) in ein neues (-c wie create) Archiv verpackt, als Ausgabedatei (-f wie file) dient die Pipe. Auf der Empfängerseite wird gleich wieder entpackt (-x wie extract), nicht unbedingt nötig ist das -v, welches dafür sorgt, dass angezeigt wird, welche Datei gerade an der Reihe ist. Dass bei diesem Verfahren immer zwei Prozesse arbeiten, sollte nicht weiter stören, schließlich ist die Kommunikation via Pipe effizient und beide Prozesse sind weniger Prozessor- als I/O-lastig.

Kopieren übers Netzwerk

Wo eine Pipeline Verwendung findet, kann man auch irgendwie übers Netzwerk tunneln. Ganz einfach klassisch, unkompliziert und unverschlüsselt geht es mit nc oder netcat, einem Tool, das nichts anderes macht, als übers Netz zu “catten”. Zuerst öffnet man auf Empfängerseite ein lauschendes (l wie listen) nc auf einem unbenutzten Port und übergibt den Datenstrom gleich an das entpackende tar:

nc -l -p 12345 | tar -C /tmp/ -xvf -

Jetzt kann auf Senderseite mit der Übertragung unter Angabe der IP-Adresse des Zielsystems begonnen werden:

tar -C /irgend/wo -cvf - . | nc -q 5 123.45.67.89 12345

Insgesamt sind vier Prozesse beteiligt und man muss auf beiden Rechnern Befehle starten. Dafür läuftnc schön flott. Denn Nachteil der fehlenden Verschlüsselung kann man umgehen, indem man zu ssh greift. Da geht es auch in einem einzigen Befehl. Entweder man startet tar auf dem sendenden System:

tar -C /irgend/wo -cf - . | ssh mattias@123.45.67.89 tar -C /tmp/ -xvf -

Genausogut geht es im “Pull-Verfahren”:

ssh mattias@123.45.67.98 tar -C /irgend/wo -cf - . | tar -C /tmp/ -xvf -

Verwendet man tar um Daten von einem System aufs andere zu transferieren, ist es oft sinnvoll, mit --numeric-owner Verwirrungen bei Nutzernamen/UIDs zu vermeiden. Bei Backups aus laufenden Systemen, wo keine Mountpoints überscprungen werden sollen, hilft zudem auf Senderseite --one-file-system.

Notfallbackup auf DVD

Gelegentlich kommt es vor, dass man einen havarierten Rechner retten muss, aber weder über Netzwerk, noch über eine USB-Festplatte verfügt. Dann hilft tar, welches es ermöglicht, einen “Tarball” direkt auf eine DVD zu schreiben. Komprimiert natürlich und ohne Umweg über eine temporäre Datei. Allerdings sollte man vorher abschätzen können, ob die zu schreibende Datenmenge draufpasst und ein Komprimierungsverfahren wählen, das möglichst keine Gefahr birgt, dass der Puffer leer läuft. Ein kleines Hindernis, das leicht zu umschiffen ist, ist die Tatsache, dass growisofs unbedingt von einer Datei lesen möchte. Kann es haben: Wir geben im die Gerätedatei /dev/stdin. So sieht die resultierende Pipeline aus:

tar -C /zu/sichern -cvzf - . | growisofs -dvd-compat -speed=2 -Z/dev/sr0=/dev/stdin

Natürlich lässt sich eine so beschriebene DVD nicht mounten. Behandeln wir das optische Laufwerk wie ein Bandlaufwerk und lesen den Inhalt der DVD sequentiell ein:

tar -tvf /dev/sr0

Entpackt wird natürlich unter Verwendung von -x statt -t und im richtigen Verzeichnis.

Fündig wurde ich mit id3ed.

Die Anwendung ist einfach (aber nicht intuitiv). Übergibt man ohne weitere Parameter einfach nur die Namen zu ändernder Dateien, kann man in einem (mit readline versehenen) CLI die Tags ändern oder fehldende hinzufügen. Richtig spannend wird aber erst der Batch-Betrieb. Möchte man zunächst alle Dateien in einem Ordner, mit Titel, Interpret, Album und Jahr versehen, geht das mit Kleinbuchstaben und einem ‘-q’, welches anzeigt, dass die übrigen Tags nicht mehr angefasst werden sollen:

id3ed -q -n 'Marillion' -a 'Misplaced Childhood' -y 1985 -g 'Progressive Rock' *.mp3

Ob Misplaced Childhood als Progressive durchgeht, soll an dieser Stelle nicht erörtert werden. Anschließend können die einzelnen Titel mit Tracknummer und Titel versehen werden. Die explizite Angabe der Parameter als Großbuchstaben sorgt dafür, dass keine weiteren Tags bestätigt werden müssen:

id3ed -KS *.mp3

Den Erfolg der ganzen Aktion zeigt schließlich:

id3ed -i *.mp3

Auch id3ed hat so seine Probleme: id3ed schreibt nur v1-Tags, aber leider können viele Player nicht frischer und Umlaute werden je nach eingestelltem Zeichensatz nicht richtig übernommen (im Zuge der Player-Kompatibilität verzichtet man bei Mägo de Oz oder Mötley Crüe) eh besser auf den Heavy-Umlaut…
]]> http://blog.rootserverexperiment.de/2008/05/28/tool-der-woche-id3ed-id3-tags-auf-der-kommandozeile/feed/ 0