IT-Blog von Sebastian van de Meer

Schlagwort: Fujitsu

NEXT Biometrics NB-2033-U: Reverse Engineering eines Fingerabdrucklesers für Linux

Illustration eines USB-Fingerabdrucklesers mit Linux-Tux und USB-Protokollanalyse (Reverse Engineering NB-2033-U)

Im letzten Beitrag zum Thema hatte ich angekündigt, dass ich mir auch den NB-2033-U vornehmen will. Der steckt in einem zweiten Fujitsu Notebook hier, dem von meiner Tochter Maja. Gleicher Hersteller, gleiche Sensorfamilie, sollte ähnlich laufen wie beim NB-2020-U. Dachte ich.

Falsch gedacht.

Hersteller sagt: geht nicht

Ich hatte bei NEXT Biometrics nach Protokolldokumentation oder einem SDK für den NB-2033-U gefragt. Kevin Hung, Director FAE, antwortete freundlich aber eindeutig:

„Both 2020-U and 2033-U have different firmware and USB stack. The code flow (libusb) related to 2033-U and 2020-U is different. This could be the reason for 2033-U failure/unsupported in linux. As of now, it is not supported.“

Kein SDK, keine Doku, kein Support. Und 74 Einträge auf linux-hardware.org mit Status „failed“ für die USB ID 298d:2033. Weltweit kein Linux-Support für dieses Gerät.

Gut. Dann eben Reverse Engineering.

Erster Versuch: Windows-Treiber belauschen

Plan A war klassisch: Windows-Treiber in einer VM laufen lassen, USB-Traffic mitschneiden. VirtualBox installiert, USB-Passthrough konfiguriert, Windows gestartet. Der Fingerabdruckleser tauchte im Gerätemanager auf. Mit Code 31. Treiber konnte das Gerät nicht starten. Secure Boot hatte VirtualBox den Kernel-Treiber nicht signiert, und der USB-Passthrough war damit unbrauchbar.

Plan A verworfen.

Plan B: Das SDK direkt auf Linux

Das SDK von NEXT Biometrics (libNBBiometrics.so) unterstützt den NB-2033-U intern. Es kommuniziert direkt über libusb, ohne Kernel-Treiber. Das heißt: ich kann das SDK-Sample direkt auf dem Linux-Notebook laufen lassen und gleichzeitig den USB-Traffic mit usbmon mitschneiden.

Dafür musste Secure Boot deaktiviert werden. usbmon ist ein Kernel-Modul, und lockdown=integrity (von Secure Boot gesetzt) blockiert es auch für root. Secure Boot im BIOS aus, lockdown=none in GRUB, Neustart. Danach:

modprobe usbmon
cat /sys/kernel/debug/usb/usbmon/3u > /tmp/capture.txt &
./NBBSample

7654 Zeilen USB-Traffic. Das komplette Protokoll des NB-2033-U, aufgezeichnet während einer Enrollment-Session.

Was dabei rauskam

Das Protokoll ist komplett anders als beim NB-1010-U/NB-2020-U. Kevins Aussage stimmte. Hier die wesentlichen Unterschiede:

EigenschaftNB-1010-U / NB-2020-UNB-2033-U
Bulk IN EndpointEP 3 (0x83)EP 1 (0x81)
Kommandoformat[0x80][CMD][SEQ][0x00]...[CMD][0x00][LEN_LO][LEN_HI][PAYLOAD] (TLV)
Finger-ErkennungEinzelnes 0x38Zwei 0x0D Config + 0x38
Bildübertragung90 Chunks à 540 Bytes180 Chunks à 268 Bytes
InitEinmal 0x07Zweimal 0x07 nötig

Gleicher Sensor-Die (256×180 Pixel, 385 DPI, aktiv thermisch), aber ein komplett anderer USB-Stack. Der NB-2033-U nutzt ein TLV-Format (Type-Length-Value) statt des festen Kommandoschemas vom NB-1010-U. Jedes Kommando hat eine eigene Längenangabe, und die Antworten sind anders strukturiert.

Die Kommandos im Detail

Aus dem USB-Capture konnte ich sechs Kommandos identifizieren:

  • 0x07 — Init/Wake. Muss zweimal gesendet werden, sonst reagiert der Sensor nicht.
  • 0x0D — Sensor-Konfiguration. Wird zweimal vor jeder Finger-Erkennung gebraucht, um den „Enhanced“ Modus zu aktivieren.
  • 0x38 — Finger-Erkennung. Byte 4 der Antwort ist der Detect-Level. Schwellwert 40.
  • 0x12 — Capture starten. Liefert 180 Zeilen à 256 Pixel, 8-Bit Graustufen.
  • 0x13 — Geräteinformationen (Hersteller, Modell, Seriennummer).
  • 0xF7 — Firmware-Version.

Thermischer Sensor: Eigenheiten

Der Sensor misst Temperaturänderungen, nicht statischen Kontakt. Das klingt nach einem Detail, ist aber für die Treiber-Implementierung entscheidend. Finger auflegen erzeugt einen kurzen Spike im Detect-Wert (10 bis 50+). Finger bleibt liegen, und der Wert fällt zurück auf Basisniveau. Der Treiber muss also den Spike erkennen, nicht einen dauerhaften Zustand.

Dazu kommt: Nach dem Init gibt es transiente Spikes, die ungefähr 1,5 Sekunden brauchen, bis sie abklingen. Ohne Settle-Pause nach dem Init erkennt der Treiber Phantom-Finger.

Der Treiber

Rausgekommen ist nb2033.c, ein eigenständiger libfprint-Treiber mit rund 350 Zeilen. Kein proprietärer Code, keine SDK-Abhängigkeit. Das SDK diente nur als Referenz für die Capture-Analyse, der Treiber ist sauber von Grund auf geschrieben. Lizenz: LGPL 2.1+ wie alle libfprint-Treiber.

Die State Machine:

  1. Init (0x07 × 2) mit 1,5 Sekunden Settle-Pause
  2. Finger-Detect-Polling (0x0D + 0x0D + 0x38, Schwellwert 40)
  3. Pre-Capture Config (0x0D)
  4. Capture (0x12) mit 150 ms Pause, dann 180 Zeilen lesen
  5. Bild an libfprint übergeben

Test

Getestet auf Majas Fujitsu Notebook mit Linux Mint 22.3:

$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
[... 5/5 Stages ...]
Enroll result: enroll-completed
$ fprintd-verify
Using device /net/reactivated/Fprint/Device/0
Listing enrolled fingers:
 - #0: right-index-finger
Verify result: verify-match (true)

Richtiger Finger: Match. Falscher Finger: No Match. Enrollment sauber, Verifikation zuverlässig.

Upstream

Der Merge Request ist eingereicht: MR !574 bei libfprint. Fünf Dateien: der neue Treiber, meson.build, autosuspend.hwdb und die Allowlist. CI läuft durch. Der verwandte MR !569 für den NB-2020-U ist noch in Review.

Für die Wiki-Aktualisierung (das Gerät von der „unsupported“ Liste nehmen) gibt es Issue #134.

Fazit

Der Hersteller sagt „not supported“, 74 Linux-User melden „failed“, und trotzdem war das an einem Nachmittag erledigt. SDK auf Linux ausführen, USB-Traffic mitschneiden, Protokoll rekonstruieren, Treiber schreiben, testen, upstream einreichen. Alles mit Open-Source-Tools: usbmon, libusb, libfprint.

Das Ergebnis: Majas Notebook hat jetzt einen funktionierenden Fingerabdruckleser unter Linux. Und sobald der Merge Request durch ist, haben ihn alle anderen auch.

Wie immer: Bei Fragen, fragen.

NEXT Biometrics NB-2020-U Fingerabdruckleser unter Linux zum Laufen gebracht

In meinem Fujitsu Notebook steckt ein Fingerabdruckleser. Ein NEXT Biometrics NB-2020-U, USB ID 298d:2020. Unter Windows funktioniert er, unter Linux nicht. Kein Treiber, kein Support, nichts. Das Gerät taucht in lsusb auf, wird aber von keinem Treiber erkannt. Im libfprint Wiki steht es auf der Liste der nicht unterstützten Geräte. Dort steht es schon eine Weile.

Das hat mich gestört.

Picture of NB-2020-U

libfprint kennt den NB-1010-U. Das ist ein externer USB Fingerabdruckleser von NEXT Biometrics, der seit einiger Zeit einen funktionierenden Treiber hat. Der NB-2020-U ist die eingebettete Variante desselben Sensors, gedacht für den Einbau in Notebooks. Wenn man sich Teardown Reports ansieht, etwa von System Plus Consulting oder Yole Group, dann stellt man fest: Beide Geräte verwenden den identischen Sensor Die. Gleiche Technik, anderes Gehäuse.

Das war der erste Anhaltspunkt. Wenn die Hardware gleich ist, sollte auch das USB Protokoll gleich sein. Und wenn das Protokoll gleich ist, sollte der vorhandene Treiber funktionieren.

Bevor ich aber einfach auf Verdacht losprogrammiert habe, wollte ich es absichern. Ich habe NEXT Biometrics direkt angeschrieben. Kevin Hung, Director FAE bei NEXT Biometrics, hatte mir bereits 2022 auf eine Anfrage zu Linux Treibern geantwortet. Damals war sein Vorschlag, über Fujitsu zu gehen. Das führte ins Leere. Diesmal habe ich konkret angeboten, selbst einen libfprint Treiber zu schreiben, und um das SDK gebeten.

Kevin hat mir daraufhin das NBBiometrics ANF SDK 3.0.0.1384 zugeschickt. Ein komplettes SDK mit Headern, Bibliotheken, Beispielcode und Dokumentation. Das war sehr hilfreich, denn die Header bestätigen einiges. Das SDK nutzt eine einzige Shared Library libNBBiometrics.so für alle Gerätetypen. Der NB-1010-U hat den internen Gerätetyp 200, der NB-2020-U den Typ 202. Beide verwenden dasselbe Scanformat: 180×256 Pixel bei 385 DPI. Die USB Vendor ID ist bei beiden 0x298d, nur die Product ID unterscheidet sich: 0x1010 beim einen, 0x2020 beim anderen.

Wichtig: Das SDK ist proprietär. Für den eigentlichen Treiber habe ich keinen Code daraus verwendet. libfprint akzeptiert nur sauberen, eigenständig entwickelten Code. Das SDK diente ausschließlich als Referenz, um die Protokollkompatibilität zu bestätigen.

Also habe ich es einfach ausprobiert. Den bestehenden nb1010.c Treiber genommen, die USB Product ID 0x2020 zur id_table hinzugefügt und gebaut. Dann auf dem Fujitsu Notebook getestet.

Es funktionierte sofort.

Geräteerkennung, USB Interface Claim, die State Machine für die Fingererkennung, alles lief auf Anhieb. fprintd-enroll hat Fingerabdrücke aufgenommen, fprintd-verify hat sie korrekt verifiziert. Der bestehende Treibercode brauchte keinerlei Anpassungen. Null. Nur die PID in der Tabelle und den Gerätenamen.

Ein Blick auf die USB Deskriptoren bestätigt das Bild. Der NB-2020-U hat exakt dasselbe Endpoint Layout wie der NB-1010-U: Bulk OUT auf Endpoint 0x02, Bulk IN auf Endpoint 0x83. Dazu kommt ein Interrupt Endpoint auf 0x81, den der Treiber nicht verwendet. Die Kommunikation läuft identisch ab.

Der Patch selbst ist entsprechend klein. Drei Dateien, drei Zeilen rein, drei Zeilen raus:

  1. libfprint/drivers/nb1010.c: Die neue PID 0x2020 wird in die id_table eingetragen und der full_name auf "NextBiometrics NB-1010-U/NB-2020-U" erweitert.
  2. data/autosuspend.hwdb: Der Eintrag 298d:2020 wird von der Liste der nicht unterstützten Geräte in die Sektion des nb1010 Treibers verschoben.
  3. libfprint/fprint-list-udev-hwdb.c: Der Eintrag wird aus der Allowlist der nicht unterstützten Geräte entfernt, da er jetzt vom Treiber abgedeckt wird.

Den Merge Request habe ich bei libfprint upstream eingereicht: MR !569. Die CI Pipeline läuft durch, alle 124 Tests bestehen. Jetzt heißt es warten auf das Review durch die Maintainer.

Für alle, die denselben Fingerabdruckleser in ihrem Notebook haben: Sobald der Patch gemergt und in einer neuen libfprint Version enthalten ist, funktioniert der Sensor out of the box. Enrollment und Verifikation über fprintd laufen sauber. Wer nicht warten möchte, kann den Patch auch jetzt schon selbst auf ein aktuelles libfprint anwenden.

Im selben Fujitsu Notebook meiner Tochter steckt ein NB-2033-U, ein weiterer Fingerabdruckleser aus der gleichen Familie. Der verwendet allerdings ein komplett anderes Protokoll und ließ sich nicht einfach mit dem nb1010 Treiber ansprechen. Den habe ich per Reverse Engineering geknackt.

VueScan: Beste Scannersoftware für alte und vielseitige Scanner​

Einen guten Dokumentenscanner zu finden, der auch noch bezahlbar ist, kann schnell zu einer Herausforderung werden. Viele ältere Geräte verlieren nach kurzer Zeit den Support für das nächste Betriebssystem und funktionieren dann nicht mehr. Wenn der Scanner zusätzlich unter Linux reibungslos laufen soll, wird es noch spannender.

Vor vielen Jahren konnte ich mir günstig einen Fujitsu ScanSnap S1500 zulegen. Dieser Dokumentenscanner erfüllt genau meine Anforderungen: Er zieht mehrere Seiten über den automatischen Dokumenteneinzug (ADF) ein, scannt beidseitig, ist schnell und liefert eine gute Auflösung. Wenn ich ihn nicht brauche, lässt er sich genauso schnell zusammenklappen, wie er sich aufstellen lässt, und nimmt kaum Platz auf meinem ohnehin schon überladenen Schreibtisch ein. Ich nutze den Scanner, um meine Post, Rechnungen und andere wichtige Unterlagen zu digitalisieren. Anfangs lief dies noch über eine Windows-VM, da es lange keine wirklich einfache Software für Linux gab, die auf Knopfdruck Dokumente scannt, Texterkennung (OCR) anwendet und alles als durchsuchbares PDF abspeichert. Dieses PDF wandert dann automatisch in meine Nextcloud und hilft mir, Ordnung in meinen Unterlagen zu halten.

Vor etwa anderthalb Jahren stieß ich auf die Software VueScan. Zwar kostet sie etwas, aber für mich ist sie jeden Cent wert. Sie läuft nativ oder als Flatpak auf meinem Linux-System, bietet mehr Funktionen, als ich tatsächlich benötige, und unterstützt eine beeindruckend große Anzahl an Scannern. Sie scannt sogar mein Netzwerk nach anderen Geräten – so läuft auch mein Samsung-Multifunktionsdrucker problemlos damit. Was mich jedoch wirklich beeindruckt, sind die Menschen hinter der Software.

Soweit ich weiß, wird VueScan nur von zwei Leuten entwickelt. Sie reagieren extrem schnell auf E-Mail-Anfragen und bieten hervorragenden Support. Gestern ist die Anwendung zum ersten Mal abgestürzt. Ich konnte sie direkt wieder öffnen, und alles war in Ordnung. Da VueScan den Absturz jedoch selbst erkannte, öffnete sich sofort ein Dialog für einen Fehlerbericht. Das kennt man ja. Ich füllte den Bericht aus und schickte ihn ab – und heute hatte ich bereits eine E-Mail vom Entwickler im Postfach, der mir Unterstützung anbot und weitere Fragen zum Absturz stellte. Diese schnelle, persönliche Reaktion hat mich sehr positiv überrascht.

Klar, mir war bereits aufgefallen, dass VueScan sehr häufig und regelmäßig Updates erhält, aber dass der Entwickler so engagiert dahintersteht, beeindruckt mich wirklich. Das gibt mir ein gutes Gefühl. Die Software ist klasse, der Preis ist in Ordnung (ich habe die Professional-Version), und der Support sowie die Reaktionszeit sind erstklassig. Außerdem unterstützen sie gefühlt jeden Scanner auf diesem Planeten. Und ja, die Software gibt es natürlich auch für Windows und Mac..

Ich muss also nur einmal lernen, wie eine Software funktioniert, und bin dann in der Lage, auf verschiedenen Betriebssystemen und mit verschiedenen Geräten zu arbeiten. Ich möchte ja nicht Experte für x verschiedene Softwarelösungen werden, sondern einfach nur schnell meine Dokumente digitalisieren.

Ich bekomme für diesen Beitrag keinerlei Vergütung oder Ähnliches – ich bin einfach wirklich überzeugt von VueScan. Probiert es doch einfach mal aus, und ich bin gespannt, ob ihr meine Meinung teilt.

Fragen? Einfach melden.

Kabelbruch am Fujitsu Siemens Notebook

Irgendwo hat mein Notebook einen „Wackler oder Kabelbruch“ auf dem Weg zum Display. Fujitsu Siemens NH751… Ich habe das Thema einfach eine Zeit lang ignoriert. Löst natürlich nicht das Problem, ist mir klar.
Wie zu erwarten wurde es nicht besser sondern schlimmer. In der Zwischenzeit war es nicht mal mehr damit erledigt eine „funktionierende“ Kippstellung des Monitors zu finden. Also aufschrauben und nachschauen!

Es scheint wirklich ein Kabelbruch zu sein, irgendwo in der Nähe des rechten Scharniers. Gott ist das Notebook schlecht zu zerlegen. Da hat wohl jemand bei der Konstruktion nicht an Techniker gedacht 🙁

Ich habe 1 Stunde herum gefummelt, bevor ich den Kabelbruch gelötet hatte. Wie auch immer. Inzwischen ist es verlötet und es klappt wieder alles korrekt.

Es ärgert mich denn noch dass bei so vielen Geräten nicht darauf geachtet wird es am Ende reparieren zu können. Sollen wir denn wirklich alles wegwerfen?

 

 

Fragen? Einfach melden.

Wlan-Sicherheit

Veraltet: Dieser Beitrag stammt von 2009 und beschreibt WEP-Cracking mit einem Sharp Zaurus. WEP wird seit über einem Jahrzehnt nicht mehr eingesetzt, WPA2/WPA3 sind Standard. Die Konzepte (Monitoring, Deauthentication, Handshake-Capture) gelten grundsätzlich noch, die gezeigten Tools und Hardware sind aber veraltet.

Wie finde ich heraus ob mein Wlan sicher ist? (Bilder werden beim Anklicken gross.) Hier möchte ich die möglichen „Angriffsmethoden“ zu einem Wlan beschreiben. Am Ende wird jedem Sysadmin dann selbst auffallen, welche Bereiche man am besten wie schützen sollte. Es kommt immer wieder vor, dass Angestellte in der Firma einen AccessPoint aufstellen. Dieses ohne den Admin darüber zu informieren. Was natürlich ein grosses Sicherheitsproblem ist. Daher werde ich zum Anfang erst einmal beschreiben, wie es überhaupt möglich ist ein Wlan zu finden. Alle meine Beschreibungen werden sehr grob ausfallen. Wer sich wirklich mit diesem Thema beschäftigen möchte sollte sich besser selbst mit den Einzelheiten auseinandersetzen. Anhand folgender Ausrüstung, welche ich selbst besitze, werde ich die Beschreibung und meine Beispiele machen. Sharp Zaurus PDA for WLAN security testing Um mich nicht schon beim Suchen mit einem grossen und auffälligen Notebook herumschlagen zu müssen habe ich den Sharp Zaurus SL-5500G mit einer SanDisk CompactFlash 802.11b Low Power Wireless LAN Card. Die Wlan Karte braucht sehr wenig Strom und hat einen Prism II-Chip verbaut. Will man eine Wlan-Karte, welche ohne Probleme mit Linux zusammenarbeiten, sollte man auf diesen Chip achten. Mit Hilfe von meinem kleinen Zaurus kann ich nun sehr bequem und unauffällig durch die Gegend laufen und nach WLANs ausschau halten. Habe ich dort mit Hilfe vom Wellenreiter ein Funknetzwerk gefunden, bekomme ich gleich einige wichtige Informationen. Diese helfen mir dann dabei das Wlan einzuordnen. Hat man ein Netz gefunden, welches interessant ausschaut (meist schon an der SSID zu erkennen), ist es natürlich angenehmer mit einem Notebook zu arbeiten. Auch die Möglichkeiten sind hier grösser. Jetzt gibt es aber wieder Probleme. Mit einem Notebook in der Hand fällt man auf. Man muss sich also in eine Ecke verdrücken. Meist leidet der Empfang darunter. Sitzt man im Auto schirmt das Metall sofort alles ab. Darum gibt es so etwas: WLAN antenna for extended signal reception Links ist ein Standfuss mit Magnet. Dieser hält auch bei 50km/h noch auf dem Autodach. Auf diesen wird nun die Antenne (Mitte) geschraubt. Dieses kann man nun ohne Probleme in die Orinoco Gold PCMCIA-Karte (rechts) stecken, hier ist auch ein Prism II Chip verbaut. Fertig….. Der Empfang ist einfach nur geil. Egal wo man nun genau sitzt! Jetzt fehlt nur noch ein Notebook. Notebook running WLAN security tools Ich nutze ein Fujitsu Siemens LifeBook E 7110! Linux arbeiten mit allen Komponenten in diesem Notebook ohne Probleme und gebastel zusammen. Um Funknetzwerke zu finden, muss die Wlan-Karte in den Monitor Mode gesetzt werden. Im Monitor Mode nimmt die Karte alle Packet an. Egal aus welchem Netz sie kommen und egal für wen sie bestimmt sind. Der Standart Linux-Kernel kann die Karte nicht in den Monitor Mode setzen. Dieser muss also gepatch werden oder es muss ein passendes Kernelmodul erstellt werden. Am einfachsten geht es so: 0. Mit iwpriv schauen ob der eigene Kernel vielleicht schon gepatcht wurde! 1. Quellen des aktuellen Kernels installieren. 2. gcc installieren. 3. Die aktuelle Konfiguration des Kernels ins root der Kernelquellen legen. Unter Suse: zcat /proc/config.gz > .config Als Root unter /usr/src/linux 4. Saug dir hier die Datei orinoco-0.13e-SN-5.tar.bz2 5. Datei schön entpacken! 6. Als Root-User folgendes im root des Kernelmodules tippern: make modules; make install 7. alle Dateien mit der Endung ko in /lib/modules/dein-aktueller-kernel/drivers/net/wireless kopieren. Vorher Sicherung davon machen, da du einiges überschreiben musst! 8. Neustarten oder die Module entladen und laden. Jetzt sollte nach der Eingabe von „iwpriv“, beim Teil der Wlan-Karte der Monitor Mode auftauchen. Um mit dem Notebook nun nach Wlans zu suchen, nutzt man am besten das Programm Kismet. Kismet wireless network scanner interface Dieses sollte vorher noch konfigurieren werden;-). Es gibt unter /etc/kismet/ die Datei: kismet.conf. In dieser müssen wir zwei Änderungen vornehmen. Beim Punkt „suiduser=“ tragen wir hinter dem = unseren Usernamen ein mit dem wir auf der Linux Kiste arbeiten. Am Punkt „source=“ tragen wir hinter dem = folgendes ein: orinoco,eth1,orinocosource Wobei wir eth1 natürlich gegebenenfalls gegen unsere Wlan-Karte austauschen! Ein „sudo kismet“ in der Userkonsole sollte nun das Programm starten und sogleich nach Netzen suchen. Haben wir eines gefunden und wollen erst einmal nachschauen, was genau dort durch die Gegend fliegt. Brauchen wir dazu ein Programm mit dessen Hilfe wir den Datenstrom auslesen können. Dieses erledigt Ethereal super. Später ist es auch drin, mit diesem Programm sehr komplexe Filterungen auf den Datenstrom anzuwenden. Da wir aber nur die Daten annehmen können welche auf unserem Channel gesendet werden. Betreibt Kismet Channelhopping. D.h.: Kismet springt im ms. Takt vom Einen in den Anderen Channel. Wenn wir einen konstanten Datenstrom mitlesen wollen, ist das scheisse! Wir können dann ja nur die Daten mitlesen, wenn wir auch gerade im passenden Channel sind. Daher beenden wir Kismet und setzen die Karte von Hand in den Monitor Mode und den passenden Channel. Dieses geht als User-Root so: iwpriv eth1 monitor 1 1 eth1 ist in diesem Fall die Wlan-Karte, mit monitor 1 sagen wir das der Monitor Mode gestartet werden soll (mit iwpriv eth1 monitor 0 würden wir ihn also wieder beenden) und die letzte 1 gibt den Channel an, in welchem die Karte gesetzt werden soll. Ethereal network traffic monitor capturing packets Ethereal kann nun mit den im Bild angezeitgen Optionen gestartet werden. Nun würde Ethereal JEDES Datenpaket welches im Channel 1 durch die Gegend fliegt auffangen und speichern. Sollte auf dem AccessPoint eine Mac-Adressenfilterung eingerichtet sein, so müssen wir uns um diese nicht weiter kümmern. Wir versuchen uns ja nicht am AP anzumelden, sondern hören ja einfach nur zu. Interessant wird es erst, wenn das Netzwerk die Daten verschlüsselt überträgt. Wir bekommen zwar immer noch alles, können damit aber nichts mehr anfangen. Es ist aber Möglich WEP-Verschlüsselungen aufzubrechen, den Schlüssel zu errechnen. AirSnort WEP key recovery tool AirSnort ist ein Programm welches genau das macht. Es kann die Karte in den Monitor-Mode packen. Wenn vom User gewünscht auch gleich noch in den passenden Channel. Ab diesem Zeitpunkt sammelt Airsnort die verschlüsselten Packete. Bei einer 128 Bit WEP Verschlüsselung muss es ca. 6 Millionen Pakete sammeln. Das liegt daran, dass für die WEP Verschlüsselung nur ein begrenzter Zufallszahlenraum zur Verfühgung steht. Nach ca. 6 Millionen Paketen wiederholen sich in jedem Fall Teile. Mit diesen kann AirSnort nun rechnen. Hat AirSnort den Schlüssel erfolgreich errechnet, tragen wir ihn einfach mit iwpriv bei unserer Wlan-Karte ein und schon kann es weiter gehen! WEP Verschlüsselungen mit einer Stärke von 256 Bit sind im Vergleich noch sehr sicher. Es würde eine sehr lange Zeit dauern die notwendigen Pakete zu sammeln. Leider arbeiten kaum Karten mit 256 Bit WEP Schlüsseln. Es gibt auch eine neue Methode: WPA… WPA gilt bisher als sicher. Ich stufe mein Wlan immer noch als ein feindliches Netz ein. So behandelt es auch meine Firewall und so sollte es jeder Admin behandeln. Es ist und bleibt wohl noch über lange Zeit ein grosses Sicherheitsproblem. Genauere Fragen zu diesem Thema beantworte ich gerne per E-Mail! Solltest du Fragen stellen achte bitte darauf deine Frage so genau wie irgend möglich zu stellen. Beschreibe kurz dein Problem, haue mich nicht mit log und configs zu und habe etwas Geduld. Ich bekomme nicht nur eine E-Mail am Tag. Darum werde ich ganz sicher nicht auf unfreundliche und ungenaue Fragen antworten. KEINER hat ein Recht drauf von mir Support zu bekommen!!

Fujitsu Siemens Lifebook E7110: Linux auf einem Pentium 4-M Notebook

Dieser Beitrag ist ein Zeitdokument von 2009. Das Lifebook E7110 war damals schon alt, die Tipps sind heute nur noch historisch interessant. Aber wer wissen will, wie Linux auf einem Pentium 4-M Notebook mit Gentoo, Kernel 2.6.12 und PCMCIA lief, ist hier richtig.

Ich habe mir das Fujitsu Siemens Lifebook E7110 angeschafft. Mitgeliefert wurde Windows XP Professional, was natürlich nicht lange auf dem Gerät überlebt hat. Ungefähr so lange, bis ich es in Händen gehalten habe. Installiert habe ich sofort Linux. Da ich mich vor dem Kauf über die Hardware informiert hatte, lief auch so ziemlich alles.

Hardware-Kompatibilität

StatusGerätDetails
JaProzessorIntel Mobile Pentium 4-M, 2,0 GHz
JaChipsatzIntel 845 MP
JaSpeicher1 GB DDR-RAM
JaGrafikATI Radeon M 7500, 32 MB DDR (dedicated)
JaDisplay15,1″ SXGA+ (1024×786)
JaSoundSigmaTel STAC9767, SB Pro kompatibel
JaEthernetRealtek 8139/8139C
JaWLANPrism2 (InterSil), MiniPCI
JaUSBIntel 845-MP 82801CA
JaIEEE 1394Texas Instruments TSB43AA21
JaIrDASMSC LPC47N267
JaCardBusO2Micro OZ 711 E1
JaDVD-ComboToshiba SD-R2212
JaTV-OutS-Video (über atitvout)
JaACPIPhoenix ACPI, Suspend funktioniert
TeilweiseModemV.90 Mini-PCI (nie getestet, nicht gebraucht)
NeinSondertasten5 Tasten, unter Linux nicht nutzbar

Festplatten-Tuning

Die originale Toshiba MK4018GAS (40 GB) habe ich gegen eine Hitachi Travelstar 7200 RPM (60 GB) getauscht. 40 MB/s statt 26 MB/s. Dazu noch etwas hdparm-Tuning:

hdparm -d1 -c1 -A1 -m16 -u1 -a64 -k1 /dev/hda

WLAN-Firmware

Die Prism2-Karte von InterSil kam mit einer alten Firmware (~1.4.1). Damit gab es defekte Pakete und kein Hidden ESSID. Erst ab Firmware 1.7.4 lief alles sauber. Das Flashen war etwas abenteuerlich, hat aber funktioniert.

Bluetooth und SmartCard

Bluetooth per USB-Stick (MSI BToes) lief sofort. Hauptnutzen: SMS verschicken und das Sony Ericsson T610 synchronisieren. Später kam eine 3COM Bluetooth PCMCIA-Karte, die direkt mit dem Kernel-Treiber funktionierte.

Der mitgelieferte O2Micro SmartCard Reader (PCMCIA) brauchte den MUSCLE-Treiber und pcsc-lite. Die Konfigurationsdatei musste manuell in die PCMCIA-Config kopiert werden, dann lief auch das.

Das System

Gentoo Linux mit Kernel 2.6.12 und KDE. Der Kernel war sorgfältig auf das Notebook zugeschnitten. Ab Kernel 2.6.13 gab es Probleme mit dem neuen PCMCIA-Subsystem (pcmciautils statt cardmanager), deshalb bin ich bei 2.6.12 geblieben.

Wer noch mehr mit WLAN-Hardware experimentieren will: Im Beitrag D-Link DWL-900AP+ aufbohren geht es darum, die Sendeleistung eines Access Points per Lötkolben zu erhöhen.

Fragen? Einfach melden.

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑