Huan generates encrypted PE loaders to study Windows loading internals

A crypter written to learn the loader, not to ship one

The README is unusually direct about intent. Huan is described as an encrypted PE Loader Generator that the author developed for learning PE file structure and PE loading processes. That framing matters for how you should read the rest of the project, because a loader that decrypts and executes a payload from memory is exactly the shape of tool that malware authors also build, and the difference here is stated intent rather than capability. The project is written in C, and the top level entries are a Visual Studio solution and project file, a small set of C and C++ sources, and a HuanLoader/ directory. The author also adds a disclaimer restricting the tool to authorised security testing and noting that misuse against systems without explicit permission is illegal. There is no homepage, no package registry entry and no release, so the project is consumed by cloning it and building it, which is the normal shape for a study artefact rather than a dependency.

The build pipeline: encrypt, compile, append a .huan section

The described flow has three stages, and the order matters. First Huan reads the given PE file and encrypts it with CBC mode AES-128, using the Tiny AES in C library with padding code prepared to satisfy that library's requirements. Second, once encryption is complete, it compiles the loader with the Visual Studio compiler, MsBuild.exe, producing an executable. Third, it creates a section called .huan on that executable and embeds four things in it: the encrypted content, the size information, the IV and the symmetric key. The README states that both keys are created randomly for each copy of the loader, which is the one design decision here that has a real security consequence. A random key per copy means two loader binaries built from the same input differ, so a signature written against one sample will not match the next. The layout of the .huan section is documented with a diagram linked from the README, so a reader can see the ordering of content, size, IV and key without reading the code.

Runtime self-location through the PEB and .huan parsing

The loader side of the project is where the PE knowledge becomes visible. When the loader executes, it first takes the image base of itself by reading the Process Environment Block. Once it knows its own image base, it parses the loaded copy of itself to find the .huan section. It then decrypts the whole content, buffers it, and loads the binary from memory rather than from disk. Two details are worth pausing on. The first is the self-reference: rather than assuming a fixed address, the loader derives where it is in memory from process structures, which is the standard trick for position independent code and is what lets the same executable work under different base addresses. The second is the ordering constraint, since decryption depends on having found the section, which depends on knowing the image base, which depends on reading the PEB. The README's reference list backs this up with a base relocation write-up and a pair of articles on the PE file format and on import address table hooking, which tells you which parts of the format the author was working from.

The repository is small enough to read end to end

The file listing is compact and maps cleanly onto the pipeline described above. Main.cpp is the driver, NewSection.cpp and NewSection.h handle the part where a new section has to be added to an already compiled executable, and Crypto.cpp with Crypto.h cover the encryption side. The AES implementation is vendored directly as aes.c, aes.h and aes.hpp, so there is no package manager step and no dependency resolution. The HuanLoader/ directory holds the loader sources that get compiled into the generated executable, which is how the two halves of the project stay separate: one program produces the loader, and the loader is what runs on the target. Huan.sln, Huan.vcxproj, Huan.vcxproj.filters and Huan.vcxproj.user are the Visual Studio solution and project files, so a Windows developer with Visual Studio installed opens the solution and builds. The LICENSE file sits at the root under the MIT licence, and the README closes with a disclaimer and the reference links.

What the README does not document: usage, flags and 32-bit support

There are real gaps in the documentation and they are worth stating before you build anything. There is no installation section, no command line syntax and no description of how the input PE file is passed to the generator, so the README does not tell you how to invoke the tool once it is compiled. There is also no statement about the loader's entry point behaviour, its error handling, or what happens if the .huan section is missing or corrupted at run time. The scope constraint is clearer: the README says it currently works on 64 bit PE files, and the TO-DO list puts 32 Bit support as the first open item, alongside improvements on the PE loader, a planned blog post about the PE loading process, and reducing the detection rate of the loader. Because 32-bit input is out of scope, feeding a 32-bit PE to the tool is outside what the author claims to support, and the README offers no error path for that case. Expect to read Main.cpp to learn the invocation rather than to find it in a usage section.

Why a crypter is a different thing from a packer

The realistic alternative for someone who wants a program to run an embedded binary is to write the in-memory loading part yourself, without the encryption layer, or to use an existing compression or packing tool for the distribution step. The difference in approach is precise. A plain manual loader takes a payload, locates it in a section, and maps it into memory, so its content is visible to anyone inspecting the file with a hex editor. Huan adds a symmetric encryption stage with a random key per copy, so the payload on disk is ciphertext and each build differs. That is the entire value of the project, and it is also where the risk sits. A TO-DO item about reducing the detection rate of the loader tells you plainly that the author is aware such binaries attract attention from endpoint tooling, and any tool whose roadmap includes lower detection is being judged by criteria different from those of a normal build utility. For learning, reading the code is the point and the file list is short enough for that. For anything else, an ordinary signed installer is the tool you want.

A project last touched on 2026-04-04 with no releases

The repository is not archived, but the last push was on 2026-04-04 and there are no GitHub releases, so there is no version to pin, no changelog to read and no binary to download. Anyone picking this up should expect to resolve the Visual Studio toolchain themselves and to hit whatever the state of MsBuild.exe and the project files is on their machine. The cryptographic choices are dated in a similar way, with AES-128 in CBC mode and a hand prepared padding layer wrapped around a small C AES implementation, which is a reasonable choice for understanding the mechanics and not a choice to build new protections on. The licence is MIT, which is permissive and short, and it applies to the source in this repository. The upstream references the project leans on, including the Tiny AES in C library and the PE format articles, are the more durable part of the ecosystem here, and the PE format documentation linked in the README remains the reference to check the loader logic against.

Editorial conclusion

Huan is worth reading and building if you are studying PE file structure, section handling or in-memory loading on Windows, and the source is small enough to read in an afternoon. Do not adopt it as a deployment tool, a packer for legitimate binaries, or anything that runs on machines you are not authorised to test, and note that the last push was on 2026-04-04 with no tagged releases, so expect to fix the build yourself. Before using it, check that your Visual Studio toolchain and MsBuild.exe are in place and confirm your input is a 64-bit PE, because 32-bit support is still an open to-do item.

Frequently asked questions

Official sources

1. frkngksl/Huan on GitHub
2. Issues
3. License: MIT
4. README