PinePhone GPS / WWAN / LTE-Modem
Bei der Entwicklung von Software auf PinePhone stieß ich auf eine merkwürdige Nachricht in
dmesg
:
[ 25.476857] modem-power serial1-0: ADB KEY is '41618099' (you can use it to unlock ADB access to the modem)
Zum Kontext möchte ich sagen, dass das PinePhone über ein Quectel EG25-G- Modem verfügt , das für das GPS und die drahtlose Kommunikation des PinePhone verantwortlich ist. Diese Hardware ist eine der wenigen Closed-Source- Telefonkomponenten .
Als ich diese Nachricht und die Erwähnung von ADB sah, dachte ich sofort an die Android Debug Bridge, dh die Software, die üblicherweise für die Kommunikation mit Android-Geräten verwendet wird. Ich dachte: "Natürlich kann dies nicht dieselbe ADB sein." Nun, es stellt sich heraus, dass es so ist.
Diese Nachricht bezieht sich auf einen Artikel , in dem dieses Modem beschrieben wird. Es ist auch mit einem Entsperrdienstprogramm verknüpft , das AT-Befehle zum Sichern des
adbd
Modems ausgibt .
$ ./qadbkey-unlock 41618099
AT+QADBKEY="WUkkFzFSXLsuRM8t"
AT+QCFG="usbcfg",0x2C7C,0x125,1,1,1,1,1,1,0
Sie können an das Modem gesendet werden, indem Sie
screen
:
# screen /dev/ttyUSB2 115200
Aus irgendeinem Grund gab meine Eingabe keine Daten zurück, aber die Bildschirmsitzung gab zweimal "OK" zurück, was darauf hinweist, dass die Befehle erfolgreich ausgeführt wurden.
Nach dem Einrichten der Regeln
udev
und
adb
auf meinem "Host-Computer", dh auf dem PinePhone, begann das Modem mit der Ausgabe, für
adb devices
die ich an die Shell senden konnte:
$ adb devices
List of devices attached
(no serial number) device
$ adb shell
/ #
Da ich
adbd
als Root ausgeführt wurde, habe ich die Ausgabe an die Root-Shell weitergeleitet. Ausgezeichnet.
Es stellte sich heraus, dass das Modem ein eigenes Betriebssystem ausführt, das völlig unabhängig vom Rest des PinePhone-Betriebssystems ist. Mit den neuesten Updates läuft Linux 3.18.44.
Starten des Webservers
Aus irgendeinem Grund dachte ich, es würde Spaß machen, mein Blog auf diesem Gerät zu betreiben. Da wir mit begrenzten Ressourcen arbeiten (ca. 48 MB Speicherplatz und dieselbe Speichermenge) und mein Blog nur aus statischen Seiten besteht, habe ich beschlossen, dass so etwas wie Nginx (egal wie leicht) für meinen Zweck eine Verschwendung von Ressourcen wäre ...
Es schien mir, dass darkhttpd meine Anforderungen gut erfüllte . Einzelne Binärdateien, keine externen Abhängigkeiten, führen nur GET- und HEAD-Anforderungen aus. Im Idealfall.
Ich habe die Toolchain armv7l -linux-musleabihf-cross verwendet , um diesen Server für ARMv7 zu kompilieren, und ihn statisch mit musl verknüpft. Mittels
adb push
Es gelang mir problemlos, die Binärdatei und die Ressourcen meiner Site in den Modemordner zu übertragen
/usrdata
, in den eine 50-MB-Partition mit Schreibfähigkeit eingehängt ist.
Der HTTP-Server funktioniert hervorragend. Ich habe mich entschieden, ADB zu verwenden, um den HTTP-Port für mein PinePhone zu öffnen:
$ adb forward tcp:8080 tcp:80
Da ADB-weitergeleitete Ports nur an die Loopback-Schnittstelle gebunden sind, habe ich sie manuell für externe Verbindungen geöffnet:
# sysctl -w net.ipv4.conf.all.route_localnet=1
# iptables -t nat -I PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 127.0.0.1:8080
Dann konnte ich auf meinen Blog unter zugreifen
http://pine:8080/
. Cool!
Performance?
Ich habe die
iperf
ADB-Portweiterleitung ausgeführt, um zu sehen, wie viel Leistung ich erhalten habe.
$ iperf -c localhost
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 44230 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.6 sec 14.4 MBytes 11.4 Mbits/sec
Das sind ungefähr 10 Mbit / s. Nicht großartig, nicht schrecklich.
Das PinePhone selbst ist über USB mit dem Netzwerk verbunden (Hinweis: Damit die USB-Netzwerkverbindung funktioniert, musste ich zwei Komponenten von der Karte entfernen ). Aus Gründen des Interesses bin ich auch
iperf
für diese Verbindung gelaufen :
$ iperf -c 10.15.19.82
------------------------------------------------------------
Client connecting to 10.15.19.82, TCP port 5001
TCP window size: 136 KByte (default)
------------------------------------------------------------
[ 3] local 10.15.19.100 port 58672 connected with 10.15.19.82 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.4 sec 25.8 MBytes 20.7 Mbits/sec
Ich habe mehr erwartet, aber das spielt keine Rolle, da der Engpass darin besteht, dass die Verbindung über ADB umgeleitet wird.
Andere Argumentation
Ich habe mich über die Sicherheit des Modems gewundert. Es stellte sich heraus, dass viele AT-Teams
system()
. Ich vermute, dass einige dieser AT-Befehle für die Befehlsinjektion anfällig sind, aber ich habe keine weiteren Untersuchungen durchgeführt. Es spielt keine Rolle, da die ADB-Root-Shell sehr einfach zu implementieren ist.
Auf den ersten Blick scheint dies ein idealer Weg zu sein, um die Ausfallsicherheit von Schadcode sicherzustellen. Mit dem Root-Zugriff auf den Host kann sich bösartiger Code in das Modem einbetten, sodass er die Neuinstallation des Host-Betriebssystems überlebt, die Kommunikation abfängt oder den Standort des Geräts verfolgt. Der Schaden wird teilweise durch die Tatsache gemindert, dass die gesamte Interaktion mit dem Host-Betriebssystem über USB und I2S erfolgt und nur dann, wenn das Host-Betriebssystem dies initiiert, sodass der Schadcode im Modem nicht direkt mit dem Host-Betriebssystem interagieren kann.
Werbung
Epische Server für Hosting-Sites und mehr! Günstiges VDS basierend auf den neuesten AMD EPYC-Prozessoren und NVMe-Speicher von Intel zum Hosten von Projekten jeder Komplexität, von Unternehmensnetzwerken und Spieleprojekten bis hin zu Zielseiten und VPNs. Mit wenigen Klicks können Sie Ihre eigene Serverkonfiguration erstellen!
Abonnieren Sie unseren Chat auf Telegramm .
