Theodosius (Theo for short) is a jit linker created for obfuscation. The project is extremely modular in design and supports both kernel and usermode projects.
Download and install cmake on your system, then execute the following command in the root dir of this project:
*`cmake -B build`
Then navigate into `dependencies/xed/` and run `python3 mfile.py`. Building XED can be tricky on windows, I suggest you use the visual studios console since it has env vars to everything needed to build XED. linux seems to build it just fine...
A linker is a program which takes object files produces by a compiler and generates a final executable native to the operating system. A linker interfaces with not only object files but also static libraries, "lib" files. What is a "lib" file? Well a lib file is just an archive of obj's. You can invision it as a zip/rar without any compression, just concatination of said object files.
Theo is a jit linker, which means it will link objs together and map them into memory all at once. For usability however, instead of handling object files, Theo can parse entire lib files and extract the objects out of the lib.
#### Object Files
If you define a c++ file called "main.cpp" the compiler will generate an object file by the name of "main.obj". When you refer to data or code defined in another c/c++ file, the linker uses a symbol table to resolve the address of said code/data. In this situation I am the linker and I resolve all of your symbols :).
#### Static Linking
Static linking is when the linker links entire routines not created by you, into your code. Say `memcpy` (if its not inlined), will be staticlly linked with the CRT. Static linking also allows for your code to be more independant as all the code you need you bring with you. However, with Theo, you cannot link static libraries which are not compiled with `mcmodel=large`. Theo supports actual static linking, in other words, using multiple static libraries at the same time.
#### Dynamic Linking
Dynamic linking is when external symbols are resolved at runtime. This is done by imports and exports in DLL's (dynamiclly linked libraries). Theo supports "dynamic linking", or in better terms, linking against exported routines. You can see examples of this inside of both usermode and kernelmode examples.
# Usage - Using Theodosius
## Integrating Clang
For integration with visual studios please open install [llvm2019](https://marketplace.visualstudio.com/items?itemName=MarekAniola.mangh-llvm2019) extension, or [llvm2017](https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain) extension. Once installed, create or open a visual studio project which you want to use with LLVM-Obfuscator and Theo. Open ***Properties*** --> ***Configuration Properties*** ---> ***General***, then set ***Platform Toolset*** to ***LLVM***.
Once LLVM is selected, under the ***LLVM*** tab change the clang-cl location to the place where you extracted [clang-cl.rar](https://githacks.org/_xeroxz/theodosius/-/blob/cc9496ccceba3d1f0916859ddb2583be9362c908/resources/clang-cl.rar). Finally under ***Additional Compiler Options*** (same LLVM tab), set the following: `-Xclang -std=c++1z -Xclang -mcode-model -Xclang large -Xclang -fno-jump-tables -mllvm -split -mllvm -split_num=4 -mllvm -sub_loop=4`.
Please refer to the [LLVM-Obfuscator Wiki](https://github.com/obfuscator-llvm/obfuscator/wiki) for more information on commandline arguments.
#### Requirements
* No SEH support, do not add `__try/__except` in your code.
* No CFG (control flow guard) support. Please disable this in C/C++ ---> Code Generation ---> Control Flow Guard
* No Stack Security Check Support. Please disablel this in C/C++ ---> Code Generation ---> Security Check (/GS-)
* Your project must be set to produce a .lib file.
* Your project must not link with other static libraries which are not compiled with `-Xclang -mcmodel-large`.
* Project must be compiled with the following flags
*`-Xclang -fno-jump-tables`, removes jump tables created by switch cases.
*`/Zc:threadSafeInit-`, static will not use TLS (thread local storage).
## RIP Relative Addressing
In order to allow for a routine to be scattered throughout a 64bit address space, RIP relative addressing must not be used. In order to facilitate this, a very special version
of clang-cl is used which can use `mcmodel=large`. This will generate instructions which do not use RIP relative addressing when referencing symbols outside of the routine in which the
instruction itself resides. The only exception to this is JCC instructions, (besides call) also known as branching instructions. Take this c++ code for an example:
```cpp
ObfuscateRoutine
extern "C" int ModuleEntry()
{
MessageBoxA(0, "Demo", "Hello From Obfuscated Routine!", 0);
UsermodeMutateDemo();
UsermodeNoObfuscation();
}
```
This c++ function, compiled by clang-cl with `mcmodel=large`, will generate a routine with the following instructions:
```
0x00: ; void UsermodeNoObfuscation(void)
0x00: public ?UsermodeNoObfuscation@@YAXXZ
0x00: ?UsermodeNoObfuscation@@YAXXZ proc near ; CODE XREF: ModuleEntry+42↓p
As you can see from the code above, (sorry for the terrible syntax highlighting), references to strings and calls to functions are done by first loading the address of the symbol into a register and then interfacing with the symbol.
