Este post foi editado pela última vez por Summer em 2025-10-14 às 22:59
Uma versão da câmera virtual que já foi hackeada pelo autor antes postou um vídeo no Bilibili
A versão anterior que quebrei também estava rachada
Link:O login do hiperlink está visível.
Recentemente, um cliente me pediu para decifrar outra versão da câmera virtual do mesmo autor e simplesmente estudá-la
Verifique primeiro o projétil, reforço livre de Bangbang, relativamente simples, apenas uma detecção simples da Frida, o link acima fez uma análise muito detalhada do reforço e detecção da versão sem Bangbang, usando várias ferramentas como ebpf
Primeiro com o gancho com a frida, há sinais de crash, pode ser que o passo seja injetado cedo demais, ou o endereço fique inacessível quando o gancho está pronto, corrigindo o código do gancho do script para frida
Em geral, o tempo de injeção atrasava um pouco, o que resolvia o problema das falhas de injeção
Gancho O processo de ativação dele recebe os dados retornados pela ativação, e ele precisa solicitar ao servidor que verifique se recebeu o carimbo de tempo da ativação
O usuário então recebe tempo calculando a diferença de tempo.
Essa câmera virtual também solicita permissões root, caso contrário não há comunicação entre processos de versão,
No total, esta câmera tem três processos iniciados
Um deles é o processo principal do aplicativo de câmera, que é a comunicação entre processos entre a camada Java e a camada C++
A segunda é que o processo principal executa o parâmetro binário executável vcmplay na linha de comando através da camada Java para iniciar o segundo processo, que é principalmente responsável pela comunicação entre processos entre o processo principal do camera vcmpaly e o processo libvc.so que injeta no serviço de câmera do sistema, e a principal forma de comunicação é ibinder.
O terceiro é o arquivo SO do cameraserver da câmera injetado no serviço do sistema.
Se a aplicação não conseguir obter privilégios root ou houver um problema de rede, o processo falhará ao iniciar
Essa câmera precisa de um código de ativação para ser ativada e usada, e ao analisar a camada Java, todas as suas interfaces são conectadas
A ativação exige que o servidor obtenha as informações de verificação
Os dados que você recebe são todos criptografados
Ao analisar o executável binário do VCMPLAY, podemos obter que os dados solicitados são criptografia RSA, e a chave está localizada pela ferramenta EBPF do stackplz, e a chave de criptografia tem 128 bits
Mais uma palavra
Esse aplicativo é muito astuto, ele adicionou um sufixo so ao vcmplay, o que faz as pessoas pensarem que é um arquivo SO, e que precisa ser carregado na memória do Java, mas na verdade é outro processo.
Conectei o serviço de câmera do servidor de câmeras libvc.so descobri que o Frida travou assim que o serviço de conectar câmera travou, não sei se foi detectado, analisei por muito tempo e acidentalmente descobri que o VCMPLAY morreu uma vez, e ele conseguiu conectar. Suspeita-se que pode ser o processo do VCMPLAY que detectou o processo de cameraserve
Usei o ida para depurar o processo do VCMpay, e descobri que ele ainda tinha anti-debugging, escaneei o tracepid em proc/self/status para determinar se estava debuggado, e o que foi ainda mais assustador foi que ele descobriu que o anti-debugging não era um travamento do programa, ele realmente deletou arquivos importantes do sistema Android por permissões root, e então o telefone reiniciou em estado de dupla limpeza, e o sistema precisava ser inicializado para entrar no sistema, e tudo no telefone tinha sumido. Escrevi o módulo kernel hook kpm via kernelpatch e pulei a depuração
Depois de várias noites sem dormir aqui, a lógica geral foi descoberta, e estima-se que não será fácil decifrá-la.
Continuará depois......
|
Postado em 2025-10-14 10:40:57
|
|
|
|
