dittobytes - Metamorphic cross-compilation of C++ & C-code to P

项目说明

<p align="center">
<img src=" alt="Dittobytes Logo" />
</p>
<p align="center">
<a href=" src=" alt="Latest Dittobytes release" /></a>
&nbsp;
<a href=" src=" alt="Latest Dittobytes status" /></a>
&nbsp;
<a href=" src=" alt="Dittobytes license badge" /></a>
</p>
<p align="center">
<img src=" alt="AMD64 logo" width="50" height="50" />
&nbsp;&nbsp;
<img src=" alt="MacOS logo" width="50" height="50" />
&nbsp;&nbsp;
<img src=" alt="Windows logo" width="50" height="50" />
&nbsp;&nbsp;
<img src=" alt="Linux logo" width="50" height="50" />
&nbsp;&nbsp;
<img src=" alt="ARCH64 logo" width="50" height="50" />
</p>
<p align="center">
<b>Metamorphic cross-compilation of C++ & C-code to PIC, BOF & EXE.</b>
<br/>
<sup>Built with ♥ by <a href=" Gommers</a> – Buy me a coffee via <a href=" or <a href="
<br/>
</p>
<p align="center">
<a href="#-system-requirements">Requirements</a>
&nbsp;•&nbsp;
<a href="#-getting-started">Getting started</a>
&nbsp;•&nbsp;
<a href="#-ad">Ad usage</a>
&nbsp;•&nbsp;
<a href="#-metamorphications">Metamorphications</a>
&nbsp;•&nbsp;
<a href="#-limitations">Limitations</a>
&nbsp;•&nbsp;
<a href="#-issues--requests">Issues</a>
&nbsp;•&nbsp;
<a href="#-license--copyright">License</a>
</p>
<hr>

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 reflecti such as Donut or sRDI as it can compile your C-code directly to PIC. A subsequent ad is that the output size of the shellcode is extremely small (almost no o), and remains very simple.

<table align=center>
<tr>
<td align=center>Original</td>
<td align=center></td>
<td align=center>Metamorphicated (example)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
</tr>
</table>
<p align=center>^{Illustration 1: Example metamorphications by Dittobytes (left and right are functionally equi).}</p>

<p>
Dittobytes uses a custom LL with two transpilers. Any compilation of your code using Dittobytes is done with this LL. The first transpiler uses a modern <a href=" Pass</a> (on intermediate level) to inline constant otherwise located in e.g. <code>.rodata</code> segments (this aids the de of Position Independent Code). The second one is the machine transpiler that uses a legacy <a href=" Pass</a> to perform the metamorphic transformations (e.g. instruction substitutions), introducing randomness in the assembly code during compilation. Check the <a href="#-metamorphications">roadmap</a> for all implemented (and yet to implement) metamorphic transformations.
</p>

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.

<h1><img src=" width=25 height=25 /> System requirements</h1>

<p>The build en itself works best (and is tested) on Linux (AMD64 & ARM64). Use Docker for an easy setup.</p>

<details>
<summary>System requirements if you use <b>Docker</b><br><sup>Difficulty: <strong>easy</strong></summary>
<hr>
<p>
A custom of <a href=" 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.
<blockquote>⚠️ If Docker cannot allocate enough resources, the build might fail with an error like <code>ResourceExhausted: cannot allocate memory</code>.</blockquote>
<ul>
<li>Set CPU limit to: <code>8</code>.</li>
<li>Set memory limit to: <code>10 GB</code>.</li>
<li>Set swap to: <code>2 GB</code>.</li>
<li>Set disk usage limit: <code>1 TB</code> (though this can likely be much lower).</li>
</ul>
</p>
<hr>
</details>

<details>
<summary>System requirements if you use <b>Windows Subsystem for Linux</b><br><sup>Difficulty: <strong>intermediate</strong></summary>
<hr>
<p>
A custom of <a href=" 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.
<ul>
<li>CPU cores: <code>8</code>.</li>
<li>Memory: <code>10 GB</code>.</li>
<li>Disk space: <code>1 TB</code> (though this can likely be much lower).</li>
</ul>
</p>
<hr>
</details>

<details>
<summary>System requirements if you directly use <b>your host</b><br><sup>Difficulty: <strong>ad</strong></summary>
<hr>
<p>
A custom of <a href=" 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.
<ul>
<li>CPU cores: <code>8</code>.</li>
<li>Memory: <code>10 GB</code>.</li>
<li>Disk space: <code>1 TB</code> (though this can likely be much lower).</li>
</ul>
</p>
<hr>
</details>

<h1><img src=" width=25 height=25 /> Getting started</h1>

Presentation

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

O

<details>
<summary>Directory structure</summary>
<hr>

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 LL that act as metamorphic engine.
├── intermediate/
│ └── src/
│ ├── IntermediateTranspiler.cpp
│ └── ...
└── machine/
└── src/
├── MachineTranspiler.cpp
└── ...

<hr>
</details>

Preparing

<details>
<summary>Cloning the repository</summary>
<hr>
<ul>
<li>Clone this repository using Git:<br><pre><code>git clone
<li>Manually <a href=" the code so you know what you're compiling and running.</li>
<li>Finally, move into the project directory and start de:<br><pre><code>cd ./dittobytes/</code></pre></li>
</ul>
<hr>
</details>

<details>
<summary>Configuring the build en in a <b>Docker</b> container<br><sup>Difficulty: <strong>easy</strong></summary>
<hr>
<p>
The easiest way to use Dittobytes is . For this, you need to build a Docker image using the provided <code>Dockerfile</code>.
<br>
<ul>
<li>Build the Docker image:<br><pre><code>docker buildx build -t dittobytes .</code></pre></li>
<li>Building the image will take around 2.5 hours as LL to be built from source.</li>
</ul>
</p>
<hr>
</details>

<details>
<summary>Configuring the build en in a <b>Windows Subsystem for Linux</b> container instead<br><sup>Difficulty: <strong>intermediate</strong></summary>
<hr>
<p>
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.
<br>
<ul>
<li>First of all, install a Debian WSL container:<br><pre><code>wsl --install -d Debian</code></pre></li>
<li>Then start & enter the container:<br><pre><code>wsl -d Debian</code></pre></li>
</ul>
<p>
Custom of Clang and LLVM are e 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 <a href=" or <a href=" Workflow</a> for reference. Follow the exact same steps as in one of those files. For now, there is no further documentation on setting up the en in WSL.
</p>
</p>
<hr>
</details>

<details>
<summary>Configuring the build en on <b>your host</b> instead<br><sup>Difficulty: <strong>ad</strong></summary>
<hr>
<p>
Custom 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 <a href=" or <a href=" Workflow</a> 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 en on your host machine.
</p>
<hr>
</details>

De

<details>
<summary>The basics</summary>
<hr>
<p>
You can modify <code>./code/beacon.c</code> however you like. Just keep the following in mind:
<br>
<ul>
<li>The first function in your code must be named <code>EntryFunction</code>.</li>
<li><code>EntryFunction</code> must literally (in order) be the first function in your code.</li>
<li>You cannot use global (PIC limitation).</li>
<li>You cannot use any data from other segments (PIC limitation).</li>
<li>You must resolve any API function you want to use by yourself (PIC limitation).</li>
</ul>
</p>
<p>
The following example may give you some guidance. It simulates global by using a context struct that you would need to pass to any function you call. It initializes a string by using a <code>char[]</code> 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).
</p>
<p>
<a href=" 'The Basics' (<code>example-basics.c</code>)</a>
</p>
<hr>
</details>

<details>
<summary>A hello world</summary>
<hr>
<p>
A hello world requires printing to the console, thus requiring an OS API call to e.g. <code>puts</code>. This is OS specific. For example, for Windows it would require loading <code>KERNEL32.dll</code>, ultimately resolving <code>LoadLibraryA</code> and <code>GetProcAddress</code>. With these two functions resolved, you can then load any function address, such as the address of <code>puts</code>.
</p>
<p>
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.
</p>
<p>
<a href=" 'Popping Calc' (<code>example-calc.c</code>)</a>
</p>
<hr>
</details>

Compiling

<details>
<summary>Compile your code</summary>
<hr>
<ul>
<li>If using Docker, run the Dittobytes container (or use an equi command for your build en):<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Compile your code (for all platforms, architectures & formats):<br><pre><code>make</code></pre></li>
<li>You can also create specific builds: <code>make beacon-[platform]-[arch]-[format]</code>.
<ul>
<li>Options:
<ul>
<li>Platforms: <code>win</code>,<code>lin</code>,<code>mac</code>.</li>
<li>Architectures: <code>amd64</code>,<code>arm64</code>.</li>
<li>Formats: <code>exe</code>,<code>raw</code>,<code>bof</code>.</li>
</ul>
</li>
<li>Examples:
<ul>
<li><code>make beacon-win-amd64-bof</code> (compile your code to Windows AMD64 BOF/COFF).</li>
<li><code>make beacon-mac-arm64-raw</code> (compile your code to MacOS ARM64 raw shellcode).</li>
<li><code>make beacon-lin-all-raw</code> (compile your shellcode to raw shellcode for Linux and any architecture).</li>
<li><code>make beacon-all-all-raw</code> (compile your shellcode to raw shellcode for any platform and architecture).</li>
<li><code>make beacon-all-all-all</code> (compile your shellcode to any format any platform and any architecture).</li>
</ul>
</li>
</ul>
</li>
</ul>
<hr>
</details>

Outputs

<details>
<summary>Position Independent Code (<code>.raw</code>)</summary>
<hr>
<p>Dittobytes was originally designed to output Truly Position Independent Code (PIC). Simply put, PIC consists of the executable assembly instructions from the <code>.text</code> segment of an executable binary, without any reference to other segments or absolute memory addresses.</p>
<p>Dittobytes generates <code>.raw</code> files for Windows, Linux and MacOS (and both AMD64 and ARM64).</p>
<hr>
</details>

<details>
<summary>Beacon Object File (<code>.obj</code>)</summary>
<hr>
<p>In the process of creating Position Independent Code, Dittobytes creates an <code>.obj</code> file (COFF/ELF format). This file is later used to extract the <code>.text</code> segment (<code>.raw</code>) from, or create the executable format (<code>.exe</code>) with. However, the <code>.obj</code> file itself can be used as Cobalt Strike (or any other C&C framework) Beacon Object File (BOF) as well.</p>
<p>Dittobytes generates <code>.obj</code> files for Windows, Linux and MacOS (and both AMD64 and ARM64).</p>
<hr>
</details>

<details>
<summary>Executable/Clickable (<code>.exe</code>)</summary>
<hr>
<p>Dittobytes uses the generated Position Independent Code (PIC) in the <code>.obj</code> file to e generate an executable/clickable file format (<code>.exe</code>). This means that all executables generated by Dittobytes solely contain Position Independent Code (PIC). For example, constants are inlined instead of stored in the <code>.rodata</code> segment.</p>
<p>Dittobytes generates <code>.exe</code> files for Windows, Linux and MacOS (and both AMD64 and ARM64).</p>
<hr>
</details>

Testing

<details>
<summary>Running your shellcode</summary>
<hr>
<ul>
<li>
Run and test your shellcode using the pre-shipped shellcode loader:
<br>
<pre><code>./build/loader-[os]-[arch].[ext] ./build/beacon-[os]-[arch].raw</code></pre>
</li>
</ul>
<hr>
</details>

<details>
<summary>Running feature tests</summary>
<hr>
<p>
Dittobytes comes pre-shipped with feature tests. A feature test is similar to a unit test, but tests from a large feature perspecti of a specific code unit perspecti, you can only run feature tests for shellcodes that are compiled for the platform you are running the tests on. For example, in the Docker container only the Linux shellcode would be tested & .
<br>
<ul>
<li>If using Docker, run a Dittobytes container:<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Build the tests:<br><pre><code>make test-suite-build</code></pre></li>
<li>Run the tests:<br><pre><code>make test-suite-test</code></pre></li>
</ul>
</p>
<hr>
</details>

<h1><img src=" width=25 height=25 /> Ad usage</h1>

<details>
<summary>Using C++ instead of C for your code</summary>
<hr>
<p>
You can easily utilize functionality of C++ by renaming your code file from <code>./code/beacon.c</code> to <code>./code/beacon.cpp</code>. Just make sure to prepend the <code>EntryFunction</code> in the file with <code>extern "C"</code>. Also ensure that the <code>SOURCE_PATH</code> option in the <code>makefile</code> points to the new filename. Do note that you <b>cannot</b> use functionality from external libraries such as <code>libstdc++</code> or <code>libc++</code>. This means you <b>cannot</b> make use of e.g. <code>std::string</code> ⚠️.
</p>
<p>
<a href=" 'C++ instead of C-code' (<code>example-cpp.c</code>)</a>
</p>
<p>Compiling C++ code in Dittobytes works exactly the same as compiling regular C-code.</p>
<ul>
<li>If using Docker, run a Dittobytes container:<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Then compile your code:<br><pre><code>make</code></pre></li>
</ul>
<hr>
</details>

<details>
<summary>Compiling a Cobalt Strike Beacon Object File (BOF)</summary>
<hr>
<p>
To compile a Beacon Object File (BOF) for Cobalt Strike or any other Command & Control framework, copy <code>./code/examples/example-bof/example-bof.c</code> to <code>./code/beacon.c</code>. Then adjust the source code to your needs.
</p>
<p>
<a href=" 'Beacon Object File' (<code>example-bof.c</code>)</a>
</p>
<p>Remember to solely compile to the <code>BOF/COFF</code> format using the <code>make</code> command (see below example) ⚠️.</p>
<ul>
<li>If using Docker, run a Dittobytes container:<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Then compile your code:<br><pre><code>make beacon-win-amd64-bof</code></pre></li>
</ul>
<hr>
</details>

<details>
<summary>Modification & compilation of the pre-shipped loaders</summary>
<hr>
<p>
You can modify the pre-shipped loaders by editing the code in <code>./ditto/loaders/[platform]/src/main.c</code>, after which you can compile them using the following commands in the root of the Dittobytes project:
<br>
<ul>
<li>If using Docker, run a Dittobytes container:<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Compile the loaders:<br><pre><code>make ditto-loaders</code></pre></li>
</ul>
</p>
<hr>
</details>

<details>
<summary>Modification & compilation of the pre-shipped transpilers</summary>
<hr>
<p>
You can modify the pre-shipped transpiler(s) by editing the code in <code>./ditto/transpilers/[type]/src/[type].cpp</code>, after which you can compile them using the following commands in the root of the Dittobytes project:
<br>
<ul>
<li>If using Docker, run a Dittobytes container:<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Compile the transpilers:<br><pre><code>make ditto-transpilers</code></pre></li>
</ul>
Dittobytes ships with two transpilers. The first one is the intermediate transpiler that uses a modern <a href=" Pass</a> to inline constant otherwise located in <code>.rodata</code> segments. The second one is the machine transpiler that uses a legacy <a href=" Pass</a> to perform the metamorphism.
</p>
<hr>
</details>

<details>
<summary>Compiling & running one specific feature test</summary>
<hr>
<p>
The test-suite commands in the makefile usually compile and test all feature tests (cross-os and cross-architecture). If you want to test just one specific feature test, or if you want to to test build artifacts for a specific os or architecture, use the commands below. You can adjust the <code>TEST_*</code> arguments to your needs.
<br>
<ul>
<li>If using Docker, run a Dittobytes container:<br><pre><code>docker run --rm -v ".:/tmp/workdir" -it dittobytes</code></pre></li>
<li>Build the test(s):<br><pre><code>make TEST_OS=win TEST_ARCH=arm64 TEST_SOURCE_PATH=./ditto/tests/all/all/3_metamorphication_010_transform_nullifications.c TEST_METAMORPHICATION=transform_nullifications test-suite-build</code></pre></li>
<li>Run the test(s):<br><pre><code>make TEST_OS=win TEST_ARCH=arm64 TEST_SOURCE_PATH=./ditto/tests/all/all/3_metamorphication_010_transform_nullifications.c TEST_METAMORPHICATION=transform_nullifications test-suite-test</code></pre></li>
</ul>
The abo would build the feature test <code>3_metamorphication_010_transform_nullifications.c</code> for Windows ARM64. This may result in many build artifacts (<code>[amount of feature tests] × [amount of os's] × [amount of arch's] × [amount of metamorphications]</code>), in this case 1 (<code>1 × 1 × 1 × 1</code>). The second command the build artifacts based on the <code>@</code> statements in the feature test source code file(s).
</p>
<hr>
</details>

<h1><img src=" width=25 height=25 /> Metamorphications</h1>

There is no specific planning, so this might be more of a to-do or progress list.

<details>
<summary>
✅ Randomize register allocation<br>
^{Implemented in release 1.0.0.}
</summary>
<p>Randomizes the allocation order of CPU registers, causing different registers to be used each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
✅ Transform <code>mov reg, imm</code><br>
^{Implemented in release 1.0.0.}
</summary>
<p>Substitutes instructions that move an immediate value to a register in ways each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
✅ Transform <code>mov [reg+var], imm</code><br>
^{Implemented in release 1.0.9.}
</summary>
<p>Substitutes instructions that move an immediate value to the stack in ways each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
✅ Transform nullifications<br>
^{Implemented in release 1.0.2.}
</summary>
<p>Substitutes instructions that nullify a register each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
⏳ Insert semantic noise (meaningful dead code)<br>
^{To be implemented.}
</summary>
<p>Insertion of opaque instructions or basic blocks (from trusted software) that do not affect code functionality.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
⏳ Transform <code>mov reg, reg</code><br>
^{To be implemented.}
</summary>
<p>Substitutes instructions that move a register value to another register in ways each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
⏳ Swap simple math<br>
^{To be implemented.}
</summary>
<p>Transform mathematical instructions with equi each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<details>
<summary>
⏳ Transform <code>mov reg, reg</code><br>
^{To be implemented.}
</summary>
<p>Substitutes instructions that move a register value to another register in ways each compile.</p>
<table>
<tr>
<td align=center>Original</td>
<td></td>
<td align=center>Metamorphicated (sample 1)</td>
<td align=center>Metamorphicated (sample 2)</td>
</tr>
<tr>
<td>

</td>
<td align=center>→</td>
<td>

</td>
<td>

</td>
</tr>
</table>
<hr>
</details>

<h1><img src=" width=25 height=25 /> Limitations</h1>

There are currently two known limitation in the use of Dittobytes.

* LL inline compile float's and double's, causing them to end up in the .rodata segment. As a result, these types do not work when compiled with Dittobytes.
* C++ exceptions are not yet supported as they generate exception tables outside the .text segment.

<h1><img src=" width=25 height=25 /> Issues & requests</h1>

Issues or new feature requests can be reported via the issue tracker. Please make sure your issue or feature has not yet been reported by anyone else before submitting a new one.

<h1><img src=" width=25 height=25 /> License & copyright</h1>

Copyright &copy; 2025 Tijme Gommers. Dittobytes is released under the Mozilla Public License 2.0. View LICENSE.md for the full license. Dittobytes depends on open-source components which all ha own license and copyright.

项目信息

开发语言：C++

Star 数：651

技术要点

该项目属于病毒分析方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Metamorphic cross-compilation of C++ & C-code to PIC, BOF & EXE. 展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。