dittobytes

 

 



  

  

  

  


Metamorphic cross-compilation of C++ & C-code to PIC, BOF & EXE.


Built with ♥ by Tijme Gommers – Buy me a coffee via PayPal or Bunq.


Requirements
 • 
Getting started
 • 
Advanced usage
 • 
Metamorphications
 • 
Limitations
 • 
Issues
 • 
License

Dittobytes compiles your C-code to truly Position Independent Code (PIC) for Windows, MacOS, and Linux, and both AMD64 and ARM64. It features a metamorphic engine that ensures each compilation produces unique, functional shellcode. It does not rely on the classic decrypt stubs often seen in e.g. polymorphic compilations, and additionally it does not require reflective loaders such as Donut or sRDI as it can compile your C-code directly to PIC. A subsequent advantage is that the output size of the shellcode is extremely small (almost no overhead), and remains very simple.

    Original
    
    Metamorphicated (example)

# push    rbp
# mov     rbp, rsp
- push    r15
- push    r11
- sub     rsp, 40h
- xor     rax, rax
- mov     [rbp+var_1B], rax

→

# push    rbp
# mov     rbp, rsp
+ push    r9
+ push    r15
+ sub     rsp, 38h
+ mov     rdx, 0
+ mov     [rbp+var_33], rdx

Illustration 1: Example metamorphications by Dittobytes (left and right are functionally equivalent).

Dittobytes uses a custom LLVM build with two transpilers. Any compilation of your code using Dittobytes is done with this LLVM build. The first transpiler uses a modern LLVM Function Pass (on intermediate level) to inline constant variables otherwise located in e.g. .rodata segments (this aids the development of Position Independent Code). The second one is the machine transpiler that uses a legacy LLVM MachineFunction Pass to perform the metamorphic transformations (e.g. instruction substitutions), introducing randomness in the assembly code during compilation. Check the roadmap for all implemented (and yet to implement) metamorphic transformations.

The pre-shippped minimal C-code file (./code/beacon.c) can cross-compile to all supported platforms (Windows, Linux & MacOS), architectures (AMD64 & ARM64) and formats (PIC, BOF, EXE). Additionally, Dittobytes ships with loaders (for each platform and architecture) that can be used for testing purposes.

System requirements

The build environment itself works best (and is tested) on Linux (AMD64 & ARM64). Use Docker for an easy setup.

System requirements if you use Docker

Difficulty: easy

    A custom version of LLVM needs to be built from source, which requires quite some memory and disk space to be allocated by Docker. The build takes around 2.5 hours. I got it to work with the following Docker resource configuration.

⚠️ If Docker cannot allocate enough resources, the build might fail with an error like ResourceExhausted: cannot allocate memory.

Set CPU limit to: 8.

Set memory limit to: 10 GB.

Set swap to: 2 GB.

Set disk usage limit: 1 TB (though this can likely be much lower).

System requirements if you use Windows Subsystem for Linux

Difficulty: intermediate

    A custom version of LLVM needs to be built from source. Quite some memory and disk space is required. The build takes around 2.5 hours. I got it to work with the following resources.

CPU cores: 8.

Memory: 10 GB.

Disk space: 1 TB (though this can likely be much lower).

System requirements if you directly use your host

Difficulty: advanced

    A custom version of LLVM needs to be built from source. Quite some memory and disk space is required. The build takes around 2.5 hours. I got it to work with the following resources.

CPU cores: 8.

Memory: 10 GB.

Disk space: 1 TB (though this can likely be much lower).

Getting started

Presentation

This research has been presented at OrangeCon 2025. The slides are available on GitHub and a recording can be found on YouTube.

Overview

Directory structure


dittobytes/
├── code/                               # Your C-code that will compile to shellcode.
│   ├── beacon.c                        # Example file that you can compile using Dittobytes.
├── build/                              # Build dir containing loaders and your shellcodes.
│   ├── beacon-[platform]-[arch].raw    # Your C-code compiled to raw shellcode (.text segment only).
│   ├── beacon-[platform]-[arch].obj    # Your C-code compiled to BOF/COFF format.
│   ├── beacon-[platform]-[arch].exe    # Your C-code compiled to executable format.
│   ├── loader-[platform]-[arch]        # Pre-built raw shellcode loaders for testing purposes.
│   └── ...
└── ditto/                              # Internal files supporting the Dittobytes project.
    ├── loaders/                        # Simple shellcode loaders for testing purposes (pre-built).
    │   └── [platform]/
    │       ├── src/
    │       │   └── main.c
    │       └── lib/
    │           └── ...
    ├── scripts/                        # Helper scripts used by the makefile(s).
    │   ├── extract-text-segment.py
    │   └── ...
    ├── tests/                          # C-code files used for feature testing.
    │   ├── [feature-test].c
    │   └── ...
    └── transpilers/                    # The LLVM plugins that act as metamorphic engine.
        ├── intermediate/
        │   └── src/
        │       ├── IntermediateTranspiler.cpp
        │       └── ...
        └── machine/
            └── src/
                ├── MachineTranspiler.cpp
                └── ...

Preparing

Cloning the repository

Clone this repository using Git: git clone https://github.com/tijme/dittobytes.git

Manually review the code so you know what you're compiling and running.

Finally, move into the project directory and start developing: cd ./dittobytes/

Configuring the build environment in a Docker container

Difficulty: easy

    The easiest way to use Dittobytes is via Docker. For this, you need to build a Docker image using the provided Dockerfile.

Build the Docker image: docker buildx build -t dittobytes .

Building the image will take around 2.5 hours as LLVM needs to be built from source.

Configuring the build environment in a Windows Subsystem for Linux container instead

Difficulty: intermediate

    If you are on Windows, a more performant option to build the build tools is to use Windows Subsystem for Linux (WSL). However, in contrast to Docker, the installation of the build tools is a manual process.

First of all, install a Debian WSL container: wsl --install -d Debian

Then start & enter the container: wsl -d Debian

        Custom versions of Clang and LLVM are eventually used to cross-compile your code, the loaders and the transpilers. Performing this compilation in WSL requires you to configure your WSL the same way as the Docker container is configured. Take a look at the Dockerfile or GitHub Workflow for reference. Follow the exact same steps as in one of those files. For now, there is no further documentation on setting up the environment in WSL.
    





Configuring the build environment on your host instead

Difficulty: advanced

    Custom versions of Clang and LLVM are used to cross-compile your code, the loaders and the transpilers. If you want to perform this compilation on your host machine, configure your host the same way as the Docker container is configured. Take a look at the Dockerfile or GitHub Workflow for reference. Follow the exact same steps as in one of those files. And please make sure you're on a Linux host. For now, there is no further documentation on setting up the environment on your host machine. 

Developing

The basics




    You can modify ./code/beacon.c however you like. Just keep the following in mind:

The first function in your code must be named EntryFunction.

EntryFunction must literally (in order) be the first function in your code.

You cannot use global variables (PIC limitation).

You cannot use any data from other segments (PIC limitation).

You must resolve any API function you want to use by yourself (PIC limitation).

    The following example may give you some guidance. It simulates global variables by using a context struct that you would need to pass to any function you call. It initializes a string by using a char[] array. It calls another function by defining its definition first (as the other function needs to be defined before you can call it, but it cannot be the first function in your code).




    Example 'The Basics' (example-basics.c)




A hello world




    A hello world requires printing to the console, thus requiring an OS API call to e.g. puts. This is OS specific. For example, for Windows it would require loading KERNEL32.dll, ultimately resolving LoadLibraryA and GetProcAddress. With these two functions resolved, you can then load any function address, such as the address of puts.




    An example would become quite large, thus for now I'd like to forward you to example file below. It is a Position Independent Code (PIC) for Windows AMD64 & ARM64 which pops a calculator as example.




    Example 'Popping Calc' (example-calc.c)

Compiling

Compile your code

If using Docker, run the Dittobytes container (or use an equivalent command for your build environment): docker run --rm -v ".:/tmp/workdir" -it dittobytes

Compile your code (for all platforms, architectures & formats): make

You can also create specific builds: make beacon-[platform]-[arch]-[format].

Options:

Platforms: win,lin,mac.

Architectures: amd64,arm64.

Formats: exe,raw,bof.

Examples:

make beacon-win-amd64-bof (compile your code to Windows AMD64 BOF/COFF).

make beacon-mac-arm64-raw (compile your code to MacOS ARM64 raw shellcode).

make beacon-lin-all-raw (compile your shellcode to raw shellcode for Linux and any architecture).

make beacon-all-all-raw (compile your shellcode to raw shellcode for any platform and architecture).

make beacon-all-all-all (compile your shellcode to any format any platform and any architecture).

Outputs

Position Independent Code (.raw)

Dittobytes was originally designed to output Truly Position Independent Code (PIC). Simply put, PIC consists of the executable assembly instructions from the .text segment of an executable binary,