Spy Cam & Mic vs ADB

Como verificar se algum aplicativo no smartphone Android tem uma foto ou vídeo reportado, embora ele nunca precise dele? A opção a seguir não é perfeita, mas não requer um firmware "raiz" ou personalizado.

PS Adicionei uma descrição do monitoramento do acesso de aplicativos ao microfone do artigo.

O que você precisa instalar:
  • ADB ( Android Debug Bridge ) (por exemplo, como parte do Android SDK Platform Tools - você pode fazer o download aqui );
  • driver para o telefone (se necessário, por exemplo, o driver USB do Google pode ser baixado aqui ).

Ativamos o modo de depuração USB no telefone e conectamos o smartphone à porta USB do computador, e você deve selecionar o modo de conexão USB , exceto "Somente carregamento".
Texto oculto
No smartphone "Gerenciador de dispositivos" é exibido, por exemplo, da seguinte maneira:
no modo "Foto" ou "Arquivos"

no modo de drive USB

E assim, na saída do comando lsusb :


Abra a linha de comando no diretório em que as "ferramentas" estão instaladas.
Verifique se a conexão foi bem-sucedida (o número de série do smartphone conectado é exibido):
adb devices 
(para janelas )

Para Linux, o comando ficaria assim:
 ./adb devices 

Se o computador não estiver autorizado para uso com este smartphone (para Android 4.2.2 e posterior), a mensagem de aviso " não autorizado " aparecerá ao lado do número de série.
Para autorização, você precisa confirmar a permissão de depuração via USB no smartphone.
Texto oculto
No Linux , a mensagem " sem permissão " pode aparecer - no meu caso, consegui resolver o problema alternando o smartphone para o modo "Dispositivo de mídia ( MTP )".

Inicie o shell no dispositivo (recebemos o prompt "$"):
 adb shell 



Em seguida, apresentamos os seguintes símbolos "mágicos":
 while true; do ps `while ! (dumpsys media.camera | grep -E "PID") do done | grep -o "[^PID: ][0-9]*$"` | grep -o "[^S ]*$" ; date; sleep 1; done 



Versão aprimorada, removendo a saída "NAME" e as linhas vazias:
 while true; do ps `while ! (dumpsys media.camera | grep -E "PID") do done | grep -o "[^PID: ][0-9]*$"` | grep -o "[^S ]*$" | grep -v "NAME" | grep .; date; sleep 1; done 


E nada acontece :-) Até que algo decida dar uma chance :-)

O conjunto de caracteres "mágicos" indicado começa a monitorar o acesso ao serviço da câmera - media.camera o mais rápido possível (esse serviço é implementado pela biblioteca libcameraservice.so ). Se a câmera não estiver ativa, o dumpsys exibirá algo como isto:

E se for necessária uma câmera, isso aparecerá:


grep- s verifica a presença de um " PID " e, se essa cadeia existir, eles cortam o número do processo da string e o alimentam com o comando ps , que exibe dados sobre esse processo, e outro grep corta seu nome. Depois de detectar a atividade da câmera, faça uma pausa por um segundo para que as mensagens não vazem com muita frequência. Para interromper o comando, use a combinação de teclas CTRL-C e saia do shell - CTRL-D .

O exemplo mais simples é que, após o lançamento do aplicativo comum do smartphone para foto / vídeo, as mensagens com o nome do processo e a data / hora começam a aparecer em intervalos de 1 segundo:

"

Mas existem aplicativos mais astutos, eles podem ser encontrados pela palavra-chave “spy cam” (usando um truque, por exemplo, com uma visualização de pixel único ( http://www.ez.ai/2014/05/exploring-limits-of-covert-data .html )). Essa criação entra em colapso no início das filmagens e relatórios, mas as mensagens são enviadas regularmente:



Também verifiquei a funcionalidade do método proposto em um aplicativo que tira uma única foto ao clicar em um botão flutuante sem qualquer janela de visualização visível.
O script capturou com sucesso uma chamada para a câmera e emitiu duas mensagens com cada foto:


Mas não há nada que o impeça de implementar funcionalidades semelhantes em um aplicativo com um nome mais inócuo ( https://www.zdnet.com/article/this-scary-android-malware-can-record-audio-video-and-steal-your- data / ) e permissões - bem, existem todos os tipos de casos. E o aplicativo "legal" pode relatar quando lhe agrada (conheci a menção de um desses casos). E não é em vão que o Android P tomou medidas para impedir que aplicativos em segundo plano acessem a câmera.

O método foi testado nos smartphones Huawei SCL-L01 ( Android 5.1.1) e Huawei G700-U20 ( Android 4.2.1). Em outros modelos de smartphones, o formato de saída dumpsys pode ser diferente (não é padronizado para o serviço media.camera ), o que exigirá correção de código .
O formato da mensagem é codificado na biblioteca /system/lib/libcameraservice.so - por exemplo, para o smartphone Huawei SCL-L01 :

No comentário - uma dica de como alterar o código para trabalhar com um smartphone no Android 9.
Este comentário mostra o registro de acesso à câmera mantido pelo HTC U11 .
Mas, por exemplo, no "antigo" Huawei U8650 ( Android 2.3.4) dumpsys funciona bem:

E os direitos não são suficientes para ... grep :-)


Monitoramento de acesso ao microfone

Um método semelhante pode ser aplicado para monitorar o acesso de aplicativos ao microfone. Nesse caso, você precisa monitorar o serviço media.audio_flinger .
Nós inserimos o comando no "shell" (o código fornecido funciona no smartphone Huawei SCL-L01 ( Android 5.1.1)):
 while true; do ps `while ! (dumpsys media.audio_flinger | grep -A20 Input| grep -A1 Client | grep yes | grep -o "[^yes ].*" | grep -o [0-9]*) do done` | grep -o "[^S ]*$" | grep -v "NAME" | grep .; date; sleep 1; done 

Se algum aplicativo gravar som através de um microfone, na saída do dumpsys media.audio_flinger haverá um fragmento semelhante:

( Thread de entrada - fluxo de entrada, 22467 - PID do processo de gravação de som).
Ao gravar som através do aplicativo padrão “Gravador de voz” e o monitoramento estiver ativado (através do código acima), as seguintes mensagens aparecem:

Mas que mensagens são exibidas quando a entrada de voz do tradutor do Google é ativada:

Em outros smartphones, o formato de saída dumpsys pode ser diferente, o que exigirá uma correção de código.
Por exemplo, em um smartphone Huawei G700-U20 ( Android 4.2.1):

Nesse caso, o código de monitoramento será semelhante a:
 while true; do ps `while ! (dumpsys media.audio_flinger | grep -A3 Input| grep -A1 Clien | grep -o "[^ ].*" | grep -o [0-9]*) do done` | grep -o "[^S ]*$" | grep -v "NAME" | grep .; date; sleep 1; done 

Aqui está como a Alice "revivida" se manifesta neste caso:

Source: https://habr.com/ru/post/pt435098/


All Articles