Monthly Archives: March 2010

Gebrauchte Daten kaufen

In den letzten Wochen habe ich für dienstliche Zwecke vier alte Speicherkarten vom Typ MMC gebraucht bei der elektronischen Bucht erstanden. Auf allen vieren waren noch Daten drauf. Sicher, die waren frisch formatiert, aber alle nur im Schnelldurchlauf. Neues Dateisystem anlegen und fertig. Kein einziger der Verkäufer hielt es für notwendig, wirklich alle Daten zu löschen.

Ich bin nun kein Forensiker und meine Zeit für solchen Spielkram ist begrenzt. Aber da ich den coolen Hex-Editor Bless sowieso installiert und Images der Karten angelegt hatte, um Partitionstabellen und Volume Boot Records zu untersuchen, hab ich natürlich noch kurz weiter über die Dumps geschaut. Beim wirklich nur flüchtigen drüber Gucken habe ich Kartendaten für ein Navigationsgerät, Musikdateien im mp3-Format und Tabellen mit Adressen von Ärzten1 gefunden. Gerade bei letzterem handelt es sich um sensible Daten, die man vermutlich nicht wissentlich weitergegeben hat. Da rollen sich mir ja dann schon die Fußnägel hoch.

Damit die ganze Aufregung hier nicht umsonst ist, noch ein kleiner Tipp, wie man hier zwei Fliegen mit einer Klappe schlagen kann. Man benutzt einfach das Tool badblocks unter Linux im Schreibmodus. Vorsicht ist angebracht, mit Datenträgern, die man noch braucht, wenn aber wirklich alles gelöscht werden kann, dann hier der Auszug aus der manpage mit der passenden Option:

-w Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every block and comparing the contents.

Das Programm schreibt also bestimmte Muster auf die Karte und liest diese dann nochmal zurück und zwar für jeden einzelnen Block. Wenn Fehler dabei auftreten, werden die gemeldet und man kann den Datenträger wegwerfen. Wenn keine Fehler auftreten, kann man die Karte ruhigen Gewissens verkaufen und sicher sein, dass ausschließlich Nullen drauf stehen.

Ganz wichtig: damit das funktioniert, führt man badblocks mit root-Rechten aus und lässt es auf das ganze Device los. Da muss man vorher das passende rausfinden und 100% (und kein µ weniger) sicher sein, dass man das richtige erwischt hat. Wenn noch ein Filesystem auf der Karte ist, einfach mounten und mit mount nach dem Device gucken. Oder mit dmesg anzeigen lassen, wie die Karte beim Anstecken erkannt wurde. Oder aus /proc/partitions das Device mit der passenden Größe ablesen. Oder am besten alle Möglichkeiten zusammen. Der fertige Befehl in meinem Fall hier und heute:

Falls man nun gerade kein Linux zur Hand hat, bitte in Windows beim Formatieren unbedingt vermeiden die »Schnellformatierung« zu aktivieren. Oder am besten nach der Formatierung nochmal das Programm h2testw der c’t drüber laufen und Daten schreiben lassen, damit wenigstens die Adressdaten der Homöopathen verschwinden. Nicht dass die am Ende noch wer aufsucht, oder vermöbelt oder potenziert oder so …

Ach ja und abgesehen vom Verkaufen von alten Datenträgern: die erwähnten Programme sollte man auch auf jeden frisch neu erworbenen Datenträger loslassen, um sicherzugehen, dass der auch funktioniert. Ist mir nämlich in den letzten Wochen mit einer neuen Festplatte und einem neuen USB-Stick passiert, dass die gleich vom Start weg defekt waren und umgetauscht werden mussten.

  1. und Homöopathen, man beachte die Unterscheidung … ;) []

Logitech-HID mit Debian Sid

Nutzer der Unstable-Variante von Debian (auch als Debian Sid bekannt) bekommen ja bekanntlich regelmäßig Gratisabenteuer aus dem Bereich der Systemadimistration geschenkt; sozusagen ein Quest-Abo.

Problem des Tages: Einen Systemstart nach dem letzten Update funktionierten Bluetooth-Tastatur und -Maus von Logitech nicht mehr, in meinem Fall konkret das Dinovo-Set.

Ich habe häufiger Ärger mit Logitech unter Linux, meistens ließ sich das aber mit einem Reset des Bluetooth-Dongles1 beheben. Dieses Mal nicht, der Fehler war persistent.
dmesg, logs und Modulliste waren soweit korrekt, es war alles da, was für die Geräte gebraucht würde und es wurde laut lsusb auch alles erkannt. Nur funktionierte einfach nichts. $SUCHMASCHINE lieferte dafür auch keine weiteren Ergebnisse.

Letztendlich habe ich das Problem in den udev-Regeln2, speziell der Datei 70-hid2hci.rules gefunden. Dort steht in Zeile 15:

Ein kurzer Blick auf die Manpage zeigt, dass der Aufruf nicht korrekt ist. Ich habe die Zeile so abgeändert:

Seit dem funktionieren Tastatur und Maus wieder einwandfrei.

Die Regel deckt einen großen Bereich von Logitech-Produkten ab, das Problem tritt also wohl auch dort auf. Debian-Bugreport kommt dann später noch.

  1. Abziehen und wieder dranstecken. ;) []
  2. zu finden unter /lib/udev/rules.d/ []

Zurück im Jahr 2000 mit fli4l

Ich befinde mich gerade auf den Chemnitzer Linux-Tagen 2010 am Stand von eisfair und fli4l. Unser überaus schicker Standrouter1 ist ein sogenanntes WRAP Board, also schon bisschen abgehangen. Der Hersteller hat hier leider keine Pufferbatterie für die RTC vorgesehen, so dass die Uhr nach jedem Stromausfall am 1.1.2000 um 0:00 (UTC) losläuft.

Nun läuft selbstverständlich fli4l (in der aktuellen Version 3.4.0) auf der Kiste und dort gibt es das Paket (bei fli4l traditionell opt genannt) chrony, was eben chrony bereitstellt, einen kleinen Dienst um die Zeit über NTP abzugleichen. Den Sprung von 2000 auf 2010 möchte der aber nicht automatisch abgleichen, so dass hier ein manueller Eingriff erforderlich ist. Die nötige Prozedur ist leider nicht ganz selbsterklärend, daher hier das kurze HowTo, wie man dort vorgehen kann.

Schritt 1: Den chronyd mit den richtigen Optionen neu starten. Per default wird dort bloß -r gesetzt. Die Option -s erlaubt auch das Setzen der RTC über chrony. Also erstmal per ssh einloggen. Dann:

Schritt 2: Beim chronyd einloggen. Dazu gibt man auf der Shell einfach chronyc ein. Per default darf man dann erstmal fast nichts, aber man kann das vom Paketmaintainer hinterlegte Passwort eingeben, um mehr Rechte zu erlangen. Bitte wie folgt eingeben:

Schritt 3: Die Zeit setzen. Dazu erlaubt man sich das zunächst mal mit dem Befehl manual, dann setzt man die Zeit und dann sagt man ihm noch, dass er das auch der RTC verklickern soll. Beim Setzen der Zeit reicht es das auf eine Minute genau zu machen, den Rest erledigt chrony später ganz normal per NTP.

Bei der Eingabe von settime springt die von chronyd erzeugte CPU-Last auf über 90%. Nach einem weiteren Neustart von chronyd, ist die Zeit gesetzt, ich kann nicht sagen warum, aber der pragmatische Ansatz funktioniert hier. Also:

Jetzt passt schonmal die Systemzeit, ein rtcdata im chronyc zeigt aber noch die alte Zeit der RTC. Also führt man hier nochmal ein trimrtc aus. Die Änderung braucht ein paar Minuten um übernommen zu werden, das geschieht aber dann automatisch.

So, und jetzt wo die Zeit vom Messerouter richtig eingestellt ist, freuen wir uns auf den zweiten Tag hier. Gestern war es schon gut besucht und es waren viele freundliche Interessenten am Stand. Der Sonntag Morgen läuft etwas ruhiger an, da könnte man eigentlich nochmal einen Kaffee trinken …

Update: die so gesetzte Uhrzeit übersteht auch einen Soft Reboot. D.h. wenn man das WRAP hinter eine USV hängt, braucht man die ganze Prozedur nur einmal auszuführen! ;-)

  1. wo alle Besucher nur fragen, wo man die Hardware kaufen kann []