PinePhone GPS / WWAN / LTE Modem
While developing software on PinePhone, I came across a curious message in
dmesg
:
[ 25.476857] modem-power serial1-0: ADB KEY is '41618099' (you can use it to unlock ADB access to the modem)
For context, I will say that the PinePhone has a Quectel EG25-G modem that is responsible for GPS and PinePhone wireless communication. This hardware is one of the few closed source phone components .
When I saw this message and the mention of ADB, I immediately thought of the Android Debug Bridge, that is, the software that is commonly used to communicate with Android devices. I thought, "Of course, this cannot be the same ADB." Well, it turns out that it is.
This message is related to an article that details this modem. It is also associated with an unlocker utility that prints out AT commands to secure the
adbd
modem.
$ ./qadbkey-unlock 41618099
AT+QADBKEY="WUkkFzFSXLsuRM8t"
AT+QCFG="usbcfg",0x2C7C,0x125,1,1,1,1,1,1,0
They can be sent to the modem using
screen
:
# screen /dev/ttyUSB2 115200
For some reason, my input did not return any data, but the screen session returned "OK" twice, indicating that it completed the commands successfully.
After setting up the rules
udev
and
adb
on my "host machine", that is, on the PinePhone, the modem began to produce output for
adb devices
, which I could send to the shell:
$ adb devices
List of devices attached
(no serial number) device
$ adb shell
/ #
Since I
adbd
was running as root, I piped the output to the root shell. Excellent.
It turned out that the modem runs its own operating system, completely independent of the rest of the PinePhone operating system. With the latest updates, it runs Linux 3.18.44.
Launching the web server
For some reason, I thought it would be fun to run my blog on this device. Since we are working with limited resources (about 48MB of storage and the same amount of memory), and my blog consists of only static pages, I decided that something like nginx (no matter how lightweight) would be a waste of resources for my purpose. ...
It seemed to me that darkhttpd met my requirements well . Single binary, no external dependencies, only execute GET and HEAD requests. Ideally.
I used the armv7l -linux-musleabihf-cross toolchain to cross-compile this server for ARMv7, and statically linked it with musl. With help
adb push
I easily managed to transfer the binary file and resources of my site to the
/usrdata
modem folder , to which a 50 MB partition is mounted with the ability to write.
The HTTP server works great. I decided to use ADB to open the HTTP port for my PinePhone:
$ adb forward tcp:8080 tcp:80
Since ADB-forwarded ports are bound only to the loopback interface, I manually opened it for external connections:
# 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
Then I was able to access my blog at
http://pine:8080/
. Cool!
Performance?
I ran
iperf
ADB port forwarding to see how much performance I was getting.
$ 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
That is about 10 Mbps. Not great, not terrible.
The PinePhone itself is connected to the network via USB (note: for the USB network connection to work, I had to remove two components from the board ). For fun, I ran
iperf
for this connection as well:
$ 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
I expected more, but it doesn't really matter because the bottleneck is the connection being redirected through ADB.
Other reasoning
I wondered about the security of the modem. It turned out that many AT teams
system()
. I suspect that some of these AT commands may be vulnerable to command injection, but I haven't done more research. It doesn't really matter, since the ADB root shell is very easy to implement.
At first glance, this seems like an ideal way to ensure the resilience of malware. With root access to the host, malicious code can embed itself into the modem, allowing it to survive a host OS reinstallation, intercept communications, or track the location of a device. The damage is partially mitigated by the fact that all interaction with the host OS is done via USB and I2S, and only when the host OS initiates it, so the malicious code in the modem will not be able to directly interact with the host OS.
Advertising
Epic servers for hosting sites and more! Cheap VDS based on the latest AMD EPYC processors and NVMe storage from Intel for hosting projects of any complexity, from corporate networks and gaming projects to landing pages and VPNs. You can create your own server configuration in a couple of clicks!
Subscribe to our chat on Telegram .
