While developing software on Pinephone, I got this strange message dmesg,
[ 25.476857] modem-power serial1-0: ADB KEY is '41618099' (you can use it to unlock ADB access to the modem)
For reference, the PinePhone has a Quectel EG25-G modem, which handles GPS and wireless connectivity for the PinePhone. This piece of hardware is one of the few components of the phone that is closed-source.
When I saw that message and the mention of ADB, I immediately thought of the Android Debug Bridge, software commonly used to communicate with Android devices. “Surely,” I thought, “it cannot be talked about He ADB”. Well, turns out it is.
This message links to an article describing the modem in question. It also links to an unlocker utility, which when used prints the AT command to enable adbd on the modem.
$ ./qadbkey-unlock 41618099
AT+QADBKEY="WUkkFzFSXLsuRM8t"
AT+QCFG="usbcfg",0x2C7C,0x125,1,1,1,1,1,1,0
These can be sent to the modem using screen,
# screen /dev/ttyUSB2 115200
For whatever reason, my input was not being echoed back, but the screen session printed “OK” twice, indicating that it had executed the command properly.
after proper installation udev rules and adb On my “host machine”, which is the Pinephone, the modem popped up in the output adb devicesAnd I can fall into a shell:
$ adb devices
List of devices attached
(no serial number) device
$ adb shell
/ #
Because adbd Was running in root mode, I went into root shell. clean.
This shows that the modem runs its own OS completely separate from the rest of the Pinephone OS. With the latest update, it runs Linux 3.18.44.
For whatever reason, I thought it would be fun to run my own blog on this thing. Since we were working with limited resources (about 48M of space and the same amount of memory), and the fact that my blog is just a bunch of static files, I decided that something like nginx (as lightweight as it is) would be a little overkill for my purposes.
DarkHTTPD seems to fit the bill nicely. Single binary, no external dependencies, only GET and HEAD requests. Excellent.
I used the Armv7l-linux-musleabihf-cross toolchain to compile it for ARMv7 and link it statically against musl. adb push Let me push binaries and my site assets to the modem easily /usrdata The directory, which appears to have a writable partition about 50M large.
HTTP server works fine. I decided to use ADB to expose the HTTP port in my Pinephone:
$ adb forward tcp:8080 tcp:80
Since the ADB-forwarded port is bound only to the loopback interface, I also manually exposed it to 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
Now I can access my blog http://pine:8080/Cold!
i ran iperf Just tried ADB port forwarding on to see what kind of throughput I get.
$ 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
So around 10Mb/s. Not great, not terrible.
The Pinephone itself is connected to the network over USB (side note: I had to remove two components from the board to get the USB networking to work). I ran out of interest iperf Also on that connection:
$ 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
Although I was expecting more, it didn’t really matter, since I was hitching an ADB-forwarded connection.
I wonder how secure the modem is. This shows that a lot of AT commands are used system() on the modem. I suspect that some of them may be sensitive to AT command injection, but I haven’t looked into it further. Doesn’t really matter even though it’s so easy to drop into a root shell using ADB.
At first glance, this seems like an ideal way for malware to achieve persistence. With root access on the host system, malware can implant itself in the modem, which would enable it to avoid a re-install of the host OS and spy on communications or track the device’s location. Some of the impact is mitigated by the fact that all interaction with the host OS happens over USB and I2S and only if the host OS initiates it, so malware in the modem cannot interact with the host OS directly.
<a href