Como Desenvolvi um Construtor PoC para Aplicações Android
Um pesquisador de segurança compartilha sua experiência na criação de uma ferramenta para simplificar o teste de segurança em aplicações Android. O artigo detalha o desenvolvimento de um construtor PoC (Proof of Concept) que automatiza a criação e execução de exploits, agilizando o processo de identificação de vulnerabilidades.
MundiX News·26 de maio de 2026·10 min de leitura·👁 3 views
Segurança de Software
2,2
Avaliação
4
Inscritos
Inscrever-se
throttlin
1 minuto atrás
Como Desenvolvi um Construtor PoC para Aplicações Android
Médio
6 min
29
Blog da Empresa Soluções de Software Seguras
Segurança da Informação
Teste de Aplicações Móveis
Android
Gerenciamento de Desenvolvimento
Estudo de Caso
Qualquer pessoa que já tenha testado a segurança de aplicações Android inevitavelmente se deparou com vários problemas:
Encontrou uma potencial vulnerabilidade? Pensa em como confirmá-la melhor.
A verificação só pode ser acionada a partir do código? Escreve uma aplicação.
Encontra novos lugares com potenciais vulnerabilidades? Refina a aplicação ou escreve uma nova.
De repente, em vez de verificações, você já está trabalhando como desenvolvedor… repetidamente.
Olá a todos, meu nome é Anton Khazov, e na equipe da SecWare, frequentemente nos deparamos com testes de aplicações Android em busca de vulnerabilidades. Um dia, calculei quanto tempo eu, como pesquisador de segurança de software móvel, preciso gastar escrevendo código. Após perceber esse número assustador, tive a ideia de tentar criar um construtor PoC para essas verificações. Veja o que consegui.
Por que as ferramentas comuns não funcionam?
Farei uma breve digressão teórica (aqueles que já estão familiarizados com o assunto podem pular esta seção). Aplicações Android e seus componentes exportados (Activity, Service, ContentProvider, BroadcastReceiver) costumam estar acessíveis externamente apenas formalmente – não é incomum que a lógica de uso esteja ligada aos meandros da própria aplicação, onde se pode encontrar Intent’s complexos com um grande conjunto de parâmetros ou um objeto Parcelable personalizado com dependência direta das classes internas da aplicação. E a ferramenta de depuração ADB existente, com toda a sua utilidade, cobre apenas cenários básicos, e passar algo mais complexo do que tipos primitivos torna-se desconfortável ou até impossível (e olá novamente aos objetos Parcelable).
Sim, muitos podem notar que a maioria dos problemas potenciais podem ser resolvidos com uma ferramenta tão poderosa como Frida – e isso é realmente verdade. Mas então estaremos falando de interferência dinâmica na aplicação, e ninguém quer operar com isso quando queremos construir um Proof-Of-Concept, onde, para ser sincero, até mesmo o modo de desenvolvedor ativado (e, portanto, ADB) nos afasta das condições de sandbox em tempo real.
É aqui que chegamos à conclusão de que o que mais nos aproxima das condições de combate é apenas escrever uma aplicação separada com a carga necessária no código. No entanto, na prática, a luta com o Android Studio ilimitado pode levar uma quantidade excessiva de tempo para um PoC refinado. Construtores Maven e Gradle, vários gerenciadores de depuração, emulação, gerenciamento de versões SDK, editores visuais XML, centenas de seletores Toolbar, etc. – tudo isso parece redundante quando se trata de escrever um pequeno código de ~25 linhas. E, como mostra a prática, mesmo para uma aplicação, é preciso realizar dezenas dessas verificações.
De dezenas de APKs para uma ferramenta
Quando percebi que para cada hipótese eu tinha que desenvolver uma aplicação separada, ficou claro que esse processo exigia automação. A tarefa era simplificar a abordagem para escrever um pequeno código Java, compilar e executar diretamente no dispositivo, ignorando a montagem da própria aplicação. A ideia veio rapidamente e foi simples como três centavos – apresento a vocês uma solução de duas partes:
DexRunner: uma aplicação Android com uma base para carregar e executar código.
DEXLab: uma extensão VS Code para simplificar a montagem e entrega da carga.
[Imagem da Icone DEXLab]
No coração do DexRunner está o mecanismo padrão para executar arquivos DEX no Android – o método DexClassLoader, e o DEXLab está ligado ao uso do ambiente Android Studio. Para o DEXLab, até tentei desenhar um ícone.
A primeira panqueca foi um código de vibração, mas funcionando! Inicialmente, pedi ajuda ao Claude AI – é legal que o código de vibração economize muito tempo no desenvolvimento, mas era preciso sempre tomar cuidado para não perder detalhes, por isso era preciso refinar o código sozinho. E no início eu só queria verificar se nada iria interferir no trabalho. A arquitetura da carga neste momento consistia em:
Um arquivo de configuração config.json, que armazenava informações sobre para quem transferir o controle:
Carga DEX, cuja montagem tinha um pipeline: compilação Java com android.jar --> JAR --> DEX.
E parece que é hora de abrir o champanhe, mas aqui é importante lembrar que a carga pode ter dependências da aplicação em estudo (suas classes, métodos ou alguns outros dados). Nesta fase, converti manualmente, via dex2jar, todos os arquivos DEX da aplicação em estudo em JAR, que então usei ao montar a carga. Mas, além da montagem, para não perder as dependências, antes de executar a carga, é preciso passar os arquivos DEX da aplicação em estudo para o DexRunner. Pode haver muitos arquivos DEX na própria aplicação, e quais deles são necessários para executar a carga é difícil de entender rapidamente.
Quando há muitos arquivos
Em meu plano, espero duas abordagens da implementação do construtor PoC:
Quando a carga é um PoC completo, que é entregue manualmente via Intent.ACTION_OPEN_DOCUMENT e é executado pela interface do usuário DexRunner, pois se considera que a execução ocorrerá sem o modo de desenvolvedor.
Quando a carga é uma verificação intermediária rápida, onde é importante não perder tempo com a transferência, para que as verificações sejam realmente rápidas e o desenvolvimento seja facilitado.
Portanto, para o segundo caso, adicionei automação de entrega e execução no DexRunner via BroadcastReceiver com comandos para carregar (LOAD_BUNDLE) e executar (RUN_BUNDLE).
O DexRunner salva o arquivo DEX (na pasta code_cache) em seu armazenamento pessoal da aplicação, e quando RUN_BUNDLE é chamado, pega a carga desta pasta e a executa. Essa manobra é causada pela contornagem da proteção contra a execução perigosa de código de diretórios de usuários – é quando você pode carregar a carga no diretório /sdcard/, mas não pode executar nada de lá (no futuro, o DEXLab carregará a carga por padrão no diretório /data/local/tmp/, de onde o DexRunner a pegará mais tarde).
Mais tarde, esses comandos Broadcast foram introduzidos no DEXLab, o que tornou possível reproduzir automaticamente o ciclo completo de montagem e preparação para entrega e execução no dispositivo com um único comando da extensão. No entanto, faltava apenas uma coisa – um formato unificado com todos os arquivos necessários para executar, então um formato zip próprio com a extensão ".dexs" foi desenvolvido. Eu o tornei amigo do DexRunner e até conectei uma assinatura a este arquivo via HMAC-SHA256. E aqui, como exemplo, como a carga DEXS montada pode parecer por dentro (destacado – config e, diretamente, a carga):
Quais foram os resultados?
Agora eu gostaria de finalmente percorrer um pouco o uso da própria extensão DEXLab. Nela, coloquei dois comandos para criar um modelo de projeto: com a aplicação em estudo como alvo e sem ela.
Após criar o projeto, a estrutura final do modelo inclui os diretórios e arquivos de configuração necessários com diferentes versões para montagem, bem como um arquivo payload.java básico com um pequeno toast e println, para que você possa obter imediatamente um projeto que seja montado com sucesso e mostre sua atividade. Coloquei os comandos no submenu para dexlab.config.json – o arquivo de configuração do projeto (não confundir com a configuração que é embalada no pacote DEXS). Aconteceu o que pode ser visto na captura de tela abaixo.
[Imagem da Captura de Tela]
Na tela, a árvore do modelo do projeto foi intencionalmente totalmente revelada e toda a funcionalidade possível foi chamada no momento, para que você possa ver o que eu, na verdade, estava buscando. Um leitor atento também notará uma semelhança na experiência do usuário com o APKLab e não é por acaso – como você pode entender, fui em parte inspirado por esta extensão e até mesmo o próprio nome DEXLab de alguma forma sugere isso =)
O que sobre os comandos:
Build and Run on Device – monta e executa com um comando
Build – monta o payload e o empacota em payload.dex
Bundle (.dexs) – empacota todos os arquivos DEX (payload+target) e assina DEXS
Disassemble DEX – descompila payload.dex
Prepare Target – prepara a aplicação em estudo, extraindo todos os arquivos DEX dela e os monta em uma única biblioteca JAR
Deploy to Device – envia payload.dexs e sinaliza DexRunner
Run on Device – sinaliza DexRunner para executar
Set Secret – envia o segredo durante a montagem, se necessário
Install / Update DexRunner – baixa e instala a última compilação de lançamento do github
Download baksmali – baixa baksmali
Download dex2jar – baixa o pacote de utilitários dex2jar
Clean – limpa a montagem
Do saboroso, também recomendo usar a extensão Language Support for Java(TM) by Red Hat, que permite que você se refira lindamente às classes da biblioteca JAR formada, recebida da aplicação em estudo.
Principais características
As características principais do DEXLab são claras, mas como é o próprio DexRunner? Tudo é bastante comum: informações sobre a carga, botões de controle manual e uma atividade separada com logs. Se você executar o modelo de projeto criado pela extensão DEXLab no DexRunner, obterá o Toast curto esperado e mensagens de depuração nos logs.
Resultados
Na verdade, o resultado de tudo isso é que obtive uma ferramenta conveniente e multifuncional para escrever PoCs e pesquisas com a capacidade de incluir o ambiente de trabalho das classes da aplicação em estudo. A ferramenta já demonstrou sua conveniência e demonstra sua principal força – a capacidade de reproduzir PoCs sem alterar o ambiente e sem interferir na aplicação.
Eu acho que este ainda não é o limite de suas capacidades potenciais. Ao testar, algo muito complicado pode aparecer, e isso certamente levará à expansão adicional da funcionalidade. Terei prazer em ler comentários e novas ideias, e por enquanto fui desenhar um ícone para o DexRunner =)
P.S. Publiquei meus trabalhos no Github. Também ficarei feliz com as assinaturas no meu (ainda pequeno e aconchegante) canal do Telegram.
Tags:
segurança
extensão vscode
segurança móvel
pesquisa
segurança móvel
dex
segurança android
android
poc
payload
Hubs:
Blog da Empresa Soluções de Software Seguras
Segurança da Informação
Teste de Aplicações Móveis
Android
Gerenciamento de Desenvolvimento
0
0
0
Soluções de Software Seguras
Site
1
Karma
Anton
@throttlin
Usuário
Inscrever-se
GitHub
O fluxo de desenvolvimento móvel está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr
Habr Cursos para todos
PUBLICIDADE
Prática, Hexlet, SkyPro, cursos do autor — reunimos todos e pedimos descontos. Resta escolher!
Ir
Ir para o fluxo de desenvolvimento móvel
Comentar
Melhor do dia
Semelhante
Segurança de Software
2,2
Avaliação
4
Inscritos
Inscrever-se
throttlin
1 minuto atrás
Como Desenvolvi um Construtor PoC para Aplicações Android
Médio
6 min
29
Blog da Empresa Soluções de Software Seguras
Segurança da Informação
Teste de Aplicações Móveis
Android
Gerenciamento de Desenvolvimento
Estudo de Caso
Qualquer pessoa que já tenha testado a segurança de aplicações Android inevitavelmente se deparou com vários problemas:
Encontrou uma potencial vulnerabilidade? Pensa em como confirmá-la melhor.
A verificação só pode ser acionada a partir do código? Escreve uma aplicação.
Encontra novos lugares com potenciais vulnerabilidades? Refina a aplicação ou escreve uma nova.
De repente, em vez de verificações, você já está trabalhando como desenvolvedor… repetidamente.
Olá a todos, meu nome é Anton Khazov, e na equipe da SecWare, frequentemente nos deparamos com testes de aplicações Android em busca de vulnerabilidades. Um dia, calculei quanto tempo eu, como pesquisador de segurança de software móvel, preciso gastar escrevendo código. Após perceber esse número assustador, tive a ideia de tentar criar um construtor PoC para essas verificações. Veja o que consegui.
Por que as ferramentas comuns não funcionam?
Farei uma breve digressão teórica (aqueles que já estão familiarizados com o assunto podem pular esta seção). Aplicações Android e seus componentes exportados (Activity, Service, ContentProvider, BroadcastReceiver) costumam estar acessíveis externamente apenas formalmente – não é incomum que a lógica de uso esteja ligada aos meandros da própria aplicação, onde se pode encontrar Intent’s complexos com um grande conjunto de parâmetros ou um objeto Parcelable personalizado com dependência direta das classes internas da aplicação. E a ferramenta de depuração ADB existente, com toda a sua utilidade, cobre apenas cenários básicos, e passar algo mais complexo do que tipos primitivos torna-se desconfortável ou até impossível (e olá novamente aos objetos Parcelable).
Sim, muitos podem notar que a maioria dos problemas potenciais podem ser resolvidos com uma ferramenta tão poderosa como Frida – e isso é realmente verdade. Mas então estaremos falando de interferência dinâmica na aplicação, e ninguém quer operar com isso quando queremos construir um Proof-Of-Concept, onde, para ser sincero, até mesmo o modo de desenvolvedor ativado (e, portanto, ADB) nos afasta das condições de sandbox em tempo real.
É aqui que chegamos à conclusão de que o que mais nos aproxima das condições de combate é apenas escrever uma aplicação separada com a carga necessária no código. No entanto, na prática, a luta com o Android Studio ilimitado pode levar uma quantidade excessiva de tempo para um PoC refinado. Construtores Maven e Gradle, vários gerenciadores de depuração, emulação, gerenciamento de versões SDK, editores visuais XML, centenas de seletores Toolbar, etc. – tudo isso parece redundante quando se trata de escrever um pequeno código de ~25 linhas. E, como mostra a prática, mesmo para uma aplicação, é preciso realizar dezenas dessas verificações.
De dezenas de APKs para uma ferramenta
Quando percebi que para cada hipótese eu tinha que desenvolver uma aplicação separada, ficou claro que esse processo exigia automação. A tarefa era simplificar a abordagem para escrever um pequeno código Java, compilar e executar diretamente no dispositivo, ignorando a montagem da própria aplicação. A ideia veio rapidamente e foi simples como três centavos – apresento a vocês uma solução de duas partes:
DexRunner: uma aplicação Android com uma base para carregar e executar código.
DEXLab: uma extensão VS Code para simplificar a montagem e entrega da carga.
[Imagem da Icone DEXLab]
No coração do DexRunner está o mecanismo padrão para executar arquivos DEX no Android – o método DexClassLoader, e o DEXLab está ligado ao uso do ambiente Android Studio. Para o DEXLab, até tentei desenhar um ícone.
A primeira panqueca foi um código de vibração, mas funcionando! Inicialmente, pedi ajuda ao Claude AI – é legal que o código de vibração economize muito tempo no desenvolvimento, mas era preciso sempre tomar cuidado para não perder detalhes, por isso era preciso refinar o código sozinho. E no início eu só queria verificar se nada iria interferir no trabalho. A arquitetura da carga neste momento consistia em:
Um arquivo de configuração config.json, que armazenava informações sobre para quem transferir o controle:
Carga DEX, cuja montagem tinha um pipeline: compilação Java com android.jar --> JAR --> DEX.
E parece que é hora de abrir o champanhe, mas aqui é importante lembrar que a carga pode ter dependências da aplicação em estudo (suas classes, métodos ou alguns outros dados). Nesta fase, converti manualmente, via dex2jar, todos os arquivos DEX da aplicação em estudo em JAR, que então usei ao montar a carga. Mas, além da montagem, para não perder as dependências, antes de executar a carga, é preciso passar os arquivos DEX da aplicação em estudo para o DexRunner. Pode haver muitos arquivos DEX na própria aplicação, e quais deles são necessários para executar a carga é difícil de entender rapidamente.
Quando há muitos arquivos
Em meu plano, espero duas abordagens da implementação do construtor PoC:
Quando a carga é um PoC completo, que é entregue manualmente via Intent.ACTION_OPEN_DOCUMENT e é executado pela interface do usuário DexRunner, pois se considera que a execução ocorrerá sem o modo de desenvolvedor.
Quando a carga é uma verificação intermediária rápida, onde é importante não perder tempo com a transferência, para que as verificações sejam realmente rápidas e o desenvolvimento seja facilitado.
Portanto, para o segundo caso, adicionei automação de entrega e execução no DexRunner via BroadcastReceiver com comandos para carregar (LOAD_BUNDLE) e executar (RUN_BUNDLE).
O DexRunner salva o arquivo DEX (na pasta code_cache) em seu armazenamento pessoal da aplicação, e quando RUN_BUNDLE é chamado, pega a carga desta pasta e a executa. Essa manobra é causada pela contornagem da proteção contra a execução perigosa de código de diretórios de usuários – é quando você pode carregar a carga no diretório /sdcard/, mas não pode executar nada de lá (no futuro, o DEXLab carregará a carga por padrão no diretório /data/local/tmp/, de onde o DexRunner a pegará mais tarde).
Mais tarde, esses comandos Broadcast foram introduzidos no DEXLab, o que tornou possível reproduzir automaticamente o ciclo completo de montagem e preparação para entrega e execução no dispositivo com um único comando da extensão. No entanto, faltava apenas uma coisa – um formato unificado com todos os arquivos necessários para executar, então um formato zip próprio com a extensão ".dexs" foi desenvolvido. Eu o tornei amigo do DexRunner e até conectei uma assinatura a este arquivo via HMAC-SHA256. E aqui, como exemplo, como a carga DEXS montada pode parecer por dentro (destacado – config e, diretamente, a carga):
Quais foram os resultados?
Agora eu gostaria de finalmente percorrer um pouco o uso da própria extensão DEXLab. Nela, coloquei dois comandos para criar um modelo de projeto: com a aplicação em estudo como alvo e sem ela.
Após criar o projeto, a estrutura final do modelo inclui os diretórios e arquivos de configuração necessários com diferentes versões para montagem, bem como um arquivo payload.java básico com um pequeno toast e println, para que você possa obter imediatamente um projeto que seja montado com sucesso e mostre sua atividade. Coloquei os comandos no submenu para dexlab.config.json – o arquivo de configuração do projeto (não confundir com a configuração que é embalada no pacote DEXS). Aconteceu o que pode ser visto na captura de tela abaixo.
[Imagem da Captura de Tela]
Na tela, a árvore do modelo do projeto foi intencionalmente totalmente revelada e toda a funcionalidade possível foi chamada no momento, para que você possa ver o que eu, na verdade, estava buscando. Um leitor atento também notará uma semelhança na experiência do usuário com o APKLab e não é por acaso – como você pode entender, fui em parte inspirado por esta extensão e até mesmo o próprio nome DEXLab de alguma forma sugere isso =)
O que sobre os comandos:
Build and Run on Device – monta e executa com um comando
Build – monta o payload e o empacota em payload.dex
Bundle (.dexs) – empacota todos os arquivos DEX (payload+target) e assina DEXS
Disassemble DEX – descompila payload.dex
Prepare Target – prepara a aplicação em estudo, extraindo todos os arquivos DEX dela e os monta em uma única biblioteca JAR
Deploy to Device – envia payload.dexs e sinaliza DexRunner
Run on Device – sinaliza DexRunner para executar
Set Secret – envia o segredo durante a montagem, se necessário
Install / Update DexRunner – baixa e instala a última compilação de lançamento do github
Download baksmali – baixa baksmali
Download dex2jar – baixa o pacote de utilitários dex2jar
Clean – limpa a montagem
Do saboroso, também recomendo usar a extensão Language Support for Java(TM) by Red Hat, que permite que você se refira lindamente às classes da biblioteca JAR formada, recebida da aplicação em estudo.
Principais características
As características principais do DEXLab são claras, mas como é o próprio DexRunner? Tudo é bastante comum: informações sobre a carga, botões de controle manual e uma atividade separada com logs. Se você executar o modelo de projeto criado pela extensão DEXLab no DexRunner, obterá o Toast curto esperado e mensagens de depuração nos logs.
Resultados
Na verdade, o resultado de tudo isso é que obtive uma ferramenta conveniente e multifuncional para escrever PoCs e pesquisas com a capacidade de incluir o ambiente de trabalho das classes da aplicação em estudo. A ferramenta já demonstrou sua conveniência e demonstra sua principal força – a capacidade de reproduzir PoCs sem alterar o ambiente e sem interferir na aplicação.
Eu acho que este ainda não é o limite de suas capacidades potenciais. Ao testar, algo muito complicado pode aparecer, e isso certamente levará à expansão adicional da funcionalidade. Terei prazer em ler comentários e novas ideias, e por enquanto fui desenhar um ícone para o DexRunner =)
P.S. Publiquei meus trabalhos no Github. Também ficarei feliz com as assinaturas no meu (ainda pequeno e aconchegante) canal do Telegram.
Tags:
segurança
extensão vscode
segurança móvel
pesquisa
segurança móvel
dex
segurança android
android
poc
payload
Hubs:
Blog da Empresa Soluções de Software Seguras
Segurança da Informação
Teste de Aplicações Móveis
Android
Gerenciamento de Desenvolvimento
0
0
0
Soluções de Software Seguras
Site
1
Karma
Anton
@throttlin
Usuário
Inscrever-se
GitHub
O fluxo de desenvolvimento móvel está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr
Habr Cursos para todos
PUBLICIDADE
Prática, Hexlet, SkyPro, cursos do autor — reunimos todos e pedimos descontos. Resta escolher!
Ir
Ir para o fluxo de desenvolvimento móvel
Comentar
Melhor do dia
Semelhante
