- O app BM2, usado para verificar o estado da bateria do veículo, coletava não só coordenadas de GPS, mas também informações de Wi‑Fi ao redor e de torres de telefonia móvel, enviando tudo a servidores remotos
- Os dados eram enviados ao servidor
bm2.quicklynks.comda Leagend, desenvolvedora do produto/app, e também aos servidores da AMap, desenvolvedora do SDK de serviços de localização; ambos foram identificados respectivamente em hosts da Alibaba Cloud em Hong Kong e Pequim - No Google Play, o app tinha 100K+ downloads, mas as indicações iniciais de privacidade na loja — como “nenhum compartilhamento de dados”, “nenhuma coleta de dados” e “criptografado em trânsito” — não batiam com o comportamento real
- No Android, o Bluetooth scan exige permissão de localização, então na prática o usuário precisava concedê-la para usar o dispositivo; no iOS, o monitor de bateria continuava funcionando mesmo com a permissão de localização negada
- Após a atualização de 25 de julho de 2023, o SDK da AMap foi removido das versões nas duas lojas, mas os dados de localização por GPS continuaram sendo enviados a um servidor da Alibaba Cloud em Hong Kong, e o app para iPhone também enviava o endereço da rua do usuário
Dados de localização enviados pelo app do monitor de bateria
- O produto analisado é um monitor Bluetooth de bateria que se conecta aos terminais da bateria do carro, faz pareamento com o smartphone e mostra voltagem/porcentagem, além de executar testes de partida
- A análise foi feita a partir de um produto da marca PowerTech comprado na varejista australiana Jaycar Electronics, que aparenta ser um rebranding do Bluetooth 4.0 Battery Monitor da Leagend
- Produtos da mesma linha também foram identificados sob nomes como Century da Repco,
ZX-1689eLi Battery Monitor - O app Android BM2 registra 100K+ downloads e 1.55K avaliações no Google Play
- O app BM2 para iPhone também, segundo a análise do tráfego de rede, enviava dados de localização para servidores remotos
Destinos do envio e escopo da coleta
- O app coletava não só a voltagem da bateria, mas também coordenadas de GPS, dados de torres de celular próximas e informações de pontos de acesso Wi‑Fi ao redor
- Na época, foram identificados dois grupos de destinos para o envio dos dados de localização
- Servidor da Leagend/app BM2:
bm2.quicklynks.com,47.244.125.231, Alibaba Cloud Hong Kong - Servidor do SDK AMap:
dualstack-cgicol.amap.com,106.11.130.194, Alibaba Cloud Pequim
- Servidor da Leagend/app BM2:
- A AMap é uma fornecedora chinesa de mapas digitais adquirida pela Alibaba, e seu SDK coleta não só GPS, mas também outros dados relacionados à localização que o celular consegue obter
- Após a atualização de 25 de julho de 2023, o SDK da AMap foi removido dos apps nas duas lojas
- A coleta de dados de GPS, Wi‑Fi e torres de celular enviados aos servidores da AMap na China continental foi interrompida
- Os dados de localização por GPS continuaram sendo enviados a um servidor da Alibaba Cloud em Hong Kong
- O app para iPhone também consultava e enviava o endereço da rua do usuário
Indicações de privacidade na loja e comportamento real
- Em 27 de junho de 2023, o desenvolvedor do app BM2 atualizou as informações de privacidade no Google Play e na Apple App Store para declarar a coleta de dados precisos de localização
- Antes disso, a indicação no Google Play não correspondia ao funcionamento real do app
- “Nenhum compartilhamento de dados com terceiros”: latitude e longitude eram enviadas ao servidor
quicklynks.comjunto com estatísticas da bateria; análises de falhas iam paraumeng.com; e Wi‑Fi, torres de celular e coordenadas de GPS eram enviados à AMap - “Nenhuma coleta de dados”: dados de localização e dados relacionados à bateria eram coletados
- “Criptografado em trânsito”: os dados enviados ao servidor em nuvem do BM2 eram transmitidos por HTTP sem criptografia
- “Nenhum compartilhamento de dados com terceiros”: latitude e longitude eram enviadas ao servidor
- O texto detalhado da política de privacidade incluía “Hong Kong” e “location information”
O problema estrutural criado pelas permissões no Android
- O app Android exigia permissão de localização para funcionar, e sem ela não era possível usar o dispositivo de hardware
- Desde o Android 6.0, para acessar identificadores de hardware de dispositivos externos próximos via Bluetooth e Wi‑Fi scan, é necessária a permissão
ACCESS_FINE_LOCATIONouACCESS_COARSE_LOCATION - O que o app BM2 realmente precisava era de BLE scan, mas a permissão ampla de localização também permitia acesso a dados de GPS, torres de celular e Wi‑Fi, abrindo margem para abuso
- No Android 12 ou superior, é possível fazer BLE scan apenas com a permissão BLUETOOTH_SCAN
- Segundo a documentação do Google, é possível definir
android:usesPermissionFlags="neverForLocation"emACCESS_FINE_LOCATION, mas isso só vale quando o resultado do Bluetooth scan não é usado para inferir localização física
O que foi confirmado no tráfego de rede
- O tráfego do app móvel foi analisado com o modo WireGuard do Mitmproxy
- Como o BM2 não usa HTTPS, foi possível confirmar no Android e no iOS o envio de latitude e longitude sem instalar certificado
- Depois que o app se conectava ao dispositivo monitor de bateria, ele enviava uma requisição
POSTparahttp://bm2.quicklynks.com:8080/api/bm2/userDevice/upload? - A requisição incluía campos de latitude e longitude, além de amostras de voltagem da bateria, endereço MAC do hardware,
nicknameeserialNo - Na época, consultas de DNS e IP mostraram que
bm2.quicklynks.comresolvia para47.244.125.231, com informações de IP apontando para um AS ligado à Alibaba em Sham Shui Po, Hong Kong
Sinais de localização tratados pelo SDK da AMap
- O SDK da AMap coletava dados de GPS, Wi‑Fi e torres de telefonia móvel
- Os dados de telefonia incluíam o Cell Global Identity
MCC: Mobile Country CodeMNC: Mobile Network CodeMCC + MNC: PLMN, identificador da operadora móvelLAC: agrupamento regional de estações rádio-baseCI: identificador do transceptor da estação rádio-base na região- Em 4G, usa-se
TAC
- Os dados de Wi‑Fi incluíam o endereço MAC
BSSIDe o nome do ponto de acessoSSID - Os dados da AMap eram processados como um blob binário serializado criptografado antes de serem gravados em disco ou enviados pela internet
- Os dados de localização eram criptografados com uma chave AES temporária, e essa chave AES era criptografada novamente com uma chave pública RSA
- Esse método não depende de certificate pinning
- Sem modificar o app ou ter a chave privada RSA correspondente, é difícil inspecionar o conteúdo com análise de rede man-in-the-middle
Hardware e ambiente de teste
- O interior do hardware é simples, centrado em um regulador de tensão e no MCU Bluetooth Low Energy CC2541 da Texas Instruments
- A CPU do CC2541 é baseada no Intel 8051 de 8 bits, enquanto gerações posteriores da linha CC usam arquitetura ARM Cortex
- Os SoCs da linha CC suportam uma interface dedicada de depuração on-chip, e não foi observado JTAG nem SWD
- O dispositivo suporta atualização OTA, e um endpoint REST que retorna o firmware é documentado na parte 3
- Não foram vistos shunt de medição de corrente nem outros circuitos de medição de corrente, o que sugere uma configuração de hardware muito simples
- Os testes foram realizados com uma pequena bateria chumbo-ácido de 12 V, o monitor de bateria BM2 e um aparelho Android com root
- Como os dados de localização da AMap só eram gravados da memória para o banco de dados quando havia detecção de movimento físico, foram usados Frida e Objection para instrumentação em tempo de execução
Procedimentos de análise dinâmica e estática
- As coordenadas de GPS podiam ser alteradas para valores arbitrários com Frida, fazendo hook em
android.location.Location.getLatitudeegetLongitude - Com o plugin Wallbreaker do Objection, foi possível verificar na heap do app instâncias de dados de GPS, torres de celular da operadora e Wi‑Fi
- O APK foi extraído do aparelho após obter o caminho com
adb shell pm pathe depois decompilado com JADX - No
AndroidManifest.xml, além deFINE_LOCATION, apareciam permissões comoCAMERA,IMAGE_CAPTURE,ACTION_VIDEO_CAPTURE,MODIFY_AUDIO_SETTINGSeRECORD_AUDIO, mas ainda seria necessária investigação adicional para confirmar se essas funções eram usadas - O ponto de entrada do app era
com.stub.StubApp, com uso do empacotador comercialqihoo.util - Com frida-dexdump, foi feito dump do bytecode Dalvik original a partir da memória em execução, depois convertido com
dex2jare JADX em código Java legível - O corpo principal do app BM2 não tinha ofuscação adicional, mas o SDK de serviços de localização
amapestava ofuscado, e parte dos nomes de classes foi recuperada com o recurso de deobfuscation do JADX
1 comentários
Opiniões no Hacker News
Resultado de uma engenharia reversa feita em um monitor BLE de bateria automotiva. O app tem mais de 100 mil downloads só no Google Play.
No fim, ele ficava enviando continuamente GPS, IDs de células de torres de telefonia e dados de beacons Wi-Fi para servidores em Hong Kong e na China continental. Nas páginas do app no Google e na App Store da Apple, consta que ele não coleta dados pessoais nem os envia a terceiros.
Espero que isto sirva como algumas dicas para quem quiser analisar apps de dispositivos conectados.
https://www.amazon.de/dp/B0BLG9Z462
Ao clicar na terceira imagem, aparece uma tabela comparativa; é interessante que eles apresentam isso como se fosse um recurso especial exclusivo do BM6, quando na verdade é apenas uma função do app.
O QR code do dispositivo [0] aponta para este app: https://play.google.com/store/apps/details?id=com.dc.bm6
Por isso, também verifiquei outras URLs como https://link.quicklynks.com/bm3.html e https://link.quicklynks.com/bm4.html; esta última redireciona para https://www.leagend.com/ e eles mantêm este canal no YouTube: https://www.youtube.com/channel/UCqkvyOFP5cXQ02f3h1Ns42Q
[0] http://link.quicklynks.com/bm6.html
Também não sei se vale a pena ficar consumindo a bateria do celular o tempo todo só para ver na tela do telefone algo que o painel já informa. Se for uma bateria estacionária, não bastaria usar um mostrador analógico de voltímetro?
Hoje em dia é difícil demais encontrar dispositivos independentes que funcionem sem app. Por exemplo, foi difícil até achar uma luminária LED que permitisse escolher a cor pelos botões do próprio aparelho, sem app; encontrei uma, mas ainda assim não era possível alternar as cores sem o app.
Se as pessoas não preferissem esse tipo de bobagem, seria mais fácil voltar a encontrar eletrônicos normais.
Não entendo por que, no Android, o usuário não pode impedir um app de 1) iniciar na inicialização e 2) rodar em segundo plano. No mínimo, isso deveria ser uma permissão aprovada pelo usuário.
Isso poderia bloquear muitos apps que sugam dados desse jeito; vejo o Google como cúmplice também.
https://grapheneos.org/
Sei que um app pode solicitar a ativação dos dados de localização, mas me surpreendeu que ele pudesse ativá-la unilateralmente, e não encontrei uma forma de impedir isso.
Por motivos como esse, sinto que é difícil confiar em qualquer celular.
Por causa de casos assim, não podemos parar a luta pela privacidade digital e por leis que a protejam.
Não é uma questão de “não tenho nada a esconder”, mas de impedir que terceiros vigiem e vendam dados pessoais sem conhecimento e consentimento explícitos.
Estamos no meio de uma guerra total de dados, e precisamos resistir com força.
É irritante que isso tenha virado praticamente o padrão, quando atores maliciosos basicamente não pagam preço nenhum.
Ao ver este texto, fiquei feliz por estar usando GrapheneOS. Uso no dia a dia há alguns meses, e todos os apps, ao serem instalados, precisam ter a permissão de rede explicitamente concedida ou negada.
Nunca dou permissão de rede para apps locais desse tipo, nem para apps de teclado, que sempre me deixaram desconfortável.
Não é apenas ridículo; é abertamente hostil à privacidade e segurança do usuário.
Os sistemas operacionais deveriam transformar o acesso à internet em uma permissão que o usuário possa conceder ou revogar. Acho que o Android tinha algo assim antigamente, e no iOS parece que não havia nada além de dados móveis
Se eu comprar um dispositivo que afirma usar Bluetooth, mas na prática precisar de acesso à internet, vou devolvê-lo
Se você não concordasse, não podia baixar o app. Algumas permissões ainda funcionam assim, e muitas passaram para o modelo de conceder/revogar
O acesso à internet continua sendo uma permissão, mas o Google Play não pergunta mais sobre ela, então qualquer app pode tê-la. Porém, se não for solicitada no manifest, não funciona
https://netguard.me/
Para iniciantes, poderia mostrar os domínios e, se forem domínios colocados pela Apple em uma lista de permissões de algum modo, marcá-los em verde. Se não estiverem nem na lista de permissões nem na de bloqueio, poderiam ser marcados em amarelo; ou, se cores confundirem, bastaria mostrar o nome
Apps que façam requisições para a lista de bloqueio poderiam ser barrados na App Store até uma análise adicional
Para usuários avançados, seria bom permitir tocar para ver detalhes como payload e headers. Esse recurso é realmente necessário e não parece tão difícil de adicionar
[1]: https://developer.apple.com/documentation/bundleresources/en...
Acho que os provedores de lojas de apps deveriam remover totalmente frases como “dados pessoais não são coletados nem transmitidos a terceiros”
Em vez disso, deveriam alertar: “este app tem permissões relacionadas à rede e pode enviar os dados que quiser para onde quiser” ou “o desenvolvedor afirma que não fornecerá dados a terceiros, mas não temos absolutamente nenhum meio de verificar isso”
Na prática, Apple ou Google não têm como saber o que é um terceiro. Servidores na China e em Hong Kong podem ser parte primária, quem sabe? Ninguém sabe além do desenvolvedor do app
O Partido Comunista Chinês talvez não tenha tanto interesse nos dados de um indivíduo específico, mas tem enorme interesse em dados agregados. Além disso, esses dados se tornam muito úteis quando cruzados com alvos específicos, como os dados de milhões de funcionários do governo dos EUA coletados ao longo de anos [0][1]
O “grande experimento” de que comércio aberto e intercâmbio levariam a China à democracia e à liberdade fracassou completamente. No fim, apenas tornou mais forte uma ditadura implacável que busca expansão global. Não se deve fazer negócios com a China
[0] https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
[1] https://www.nbcnews.com/tech/security/china-spent-years-coll...
É preciso perceber que o dispositivo que monitora também acaba consumindo lentamente o próprio objeto monitorado. No fim, chega-se ao ponto de ter que monitorar ativamente o monitor de novo
Esse dispositivo BLE vai drenar a bateria do carro lenta, mas seguramente. Um dia ele enviará um alerta e a bateria precisará ser recarregada; pouco depois, ele também deixará de enviar alertas
Além disso, vai sugar os dados móveis do telefone e enviá-los para a China, e também consumir a bateria do celular. É difícil imaginar um presente de fim de ano pior, e é uma rara ameaça tripla ao consumidor
Falando sério, a autodescarga é aproximadamente uma ordem de grandeza maior que a deste monitor
O Android precisa de um recurso que permita fornecer dados de GPS falsos em dispositivos reais. Seria útil para apps que exigem GPS sem motivo algum
Se um app de lanterna precisar de GPS para ligar, sem problema. Minha localização atual é o Monte Kilimanjaro
O desenvolvedor do app ainda tenta explicar ao usuário, em um pop-up, algo como “toque em permitir para que o Bluetooth funcione”
A esta altura, é razoável presumir que esses dispositivos estejam coletando grandes quantidades de dados e enviando para a matriz. Eu não ficaria surpreso se roteadores TP-Link também estivessem mandando tudo para a China
Mas isso não se limita à China; é possível que o iPhone que você usa agora também esteja enviando todos os toques de teclado e dados de localização para os EUA
Se você suspeita que um roteador TP-Link está enviando tudo para um servidor remoto, basta monitorar o tráfego
Quando meus amigos zombam da minha obsessão com privacidade e coleta de dados, é exatamente esse tipo de caso que eu mostro.
Não há motivo para acreditar que façam isso por razões maliciosas, mas, na prática, não há como saber. Talvez seja apenas ignorância ou incompetência.
A quantidade de dados de localização coletada por fabricantes de dispositivos é considerável. Se por acaso eles estiverem monetizando isso, fico me perguntando se ainda poderia ser considerado malicioso mesmo sem ter sido divulgado ao usuário final.
O AMap SDK usado pelo app coleta muito mais dados de localização. Aqui, parece provável que o objetivo seja melhorar a precisão dos serviços de localização e do software de mapas, e não vejo isso, por si só, como algo malicioso.
Mas, se esse comportamento não foi divulgado a usuários e desenvolvedores, a história muda. O site está em chinês [1], e nem sei se alguém leria até os termos detalhados para conferir.
[1] https://lbs.amap.com/api/lightweight-android-sdk/download
Isso me lembra quando, no passado, eu achava que os botões “Like” do Facebook em todos os sites eram inofensivos, até descobrir o quanto éramos rastreados de forma ampla sem consentimento.
O modo típico chinês é coletar dados deliberadamente de uma forma que pareça inofensiva por fora, ou deixar propositalmente escancaradas brechas de segurança que possam ser exploradas depois. Quando são pegos, dizem: “Desculpe, vamos corrigir imediatamente”.
O pior é que não há consequência alguma para esse tipo de comportamento. Alguém — Google, UE ou FTC — deveria aplicar uma multa.