EF/CF - o Fuzzer de Contratos (ethereum smart) Extremamente Rápido

EF/CF é uma nova abordagem para fuzzing de contratos inteligentes: em vez de usar um novo fuzzer personalizado, ele reaproveita a infraestrutura de fuzzing existente para código C/C++ e a aplica a contratos inteligentes. Atualmente, o AFL++ é o fuzzer suportado principalmente, embora haja também algum suporte muito rudimentar para libfuzzer e honggfuzz.

Por que usar a infraestrutura de fuzzing existente?

• Velocidade. Conseguimos fuzzar mais rápido. Obtemos regularmente cerca de 20 mil execuções/segundo/núcleo.
• Fuzzers de código nativo são bem projetados e otimizados.
• Orientação por cobertura adequada, gerenciamento de filas, reprodução determinística de casos de teste, etc.

Quais são alguns dos problemas que encontramos pelo caminho?

• Precisamos ensinar ao fuzzer sobre estrutura: ou seja, o que é uma transação e qual é a ABI do contrato inteligente. Usamos um mutador personalizado para isso: ./src/ethmutator/
• Para aumentar a velocidade e obter feedback de cobertura útil, traduzimos o bytecode EVM para C++ usando um transpilador personalizado ./src/evm2cpp/

Este repositório é o ponto de entrada principal para o projeto EF/CF. Ele contém todo o código relevante como subprojetos em ./src/ e vários scripts de conveniência para instalação, scripts para lançar campanhas de fuzzing e diversos conjuntos de dados para testar o fuzzer (e compará-lo com outras ferramentas).

• ./src/ - contém todo o código-fonte necessário para compilar e executar o EF/CF; para reprodutibilidade, todas as dependências diretas são adicionadas como submódulos git.
• ./data/ - contém os conjuntos de dados usados durante a avaliação
• ./scripts - contém scripts para executar experimentos, instalação, etc.
• ./docker - Dockerfile para fluxo de trabalho baseado em contêiner
  • O padrão é Ubuntu, mas você também pode ter um contêiner baseado em Fedora ou Arch Linux se preferir.
  • ./docker/tools/ contém dockerfiles para ferramentas com as quais comparamos o EF/CF. Fizemos o nosso melhor para fixar as versões que avaliamos em nosso artigo nos dockerfiles.
• ./EXPERIMENTS.md - contém um guia para reproduzir os experimentos do nosso artigo.
• ./examples - contém exemplos de saídas produzidas pelo EF/CF

O Artigo do EF/CF

Descrevemos a arquitetura, a implementação e resumimos os resultados de nossa avaliação em nosso artigo: pré-impressão no arxiv

Citação em Trabalhos Acadêmicos

Ao se referir ao EF/CF em trabalhos acadêmicos, use a seguinte entrada bibtex para citar:```bibtex @InProceedings{efcf2023, author = "Michael Rodler and David Paaßen and Wenting Li and Lukas Bernhard and Thorsten Holz and Ghassan Karame and Lucas Davi", title = "EF/CF: High Performance Smart Contract Fuzzing for Exploit Generation", booktitle = "{IEEE} European Symposium on Security and Privacy ({EuroS&P})", publisher = "{IEEE}", year = "2023", }

## Início rápido

A maneira recomendada é executar EF/CF como um contêiner docker interativo.

1. Entre no contêiner com um shell   ```
   docker run --rm -it ghcr.io/uni-due-syssec/efcf-framework

ou construa o container a partir do repositório clonado ``` make gitmodules # to fetch the git submodules make container-enter

1. Compile e então faça fuzz de um contrato solidity até que o primeiro crash/bug seja
descoberto:   ```
efcfuzz --until-crash --out ./baby_bank_results/ --source ./data/examples/baby_bank.sol

2. Inspecione a falha identificada ``` cd /tmp/baby_bank_results/ ./r.sh crashes_min/default_id:000000*

Instalação / Configuração

Submódulos Git

Sem git? se você usa uma release tarball/docker, ignore isto.

Execute git submodule update --init para buscar os últimos commits dos submódulos em repositórios já clonados. Certifique-se de executar isso também em ./src/eEVM.``` git submodule update --init; cd src/eEVM/; git submodule update --init; cd ../../

*Aviso:* Executar `git clone --recursive $repo` ou passar o argumento `--recursive` para `git sumbodule (update|init)` fará com que o git entre recursivamente nos submódulos do repositório AFL++, que não são necessários para este projeto. Portanto, para economizar espaço, é melhor evitar os checkouts recursivos de submódulos.


### Contêiner

Oferecemos os seguintes alvos de conveniência do make para fluxos de trabalho baseados em contêineres:```sh
make container-build  # build default efcf container
make container-enter  # enter default efcf container in current working dir

Se você quiser garantir um build limpo, pode usar o seguinte comando```sh make container-build CLEAN_CHECKOUT=1

Alternativamente, o container pode ser construído com o seguinte comando docker:```sh
docker build \
    -f docker/ubuntu.Dockerfile \
    -t efcf:latest \
    .

Note que há também um Dockerfile baseado em Archlinux e Fedora. Eles devem funcionar também, mas não são tão bem testados.

Para distribuir manualmente uma imagem docker (por exemplo, se incluindo algumas alterações locais), use:``` make container-release docker load -i ./efcf*.tar

Recomendamos as seguintes opções do docker para execução:

* `--security-opt seccomp=unconfined` - melhor desempenho de fuzzing
* `--net=host` - para acesso fácil a um nó Ethereum local
* `--tmpfs "/tmp/efcf/":exec,size=6g` - coloque os arquivos temporários do EF/CF em um ramdisk, se possível (menos desgaste do disco)
* `--privileged` - para executar `afl-system-config` ou `efcfuzz --configure-system`
* `-v` - para persistir os dados de saída do EF/CF


### VM / Bare-Metal

Para fluxos de trabalho baseados em VM ou bare-metal:```sh
make system-install   # install efcf to current system (requires root or sudo rights)

Note que muitos dos scripts funcionam com a estrutura de diretórios relativa de qualquer forma, então isso principalmente instala dependências e algumas ferramentas que são úteis de ter no seu PATH. Testamos a execução de EF/CF nas seguintes distribuições Linux:

• Ubuntu Jammy (ou posterior)
• Fedora ($ > 35 $)
• Archlinux

(A distribuição não importa muito; testamos LLVM 13 e 14, sendo o 14 a escolha preferida. LLVM 11 ou 12 também podem funcionar, mas como sempre — quanto mais novo, melhor. O importante é que exista um LLVM compatível com o nosso fork do AFL++.)

No Mac OS / M1