J’étais curieux de savoir comment procéder pour trouver des API non documentées dans Windows.
Je connais les risques liés à leur utilisation mais cette question est axée sur leur recherche et non sur leur utilisation ou non.
Utilisez un outil pour vider la table d’exportation d’une bibliothèque partagée (par exemple, un fichier .dll tel que kernel32.dll). Vous verrez les points d’entrée nommés et / ou les points d’entrée ordinaux. En général, pour les fenêtres, les points d’entrée nommés ne sont pas définis (extern “C”). Vous devrez probablement jeter un coup d’oeil au code de l’assemblage et en déduire les parameters (types, nombre, ordre, convention d’appel, etc.) à partir du cadre de la stack (le cas échéant) et enregistrer l’utilisation. S’il n’y a pas de cadre de stack, c’est un peu plus difficile, mais toujours réalisable. Voir les liens suivants pour les références:
Découvrez des outils tels que dumpbin pour rechercher des sections d’exportation.
Il existe également des sites et des livres qui essaient de garder une liste à jour des API Windows non documentées:
Edit: Ces mêmes principes fonctionnent sur une multitude de systèmes d’exploitation. Cependant, vous devrez remplacer l’outil que vous utilisez pour vider la table d’exportation. Par exemple, sous Linux, vous pouvez utiliser nm pour sauvegarder un fichier object et répertorier sa section d’exportations (entre autres choses). Vous pouvez également utiliser gdb pour définir des points d’arrêt et parcourir le code d’assemblage d’un point d’entrée pour déterminer les arguments à utiliser.
IDA Pro est votre meilleur pari ici, mais s’il vous plaît, veuillez s’il vous plait ne pas les utiliser pour rien.
Ils sont internes parce qu’ils changent; ils peuvent (et font) même changer à la suite d’un correctif, de sorte que vous n’êtes même pas assuré que votre API non documentée fonctionnera pour la version spécifique du système d’exploitation et le niveau de Service Pack pour lequel vous l’avez écrite. Si vous expédiez un produit comme celui-là, vous vivez avec un temps d’emprunt.
Tout le monde ici manque certaines fonctionnalités substantielles qui comprennent des parties très peu documentées du RPC du système d’exploitation Windows. Les opérations RPC (pensez à rpcrt4.dll, lsass.exe, csrss.exe, etc …) sont très fréquentes sur tous les sous-systèmes, via les ports LPC ou autres interfaces, leur fonctionnalité est enterrée dans les incantations mystiques de différents types / sous-types. / struct-typedef’s etc … qui sont nettement plus difficiles à déboguer, en raison de leur nature asynchrone ou du fait qu’elles sont destinées à des processus qui, si vous deviez déboguer en mode simple ou pas, vous trouveriez le système entier blocage dû au blocage du clavier ou d’autres entrées / sorties;)
ReactOS est probablement le moyen le plus efficace d’étudier les API non documentées. Ils ont un kernel assez mature et d’autres frameworks ont été créés. IDA demande beaucoup de temps et il est peu probable que vous trouviez quelque chose que les personnes de ReactOS n’aient pas déjà.
Voici un texte de présentation de la page liée;
ReactOS® est un système d’exploitation gratuit et moderne basé sur la conception de Windows® XP / 2003. Rédigé complètement à partir de zéro, il a pour objective de suivre l’architecture Windows® conçue par Microsoft du niveau matériel jusqu’au niveau de l’application. Ce n’est pas un système basé sur Linux et ne partage aucune de l’architecture Unix.
L’objective principal du projet ReactOS est de fournir un système d’exploitation compatible avec Windows. Cela permettra à vos applications et pilotes Windows de fonctionner comme sur votre système Windows. En outre, l’apparence du système d’exploitation Windows est utilisée, de sorte que les personnes habituées à l’interface utilisateur familière de Windows® trouveraient l’utilisation directe de ReactOS. Le but ultime de ReactOS est de vous permettre de supprimer Windows® et d’installer ReactOS sans que l’utilisateur final ne le remarque.
Quand j’étudie une construction Windows rarement vue, ReactOS est souvent la seule référence crédible.
Regardez les DLL du système et les fonctions qu’elles exportent. Chaque fonction de l’API, qu’elle soit documentée ou non, est exscope dans l’une d’entre elles (utilisateur, kernel, …).
Pour les API en mode utilisateur, vous pouvez ouvrir Kernel32.dll User32.dll Gdi32.dll, spécialement ntdll.dll dans walker de dépendance et rechercher toutes les API exscopes. Mais vous n’aurez pas de documentation.
Je viens de trouver un bon article sur l’ APIS natif par Mark Russinovich