EF/CF - el Fuzzer de Contratos Inteligentes de Ethereum Extremadamente Rápido

EF/CF es un nuevo enfoque para el fuzzing de contratos inteligentes: en lugar de usar un nuevo fuzzer construido a medida, reutiliza la infraestructura de fuzzing existente de C/C++ para contratos inteligentes. Actualmente, AFL++ es el fuzzer soportado principalmente, aunque hay también un soporte muy rudimentario para libfuzzer y honggfuzz.

¿Por qué usar la infraestructura de fuzzing existente?

• Velocidad. Podemos fuzzear más rápido. Normalmente conseguimos alrededor de 20k ejecuciones/seg/núcleo.
• Los fuzzers de código nativo están bien diseñados y optimizados.
• Orientación por cobertura, gestión de colas, reproducción determinista de casos de prueba, etc.

¿Cuáles son algunos de los problemas que encontramos en el camino?

• Necesitamos enseñar al fuzzer sobre la estructura: es decir, qué es una transacción y cuál es la ABI del contrato inteligente. Usamos un mutador personalizado para esto: ./src/ethmutator/
• Para aumentar la velocidad y obtener una retroalimentación de cobertura útil, traducimos el bytecode de EVM a C++ usando un transpilador personalizado ./src/evm2cpp/

Este repositorio es el punto de entrada principal para el proyecto EF/CF. Contiene todo el código relevante como subproyectos en ./src/ y varios scripts de conveniencia para la instalación, scripts para lanzar campañas de fuzzing y varios conjuntos de datos para probar el fuzzer (y compararlo con otras herramientas).

• ./src/ - contiene todo el código fuente necesario para construir y ejecutar EF/CF; para la reproducibilidad, todas las dependencias directas se añaden como submódulos de git.
• ./data/ - contiene los conjuntos de datos utilizados durante la evaluación
• ./scripts - contiene scripts para ejecutar experimentos, instalación, etc.
• ./docker - Dockerfile para el flujo de trabajo basado en contenedores
  • El estándar es Ubuntu, pero también puedes tener un contenedor basado en Fedora o Arch Linux si lo prefieres.
  • ./docker/tools/ contiene dockerfiles para las herramientas con las que evaluamos EF/CF Hicimos todo lo posible por fijar las versiones que evaluamos en nuestro artículo en los dockerfiles.
• ./EXPERIMENTS.md - contiene una guía para reproducir los experimentos de nuestro artículo.
• ./examples - contiene ejemplos de salidas producidas por EF/CF

El artículo de EF/CF

Describimos la arquitectura e implementación de EF/CF y resumimos nuestra evaluación resultados en nuestro artículo: preprint de arxiv.org

Cita en Trabajos Académicos

Cuando se refiera a EF/CF en trabajos académicos, utilice la siguiente entrada bibtex para la cita:```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", }

## Inicio rápido

La forma recomendada es ejecutar EF/CF como un contenedor docker interactivo.

1. Entra en el contenedor con una shell   ```
   docker run --rm -it ghcr.io/uni-due-syssec/efcf-framework

o construye el contenedor desde el repositorio clonado ``` make gitmodules # to fetch the git submodules make container-enter

1. Compilar y luego fuzzear un contrato solidity hasta que se descubra el
primer fallo/error:   ```
efcfuzz --until-crash --out ./baby_bank_results/ --source ./data/examples/baby_bank.sol

2. Inspeccione el fallo identificado ``` cd /tmp/baby_bank_results/ ./r.sh crashes_min/default_id:000000*

Instalación / Configuración

Submódulos de Git

¿Sin git? Si usas una versión tarball/docker, ignora esto.

Ejecuta git submodule update --init para obtener los últimos commits de los submódulos en repositorios ya clonados. Asegúrate de ejecutar esto también en ./src/eEVM.``` git submodule update --init; cd src/eEVM/; git submodule update --init; cd ../../

*Advertencia:* Ejecutar `git clone --recursive $repo` o pasar el argumento `--recursive` a `git sumbodule (update|init)` hará que git entre de forma recursiva en los submódulos del repositorio AFL++, que no son necesarios para este proyecto. Así que para ahorrar espacio es mejor evitar los checkouts recursivos de submódulos.


### Contenedor

Proporcionamos los siguientes objetivos make de conveniencia para flujos de trabajo basados en contenedores:```sh
make container-build  # build default efcf container
make container-enter  # enter default efcf container in current working dir

Si quieres asegurar una compilación limpia, puedes usar el siguiente comando```sh make container-build CLEAN_CHECKOUT=1

Alternativamente, el contenedor puede construirse con el siguiente comando de docker:```sh
docker build \
    -f docker/ubuntu.Dockerfile \
    -t efcf:latest \
    .

Tenga en cuenta que también hay un Dockerfile basado en Archlinux y Fedora. Deberían funcionar también, pero no están tan probados.

Para distribuir manualmente una imagen de Docker (p. ej., si se incluyen algunos cambios locales), use:``` make container-release docker load -i ./efcf*.tar

Recomendamos las siguientes opciones de Docker para el lanzamiento:

* `--security-opt seccomp=unconfined` - mejor rendimiento de fuzzing
* `--net=host` - para acceso fácil a un nodo Ethereum local
* `--tmpfs "/tmp/efcf/":exec,size=6g` - poner los archivos temporales de EF/CF en un ramdisk si es posible (menos desgaste del disco)
* `--privileged` - para ejecutar `afl-system-config` o `efcfuzz --configure-system`
* `-v` - para persistir los datos de salida de EF/CF


### VM / Bare-Metal

Para flujos de trabajo basados en VM o bare-metal:```sh
make system-install   # install efcf to current system (requires root or sudo rights)

Ten en cuenta que muchos de los scripts funcionan con el diseño de directorios relativos de todos modos, por lo que esto principalmente instala dependencias y algunas herramientas que son útiles tener en tu PATH. Hemos probado ejecutar EF/CF en las siguientes distribuciones de Linux:

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

(La distribución no importa demasiado, probamos LLVM 13 y 14, siendo 14 la opción preferida. LLVM 11 o 12 también podrían seguir funcionando, pero como siempre - cuanto más nuevo, mejor. La parte importante es que haya un LLVM que sea compatible con nuestro fork de AFL++.)

En Mac OS / M1