Fritter - Fritter is a heavily modified fork of TheWover and

项目说明

Fritter

The e cousin of Donut.

Fritter is a heavily modified fork of TheWover and Odzhan's Donut shellcode generator. It generates position-independent shellcode for in-memory execution of , JScript, EXE, DLL, and .NET assemblies, with a focus on e and signature resistance. The codebase is x64-only.

What's different

Lots. Fritter strips out features that aren't commonly needed and replaces internals that ha well-signatured over the years. The crypto, compression, hashing, and API resolution layers have all been reworked among many other areas.

Polymorphism and e is the design goal. Every output is unique, and every build of the tool is itself unique. There are two distinct layers:

Per-output randomization: applied each time fritter is invoked. The entry stub, the polymorphic decoder, the encryption keys, and many structural elements within the generated shellcode are regenerated from new entropy on every PIC build.

Per-build randomization: applied each time fritter itself is compiled. Cipher and hash rotation constants, API resolution table layout, shim-side string scrambling, PEB-walk directions, post-execution wipe patterns, and several structural axes inside the loader and shim are baked at compile time.

At runtime, Fritter minimizes the executable footprint of the loader. The loader is partitioned into indi encrypted functions, each with its own PE section, XOR key, and dispatcher. Only one function's bytes are in plaintext at any gi. The earlier model has been retired in favor of this dispatch model.

!! Build from source is strongly recommended !!

This matters. The pre-built binaries a for testing in *releases* share their per-build constants across all users of the binary.

Build your own copy. The per-build axes are re-randomized on every make in:

On Windows, MSVC is the recommended toolchain. It lays each loader function into its own page-aligned PE section, which is what the N>1 per-function dispatch model needs. mingw currently emits e into a single .text and therefore runs one entry co the entire loader with one XOR key (functionally identical to MS, but only one dispatcher of polymorphism instead of many). If you don't ha Studio, build under WSL with Makefile.linux; it cross-compiles the Windows loader .

Each make runs tools/gen_poly to emit fresh per-build constants and tools/gen_api_shuffle to permute the API resolution table. The resulting fritter binary is itself unique with different cipher constants, different hash constants, a different API table layout, different shim-side string scrambling, and so on. Every shellcode generated by *that* binary will then share *those* per-build constants but vary on the per-output axes.

Usage

*A /test folder is included with calc.exe and inject_local64.exe to test Fritter. To rebuild the test hosts yourself: nmake -f Makefile.ms, or make -f Makefile.linux harness under WSL.*

Examples

Architecture (many implementations are not listed here)

A Fritter shellcode payload is structured as nested layers, each one decrypting or staging the next:

1. Entry stub. A randomized junk prefix of length, an RSP-alignment routine generated per output, and a generati. Based on the discipline of *Shikata Ga Nai*.

2. Polymorphic XOR decoder. Two-pass-assembled. Register allocation drawn from a pool by Fisher-Yates shuffle. Key length picked per output. Junk inserted between every real instruction. The hot loop's movable instruction groups are reordered within correctness constraints.

3. Dispatch shim. Replaces the earlier shim. Flips the loader region RW->RWX, then hands control to the loader entry. Under N>1 dispatch, each call is routed through a per-function thunk into a per-function dispatcher that decrypts, runs, and wipes on return. Every dispatcher's opcode layout per build *(see CHANGELOG v1.3)*.

4. Loader. PE in-memory mapper. Resolves APIs by hash, maps the embedded PE APIs, applies imports / relocations / TLS callbacks, invokes the entrypoint, then wipes. PEB walk direction, post-exec wipe byte, structural salt sites in MainProc, are all randomized per build.

5. Cleanup. Wipes loader pages with a per-build byte pattern, erases the instance, and exits or process termination per -x. No or context struct to scrub.

Residual footprint after execution is one small RWX page where the dispatch shim ran. In thread mode the mapped PE section is intentionally left intact so CRT callbacks ha.

Credits

Fritter is built on the work of TheWover and Odzhan, whose original Donut project made position-independent shellcode generation accessible and practical. Their architecture, loader design, and PIC framework are the foundation e here is built on. The PE mapping, .NET hosting, and script execution paths are largely their work, retained and respected.

License

BSD 3-Clause. See LICENSE.

项目信息

开发语言：C

Star 数：252

技术要点

该项目属于红蓝攻防方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Fritter is a heavily modified fork of TheWover and Odzhan's Donut shellcode generator.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

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

使用与学习建议

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

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

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

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

免责声明

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