Entropia is a compiled language designed specifically for writing Beacon Object Files and position-independent shellcode on Windows x86-64. Not a framework on top of C, not a template generator, not yet another Python wrapper that spits out C. It’s its own (small) language, with its own compiler, and it gives you the artifact you need without intermediate steps or linker gymnastics.
I spent some time with it, and this is what I got out of it.
why this matters
The traditional BOF development pipeline looks something like this: write C, include the BOF SDK headers, manually declare every dynamic function resolution, cross-compile with MinGW, test with a harness, fix crash, repeat. Every step can break something, including your will to live, and it’s more the toolchain than the logic.
Entropia collapses all of that into one step. You write a .etpy file, run entc compile, and get a .x64.o ready to load. The compiler handles position independence, import resolution, relocations, and all the plumbing that normally lives in your head as tribal knowledge.
the language itself
The syntax is minimal and learnable in an afternoon. It feels like a stripped-down C with modern ergonomics. Here’s the shape of a BOF entry point:
|
|
That use bof; directive tells the compiler to emit a COFF object with the right relocations and Beacon API stubs. No headers, no macros, just this little piece of code.
Need Windows structs? Instead of copy-pasting struct definitions from MSDN or fighting with SDK headers:
|
|
This pulls struct layouts and constants directly from the Windows SDK metadata. PROCESSENTRY32, TH32CS_SNAPPROCESS, all of it, correct and ready to use.
lifecycle stages
Entropia has a concept of lifecycle stages. You can write modules that hook into the Init stage, running before your actual code:
|
|
Three lines and your BOF runs in a cleaned environment. Each is a [Stage(Init)] hook that executes before go() is called. You don’t have to remember the ordering or wonder if you patched AMSI before loading the reflective DLL.
You can also write your own stages. Want to add random delays between API calls to break behavioral signatures? Write a stage that sleeps for a jittered interval before execution and use it everywhere.
a real example
I hammered together an ipconfig-equivalent BOF to test the whole pipeline. In C this would be a solid chunk of boilerplate between the DFR macros, the manual struct definitions for IP_ADAPTER_INFO and FIXED_INFO, and the two-pass buffer allocation dance.
In entropia:
|
|
As you can see there’s no more DFR, and struct definitions from MSDN are gone. Iphlpapi.GetAdaptersInfo resolves imports at compile time, the compiler handles PEB resolution at runtime.
Compile it clean, run strings on the output, and every error message is in cleartext, every import symbol spelled out as __imp_IPHLPAPI$GetAdaptersInfo, __imp_KERNEL32$HeapAlloc. Add --opsec=all --seed=random and the __imp_LIB$FUNC symbols disappear, resolved at runtime via PEB walk. The identifying strings ("could not get network adapter info", "Ethernet", "0123456789ABCDEF") get moved to the stack. The code goes through polymorphic rewriting and NOP sled insertion. Run it again with a different seed and you get a bytewise-different artifact from the same source.
You have full control over your output, built one piece at a time, reusable (call the same opsec passes across all your BOFs), and easy to plug into any CI/CD or deployment pipeline.
how i got here
The whole adventure started, as most things do in 2026, by dumping the entire documentation locally and letting a model guide me through the conversion of my existing BOFs to .etpy. I steered, it (he/she?) did, and in the process I learned. A weird loop, but it works.
By the end I came out with a devcontainer purpose-built for the entropia toolchain, a skill that assists in BOF development and conversion, and all the pieces I need to keep writing in this language. Setting up a build & deploy pipeline on top of it couldn’t have been simpler.
The project is pre-1.0 and labeled experimental, but the compiler produces working artifacts and the language surface is stable. I’ll be keeping an eye on it. Kudos to the creators.