INVESTIGAÇÃO DE SOFTWARE / ESCOPO AUTORIZADO

Quando é preciso
entender por dentro.

Engenharia reversa é uma das ferramentas para investigar sistemas existentes. Cada trabalho depende do material, do ambiente e de permissões compatíveis.

Apresentar um desafio ↗

RASTRO LAB / ENGENHARIA REVERSA AVANÇADA

Por dentro do código.
No limite da complexidade.

De uma função escondida em um executável ao comportamento de um aplicativo em execução: explore as investigações mais profundas que o REA pode apoiar.

Explorar projetos avançados ↓
UMA FUNCIONALIDADE. VÁRIAS CAMADAS DE EVIDÊNCIA.EXEMPLO CONCEITUAL
01 / INTERFACEUma ação
do usuário
→
02 / APLICAÇÃOEventos, rotas
e módulos
→
03 / EXECUÇÃOChamadas, valores
e respostas
→
04 / EXPLICAÇÃOFluxo documentado
e limites conhecidos

As camadas disponíveis variam conforme o alvo, o sistema operacional e as ferramentas configuradas.

01 / BINÁRIOS NATIVOSALTA COMPLEXIDADE

Entender uma função
sem ter o código-fonte.

Investigar instruções, pseudocódigo, referências, chamadas e tipos para explicar a lógica de uma rotina compilada.

EXEMPLO DE DEMANDA

“Como este executável interpreta o arquivo que meu sistema precisa importar?”

O que um projeto pode entregar +
  • Dossiê das funções e caminhos investigados.
  • Evidências de entradas, estruturas e decisões identificadas.
  • Documentação para orientar uma integração autorizada.

Requer motor como Ghidra, Hopper ou IDA, host e formato compatíveis. Não recupera automaticamente o fonte original. No Windows, há um escopo específico de suporte.

Capacidade documentada ↗

02 / RASTREAMENTO ENTRE CAMADASALTA COMPLEXIDADE

Seguir uma funcionalidade
por dentro do aplicativo.

Relacionar módulos, eventos, IPC e observações de execução em aplicações JavaScript/Electron, preservando o que foi observado e o que foi inferido.

EXEMPLO DE DEMANDA

“O que acontece entre clicar em Exportar e receber o arquivo final?”

O que um projeto pode entregar +
  • Mapa do fluxo e dos componentes relacionados.
  • Comparação de estrutura estática com observações de execução.
  • Pontos desconhecidos e experimentos para investigá-los.

O grafo estático não comprova execução. Observações dinâmicas dependem de cenário reproduzível, acesso e configuração do runtime.

Capacidade documentada ↗

03 / INSTRUMENTAÇÃO DINÂMICALABORATÓRIO CONTROLADO

Observar o software
enquanto ele funciona.

Usar sessões de instrumentação compatíveis, inclusive Frida, para observar chamadas e mensagens de um processo autorizado em um experimento delimitado.

EXEMPLO DE DEMANDA

“Que valores passam por esta rotina quando o problema acontece?”

O que um projeto pode entregar +
  • Plano do experimento e cenário de reprodução.
  • Registro das observações capturadas e sua cobertura.
  • Correlação com hipóteses técnicas sobre o comportamento.

Exige runtime, dispositivos e permissões compatíveis. Scripts de instrumentação executam no processo e podem alterar seu comportamento; o ambiente e o escopo são combinados antes.

Capacidade documentada ↗

04 / RECONSTRUÇÃO ORIENTADAPROJETO EM ETAPAS

Investigar uma função.
Orientar sua reimplementação.

Usar evidências para especificar um comportamento e apoiar uma implementação própria, com critérios de comparação definidos para um conjunto finito de casos.

EXEMPLO DE DEMANDA

“Podemos substituir esta rotina legada por uma implementação que atenda aos nossos casos?”

O que um projeto pode entregar +
  • Especificação delimitada do comportamento investigado.
  • Registro de requisitos, evidências e pontos desconhecidos.
  • Implementação e testes separados, quando contratados e viáveis.

O REA auxilia a investigação e a avaliação de evidências; a implementação exige desenvolvimento. Passar nos casos definidos não prova equivalência universal nem permite garantir uma cópia integral.

Fluxos documentados ↗

05 / ANDROID EM PROFUNDIDADEMOTORES EXTERNOS

Investigar classes, métodos
e relações de um APK.

Com JADX configurado, examinar manifesto, classes, métodos decompilados e referências. Recursos e dispositivos têm fluxos adicionais com ferramentas próprias.

EXEMPLO DE DEMANDA

“Em quais componentes esta funcionalidade está implementada e como eles se relacionam?”

O que um projeto pode entregar +
  • Mapa dos componentes e métodos investigados.
  • Evidências de relações entre classes e referências.
  • Orientação de próximos passos para manutenção ou integração.

Exige JADX/JDK; recursos podem exigir Apktool e dispositivo exige ADB. Ofuscação e código nativo podem limitar resultados e exigir outro motor.

Capacidade documentada ↗

06 / FIRMWARE & EMBARCADOSAMBIENTE LINUX

Explorar as camadas
de uma imagem de firmware.

Inspecionar regiões e extrair componentes de formatos suportados com Binwalk/Unblob, registrando a origem, os hashes e as lacunas de extração.

EXEMPLO DE DEMANDA

“O que existe nesta imagem do nosso equipamento e quais partes conseguimos examinar?”

O que um projeto pode entregar +
  • Inventário das regiões e componentes encontrados.
  • Relações e identidade dos arquivos extraídos.
  • Plano de análise das partes acessíveis.

Requer Linux e ferramentas externas. Conteúdo cifrado, formatos desconhecidos e falhas de extração permanecem explicitamente em aberto. Extração não é reconstrução completa.

Capacidade documentada ↗

07 / CRASHES & EVIDÊNCIA HISTÓRICAAMBIENTE LINUX

Investigar o estado
registrado em uma falha.

Examinar core dumps Linux suportados: threads, registradores, sinais e regiões registradas; enriquecer o contexto com ferramentas compatíveis quando disponíveis.

EXEMPLO DE DEMANDA

“Que evidências ficaram no arquivo de crash quando o processo caiu?”

O que um projeto pode entregar +
  • Relatório do estado efetivamente registrado.
  • Hipóteses vinculadas aos dados disponíveis.
  • Orientação de reprodução e coleta complementar.

Fluxo específico para cores ELF64 Linux e arquiteturas admitidas, com dependências externas. Memória ausente e contexto desconhecido não são reconstruídos por suposição.

Capacidade documentada ↗

08 / DIFERENÇAS DE COMPORTAMENTOINVESTIGAÇÃO COMPARATIVA

Descobrir o que mudou
onde realmente importa.

Comparar artefatos e, nos fluxos suportados, relacionar diferenças de código, módulos e cenários registrados a uma funcionalidade específica.

EXEMPLO DE DEMANDA

“Por que esta integração se comporta diferente na nova versão?”

O que um projeto pode entregar +
  • Diferenças relevantes para a pergunta acordada.
  • Evidências comparáveis entre os materiais recebidos.
  • Hipóteses de impacto e critérios de validação.

É necessário ter versões e evidências comparáveis. Uma diferença encontrada não estabelece, sozinha, a causa de uma falha.

Fluxo documentado ↗

A INVESTIGAÇÃO COMEÇA PELA VIABILIDADE.

Seu desafio exige ir mais fundo?

Projetos avançados têm proposta própria, preparação de ambiente e marcos de entrega definidos após avaliação. Os exemplos acima são demandas ilustrativas, não casos já executados pela Rastro Lab.

Apresentar um desafio avançado ↗
Capacidade do ecossistema REA × ambiente preparado

Esta vitrine apresenta possibilidades documentadas do REA. Neste notebook, a integração básica foi validada. Motores de análise nativa, Android, instrumentação e ambientes Linux/macOS precisam de preparação e validação específicas antes de aceitar esses projetos.

Entender cookies e medição