Die Platte in Tokyo einhängen

Die Idee ist schon fast zehn Jahre alt, aber es hat wohl eine Weile gedauert bis es funktioniert hat. Der Traum in Tokyo ein USB-Gerät in einen PC zu hängen und in Kenia zu benutzen, funktioniert tatsächlich. Die Lösung lautet: USBIP

Wie funktioniert das ?

Es gibt einen USBIP-Server und einen Clienten. Der Server bindet Geräte ein und stellt Sie im Netz zur Verfügung. Der Server sorgt auch dafür, daß das Gerät lokal nicht mehr zur Verfügung steht. Damit kann es bei der Benutzung keine Kollisionen geben. Der Client verbindet sich zum Server und bindet das USB-Gerät dann lokal ein und stellt es, wie jedes andere Gerät zur Verfügung.

Damit das funktioniert müssen einige Kernel-Module geladen werden. Praktischerweise ist alles was man so braucht im Paket dabei. Alles in allem ein ziemlich übersichtlicher Vorgang.

Die Installation

Die Installation ist ganze einfach:

sudo dnf -y install usbip

Das wars schon.

WARNUNG

Wie man im Beispiel sehen wird, greifen die Befehle direkt auf IP Adressen zu. D.h. wenn Ihr ein Gerät freigebt, kann jeder, der es über das Netzwerk erreichen kann, es auch benutzen. Das kann im Einzelfall ein Problem werden. Daher ist eine Begrenzung des Zugriffs per IP-Firewall zwingend notwendig.

Der USBIPd stellt die Option zur Verfügung, sich auf einen bestimmten Port zubinden :

–tcp-port PORT Listen on TCP/IP port PORT.

Damit kann man, zumindest theoretisch, mehrere Dienste parallel benutzen und somit die Freigabe per Firewall regeln.

Beispiel – Eine Kamera benutzen

Der Server hat IP 192.168.0.103. Auf dem wurden zur Vorbereitung folgende Befehle ausgeführt:

[root@warrior marius]# modprobe usbip-host
[root@warrior marius]# usbipd &

nun müssen wir natürlich noch wissen, welches Device wir überhaupt freigeben müssen:

[root@warrior marius]# usbip list -l
– busid 2-3 (0ac8:0302)
Z-Star Microelectronics Corp. : ZC0302 Webcam (0ac8:0302)

[root@warrior marius]# usbip bind -b 2-3
usbip: info: bind device on busid 2-3: complete

„usbip list -l“ listet die zur Verfügung stehenden lokalen Geräte auf.
„usbip bind -b 2-3“ bindet das USB Gerät mit der ID 2-3 an den usbipd, so daß es exportiert werden kann.

Auf der Clientseite ist das ähnlich einfach:

[root@eve marius]# modprobe vhci-hcd

Das Kernelmodul i.d.R. immer nötig, es können aber auch andere Module zusätzlich benötigt werden.

[root@eve marius]# usbip list -r 192.168.0.103
Exportable USB devices
======================
– 192.168.0.103
2-3: Z-Star Microelectronics Corp. : ZC0302 Webcam (0ac8:0302)
: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3
: (Defined at Interface level) (00/00/00)

Wie man sehen kann, ist das Gerät jetzt verfügbar. Nun müssen wir es noch lokal einfügen:

[root@eve marius]# usbip attach -r 192.168.0.103 -b 2-3

und nun können wir es benutzen, da es wie jede andere WebCam als Videogerät zur Verfügung gestellt wurde:

[root@eve marius]# camorama -d /dev/video0
… jede Menge unnötige Fehlermeldungen später …
name = medium
name = large

Wenn man es wieder abmelden will, muß man den lokalen USBIP Port kennen:

[root@eve marius]# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at Full Speed(12Mbps)
Z-Star Microelectronics Corp. : ZC0302 Webcam (0ac8:0302)
12-1 -> usbip://192.168.0.103:3240/2-3
-> remote bus/dev 002/004
[root@eve marius]# usbip detach -p 00
usbip: info: Port 0 is now detached!

Das wars. Jetzt noch auf dem Server mit unbind entfernen:

[root@warrior marius]# usbip unbind -b 2-3
usbip: info: unbind device on busid 2-3: complete

und das Gerät ist wieder lokal benutzbar.

Anwendungen

Per SSH-VPN könnte man damit z.b. WebCams in Rechenzentren benutzen, oder Festplatten einbinden, die vollverschlüsselt sind, auch wenn der „Server“ kompromittiert wurde, denn die Verschlüsselung läuft auf dem lokalen Rechner, ein MITM-Angriff kann damit nicht stattfinden. USB-Tastaturen und Mäuse würden auch lustige Sachen erlauben 😉

Zeit für Artikelbashing on How to Forge

Kleiner Disclaimer, es geht nicht um den Inhalt, sondern rein um die Darstellung.

Dieser Beitrag:

https://www.howtoforge.com/tutorial/encrypt-usb-drive-on-ubuntu/

von dem Ihr eine Variante hier findet: Mit LUKS einen USB Stick verschlüsseln mit der Fortsetzung Wie man besser USB Sticks verschlüsselt mit Linux und Double Layer Encryption mit Veracrypt. Letzterer Link beantwortet dann auch spontan die Frage des (bislang) einzigen Kommentators des HtF Artikels, wie man das Windows-kompatibel bekommt. Kurzform: LUKS ist Open Source und es gibt für Windows einen Luks mounter, ergo ist es bereits kompatibel, wenn man als Filesystem nicht EXTx benutzt, sondern NTFS. Wie sinnvoll das ist, laß ich mal im Raum stehen.

Problem

So, How-To-Forge … Wer sich den Artikel ansieht muß zwangweise drüber stolpern: Der hat die Bilder echt mit dem Handy vom Monitor abfotografiert 😀

Grund: Er wollte zeigen, wie die Aufklappmenüs aussehen, wenn man mit der Maus arbeitet, konnte es aber nicht, weil SEIN Desktop das Auslösen per STRG+DRUCK verhindert, wenn das aufgeklappt ist.

Lösung

Den Screenshot per Konsole zeitverzögert auslösen.

so macht mans richtigAlso einfach eine Konsole öffnen und folgenden Befehl eintippen:

gnome-screenshot -p -w -d 5

Das gibt Euch 5 Sekunden Zeit, das Menü auszulösen und den Zeiger in Position zu bringen. Die Zeit kann beliebig angepaßt werden.

Alternative

Macht mit SimpleScreenRecord einfach ein Video und extrahiert das Bild dann da raus 😉

Kommentar

How-To-Forge Monetarisierung an Hand von Links gezeigt

Von einem How-To-Forge Autor hätte ich mehr erwartet, als ein wackliges Handyfoto. How-To-Forge stand mal für eine Adminseite, auf der Profis gezeigt haben, wie es geht. Heute steht das für : Ich verkauf Euch an Google+ Facebook und Konsorten. (Tip: Schaut nur nicht in die Noscript Liste des Grauens rein )

Irgendwie fühle ich mich an die Youtube-Videos errinnert, wo Kinder anderen Kindern zeigen wollen wie es geht und dann mit dem  Satz „Heute zeige ich Euch mal wie..“  anfangen und komplett triviale Sachen verkacken.. Das bringt einen direkt zur Debatte um den CoC, Linus und seine Auszeit und wie Leute die Codequalität unwichtiger einstufen, als den Umgang mit „in Ihren Fähigkeiten am anderen Ende der Kette gehenden Personen“.

Wenn es einer sanft nicht versteht, muß man ihn auch mal anbrüllen dürfen, damit er kapiert, daß es Scheisse war. Die Alternative ist nämlich noch schlimmer: Kick ohne Begründung. Dabei lernt man nämlich nichts aus seinen Fehlern, fühlt sich ungerecht behandelt und verbessert sich nicht.

 

 

How-To-Forge : NoScriptversion .. urgs..

Leider, um den Bogen zurück zu HtF zu schlagen, konnte ich ohne die Werbebeacons, Googletracker, Facebookbuttons zu aktivieren, dort keinen passenden Kommentar zu der Qualität abgeben. Ansonsten wären die Bilder da nämlich jetzt schon weg, ein Ego geknickt, aber ein Mensch auf den richtigen Weg gebracht 😀

Kleines Update:

TOR ist ja unser Freund, also habe ich da mal das Tracking umgangen 🙂

Klickt mal auf die Bilder, da wird einem übel 🙁

 

Alle Tracken einen wegen Werbung, die man nicht will, für Produkte, die man nicht braucht. Alles im Namen des heiligen Commerzius.

Es gibt Hoffnung

Auch auf How-To-Forge gibt es noch Hoffnung, daß alles besser wird 🙂

Diesen Artikel fand ich jetzt schon viel informativer, als den über den USB Stick:

https://www.howtoforge.com/tutorial/passwordless-encryption-of-linux-root-partition/

Das werde ich mir für Fedora auch mal ansehen, ist natürlich obercoolio wenn Du statt ein Passwort einzutippen, bei dem man Dich beobachten kann, einen USB Stick einsteckst. Dabei kann man einen auch beobachten, seinen Schluß ziehen, den Einen dann um den USB Stick und das Laptop erleichtern und schön auf alles zugreifen.

Nein, das ist leider keine Fantasie, so was passiert laufend. ABER, wenn man sich einen RFID unter die Haut implantiert und als menschlicher Mobilfunkmast durch die Gegend läuft (ja, natürlich ist das übertrieben), dann sieht wenigstens keiner wie das Laptop aufgeht, schlitzt einem nicht die Hand auf beim Diebstahl und es könnte trotzdem mit der automatischen Entschlüsselung klappen.

Man muß immer noch einen kleinen Stecker im USB Port haben, weil RFIDs können nur die wenigstens Laptops lesen (afaik gar keine), aber den halten Angreifer dann wenigstens genau für so einen USB-KEY-Dongle, klauen den mit, stellen fest, daß es doch nicht geht und formatieren dann die Platte ohne an den Finger und die Daten gekommen zu sein. Das wäre dann ein Erfolg 😀

Fiktiver Grenzübertritt in die USA

Jetzt stellen wir uns mal ganz blöd an die US-Einreise-Schlange am New Yorker Flughafen, haben ein Laptop, einen RFID-zu-USB-Stick und einen Finger dabei. Der Einreisebeamte sieht das Laptop, geht damit weg, kommt nach 30 Minuten wieder und fragt nach dem Passwort. Man gibt es ihm nicht. Der Mann schleift einen in einen Raum, setzt einen vor das Laptop und sagt „mach auf“. Man sagt: „nö“.

Der Typ schaltet das Laptop ein, das vorher nicht wollte und ohhhhhhhh…. es geht… Ein Wunder! Alle reiben sich verdutzt die Augen! Der Typ im Nebenraum an der Kamera, der als Backup für seinen Kollegen mit Knarre an der Hüfte bereitsteht, traut seinen Augen nicht und ruft das SEK, weil das ja ein Laptop von einem Terroristen oder anderem Schwerkriminellen sein muß. 1 Minute später steht Ihr auf der Fahnungsliste der meistgesuchten Verbrecher, damit Sie das, was dann folgt, auch begründen können 🙂 Naja, so oder so ähnlich 😀

Glaubt Ihr nicht?

https://www.theatlantic.com/technology/archive/2016/05/iphone-fingerprint-search-warrant/480861/

Ist natürlich nicht ganz so wie in meiner kleinen Fanatasie, aber die sollte ja auch nur das Problem verdeutlichen. Kurzfassung: Frau + Iphone + Gerichtsbeschluß, daß Sie Ihr IPhone per Fingerprint entsperrt.

Problem: Man muß sich in einem Rechtsstaat nicht selbst belasten. Wenn ich gezwungen werde, Beweise herzuschaffen, welche die Ankläger gegen mich benutzen können, ist das eine Selbstbelastung und die darf der Staat nicht durchsetzen. Der Staat/Ankläger muß mir ein Verbrechen / Tat beweisen, nicht ich.

Wenn ich also mit einem RFID als Fingerabdruckersatz in der Hand durch die Gegend laufen und durch Handauflegen mein Handy/Laptop entsperren kann, dann wäre das eine Selbstbelastung, wenn der Staat mich genau dazu zwingen würde.

Jetzt mal rein praktisch: Securityrules für Dummies

1. Ein Passwort, daß ich durch die Gegend schleppe, ist kein Passwort

Es entfallen alle Arten von Biometrie.
Es entfallen alle Arten von Geräten wie RFID, USB-Sticks etc.

Kann man alles nachbilden und von außen aufzeichnen. Das kann ich nicht verhindern.
Man kann im Falle der Biometrie den Organismus auch passive zur Authentifizierung nutzen, da ja nur die Anwesenheit des Merkmals nötig ist, nicht die Motivation des Merkmalträgers.

2. eine Zwei/Drei-Faktor-Authentifizierung wäre hilfreich

Wenn ich eine davon preisgeben muß ( meine Hand mit dem RFID drin z.b. ) dann, bleibt noch min. eine andere Information zum Schutz übrig.

3. „Nur was im Hirn gespeichert ist, ist sicher.“

Problem: Ich muß es irgendwann eingeben. Dabei könnte ich …

… optisch beobachtet werden : kann man verhindern
… digital abgehört werden : kann man verhindern
… ich könnte es vergessen : kann man auch verhindern.
… ich könnte gezwungen werden es preiszugeben: kann man nicht immer verhindern.

Ich könnte lügen. Der Angreifer kann es nur prüfen, indem er es eingibt. Wenn es nicht stimmt, dann droht mir was, ok, aber DAS SZENARIO kann man mit einer Partition mit Fakedaten verhindern, die mit dem falschen Passwort geöffnet werden kann. Das kann der Angreifer nicht mehr so ohne weiteres prüfen.

Da kommt TrueCrypt ins Spiel. Das hatte extra Hidden Volumes im Einsatz, welche die echten Daten hatten und normale Partitionen, falls man mal gezwungen wird, etwas preiszugeben.

Die Option fällt natürlich weg, wenn man den richtigen Key per RFID aussendet. Könnte schwierig werden, das per RFID kontrollierbar für den Anwender zu machen. Ich halte es ja eh für eine blöde Idee 🙂

 

es geht um scrcpy

Heute solls um ein kleines Projekt namens „scrcpy“ gehen. Das ist jetzt kein L33t-Speak ;), sondern stand wohl mal für „screen copy“, denn genau darum geht es: Eine Bildübertragung vom Handy zum PC – Live.

„scrcpy“

Das Projekt gibt es bei GitHUB im Genymobile Repo und man muß es selbst zusammen häkeln. Das stellt natürlich eine gewisse Hürde dar, daher hier eine kleine Hilfe, was man machen muß :

Schritt 1: Buildtools installieren

Dazu bitte als Root ausführen:

Wer noch kein RPMFusion für Fedora aktiviert hat, könnte es machen:

# enable RPM fusion free
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

Ansonsten braucht Ihr nur das hier:

dnf install SDL2-devel ffms2-devel meson gcc make java

Schritt 2 – Sourcen laden

Zunächst machen wir uns mal ein neues Arbeitsverzeichnis:

[marius@eve Programme]$ mkdir scrcpy
[marius@eve Programme]$ cd scrcpy/

Dann laden wir die Sourcen von dem Programm via git herunter:

[marius@eve scrcpy]$ git clone https://github.com/Genymobile/scrcpy
Klone nach ’scrcpy‘ …
remote: Counting objects: 2441, done.
remote: Total 2441 (delta 0), reused 0 (delta 0), pack-reused 2441
Empfange Objekte: 100% (2441/2441), 539.98 KiB | 1.27 MiB/s, Fertig.
Löse Unterschiede auf: 100% (1417/1417), Fertig.

Nun brauchen wir noch den Server ( den kaputten Buildprozess für den Server überspringen wir hier, da es einen PreBuild-Server gibt, aber wir brauchen trotzdem einige Files aus dem Buildprozess):

[marius@eve scrcpy]$ wget https://github.com/Genymobile/scrcpy/releases/download/v1.3/scrcpy-server-v1.3.jar

Schritt 3 – Umgebung bauen:

[marius@eve scrcpy]$ cd scrcpy
[marius@eve scrcpy]$ meson x –buildtype release –strip -Db_lto=true
The Meson build system
Version: 0.47.1
Source dir: /home/marius/Programme/scrcpy/scrcpy
Build dir: /home/marius/Programme/scrcpy/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: undefined
Native C compiler: cc (gcc 7.3.1 „cc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)“)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency libavformat found: YES 57.71.100
Native dependency libavcodec found: YES 57.89.100
Native dependency libavutil found: YES 55.58.100
Native dependency sdl2 found: YES 2.0.7
Configuring config.h using configuration
Program ./scripts/build-wrapper.sh found: YES (/home/marius/Programme/scrcpy/scrcpy/server/./scripts/build-wrapper.sh)
DEPRECATION: build_always is deprecated. Combine build_by_default and build_always_stale instead.
Build targets in project: 6
Found ninja-1.8.2 at /usr/bin/ninja
[marius@eve scrcpy]$ cd x
[marius@eve x]$ ninja
[30/31] Linking target app/scrcpy.

Wenn Ihr das hier lest:

[31/31] Generating scrcpy-server with a custom command.
FAILED: server/scrcpy-server.jar
/home/marius/Programme/scrcpy/scrcpy/server/./scripts/build-wrapper.sh ../server/. server/scrcpy-server.jar release
Downloading https://services.gradle.org/distributions/gradle-4.4-all.zip

und dann jede Menge Gradle-Schrottdownload-Meldungen erscheinen, hats mit dem eigenen Server nicht geklappt und es kommt der nächste Schritt:

Den Scheiss wieder löschen 😉

Das Ihr hier andere Pfade habt, muß ich glaube ich, nicht extra erwähnen, oder ? 😉

[marius@eve x]$ cd ..;rm -rf x
[marius@eve scrcpy]$ meson x –buildtype release –strip -Db_lto=true -Dprebuilt_server=/home/marius/Programme/scrcpy/scrcpy-server-v1.3.jar
The Meson build system
Version: 0.47.1
Source dir: /home/marius/Programme/scrcpy/scrcpy
Build dir: /home/marius/Programme/scrcpy/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: undefined
Native C compiler: cc (gcc 7.3.1 „cc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)“)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency libavformat found: YES 57.71.100
Native dependency libavcodec found: YES 57.89.100
Native dependency libavutil found: YES 55.58.100
Native dependency sdl2 found: YES 2.0.7
Configuring config.h using configuration
Build targets in project: 6
Found ninja-1.8.2 at /usr/bin/ninja
[marius@eve scrcpy]$ cd x
[marius@eve x]$ ninja
[31/31] Linking target app/scrcpy.

Schritt 5 – Installieren

[marius@eve x]$ sudo ninja install
[sudo] Passwort für marius:
[0/1] Installing files.
Installing app/scrcpy to /usr/local/bin
Stripping target ‚app/scrcpy‘
Installing server/scrcpy-server.jar to /usr/local/share/scrcpy

Schritt 6 – Starten

Trommelwirbel und …

und wie man an dem Bild schon sehen, daß Ganze funktioniert nur, wenn man in den Entwicklereinstellungen des Handies das USB-Debugging erlaubt.

man sieht die Android Oberfläche mit Icons

Nun kann man, wenn man kann, mit der Maus das Handy auf dem PC fernsteuern, Eingaben machen, Programme starten, Surfen, Spielen, Videos schauen und mit SimpleScreenRecorder auch Tutorials vom Handy aufnehmen.

Wenn das böse Wenn nicht wär.

Die Sache mit dem Wenn man kann ist fies. Die Verbindung zu meinem Handy lebt nur wenige Sekunden, aber andere Handies bekommen das auch dauerhaft hin, wie Malte aus unserer LUG neulich demonstriert hat.

Es kommt also auf das Android ROM an, das auf dem Handy läuft. Wer eine Alternative sucht, kann Teamviewer für Android nutzen, das bekommt das deutlich stabiler auch auf einem Stock-ROM hin. Aber wer weiß dann schon, wer da mitliest.

Am Ende dann nicht vergessen den Gradle Kram wieder zu entfernen: rm -rf ~/.gradle