gargoyle is a historical Windows research proof of concept demonstrating temporal memory state, where code stays non-executable between timer/APC re-entry events for authorized forensic study.
| Tool | JLospinoso/gargoyle — historical Windows research artifact for temporal memory state, refreshed with x64, ARM64, and ARM64EC sibling demonstrations and a validation harness |
| Category | Memory forensics / Windows internals research artifact |
| Primary Use | Studying how a code region can spend its dormant interval non-executable between timer/APC re-entry events, and validating those observations via a reproducible harness (just ci) |
| Safe Use | Explicitly scoped as a benign research artifact for authorized defensive research, DFIR study, and lab reproduction; the repo states it is not a loader, deployment guide, or C2 tooling |
| Telemetry Note | The README is candid about observability: a benign action is observable during the work window, and live validation uses two benign MessageBox popups — a directly visible artifact defenders can watch for in lab environments |
gargoyle occupies an unusual and instructive position in the offensive-security research canon: it is a self-described historical proof of concept rather than an operational tool. Authored by JLospinoso and now refreshed for modern architectures, the repository frames itself around a single narrow claim — that on Win32/x86, a benign action can be made observable during a small work window while the relevant code region spends its dormant interval non-executable, returning to execution only via timer/APC re-entry. That framing matters for anyone evaluating the project, because the README goes out of its way to disclaim the sensational readings such demos often attract. It does not claim invisibility, and it does not claim to bypass any product.
The refreshed repository structure reveals a deliberate shift from 2017-era blog artifact to maintained research project. Alongside the canonical Win32/x86 implementation, there are sibling demonstrations for x64, ARM64, and ARM64EC, a reproducible validation harness, and what the README calls clearer evidence language. The topics list — memory-forensics, dfir, malware-research, reverse-engineering, temporal-memory-state, rop-gadgets, arm64ec, pic — reads like a curriculum for defensive analysts as much as for offensive researchers, and that dual audience is consistent with how the documentation is organized.
The core mechanism worth understanding as an analyst is the corrected timer/APC path documented around SleepEx(INFINITE, TRUE). The concept is alertable waits: when a thread enters an alertable wait via SleepEx with the alertable flag set, asynchronous procedure calls queued to it — including those driven by timers — get delivered, giving the dormant code a controlled re-entry point. The dedicated concept document docs/concepts/timer-apc-sleepex.md covers this evidence path in depth, and it is the right starting point for readers who want the internals rather than the nostalgia.
What separates this refresh from most research repos of its era is the explicit evidence-boundary language. The README enumerates precisely what each sibling demonstrates and, more importantly, what it does not. The x64 sibling is not a direct port of the original x86 mshtml.dll gadget/trampoline path, which is a notable admission given how often the original technique was cargo-culted. Live validation for x86/x64 uses two benign MessageBox popups — one validating initial execution, one validating later controlled re-entry — and the README states plainly that this does not validate callback identity or every memory-protection transition.
The ARM64 and ARM64EC siblings actually carry stronger evidentiary weight than their x86/x64 counterparts, at least by the project's own accounting. Their headless validation additionally checks completed-round and callback-round counters, giving more rigorous callback-delivery evidence than the MessageBox heuristic. On ARM64EC specifically, the demonstration exercises the EC-code allocation behavior used by this demo, while explicitly disclaiming that it does not demonstrate mixed x64 DLL interop or prove every ARM64EC dynamic-code pattern. This level of calibrated claim-making is rare and worth studying as a model for research hygiene.
The local validation gate is deliberately minimal: uv sync --all-groups followed by just ci under PowerShell. That is the entire documented build path, in keeping with the responsible-use posture — there is no operational guidance here, and the README says so in plain terms: no persistence, no injection, no credential access, no networking, no C2. The repository is not a loader, an operator workflow, or a deployment guide, and readers arriving expecting any of those will find the door explicitly closed via docs/responsible-use.md, which documents scope boundaries and non-goals.
For defenders and DFIR practitioners, the educational value lies in the observation asymmetry the project formalizes: time-bound memory observability. If a code region is non-executable for the majority of its lifetime and only transiently present in an executable, observable state, then point-in-time memory acquisition during the dormant interval will miss it. Conversely, the README is quick to note that the benign action remains observable during the work window — the technique narrows the observation window, it does not eliminate it. This is precisely the kind of temporal reasoning forensic tooling and scan scheduling need to account for, and gargoyle remains one of the cleanest pedagogical vehicles for the concept.
The documentation tree is unusually well-organized for a research artifact. docs/index.md provides reader paths and orientation, docs/quickstart.md offers the shortest safe build-and-validate path, docs/architectures/comparison.md tabulates what each sibling demonstration validates, and docs/validation/overview.md defines the evidence vocabulary used consistently across the repo. There are also research docs/research/references.md and a docs/research/lineage.md for source mapping and relationship boundaries — the latter being particularly useful given how many derivative and often-mischaracterized versions of gargoyle circulated after the original 2017 publication.
The historical context links anchor the project to its own lineage: the original 2017 article on memory-analysis evasion and a decade-later retrospective blog post. Reading both alongside the refreshed README gives a useful case study in how security research matures — from a single-architecture blog demo with implied capabilities toward a multi-architecture test suite with disciplined, falsifiable claims. The original x86 path through a mshtml.dll gadget trampoline was of its era; the current repo's refusal to simply port it to x64 is arguably the more interesting research statement.
Licensing is AGPL-3.0, which is worth noting for anyone considering embedding or extending the code in derivative research tooling — the copyleft terms propagate to distributed modifications. The repository runs to 917 stars in Python (the harness language; the demonstrations themselves span native x86, x64, ARM64, and ARM64EC code), reflecting the project's enduring relevance to the memory-forensics community rather than any operational popularity.
In sum, gargoyle in its current form is best approached as a teaching instrument about validation itself: what constitutes evidence of execution, how architecture differences change what a proof demonstrates, and why temporal properties of memory resist point-in-time analysis. For authorized professionals building forensic intuition about alertable waits, APC delivery, and non-executable dormant regions, the refreshed repository, its harness, and its calibration documents offer a rigorous, deliberately non-weaponized path — and its explicit non-goals make it a defensible reference even in restricted research environments.
JLospinoso/gargoyle.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.