Gargoyle

Gargoyle est une preuve de concept historique de recherche Windows portant sur l'état temporel de la mémoire. L'implémentation originale Win32/x86 reste la preuve canonique : une action bénigne est observable pendant une petite fenêtre de travail, tandis que la région de code concernée passe son intervalle dormant en non-exécutable avant la réentrée par timer/APC.

Le dépôt actualisé place cette histoire au centre tout en ajoutant des démonstrations sœurs x64, ARM64 et ARM64EC, un harnais de validation reproductible et un langage de preuve plus clair. Il documente également le chemin corrigé timer/APC autour de SleepEx(INFINITE, TRUE).

Gargoyle ne revendique ni l'invisibilité ni le contournement de produits. Ce n'est pas un loader, un workflow d'opérateur ni un guide de déploiement, et il ne fournit aucune indication sur la persistance, l'injection, l'accès aux identifiants, le réseau ou le C2.

À lire ensuite

• Accueil de la documentation pour les parcours de lecture et l'orientation du projet.
• Usage responsable pour les limites de périmètre et les non-objectifs.
• Démarrage rapide pour le chemin de compilation et de validation sûr le plus court.
• Timer APC et SleepEx pour le chemin de preuve corrigé de l'attente alertable.
• Comparaison des architectures pour ce que chaque démonstration sœur valide et ne prouve pas.
• Vue d'ensemble de la validation pour le langage de preuve utilisé dans l'ensemble du dépôt.
• Références de recherche et filiation pour la cartographie des sources et les limites des relations.

Architecture et limites des preuves

• Win32/x86 est l'implémentation historique canonique.
• x64, ARM64 et ARM64EC sont des démonstrations sœurs, et non des remplacements de la conception originale.
• La démonstration sœur x64 n'est pas un portage direct du chemin gadget/trampoline original mshtml.dll en x86.
• La validation en direct x86/x64 utilise deux MessageBox bénignes. Cela valide l'exécution initiale et la réentrée contrôlée ultérieure, mais pas l'identité du callback ni chaque transition de protection mémoire.
• La validation sans interface ARM64 et ARM64EC vérifie également les compteurs de tours terminés et de tours de callback, ce qui fournit des preuves plus solides de livraison des callbacks.
• ARM64EC exerce le comportement d'allocation de code EC utilisé par cette démo. Il ne démontre pas l'interopérabilité de DLL x64 mixtes et ne prouve pas tous les motifs de code dynamique ARM64EC.

Porte locale

uv sync --all-groups
just ci

Contexte historique

• Gargoyle, une décennie plus tard
• Article original de 2017