Once all three lambdas are defined, you can then create a `theo::hmm_ctx` (highly modular mapper context). This class is like the one from HMDM however it requires an extra lambda to resolve external symbols.
The entry point of the mapped code is not invoked by `hmm_ctx`, but rather its left up to you to call. An example of calling the entry point can be seen below.
result = reinterpret_cast<drv_entry_t>(drv_entry)();
});
```
#### VDM - Call Entry Example
Another example, this one using VDM, can be seen below.
```cpp
const auto entry_result =
vdm.syscall<NTSTATUS(*)()>(
reinterpret_cast<void*>(drv_entry));
```
#### WinAPI - CreateRemoteThread
Another example, this one using WinAPI's, can be seen below.
```cpp
std::uint32_t tid = 0u;
CreateRemoteThread
(
phandle, NULL,
NULL, drv_entry,
NULL, NULL,
(LPDWORD)&tid
);
```
# Obfuscation
# Obfuscation
The usage of the word obfuscation in this project is use to define any changes made to code, this includes code flow. `obfuscation::obfuscate`, a base class, which is inherited and expanded upon by `obfuscation::mutation`, obfuscates code flow by inserting `JMP [RIP+0x0]` instructions after every single instruction. This allows for a routine to be broken up into unique allocations of memory and thus provides more canvas room for creative ideas.
The usage of the word obfuscation in this project is use to define any changes made to code, this includes code flow. `obfuscation::obfuscate`, a base class, which is inherited and expanded upon by `obfuscation::mutation`, obfuscates code flow by inserting `JMP [RIP+0x0]` instructions after every single instruction. This allows for a routine to be broken up into unique allocations of memory and thus provides more canvas room for creative ideas.