Komodia dit:
En d'autres termes, Windows Metro Application Utilisation de l'environnement Sandboxé, quelle injection DLL ne peut pas être faite.
Voyons ce que Nektra dit:
Comme vous pouvez le voir Komodia et Nektra affirment une information conflictuelle, ma question est de savoir quel est le vrai derrière l'injection DLL sous Windows 8, puis-je injecter mon code dans la demande de métro comme d'habitude (NT, Win9X) comme Nektra?
4 Réponses :
Je suis l'auteur de l'article de Nektra. La recherche a commencé lorsque nous voulions ajouter plus de fonctionnalités à l'application de messagerie métro limitée fournie avec Windows 8.
Bien que le processus n'était pas exactement identique à celui des applications de bureau, car les applications de métro sont généralement suspendues, nous avons accroché le premier service DCOM.
Lorsque DCOM Service lance l'application Metro Mail, nous injectons à ce stade la DLL à l'aide de la méthode bien connue Createremotethread / Chargement d'appel LoadLibrary.
Dans les tests initiaux, nous avons essayé d'injecter une DLL située dans le même dossier, notre test était situé et découvert que, si la DLL était dans System32, elle se charge bien.
Plus tard, nous effectuons les recherches supplémentaires pour voir pourquoi la DLL ne se chargeait pas si non sur le dossier System32.
À propos de Hooking Winsock, nous n'avons pas testé cela, mais je pense que cela devrait être possible car, au moins sur des ordinateurs de bureau, derrière Metro, il y a les DLL communément connues (Kernel32, User32, etc.) et nous avons accroché des API sans problèmes.
Je suis l'auteur de l'article de Komodia et notre article ne contient pas de conflit avec Nektra, il est possible de gérer les applications métropolitaines ou du sandbox qui exécute les applications de métro, mais vous ne pouvez pas vous connecter à localhost, pas parce que d'accrocher mais à cause de la limitation de métro sur les connexions locales. Dans notre premier test, nous avons utilisé notre Win7 WFP (qui est un pilote de réseau) et a modifié l'IP des paquets vers localhost, qui n'a pas fonctionné avec des applications métropolitaines, NDIS ne fonctionnera pas exactement la même chose, la seule façon de le faire consiste à utiliser Microsoft's Redirection du proxy WFP.
Peut-être que quelqu'un finira par trouver ou déjà trouvé un piratage qui permet une connexion directe locale, et comme avec des hacks, il existe des risques à prendre en compte. Si vous souhaitez une méthode approuvée, la redirection du proxy WFP est la seule façon d'aller.
C'était très utile pour moi et pour les futurs lecteurs, merci.
Dans les tests initiaux, nous avons essayé d'injecter une DLL située dans le même dossier, notre test était situé et découvert que, si la DLL était dans System32, elle se charge bien.
oui, car System32 est dans la commande de recherche pour les applications Metro (Windows Store). Il n'y a pas de magie à elle.
De même, le dossier de votre test n'était probablement pas dans la commande de recherche DLL pour l'application (System32, le graphique de dépendance du package de l'application, etc.), ainsi que le chargeur ne trouverait pas votre DLL pour l'application.
Vous pouvez modifier le chemin de recherche avec ldrloaddll mais cela n'a aucun effet.
Je ne sais pas ce que lDrloaddll est. À partir d'une recherche nette rapide, il semble s'agir d'un détail de mise en œuvre non documenté dans Windows. Je ne suis pas surpris que ça ne vous fait pas bon. Le chargeur était changé pour prendre en charge des applications de métro (Windows Store), de sorte que les chemins de code et les permutations diffèrent de manière significative.
LDrloaddll est l'API qui effectue tous les travaux de chargement (LoadLibrary agit comme un wrapper). La Déclaration de l'API ne change pas d'une longue période, bien que en interne prend désormais en charge les applications métropolitaines. Et certaines vérifications sont effectuées en mode noyau pour éviter des hacks.
Je réponds par la présente parce que tout le monde est hors de point avec cela. Le fichier DLL doit avoir une autorisation en lecture / exécution à "Tous les packages d'applications" . Avec cela, le chargeur vous permettra de charger des DLL arbitraires dans des applications immersives (= applications de métro).
Je pense que cela est déjà répondu par @MAURO, mettant la DLL dans le dossier System32 équivaut à avoir les autorisations de R & X.
R & X Permission à "Tous les forfaits d'application", exactement
Notez que pour certaines applications, des autorisations de R & X sont également nécessaires pour "tous les packages d'applications restreints" (S-1-15-2-2)
Êtes-vous sûr que le premier lien n'est pas destiné à être interprété comme suit: «Vous pouvez faire une injection DLL, mais vous ne pouvez pas le faire pour rediriger le trafic»?
Chaque fois que quelqu'un dit quelque chose "n'est pas possible" ce qu'ils veulent vraiment dire, c'est quelque chose comme "n'est pas censé être possible" ou même "je ne sais pas le moyen de le faire". Nektra a trouvé un moyen: mettez la DLL dans System32.
@Sebastian: Je vais vous demander directement: lorsque je mettrai ma DLL dans le système32 et faire un crochet à une application de métro, puis-je obtenir un contrôle total au processus accroché (par exemple: rediriger Winsock Traffic, refuser l'appel à un " Dangereux "API?). S'il vous plaît faites-nous une bonne réponse dont nous avons besoin de vraiment une sorte d'information.
Si vous injectez une DLL dans un processus de cygwin, vous effectuerez la liste Bloda. Ne pas injecter des dlls dans le processus qui ne sont pas les vôtres et vous n'avez pas étudié pour des effets secondaires.
@Smartytwiti Mauro, l'auteur de l'article, répondra bientôt.