Fuzzing de Sistemas Embarcados usando Breakpoints de Hardware
Este é o código complementar para o artigo: 'Fuzzing Embedded Systems using Debugger Interfaces'. Uma pré-impressão do artigo pode ser encontrada aqui https://publications.cispa.saarland/3950/. O código permite que os usuários reproduzam e estendam os resultados relatados no artigo. Por favor, cite o artigo acima ao reportar, reproduzir ou estender os resultados.
.
├── benchmark # Scripts para construir o conjunto de teste de fuzzer do Google e executar experimentos
├── dependencies # Contém um Makefile para instalar dependências para o GDBFuzz
├── evaluation # Dados brutos dos experimentos, apresentados no artigo
├── example_firmware # Aplicações de exemplo embarcadas, usadas para a avaliação
├── example_programs # Contém um programa de exemplo compilado e configurações para testar o GDBFuzz
├── src # Contém a implementação do GDBFuzz
├── Dockerfile # Para criar uma imagem Docker com todas as dependências do GDBFuzz instaladas
├── LICENSE # Licença
├── Makefile # Makefile para criar a imagem Docker ou instalar o GDBFuzz localmente
└── README.md # Este arquivo README
A ideia do GDBFuzz é aproveitar pontos de interrupção de hardware de microcontroladores como feedback para fuzzing guiado por cobertura. Para isso, o GDB é usado como uma interface genérica para permitir ampla aplicabilidade. Para análise binária do firmware, o Ghidra é usado. O código contém uma configuração de benchmark para avaliar o método. Além disso, arquivos de firmware de exemplo estão incluídos.
O GDBFuzz permite fuzzing guiado por cobertura para sistemas embarcados, mas - para fins de avaliação - também pode fuzzar aplicações de usuário arbitrárias. Para fuzzing em microcontroladores, recomendamos uma instalação local do GDBFuzz para poder enviar dados de fuzz para o dispositivo sob teste sem problemas.
O GDBFuzz foi testado no Ubuntu 20.04 LTS e no Raspberry Pi OS 32 bits. Pré-requisitos são java e python3. Primeiro, crie um novo ambiente virtual e instale todas as dependências.
virtualenv .venv
source .venv/bin/activate
make
chmod a+x ./src/GDBFuzz/main.py
O GDBFuzz lê configurações de um arquivo de configuração com as seguintes chaves.
[SUT]
# Caminho para o arquivo binário do SUT.
# Isso pode ser, por exemplo, um arquivo .elf ou um arquivo .bin.
binary_file_path = <caminho>
# Endereço do nó raiz do CFG.
# Pontos de interrupção são colocados em nós deste CFG.
# ex.: 'LLVMFuzzerTestOneInput' ou 'main'
entrypoint = <ponto_de_entrada>
# Número de entradas que devem ser executadas sem um ponto de interrupção ser atingido até
# que os pontos de interrupção sejam rotacionados.
until_rotate_breakpoints = <número>
# Número máximo de pontos de interrupção que podem ser colocados a qualquer momento.
max_breakpoints = <número>
# Lista de funções que devem ser ignoradas.
# ignore_functions é uma lista de nomes de funções separados por espaço, ex.: 'malloc free'.
ignore_functions = <lista separada por espaço>
# Um de {Hardware, QEMU, SUTRunsOnHost}
# Hardware: Um componente externo inicia um servidor gdb e o GDBFuzz pode se conectar a esse servidor gdb.
# QEMU: O GDBFuzz inicia o QEMU. O QEMU emula binary_file_path e inicia o gdbserver.
# SUTRunsOnHost: O GDBFuzz inicia o programa alvo dentro do GDB.
target_mode = <modo>
# Defina como False se você quiser iniciar o ghidra, analisar o SUT
# e iniciar o servidor bridge do ghidra manualmente.
start_ghidra = True
# Lista separada por espaços de endereços onde pontos de interrupção de software (para código
# de tratamento de erros) são definidos. A execução destes é considerada uma falha.
# Exemplo: software_breakpoint_addresses = 0x123 0x432
software_breakpoint_addresses =
# Se todos os pontos de interrupção de software acionados são considerados como falha
consider_sw_breakpoint_as_error = False
[SUTConnection]
# A classe 'SUT_connection_class' no arquivo 'SUT_connection_path' implementa
# como as entradas são enviadas para o SUT.
# As entradas podem, por exemplo, ser enviadas via Wi-Fi, Serial, Bluetooth, ...
# Esta classe deve herdar de ./connections/SUTConnection.py.
# Veja ./connections/SUTConnection.py para mais informações.
SUT_connection_file = FIFOConnection.py
[GDB]
path_to_gdb = gdb-multiarch
#Escrito como endereço:porta
gdb_server_address = localhost:4242
[Fuzzer]
# Em bytes
maximum_input_length = 100000
# Em segundos
single_run_timeout = 20
# Em segundos
total_runtime = 3600
# Opcional
# Caminho para um diretório onde cada arquivo contém uma semente. Se você não quiser
# usar sementes, deixe o valor vazio.
seeds_directory =
[BreakpointStrategy]
# As estratégias para escolher blocos básicos estão localizadas em
# 'src/GDBFuzz/breakpoint_strategies/'
# Para o artigo, usamos as seguintes estratégias
# 'RandomBasicBlockStrategy.py' - Escolhe aleatoriamente blocos básicos não alcançados
# 'RandomBasicBlockNoDomStrategy.py' - Como o anterior, mas não usa relações de dominância para derivar nós transitivamente alcançados.
# 'RandomBasicBlockNoCorpusStrategy.py' - Como o primeiro, mas impede o crescimento do corpus de entrada e, portanto, se comporta como fuzzing de caixa preta com medição de cobertura.
# 'BlackboxStrategy.py' - Não define nenhum ponto de interrupção
breakpoint_strategy_file = RandomBasicBlockStrategy.py
[Dependencies]
path_to_qemu = dependencies/qemu/build/x86_64-linux-user/qemu-x86_64
path_to_ghidra = dependencies/ghidra
[LogsAndVisualizations]
# Um de {DEBUG, INFO, WARNING, ERROR, CRITICAL}
loglevel = INFO
# Caminho para um diretório onde os arquivos de saída (ex.: gráficos, arquivos de log) são armazenados.
output_directory = ./output
# Se definido como True, um cliente MQTT envia elementos de UI (ex.: gráficos)
enable_UI = False
Um exemplo de arquivo de configuração está localizado em ./example_programs/ junto com um programa de exemplo que foi compilado usando nosso harness de fuzzing em benchmark/benchSUTs/GDBFuzz_wrapper/common/.
Inicie o fuzzing por uma hora com o seguinte comando.
chmod a+x ./example_programs/json-2017-02-12
./src/GDBFuzz/main.py --config ./example_programs/fuzz_json.cfg
Primeiro vemos a saída do Ghidra analisando o executável binário e, em seguida, mensagens quando os pontos de interrupção são realocados ou atingidos.
Dependendo do output_directory especificado no arquivo de configuração, agora deve haver uma pasta trial-0 com a seguinte estrutura
.
├── corpus # Uma pasta que contém o corpus de entrada.
├── crashes # Uma pasta que contém entradas que causam falha - se houver.
├── cfg # O grafo de fluxo de controle como lista de adjacência.
├── fuzzer_stats # Estatísticas da campanha de fuzzing.
├── plot_data # Tabela mostrando em qual tempo relativo na campanha de fuzzing qual bloco básico foi alcançado.
├── reverse_cfg # O grafo de fluxo de controle reverso.
Definindo start_ghidra = False no arquivo de configuração, o GDBFuzz se conecta a uma instância do Ghidra executando no modo GUI. Portanto, o plugin ghidra_bridge precisa ser iniciado manualmente a partir do gerenciador de scripts. Durante o fuzzing, os blocos de programa alcançados são destacados em verde.