J'étais curieux de savoir comment faire pour trouver des API non documentées dans Windows.
Je connais les risques liés à leur utilisation, mais cette question vise à les trouver et non à savoir s'il faut les utiliser ou non.
Utilisez un outil pour vider la table d'exportation d'une bibliothèque partagée (par exemple, une .dll telle 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 Windows, les points d'entrée nommés sont démêlés (extern "C"). Vous devrez probablement jeter un coup d'œil au code d'assemblage et déduire les paramètres (types, nombre, ordre, convention d'appel, etc.) à partir du cadre de pile (s'il y en a un) et de l'utilisation des registres. S'il n'y a pas de cadre de pile, c'est un peu plus difficile, mais toujours faisable. Voir les liens suivants pour les références :
Consultez des outils tels que dumpbin pour enquêter sur les sections d'exportation.
Il existe également des sites et des livres qui tentent de tenir à jour une liste 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 vider un fichier objet et lister sa section exports (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 afin de déterminer quels doivent être les arguments.
IDA Pro est votre meilleur choix ici, mais s'il vous plaît, doublez s'il vous plaît ne les utilisent jamais pour quoi que ce soit.
Ils sont internes parce qu'ils changent ; ils peuvent (et changent) même à la suite d'un correctif, de sorte que vous n'avez même pas la garantie que votre API non documentée fonctionnera pour la version d'OS spécifique et le niveau de Service Pack pour lesquels vous l'avez écrite. Si vous expédiez un produit de ce type, vous vivez sur du temps emprunté.
Et puis, si vous êtes quelqu'un d'influent, Microsoft doit les maintenir pour toujours parce que sinon, le logiciel de Crap Inc. tombera en panne et l'utilisateur malavisé criera que Microsoft est nul et qu'Apple est génial.
Vous n'avez même pas besoin d'être aussi influent - ouvrez la base de données de shim AppCompat un jour, nous avons des applications comme Disney Timon & Puumba Learn to Type dedans.
Tout le monde ici jusqu'à présent manque une fonctionnalité substantielle qui comprend des parties non documentées du système d'exploitation Windows. RPC . Les opérations RPC (pensez à rpcrt4.dll, lsass.exe, csrss.exe, etc...) sont très fréquentes dans tous les sous-systèmes, via des ports LPC ou d'autres interfaces, leur fonctionnalité est enfouie dans les incantations mystiques de divers types/sous-types/structures-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 par le biais du single stepping ou autre, vous trouveriez le système entier verrouillé en raison du blocage du clavier ou d'autres entrées/sorties ;)
ReactOS est probablement le moyen le plus rapide d'étudier les API non documentées. Ils ont un noyau assez mature et d'autres cadres construits. IDA demande beaucoup de temps et il est peu probable que vous trouviez quelque chose que les gens de ReactOS n'ont pas déjà trouvé.
Voici un résumé de la page liée ;
ReactOS® est un système d'exploitation libre et moderne. moderne et gratuit basé sur le design de Windows XP/2003. Entièrement écrit à partir de scratch, il vise à suivre l'architecture l'architecture Windows® conçue par Microsoft, du niveau matériel jusqu'au niveau des applications d'application. Il ne s'agit pas d'un et ne partage aucunement l'architecture l'architecture Unix.
L'objectif principal de l projet ReactOS est de fournir un système d'exploitation qui est binairement compatible avec Windows. Cela permettra vos applications et pilotes Windows pilotes Windows de fonctionner comme ils le feraient sur votre système Windows. De plus, l'apparence et la l'aspect et la convivialité du système d'exploitation Windows, de sorte que les personnes habituées à l'interface utilisateur familière de familière de Windows® trouveront l'utilisation de ReactOS est simple à utiliser. L'objectif ultime de objectif de ReactOS est de vous permettre de de supprimer Windows® et d'installer ReactOS sans que l'utilisateur final ne remarque le changement.
Lorsque j'étudie une construction Windows rarement vue, ReactOS est souvent la seule référence crédible.
Oh, donc si vous essayez de faire de la rétro-ingénierie manuelle du système d'exploitation, vous devriez étudier l'utilité de l'IDL et la façon de localiser les IDL intégrés dans les DLL, et extraire l'emplacement des méthodes de mise en œuvre. Consultez également fr.wikipedia.org/wiki/MSRPC pour des points de départ plus décents.
Pour les API en mode utilisateur, vous pouvez ouvrir Kernel32.dll User32.dll Gdi32.dll, et surtout ntdll.dll en marcheur dépendant et trouver toutes les APIs exportées. Mais vous n'aurez pas la documentation, bien sûr.
Je viens de trouver un bon article sur APIS natif par Mark Russinovich
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
-1 mauvaise question : c'est jamais C'est une bonne idée d'utiliser des API non documentées ; elles le sont pour une raison, et les risques ne sont pas pour vous mais plutôt pour le fournisseur de votre système d'exploitation (s'il se soucie de la compatibilité des applications).
50 votes
+1 pas une mauvaise question. Il n'y a rien de mal à fouiller dans les entrailles de votre système d'exploitation ou de tout autre système. La curiosité est une bonne chose. Mais ne vous fiez pas à un comportement non documenté.