KSword 5.1 : une trousse ARK Windows sous licence GPL, entre héritage et prudence

Ce que KSword 5.1 résout concrètement

Le projet répond à un besoin précis : croiser les vues R3 (mode utilisateur) et R0 (noyau) pour mettre en évidence des objets cachés, des modules non alignés ou des descripteurs incohérents. Le public visé est celui des analystes forensiques, des développeurs de drivers et des personnes qui maintiennent des systèmes Windows durcis. La suite ne se contente pas de lister des processus : elle propose une vue croisée des threads, des CID et des handles, avec des preuves d'objets cachés. Le README insiste sur le fait que les pages d'audit sont en lecture seule et que les actions destructives ou de mutation sont explicitement gardées. Cela change la nature de l'outil par rapport à un simple gestionnaire de tâches amélioré. Le projet se positionne comme une source-available, pas comme un logiciel libre communautaire au sens large, même si la licence est bien la GPL-3.0.

Architecture en cinq composants, du Qt au Win32 brut

La suite est découpée en plusieurs binaires. L'application principale, Ksword5.1, est une interface Qt avec une disposition de docks à la manière d'ADS. À côté, KswordARKLight est une application Win32 native, plus légère, destinée aux anciens systèmes et aux environnements à faibles ressources. Le Launcher est un assistant de démarrage pur Win32 qui vérifie un manifeste de support avant de lancer la cible. Le cœur technique est le driver KswordARKDriver, qui implémente les protocoles d'audit pour les processus, threads, handles, mémoire, réseau, objets noyau, périphériques et sécurité. Enfin, KswordCLI offre une interface en ligne de commande pour l'automatisation et le dépannage. Cette séparation est un choix assumé : on peut exécuter la version légère sans charger toute l'interface Qt. Le README précise que l'installateur est optionnel et que l'extraction manuelle du répertoire Release est fonctionnellement équivalente.

Le mécanisme des profils DynData et des PDB en arrière-plan

Un point central du fonctionnement est la gestion des profils d'offsets. Quand un profil DynData packagé ne correspond pas à la cible, les applications pleine et légère peuvent résoudre un profil PDB exact en arrière-plan. Cette résolution n'est pas automatique : des vérifications d'identité sont requises avant que le résultat soit appliqué. Cela signifie que l'outil ne suppose jamais que sa base de connaissances est à jour. C'est une différence nette avec d'autres ARK qui embarquent des tables d'offsets figées. Le coût, c'est un temps de démarrage potentiellement plus long et une dépendance à la disponibilité des symboles Microsoft. Le README mentionne aussi que les limites d'exécution restent explicites : unsupported, troncature, DynData, privilèges et limitations matérielles sont signalés au lieu d'être masqués.

Le moniteur VMX résident et ses garde-fous

La page HVM propose des auto-tests VMX avec confirmation, un invité à usage unique et un moniteur résident Intel VT-x/EPT avec télémétrie des VM-exits. Le démarrage résident est refusé sur AMD, sous un hyperviseur existant, ou quand les gardes de cycle de vie (alimentation, topologie, déchargement) ne sont pas disponibles. C'est une limitation importante à connaître : l'outil ne fonctionne pas sur toutes les machines, et il est explicitement destiné à un usage de laboratoire autorisé et de diagnostic. Le README ne donne pas de détails sur les mécanismes de télémétrie eux-mêmes, mais la prudence affichée est cohérente avec le reste du projet. Si vous travaillez sur un ordinateur portable avec Virtualization Based Security activée, le moniteur refusera probablement de démarrer. C'est une protection, pas un bug.

L'éditeur d'octets contraint et le scanner de fichiers

Le dock Scanner effectue des analyses structurelles de fichiers PE, ELF et Mach-O. L'éditeur d'octets optionnel est volontairement limité aux modifications qui préservent la longueur. Il revalide la copie source, remplace atomiquement la cible et peut conserver une sauvegarde après un accusé de risque explicite. Ce choix de conception est rare dans les outils de ce type : on ne peut pas insérer ou supprimer des octets, ce qui limite les manipulations accidentelles. En contrepartie, cela rend impossible certaines corrections qui exigent un décalage de sections. Le mécanisme de remplacement atomique est un signe de soin, mais il faut noter que la revalidation ne garantit pas que la cible est saine, seulement que la copie source n'a pas changé entre la lecture et l'écriture.

Le catalogue de connaissances intégré, un atout documentaire

Le KernelDock contient un centre de connaissances bilingue dérivé d'un document nommé 第二规划.md. Il propose 71 sujets répartis en 12 catégories, chacun avec un article en huit parties, une requête R3/R0 versionnée, des sources IOCTL vérifiées et un lien vers la page de preuve correspondante. C'est plus qu'une aide intégrée : c'est une tentative de réduire l'écart entre la documentation et le code. Le README précise que les limites d'exécution restent affichées, ce qui évite de présenter une connaissance partielle comme complète. Pour un analyste qui débute, ce catalogue peut servir de point d'entrée. Pour un expert, il faudra vérifier la fraîcheur des entrées, car le projet évolue rapidement et les articles peuvent ne pas suivre toutes les modifications du driver.

Limites franches et comparaison avec OpenArk

Le dépôt contient un fichier docs/OpenArk功能对照与TODO.md qui compare la couverture avec OpenArk. C'est une transparence rare : le projet reconnaît qu'il a des lacunes et les documente. Les limites matérielles et logicielles sont explicites, notamment pour le moniteur VMX et les profils DynData. Le projet est aussi marqué par un rythme de publication intense : plusieurs versions ci-build par jour, avec des correctifs ciblés comme la réparation du rafraîchissement de la fenêtre de journal ou des styles de table transparents. Ce rythme indique une maintenance active, mais il impose de suivre les versions de près. La GPL-3.0 s'applique, ce qui signifie que toute redistribution doit respecter les termes de la licence, mais le README parle de source-available, une nuance qui mérite d'être vérifiée avant de réutiliser le code dans un projet fermé.

Conclusion éditoriale

Adoptez KSword 5.1 si vous travaillez dans un laboratoire autorisé, avec des machines de test dédiées, et si vous acceptez de vérifier manuellement les profils DynData et les identités PDB avant chaque application. Évitez-le pour un usage en production sur des postes sensibles : les actions destructrices sont volontairement gardées, mais le driver kernel et le moniteur VMX résident exigent une compréhension fine des risques. Avant de l'intégrer, vérifiez que votre environnement ne possède pas déjà un hyperviseur actif, car le démarrage du moniteur Intel VT-x est explicitement rejeté dans ce cas. Enfin, contrôlez la fraîcheur des profils DynData packagés, car un profil non correspondant déclenche une résolution PDB en arrière-plan dont l'identité doit être confirmée.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes