Comment j’ai gâché mes vacances avec du reverse engineering de WSC

• Partage d’expérience sur le processus de développement de defendnot, un outil qui désactive Windows Defender en exploitant directement l’API du service Windows Security Center (WSC)
• Le projet a commencé en cherchant à dépasser les limites techniques et les problèmes juridiques de l’ancien projet no-defender
• Le reverse engineering et le débogage ont été menés malgré de nombreux obstacles, notamment un environnement atypique (MacBook arm64, débogage à distance, forte latence)
• Analyse du contournement de l’enregistrement de Defender et des mécanismes de vérification des processus, puis amélioration progressive jusqu’à un fonctionnement stable après de nombreux échecs et tentatives
• Au final, la fonction d’exécution automatique a elle aussi été implémentée, avec en parallèle un retour honnête sur les difficultés rencontrées pendant le projet

---

Introduction

• Partage d’expérience autour du parcours d’implémentation de l’outil defendnot qui désactive Windows Defender
• Le texte se concentre moins sur les détails techniques que sur les problèmes concrets rencontrés et les tâtonnements en conditions réelles
• Une documentation formelle et des explications techniques plus détaillées seront publiées séparément plus tard

Retour un an en arrière

• Il y a environ un an, l’auteur a publié un projet nommé no-defender, qui exploitait le fonctionnement par lequel Windows Defender est désactivé via l’API WSC
• Ce projet s’appuyait sur du code tiers provenant d’un éditeur d’antivirus afin de faire croire au système qu’un autre antivirus était enregistré
• Après sa sortie, le projet a suscité beaucoup d’intérêt et obtenu environ 1 500 stars, mais une demande de retrait DMCA de l’éditeur concerné a conduit à la suppression du code source et à l’arrêt du projet

Pourquoi lancer ce projet

• Au moment de la rédaction, l’auteur séjournait dans un Airbnb à Séoul
• Son principal environnement de développement était un MacBook M4Pro, sans machine dédiée au reverse engineering x86
• À cause d’un CTF et d’un planning de voyage, il a dû travailler sans appareil x86
• En parallèle d’une réflexion sur une implémentation plus « normale » de no-defender, il a commencé à explorer la possibilité d’une implémentation autonome, indépendante de tout AV

Enquête initiale (jour 1)

• Avec l’aide d’un ami, l’auteur a obtenu le binaire wsc et a tenté de réimplémenter l’enregistrement WSC avec une structure similaire à celle du projet précédent
• L’implémentation via l’API COM de WSC a toutefois échoué avec une erreur Access Denied
• Il a identifié l’origine du problème dans le fait que WSC vérifie la signature et l’authentification du processus qui appelle l’API
• En injectant un module dans un processus AV pour tenter l’enregistrement, il a pu constater qu’un AV était alors enregistré avec succès

Remplacement du binaire AV et expériences supplémentaires (jour 1)

• Une tentative d’exécuter l’outil via un processus système signé (cmd.exe, etc.) a échoué lors de la vérification PPL (Protected Process Light)
• L’analyse détaillée du désassemblage et du traçage a été reportée à plus tard, et le travail temporairement mis en pause

Mise en place de l’environnement (jour 2)

• À cause des limites d’un MacBook arm64, le débogage Windows x86 était extrêmement difficile
• L’auteur a utilisé à distance le PC d’un ami vivant aux États-Unis (Parasec, Anydesk, etc.) pour mener le débogage et les tests dans un environnement à forte latence
• L’alternance complexe entre compilation du code et débogage de VM a entraîné lenteurs et confusion

Débogage du service WSC (jour 2)

• Il a confirmé que le service WSC était structuré comme une DLL exécutée par svchost
• Pour désactiver la protection PPL, il a appliqué un contournement via un pilote spécial, puis vérifié l’entrée dans les fonctions avec un débogueur
• Il a découvert qu’une vérification du jeton SID de WinDefend avait lieu à l’intérieur du service
• Il a alors formulé l’hypothèse qu’il serait possible de contourner l’authentification en imitant un processus possédant le SID WinDefend

Imitation du SID WinDefend (jour 2)

• Il a approfondi son apprentissage de la structure et du fonctionnement des jetons Windows
• Après avoir implémenté puis exécuté un code imitant le SID WinDefend, tous les appels COM retournaient SUCCESS, mais aucun AV n’était réellement enregistré

Reconstruction de l’algorithme de vérification (jour 3)

• Il a réanalysé avec soin le binaire AV pour vérifier si le contrôle du SID passait réellement
• En cas d’échec du contrôle SID, le service vérifiait aussi l’élévation de privilèges, la signature du binaire et le drapeau DllCharacteristics du PE (ForceIntegrity)
• Il a reproduit la fonction réalisant cette logique et mené des tests en l’appliquant à des binaires core du système

Utilisation du processus Taskmgr (jour 3)

• Une nouvelle tentative avec Taskmgr.exe comme processus cible a échoué, car WSC rejetait la requête à cause d’une erreur dans la transmission du nom et d’un bug IPC
• Après avoir amélioré l’inférence du chemin de fichier et la manière de transmettre le nom de l’AV, il a confirmé un fonctionnement normal

Nettoyage du code (jour 3)

• Il a réorganisé les fonctionnalités et tenté d’implémenter la fonction d’exécution automatique (autorun)
• Des échecs intermittents dans la gestion de l’exécution automatique l’ont conduit à répéter les vérifications du code et de l’environnement pour en identifier la cause

Implémentation de l’exécution automatique (jour 4)

• Il a fini par identifier comme cause une option du planificateur de tâches (Task Scheduler) configurée pour empêcher l’exécution si l’ordinateur portable n’était pas branché sur secteur
• Après avoir désactivé ce paramètre, l’exécution automatique a fonctionné normalement
• Il a terminé par un nettoyage du code et des tests

Conclusion

• Le travail de reverse engineering dans un environnement limité et inconfortable a été une expérience extrêmement éprouvante, psychologiquement et physiquement
• Une documentation plus détaillée sur l’implémentation de WSC sera publiée séparément plus tard

Remerciements

• Pindos : un ami qui a prêté son PC la nuit pour aider au débogage et a réchauffé la chambre
• MrBruh : un collègue qui a stimulé le démarrage de l’exploration du projet et fourni des retours sur les idées
• Merci aussi aux proches qui sont restés en contact pendant toute la durée du projet et ont apporté leur soutien
• L’auteur confesse son amour pour le kimchi
• Merci également à l’artiste qui a laissé un graffiti sur notre mur

[GN⁺]

Commentaires Hacker News

• La méthode la plus puissante, mais aussi la plus intrusive, pour désactiver Defender consiste à démarrer sur une clé USB Linux live, renommer le dossier C:\ProgramData\Microsoft\Windows Defender, puis créer un fichier vide à sa place
  • Les stratégies de groupe fonctionnent tellement bien que j’ai mis un contrôleur dans mon homelab et configuré un environnement de domaine local qui modifie automatiquement les politiques Defender pour tous les utilisateurs
  • C’est étrange que Windows n’ait pas de manifeste signé permettant de détecter ce genre de manipulation
  • Des produits populaires font essentiellement la même chose, et l’un d’eux a même réussi à faire tomber environ 25 % d’Internet
• Le projet a beaucoup fait parler de lui et a reçu environ 1,5k étoiles, puis le développeur de l’antivirus que j’utilisais a envoyé une demande DMCA. Je ne comprends pas de quel « antivirus que j’utilisais » il s’agit, ni pourquoi cette personne envoie une DMCA. L’auteur a sans doute rétroconçu un autre antivirus et l’a intégré à l’open source, ou au moins quelque chose lié à une imitation de WinDefend. Il semble y avoir eu un problème de droits d’auteur
  • D’après ce que j’ai compris, il s’est servi de l’enveloppe d’un autre outil antivirus pour contourner les exigences de signature. C’est transformateur, donc peut-être défendable, mais je ne suis pas juriste et ça reste une zone grise
  • Oui, il a copié des parties d’un programme antivirus existant en violation du droit d’auteur. Le paragraphe juste au-dessus de celui qui est cité explique aussi que le projet utilisait du code tiers d’un antivirus existant pour enregistrer l’AV dans le WSC
• Pour information, WSC signifie Windows Security Center
  • Merci pour l’aide. C’est vraiment pénible quand un sigle apparaît pour la première fois sans être expliqué
• C’est vraiment bizarre : https://github.com/es3n1n/defendnot/… Si ça vous intrigue, voyez ici ce qui se passe réellement : https://github.com/es3n1n/defendnot/…
  • J’aimerais bien que quelqu’un capable d’expliquer la magie du C++ m’explique pourquoi ce code est bizarre
  • Je ne vois pas ce qu’il a d’étrange. J’utilise très bien ce pattern à plusieurs endroits dans mon code. L’appelant a une signature différente, mais c’est une préférence personnelle. À noter que le langage D a une syntaxe intégrée qui se déclenche à la sortie du scope
  • Par manque de temps, je n’avais pas envie d’implémenter moi-même un pattern RAII pour tous les composants COM. Je vais changer ça dans la prochaine mise à jour
  • « Le code, c’est comme la manière dont on traite ses collègues » — Michael Feather En résumé, ce n’est pas de l’IA Le code sert à différer l’appel d’une fonction jusqu’à la fin du scope d’un objet. Il s’appuie sur des macros C pour simplifier la définition complexe de lambdas/fonctions anonymes en C et la génération de noms de variables uniques. En revanche, comme les macros ne sont pas écrites en majuscules et ressemblent à des appels de fonction, cela peut dérouter les personnes qui ne connaissent pas ce style. Pour certains, ce pattern est suffisamment utile pour être considéré comme idiomatique. Une explication technique figure dans le lien d’un autre commentaire
• L’an dernier, j’ai passé d’excellentes vacances à rétroconcevoir les bureaux virtuels de Windows, et j’en garde un super souvenir. Le reverse engineering est vraiment amusant. J’y ai appris beaucoup de choses intéressantes, par exemple que Windows RPC a en interne un mécanisme de messagerie non documenté : https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC.html
• J’ai lu récemment https://nostarch.com/windows-security-internals, et cela rend cet article encore plus parlant. Je connaissais déjà dans les grandes lignes le fonctionnement du backend de Windows, mais le dernier chapitre de ce livre explique les tokens et les SID avec autant de détail que l’auteur ici
• Je me demande pourquoi quelqu’un voudrait désactiver le WSC
  • Ça peut être pour les performances, le développement de malwares, le piratage, etc.
  • Si c’est un acteur malveillant, il a peut-être la chance qu’aucun autre produit EDR ne soit installé. Mais s’il y en a un, il sera presque certainement bloqué. Si c’est un éditeur d’EDR, cela peut servir d’appel d’API obscurci pour désactiver le pare-feu Windows. Des produits comme CrowdStrike peuvent aussi utiliser leur propre pare-feu ou remplacer celui de Windows
  • Tous les logiciels antivirus sont au minimum des powervirus. Je n’aime pas qu’on me surveille en me disant que je n’ai pas le droit d’utiliser netcat.exe
  • C’est mon matériel, j’en fais ce que je veux. C’est une raison suffisante
  • Je me demande pourquoi quelqu’un voudrait absolument installer un rootkit sur son propre système
• Ce qui est encore pire selon moi, c’est que Check Point Harmony n’utilise absolument pas l’interface prévue pour Defender et dit carrément aux utilisateurs de désactiver Defender manuellement via un article de la base de connaissances
• Au cas où vous vous poseriez la question : WSC signifie Windows Security Center. J’ai dû le chercher moi aussi
  • L’article contient bien la phrase « Tout cela est géré par Windows Security Center-WSC »
• À propos du passage « je travaille sur un macbook arm64 et il n’existe actuellement aucun moyen correct d’émuler Windows x86 sur un MacBook ARM », quelqu’un demande ce qu’il en est de UTM et mentionne que Parallels a récemment commencé à prendre en charge les VM Intel
  • J’ai essayé UTM, et avec Windows x86 c’était inutilisable. Pour du Linux en ligne de commande, on peut tolérer une certaine lenteur, mais dans un environnement GUI c’est impossible. Windows arm64 tourne bien, mais ce n’est pas du Windows x86, donc inutile pour faire du reverse engineering de composants système x86
  • Le système de recompilation dynamique de QEMU n’est pas aussi efficace que les systèmes natifs de Windows ou de macOS (Rosetta 2). Windows x86 se lance dans UTM, mais les performances sont très mauvaises. En pratique, j’ai l’impression qu’il vaut mieux utiliser le recompilateur dynamique de Windows dans une VM Windows ARM pour exécuter des applis x86, ou WINE qui s’appuie sur des sous-systèmes en code natif. Pour des besoins simples et urgents, ça peut dépanner. Si, pour l’auteur, « correct » inclut les performances, alors son point de vue se comprend
  • Corrigez-moi si je me trompe, mais il me semble que l’émulation d’un CPU avec MMU est fondamentalement lente et difficile à optimiser. Les technologies comme Rosetta d’Apple et l’équivalent chez Microsoft vont vite parce qu’elles n’exécutent que du code en espace utilisateur. Elles évitent l’émulation complète du MMU à l’échelle du système entier