homer is a research fork of donut that generates position-independent shellcode for loading Windows PE payloads from memory, hardened against static extraction for authorized red-team and defensive study.
| Tool | twili8/homer — evasive fork of donut producing position-independent shellcode that loads Windows PE payloads in memory, hardened against tools like donut-decryptor |
| Category | Offensive tooling / shellcode loader research (C, BSD-3-Clause) |
| Primary Use | Generating loader shellcode in authorized lab environments to study how in-memory PE loading works and how static extraction of donut-style payloads fails |
| Safe Use | Strictly for educational and defensive research on systems you own or are explicitly authorized to test, as stated in the README's own license warning |
| Telemetry Note | Designed to evade static extraction by donut-decryptor; defenders should treat any donut-family loader as a moving target and rely on behavioral detection of in-memory module loading, thread creation anomalies, and unbacked executable memory rather than static signature recovery |
homer is a fork of donut, the well-known position-independent shellcode loader, with a single sharpened focus: hardening the generated loader against static extraction by analysis tools such as Volexity's donut-decryptor. The original donut converts PE payloads — EXEs, DLLs, and .NET assemblies — into self-contained shellcode that resolves the loading problem entirely in memory. Its popularity made it a high-value target for defenders, and donut-decryptor in particular demonstrated that the embedded payload and configuration could be carved back out of the loader blob through careful static analysis. homer exists to explore what happens when that extraction path is closed off, which is precisely why it deserves documentary attention from both sides of the fence.
The README is admirably blunt about scope. It opens with the fork's purpose, then immediately anchors it in an Educational and defensive research purposes only clause: use only on systems you own or are authorized to test, no warranty, no liability for misuse. That framing matters here, because the tool's entire reason for existing is evasion of a defensive capability. This writeup treats homer as an object of study — a specimen in the ongoing arms race between loader generators and static decryptors — rather than as an operational recipe, and it deliberately omits anything that would constitute a weaponized workflow against third-party systems.
Architecturally, the README tells us homer keeps the general shape of its parent project while tightening the internals. The stated security model lives in a separate HOMER.md file, which the README says covers the design goals, build instructions, and usage. What we can infer from the tool's stated purpose is that the loader's embedded payload is no longer recoverable by the techniques donut-decryptor uses against stock donut output — likely by changing how, where, and in what form the payload material and its keying information are staged inside the shellcode. This is the classic hardening loop of offensive tooling: a defender publishes an extractor, and the next generation of the tool moves the goalposts.
The build system is documented and refreshingly minimal. make -f Makefile.homer all is the only invocation, and it produces the ./homer generator binary. The toolchain requirements are worth noting for anyone studying the code: gcc for the host-side generator, plus both i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc for cross-compiling the x86 and x64 variants of the loader, and python3 with the pefile module for parsing the input PE files. A small convenience is documented: the exe2h helper is built from source as part of the process, so no objcopy dependency is needed.
That build detail is more informative than it first appears. The presence of two MinGW cross-compilers confirms the loader itself is compiled per-architecture rather than shipped as a fat universal blob, and the pefile dependency confirms the generator does its own PE introspection at conversion time — reading imports, relocations, and headers so the generated shellcode can reconstruct the module in memory without ever touching disk. Understanding that pipeline is the core educational value of the entire donut lineage, and homer inherits it intact.
The choice of Volexity's donut-decryptor as the named adversary is the most strategically interesting line in the README. donut-decryptor works by emulating the loader's early execution far enough to recover the decrypted payload statically, without ever running the shellcode for real. By explicitly hardening against that class of analysis — static extraction, not dynamic detection — homer is drawing a narrow technical boundary. It does not claim to defeat memory scanning, ETW-based telemetry, or behavioral monitoring; it claims to break the specific static-recovery workflow that the research community built around stock donut. That narrowness is characteristic of well-scoped research forks and makes the project a cleaner study subject than tools with sprawling, vague evasion claims.
For defensive professionals, homer is valuable primarily as a stress test. If your detection strategy for donut-style loaders leans heavily on static extraction — pulling the payload out of a seized sample to identify the final-stage tooling — then this fork is a direct challenge to that workflow. The defensive lesson is architectural: capabilities that depend on the loader being recoverable are fragile, and robust coverage for this class of shellcode has to include runtime signals. Unbacked executable memory allocations, module stomping artifacts, unusual thread start addresses in dynamically resolved memory, and API behavior patterns of manual PE loaders (virtual allocation, section mapping, import resolution, relocation fixups) are the durable observation surface, because homer hardens the bytes, not the semantics of in-memory loading.
For authorized red teams, the legitimate context is equally clear: simulating this class of loader inside a contracted engagement or an internal lab tells you whether your blue team's detection stack actually relies on the fragile static path. Running homer-generated loaders against your own detection engineering pipeline, in an environment you control, is exactly the kind of adversarial validation that improves coverage. The tool's permissive BSD-3-Clause license makes such internal study straightforward, and the small footprint — a single generator binary, one Makefile target — keeps the lab setup lightweight.
The repository context rounds out the picture: twili8/homer is written in C, carries the topics donut, pentesting, redteam, and shellcode, and sits at 65 stars on its main branch at the time of this writing. Those signals suggest a focused research project rather than a maintained product — there is no versioning story, no release cadence, and no changelog visible in the README. Treat it as a snapshot of a specific moment in the loader-versus-decryptor arms race rather than as tooling you would build a practice around.
The deeper takeaway from homer is about the economics of public offensive tooling. donut became ubiquitous precisely because it was excellent and open; donut-decryptor became possible precisely because donut was ubiquitous. homer demonstrates the third beat of that cycle — public defensive research driving the next fork's design goal. Both red and blue teams benefit from reading this repository with that cycle in mind: defenders should assume that any published decryptor has a shelf life, and operators should assume that any published loader's evasion has one too. homer is a compact, honestly documented artifact of that dynamic, and that alone justifies studying it in an authorized setting.
twili8/homer.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.