fpicker

fpicker é um conjunto de fuzzing baseado em Frida que oferece uma variedade de modos de fuzzing para fuzzing em processo, como um modo AFL++ ou um modo de rastreamento passivo. Deve funcionar em todas as plataformas suportadas pelo Frida.

• Instruções de Instalação
• Construção e Execução
• Criação de um Harness de Fuzzing
• Modos e Configuração

Algumas informações de contexto e os pensamentos e ideias por trás do fpicker podem ser encontrados em um post de blog que escrevi.

Fpicker é baseado em esforços anteriores em ToothPicker, que foi desenvolvido durante minha dissertação de mestrado. A maior parte do fpicker foi desenvolvida durante o horário de trabalho no meu empregador (ERNW).

Requisitos e Instalação

Requisitos para executar o fpicker:

• frida_compile para compilar o script do harness em um único arquivo JS
• O frida-core-devkit para a respectiva plataforma encontrado em Frida releases no GitHub.
  • Dependendo da plataforma que você deseja segmentar, armazene a biblioteca como libfrida-core-ios.a, libfrida-core-macos.a ou libfrida-core-linux.a.
  • O mesmo vale para os arquivos de cabeçalho (frida-core.h). Armazene-os como frida-core-linux.h ou frida-core-ios.h dependendo da plataforma.
  • O Makefile foi construído desta forma para que você possa compilar para diferentes sistemas no mesmo sistema (por exemplo, seu sistema host e o telefone).
  • Se você preferir usar uma versão específica, ajuste o Makefile de acordo.
  • Para atualizar para a versão mais recente, basta executar update_frida_version.sh antes de compilar.

Requerido apenas ao executar no modo AFL++:

• AFL++
  • no macOS:
    • Compile com CFLAGS="-DUSEMMAP=1".
  • no iOS:
    • Compile com CFLAGS="-DUSEMMAP=1 -DTARGET_OS_IOS".

Construção e Execução

O Fpicker pode ser compilado para macOS, iOS ou Linux. O Makefile atualmente suporta apenas a compilação para iOS no macOS, mas deve ser totalmente possível compilar o fpicker usando um toolchain do iOS no Linux.

Dependendo do alvo desejado, execute:

make fpicker-macos
make fpicker-ios
make fpicker-linux

para compilar o fpicker.

Após compilar o fpicker, o harness de fuzzing precisa ser compilado em seguida:

Veja a pasta de exemplos para diferentes casos de fuzzing de exemplo. A abordagem geral é a seguinte:

• Crie um harness personalizado para o alvo (por exemplo, examples/test/test.js) (veja aqui para mais informações sobre harnesses)
• Compile o harness personalizado usando o frida-compile frida-compile test.js -o harness.js

Agora o fpicker pode começar a fazer fuzzing. O comando exato depende muito da configuração e da montagem. A seguir, alguns casos de exemplo são fornecidos. Eles correspondem principalmente aos exemplos na pasta de exemplos.

• Execute o fpicker como proxy AFL++ anexando a um processo alvo fuzzing uma função específica em processo:

afl-fuzz -i examples/test-network/in -o ./examples/test-network/out -- \\
    ./fpicker --fuzzer-mode afl -e attach -p test-network -f ./examples/test-network/harness.js

• Execute o fpicker no modo autônomo anexando a um servidor e executando um programa cliente para enviar a entrada de fuzzing:

./fpicker --fuzzer-mode standalone -e attach -p server-process -f harness.js --input-mode cmd \\
    --command "./client-send @@" -i indir -o outdir

• Execute o fpicker no modo autônomo anexando a um servidor, fuzzing em processo com um comando mutator personalizado:

./fpicker --fuzzer-mode active --communication-mode shm -e attach -p server-process -f harness.js \\
    -i indir -o outdir --standalone-mutator cmd --mutator-command "radamsa"

• Execute o fpicker no modo passivo anexando a um servidor coletando cobertura e payloads:

./fpicker --fuzzer-mode passive --communication-mode send -e attach -p server-process -o outdir -f harness.js

• Execute o fpicker no modo autônomo anexando a um processo em execução em um dispositivo remoto, fuzzing em processo com um comando mutator personalizado:

./fpicker --fuzzer-mode active -e attach -p test -D remote -o examples/test/out/ -i examples/test/in/ \\
    -f fuzzer-agent.js --standalone-mutator cmd --mutator-command "radamsa"

Criação de um Harness de Fuzzing

Cada alvo requer seu próprio harness de fuzzing. A parte mais importante deste harness é definir a função de entrada do Stalker do Frida, que efetivamente determina em que ponto a instrumentação é inserida. No modo in-process isso é simples. A função geralmente seria a que é chamada em cada iteração de fuzzing. No entanto, poderia ser uma diferente.

Uma implementação mínima de harness (no modo command) poderia ser esta:

// Import the fuzzer base class
const Fuzzer = require("harness/fuzzer.js");

// The custom fuzzer needs to subclass the Fuzzer class to work properly
class TestFuzzer extends Fuzzer.Fuzzer {
    constructor() {
        // The constructor needs to specify the address of the targeted function and a NativeFunction
        // object that can later be called by the fuzzer.

        const FUZZ_FUNCTION_ADDR = Module.getExportByName(null, "FUZZ_FUNCTION");
        const FUZZ_FUNCTION = new NativeFunction(
            FUZZ_FUNCTION_ADDR,
            "void", ["pointer", "int64"], {
        });

        super("test", FUZZ_FUNCTION_ADDR, FUZZ_FUNCTION);
    }
}

const f = new TestFuzzer();
exports.fuzzer = f;

Este harness configura a instrumentação para seguir a função FUZZ_FUNCTION. A instrumentação começará quando esta função for inserida e para quando a função retornar. Esta função deve ser escolhida cuidadosamente, pois é cara e quanto mais partes (potencialmente não importantes) do processo forem instrumentadas, mais lento o fuzzer fica. Claro, isso é uma consideração entre velocidade e cobertura pretendida. Além disso, o fuzzer atualmente suporta apenas funções que são inseridas apenas uma vez durante uma iteração de fuzzing, ou seja, a função não deve ser chamada mais de uma vez durante um caso de fuzzing, caso contrário as informações de cobertura podem se tornar não confiáveis.

Quando o modo in-process é usado, outra função é necessária no script do fuzzer. O método fuzz. Ele será chamado em cada iteração. Será chamado com dois parâmetros, um ponteiro para um buffer e o comprimento do buffer. Nossa função alvo exemplar recebe dois parâmetros, um ponteiro para um buffer e seu comprimento. Assim, podemos simplesmente passar os parâmetros que recebemos no método fuzz.

fuzz(payload, len) {
    this.target_function(payload, parseInt(len));
}

No modo passive, um callback precisa ser especificado para processar os dados necessários. O fuzzer espera receber um buffer de payload e seu comprimento. Dependendo da função alvo que está sendo fuzzeada, esses dados precisam ser extraídos. No exemplo a seguir, novamente temos uma função que tem dois parâmetros: um ponteiro para um buffer e seu comprimento. O parâmetro args contém todos os parâmetros potenciais que a função alvo recebe, então o parâmetro de comprimento (que é o segundo no nosso caso) pode ser acessado com args[1]. Em seguida, lemos o buffer como Uint8Array e o enviamos de volta para o fuzzer usando o método sendPassiveCorpus.

passiveCallback(args) {
    const len = args[1];
    const data = new Uint8Array(Memory.readByteArray(args[0], parseInt(len)));

    // this encodes the data and sends it back to the fuzzer
    this.sendPassiveCorpus(data, len);
}

Caso o alvo precise de algum tipo de preparação antes do fuzzer iniciar, o fpicker fornece um método prepare que é chamado durante a inicialização do fuzzer. A preparação pode ser o estabelecimento de estado, por exemplo, instanciando um objeto. Tal função de preparação poderia ser assim:

prepare() {
  // the object can be attached to the fuzzer instance so that it can be used within the
  // fuzz() method later on.
  this.required_object = call_native_function_that_creates_object();
}

Modos e Configuração

pficker oferece um grande conjunto de modos e configurações que são explicados a seguir. A maioria desses modos pode ser combinada de diferentes maneiras. No final desta seção há uma tabela que mostra quais opções podem ser combinadas e qual é o status de implementação delas.

Modo Fuzzer

Fpicker tem três diferentes modos de fuzzing: Modo AFL++, Modo Autônomo Ativo e Modo Autônomo Passivo:

• Modo AFL++: No modo AFL++, o fpicker atua como um proxy entre o AFL++ e o processo alvo. Usando as capacidades de instrumentação do Frida, o bitmap de cobertura do AFL é preenchido enquanto o alvo é fuzzeado com dados de entrada gerados pelo AFL++.
• Modo Autônomo Ativo: No modo autônomo ativo, o fuzzer usa os resumos de chamada do Stalker do Frida para coletar cobertura na forma de blocos básicos que são executados durante uma iteração. Isso não é novo e já foi implementado de várias formas antes. No entanto, em combinação com algumas das outras configurações do fuzzer, isso pode ter vários benefícios. Também é uma boa alternativa se o AFL++ não for aplicável ou desejado em um determinado ambiente ou caso.
• Modo Autônomo Passivo: O modo passivo é menos um fuzzer e mais um tracer. Essencialmente, ele faz o mesmo que o modo autônomo ativo. No entanto, ele não envia suas próprias entradas. Ele apenas anexa a uma determinada função e coleta cobertura. Uma vez observada nova cobertura, tanto a cobertura quanto a entrada são armazenadas.

Modo de Entrada

Embora o fpicker seja amplamente projetado como um fuzzer em processo, ele também suporta fuzzing por meio de um comando externo. Para isso, o fpicker oferece dois modos de entrada.

• Modo de Entrada Em Processo: No modo de entrada em processo, o harness chama diretamente uma função especificada no processo alvo. O fuzzer envia o payload para o harness e o harness prepara o payload de forma que ele possa chamar a função alvo.
• Modo de Entrada CMD: No modo de entrada por comando, o payload é redirecionado para um comando externo. Isso é útil quando é muito complexo preparar os parâmetros ou outro estado ao chamar diretamente a função alvo. A coleta de cobertura ainda precisa ser anexada a uma determinada função. Talvez haja um cliente que possa receber um payload que então aciona a função alvo.

Modo de Comunicação

O modo de comunicação determina como o harness injetado se comunica com o fuzzer. Isso depende em grande parte da aplicação alvo. O Frida oferece uma API para enviar e receber mensagens do script agente injetado. Esse tipo de comunicação é bastante custoso. Um dos fatores é que a mensagem transportada precisa ser codificada em JSON. Portanto, enviar dados binários é mais direto. Assim, o fpicker oferece um segundo modo de comunicação por memória compartilhada. No entanto, isso só funciona se for possível estabelecer memória compartilhada entre o fuzzer e a aplicação alvo, o que significa que este modo não pode ser usado quando o alvo está anexado ao host do fuzzer via USB. No modo de entrada CMD, o modo de comunicação refere-se apenas a como a informação de cobertura é comunicada de volta ao fuzzer, não a como o payload é enviado, pois isso é delegado a um comando externo.

• Modo de Comunicação Send: No modo de comunicação send, o payload é enviado usando o mecanismo de chamada RPC do Frida. Isso permite que o fuzzer execute uma função JavaScript dentro do script do harness injetado. Essa função dentro do harness pode então fazer todas as preparações necessárias para chamar a função alvo. Uma vez que a função alvo retorna, a coleta de cobertura para e o harness pode sinalizar ao fuzzer que a iteração terminou. Isso é feito enviando as informações de cobertura de volta ao fuzzer usando a API send do Frida.
• Modo de Comunicação SHM: No modo de comunicação SHM, o fuzzer e o script do harness se comunicam via memória compartilhada e semáforos. Um buffer na memória compartilhada é usado para enviar o payload e receber as informações de cobertura. Em vez de enviar e receber, os dois componentes usam espera e postagem no semáforo. Dependendo do sistema e do alvo, isso introduz ganhos de desempenho consideráveis. Especialmente porque o payload binário é escrito na memória uma vez e não precisa ser codificado e decodificado ou copiado para outros locais de memória. Infelizmente, esse modo às vezes leva a uma baixa estabilidade ao executar com AFL++. Ainda não sei o porquê.

Modo de Execução

O modo de execução pode ser spawn ou attach. Isso é bastante autoexplicativo. O fpicker pode anexar a um processo em execução ou gerar um processo. Uma coisa que é uma grande diferença entre os dois modos é que, se o alvo anexado falhar, o fpicker não tentará gerar novamente.

Mutator Autônomo

No modo autônomo, o fpicker oferece três estratégias diferentes de mutação de entrada. Dito de forma elegante, a mutação de entrada certamente tem muito espaço para melhoria.

• Mutator Autônomo NULL: Este mutator não muta o payload e apenas retorna uma cópia do mesmo payload. Principalmente para fins de teste. Caso contrário, não é realmente útil.
• Mutator Autônomo Rand: Um mutator aleatório muito ruim. Tudo o que faz é substituir aleatoriamente valores em locais aleatórios no payload original. Não altera o comprimento do payload.
• Mutator Autônomo Personalizado: Este mutator pode chamar um comando externo para mutar payloads. Ele escreve o payload no stdin e recebe o payload mutado do stdout. Devido à sua implementação superficial, tem um impacto considerável no desempenho.

Dispositivos USB

Usando a opção de dispositivo -D usb, o Frida selecionará o primeiro dispositivo USB local, por exemplo, um iPhone ou telefone Android.

Dispositivos de rede

Com a opção -D remote, é possível fuzzear um processo em execução em um dispositivo de rede. Para isso, o dispositivo remoto deve estar executando o frida-server. Como configuração de exemplo, use SSH com encaminhamento de porta para vincular a porta de escuta padrão 27042 do frida-server no dispositivo remoto a um soquete no cliente local.

ssh -N [email protected] -L 127.0.0.1:27042:127.0.0.1:27042

Em um iPhone, também é possível usar o iproxy para encaminhar a porta de uma conexão USB. Isso pode ser especialmente útil se estiver executando o Frida em uma porta não padrão em um dispositivo não desbloqueado com o Frida gadget. Ao trabalhar com o Frida gadget, o único processo disponível terá o nome Gadget, independentemente do nome do aplicativo alvo.

iproxy 27042 27042

Em seguida, use frida-ps para validar a configuração listando processos no dispositivo remoto:

frida-ps -R