Modem PinePhone GPS / WWAN / LTE
Ao desenvolver software no PinePhone, me deparei com uma mensagem curiosa em
dmesg
:
[ 25.476857] modem-power serial1-0: ADB KEY is '41618099' (you can use it to unlock ADB access to the modem)
Por contexto, direi que o PinePhone possui um modem Quectel EG25-G que é responsável pela comunicação GPS e wireless do PinePhone. Este hardware é um dos poucos componentes do telefone de fonte fechada .
Quando vi essa mensagem e a menção ao ADB, pensei imediatamente no Android Debug Bridge, ou seja, o software comumente usado para se comunicar com dispositivos Android. Eu pensei: "Claro, este não pode ser o mesmo ADB." Bem, acontece que é.
Esta mensagem está relacionada a um artigo que detalha esse modem. Ele também está associado a um utilitário de desbloqueio que imprime comandos AT para proteger o
adbd
modem.
$ ./qadbkey-unlock 41618099
AT+QADBKEY="WUkkFzFSXLsuRM8t"
AT+QCFG="usbcfg",0x2C7C,0x125,1,1,1,1,1,1,0
Eles podem ser enviados para o modem usando
screen
:
# screen /dev/ttyUSB2 115200
Por algum motivo, minha entrada não estava retornando nenhum dado, mas a sessão de tela retornou “OK” duas vezes, indicando que os comandos foram concluídos com sucesso.
Após configurar as regras
udev
e
adb
na minha "máquina host", ou seja, no PinePhone, o modem passou a produzir uma saída para a
adb devices
qual eu poderia enviar para o shell:
$ adb devices
List of devices attached
(no serial number) device
$ adb shell
/ #
Como
adbd
estava executando como root, canalizei a saída para o shell do root. Excelente.
Acontece que o modem roda seu próprio sistema operacional, completamente independente do resto do sistema operacional da PinePhone. Com as atualizações mais recentes, ele executa o Linux 3.18.44.
Iniciando o servidor web
Por algum motivo, achei que seria divertido publicar meu blog neste dispositivo. Como estamos trabalhando com recursos limitados (cerca de 48 MB de armazenamento e a mesma quantidade de memória) e meu blog consiste apenas em páginas estáticas, decidi que algo como nginx (não importa o quão leve) seria um desperdício de recursos para meu propósito ...
Pareceu-me que o darkhttpd atendeu bem aos meus requisitos . Binário único, sem dependências externas, apenas executa solicitações GET e HEAD. Idealmente.
Usei o conjunto de ferramentas armv7l -linux-musleabihf-cross para compilar este servidor para ARMv7 e vinculá-lo estaticamente ao musl. Com ajuda
adb push
Consegui facilmente transferir o arquivo binário e os recursos do meu site para a pasta do
/usrdata
modem, na qual uma partição de 50 MB é montada com capacidade de gravação.
O servidor HTTP funciona muito bem. Decidi usar ADB para abrir a porta HTTP do meu PinePhone:
$ adb forward tcp:8080 tcp:80
Como as portas encaminhadas por ADB são vinculadas apenas à interface de loopback, eu as abri manualmente para conexões externas:
# 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
Depois, consegui acessar meu blog em
http://pine:8080/
. Frio!
Desempenho?
Corri
iperf
o encaminhamento de porta ADB para ver quanto de desempenho que eu estava ficando.
$ 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
Isso é cerca de 10 Mbps. Não é ótimo, não é terrível.
O próprio PinePhone é conectado à rede via USB (nota: para a conexão de rede USB funcionar, tive que remover dois componentes da placa ). Por uma questão de interesse, também busquei
iperf
esta conexão:
$ 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
Eu esperava mais, mas isso realmente não importa porque o gargalo é a conexão sendo redirecionada por meio do ADB.
Outro raciocínio
Gostaria de saber sobre a segurança do modem. Descobriu-se que muitas equipes AT
system()
. Suspeito que alguns desses comandos AT podem ser vulneráveis à injeção de comandos, mas não fiz mais pesquisas. Isso realmente não importa, já que o shell de root do ADB é muito fácil de implementar.
À primeira vista, essa parece ser a maneira ideal de garantir a resiliência do código malicioso. Com o acesso root ao host, o código malicioso pode se embutir no modem, permitindo que ele sobreviva à reinstalação do sistema operacional do host, intercepte comunicações ou rastreie a localização do dispositivo. O dano é parcialmente mitigado pelo fato de que toda interação com o SO host é feita via USB e I2S, e apenas quando o SO host a inicia, de forma que o código malicioso no modem não será capaz de interagir diretamente com o SO host.
Propaganda
Servidores épicos para hospedagem de sites e muito mais! VDS barato baseado nos mais recentes processadores AMD EPYC e armazenamento NVMe da Intel para projetos de hospedagem de qualquer complexidade, de redes corporativas e projetos de jogos a páginas de destino e VPNs. Você pode criar sua própria configuração de servidor com alguns cliques!
Inscreva-se no nosso chat no Telegram .
