bin2cet artifacts

BIN2CET Artifact
================

This artifact supports the claims of "Retrofitting Intel CET’s Indirect Branch Tracking into Legacy Binaries through Static Binary Rewriting." paper published in XXVI Simpósio Brasileiro de Cibersegurança (SBSeg) 2026.

The aforementioned paper presents BIN2CET, an automated static binary rewriting system for retrofitting Intel CET’s Indirect Branch Tracking (IBT) support into legacy ELF binaries.
BIN2CET combines endbr64-based target instrumentation, relocation-aware trampolines to preserve overwritten instructions, and conservative notrack handling for indirect branches that cannot be safely normalized.

The purpose of this artifact is to provide the environment, scripts, datasets, and commands required to reproduce the experimental results and validation tests described in Section 5 of the paper.
This artifact also includes a demonstration of BIN2CET for the example described in Section 2.

The artifact is intended exclusively for experimental reproduction using the proposed tool.
  - The artifact is distributed as a self-contained and versioned snapshot through Zenodo: https://doi.org/10.5281/zenodo.20420793
  - The public development repository is also available for the BIN2CET tool: https://github.com/brunorrib/bin2cet

1. Paper Summary
----------------

The paper investigates how Intel CET's Indirect Branch Tracking (IBT) can be retrofitted into legacy ELF binaries that were not originally compiled with CET support.

BIN2CET performs static binary rewriting to introduce CET-compatible control-flow targets while preserving the original behavior of the binary. The approach identifies function-entry targets, instruments appropriate locations with endbr64, uses relocation-aware trampolines when instructions must be relocated, and conservatively handles indirect branches that cannot safely be normalized using notrack.

The experimental evaluation considers three main aspects:

  - CET/IBT compatibility effectiveness, including recovered function entries and indirect branches;
  - Runtime overhead and binary-size impact introduced by the rewriting process; and
  - Reduction of the effective attack surface, comparing the syntactic gadget space with the policy-valid indirect-control-transfer surface.

2. Artifact Badges Consideration
--------------------------------

The authors request the following artifact badges:

Disponível (Available)
Funcional (Functional)
Sustentável (Sustainable)
Reprodutível (Reproducible)

*** Disponível

The artifact is permanently archived on Zenodo with a DOI. The BIN2CET development repository is also publicly available.
The Zenodo archive contains the version of BIN2CET and the experimental materials required to reproduce the paper results.

*** Funcional

The artifact provides a Docker-based environment containing the required dependencies and provides a minimal execution test through the demo command.

*** Sustentável

The artifact separates the main stages of the workflow into demonstration, simulation, and result extraction commands and provides the scripts and dependencies required to reproduce the evaluation.

*** Reprodutível

The artifact contains the scripts and datasets required to reproduce the main experimental claims of the paper, including CET compatibility effectiveness, runtime overhead, binary-size impact, and attack-surface reduction.

3. Artifact and Tool Relationship
---------------------------------

The artifact contains a frozen version of BIN2CET corresponding to the version used to generate the experimental results reported in the paper.
We opted to include the entire codebase as an included zip file for two reasons: 1) for blind review, where the names of the authors were omitted; (2) and
to avoid cloning it from an external repository to ensure availability even if the repository is changed or removed afterwards.
Thus, this self-contained artifact should be resilient for future reproducibility.

BIN2CET can also be found in a public GitHub repository for the latest updated version.
The GitHub repository is the development and public distribution channel for the tool, while the Zenodo artifact preserves the exact version of the tool, scripts, datasets, and experimental environment used for the evaluation.

The Zenodo archive is therefore the authoritative source for reproducing the experimental results reported in the paper.

4. Claims Supported by the Artifact
-----------------------------------

The artifact supports the three main experimental claims presented in Section 5 of the paper.

*** Claim 1 — CET/IBT Compatibility Effectiveness

This claim corresponds to Section 5.1 of the paper.
The artifact evaluates whether BIN2CET can retrofit CET/IBT compatibility into the evaluated GNU Coreutils binaries by:

  - recovering function-entry targets;
  - instrumenting valid CET targets;
  - handling indirect branches;
  - validating observed indirect transfers; and
  - explicitly handling indirect branches that cannot safely be normalized.

Expected paper-level results include:

  - 100% coverage of recovered function entries in -O0;
  - above 80% function-entry coverage in -O2 and -O3; and
  - near-complete handling of extracted indirect jumps across the evaluated optimization levels.

*** Claim 2 — Runtime Overhead and Binary-Size Impact

This claim corresponds to Section 5.2 of the paper.
The artifact uses Linux perf hardware performance counters to compare unprotected binaries against BIN2CET-rewritten binaries.
The main performance counters used by the evaluation are: instructions, cycles, task-clock, stalled-cycles-frontend, branch-misses, branches, cache-misses, cache-references.
We expect these perf counters to be availability in the tested architecture environment for reproducibility.

Expected paper-level results include:

  - approximately 22% runtime overhead for -O0;
  - approximately 40% runtime overhead for -O2 and -O3; and
  - binary-size growth resulting from endbr64 insertion, trampolines, and control-flow redirections.

*** Claim 3 — Attack-Surface Reduction

This claim corresponds to Section 5.3 of the paper.
The artifact estimates the attack surface by comparing the syntactic gadget space reported by ROPgadget with the policy-valid indirect-control-transfer surface preserved by BIN2CET.
The ROPgadget tool was executed using the following command line options: --depth 100 --multibr.

The analysis considered:

  - syntactic gadgets identified by ROPgadget;
  - recovered function entries;
  - indirect branch sites; and
  - protected targets preserved by the instrumentation policy.

The expected paper-level result is that the policy-valid indirect-control-transfer surface is reduced to less than 1% of the syntactic gadget space.

5. Artifact Structure
---------------------

The artifact is organized around the following main components:

bin2cet_artifacts
├── Dockerfile
├── bin2cet_image.tar
├── dataset.tar
└── scripts
    ├── bin2cet.tar.bz2
    ├── entrypoint.sh
    ├── install.sh
    └── runtime
        ├── aux...
        ├── demo.sh
        ├── everything.sh
        ├── extract.sh
        ├── fixes...
        └── sim.sh

The main components are:

Dockerfile: builds the Docker image containing the experimental environment and dependencies.
bin2cet_image.tar: prebuilt Docker image used in the evaluation.
dataset.tar: prebuilt dataset used to reproduce the experiments.
scripts/: contains the BIN2CET code, scripts implementing the setup of the experimental evaluation and to run the analysis workflow.
  bin2cet.tar.bz2: compacted fix-version of the tool proposed in the paper.
  entrypoint.sh: the script that is executed by default in Docker with helper menus.
  install.sh: used by Docker to install dependencies to execute the entire experimental evaluation.
  runtime: helper tools, and scripts.

6. Requirements
---------------

The artifact is distributed as a Docker-based environment containing the tools, scripts, and datasets required to reproduce the experiments from Section 5 of the paper.

*** Docker requirements:
  operating system: Linux
  container architecture: x86-64
  container privileges: --privileged is required for the experimental workflow because the artifact uses low-level performance measurement and runtime validation facilities

*** Hardware Requirements
  an intel processor with the following perf counters: instructions, cycles, task-clock, stalled-cycles-frontend, branch-misses, branches, cache-misses, cache-references.
  sufficient disk space to hold the docker image (~4.3 GB uncompressed), the dataset (~2.4 GB uncompressed), and further resources that can be generated.
  time to run the entire suite, including setup and simulations (~36 hours on an Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz with 32GB of RAM).
  some experiments modify system-level kernel parameters required for the performance measurements: kernel.randomize_va_space, kernel.perf_event_paranoid, and kernel.nmi_watchdog.

*** Software requirements
  BIN2CET — static binary rewriting system evaluated in the paper (https://github.com/brunorrib/bin2cet).
  LIEF 0.17.6 — ELF manipulation library used by BIN2CET.
  E9Patch — static binary rewriting framework extended by BIN2CET.
  Intel PIN 4.2 — used by the runtime checker.
  Ghidra 11.0.3 — alternative binary analysis backend.
  objdump — lightweight binary analysis backend.
  perf — used to collect hardware performance counters.
    PS: requires the linux-tools-${kernel_version}_amd64.deb package available in the Ubuntu repository (http://archive.ubuntu.com/ubuntu/pool/main/l/linux/)
  ROPgadget — used to estimate the syntactic gadget space.
  GNU Coreutils 9.11 — benchmark suite used in the experiments.
    PS: 102 programs are used in the evaluation compiled with optimization levels -O0, -O2, and -O3.
  GCC 15 — compiler used to build the evaluated binaries.

7. Setup
--------

Download the artifact package from the Zenodo archive (https://doi.org/10.5281/zenodo.20420793) and decompress it:
  # tar -jxvf bin2cet_artifacts.tar.bz2

Enter the artifact directory:
  # cd bin2cet_artifacts

Prepare the dataset, which are provided using two alternatives.
  Option A) use the dataset provided with the artifact by decompressing the dataset while preserving the ownership expected by the Docker environment:
    # sudo tar --same-owner -xvf dataset.tar

  Option B) rebuild the dataset from scratch by creating an empty dataset directory with full permissions:
    # mkdir dataset
    # chmod 777 dataset

The artifact can be executed using either a locally built Docker image or the prebuilt image provided with the artifact.
  Option A — Build the Docker image locally:
    # docker build --platform=linux/amd64 -t bin2cet_image .

  Option B — Load the prebuilt Docker image:
    # docker load -i bin2cet_image.tar

Run the container by starting it with:
  # docker run --rm -it --privileged --name bin2cet -v ./dataset:/work/dataset bin2cet_image

After this command, you should be inside the artifact container.

8. Testing
----------

Once inside the Docker image, the "demo" command can be used to simulate the claims made in Section 2 of the paper.
This is an automated workflow that showcases the BIN2CET functionalities using program shown in Figure 1 of the paper.

The demonstration shows:
  - the compilation of the original source test program;
  - the analysis performed by BIN2CET;
  - the rewriting process;
  - the instrumentation introduced by BIN2CET; and
  - the resulting CET-compatible binary or intermediate files.

9. Simulations
--------------

If used Option A when preparing the dataset, then all data used in our simulation is readily available.
Thus, the command "extract" can be used to generate the charts, and tables used in the paper for each Research Question investigated.
The available commands are:
  - extract RQ1
  - extract RQ2
  - extract RQ3

If used Option B when preparing the dataset, then all data must be generated from the scratch.
This can be achieved using the "everything" command, which simulates everything and generates all the charts and tables
with the newly collected data.
This command encompasses the "sim" command that is used to build, patch, and run the test suite.
All data must be collected in full before able to extract the Research Questions, thus the "everything" command
is the recommended way to achieve it.
The complete workflow requires approximately 36 hours under the reference environment.

The results can be found in the dataset directory, within the "sims" (with all simulated data) e "analysis" (with the analyzed data),
with the following (resumed) structure.

dataset
├── analysis
│   ├── RQ1
│   │   ├── funcs-O0.csv
│   │   ├── funcs-O2.csv
│   │   ├── funcs-O2.pdf
│   │   ├── funcs-O3.csv
│   │   ├── funcs-O3.pdf
│   │   └── raw...
│   ├── RQ2
│   │   ├── overhead-O0.csv
│   │   ├── overhead-O2.csv
│   │   ├── overhead-O3.csv
│   │   ├── raw...
│   │   ├── size-O0.pdf
│   │   ├── size-O2.pdf
│   │   └── size-O3.pdf
│   └── RQ3
│       ├── gadgets_by_functions.pdf
│       ├── gadgets_by_indirects.pdf
│       ├── gadgets_by_ropgadgets.pdf
│       ├── gadgets_stacked.pdf
│       └── raw...
└── sims
    ├── pie-O0
    │   ├── build
    │   ├── patches
    │   └── runs
    ├── pie-O2
    │   ├── build
    │   ├── patches
    │   └── runs
    └── pie-O3
        ├── build
        ├── patches
        └── runs

Some variance is expected since the experimental results depend on the execution environment, particularly for hardware performance measurements.
The CET compatibility and attack-surface analyses are expected to be substantially more stable across compatible environments because the relevant binary transformations and analyses are deterministic for a given input.
Performance measurements may vary across processors and system configurations.
If the host processor does not expose the required counters, the performance experiment cannot be reproduced on that machine.

10. License
-----------

This artifact is released under the Creative Commons Attribution 4.0 International (CC BY 4.0) license.