Tenía curiosidad sobre cómo encontrar una API incobrables en Windows.Encontrar API indocumentadas en Windows
Conozco los riesgos que conlleva usarlos, pero esta pregunta se centra en encontrarlos y no en utilizarlos o no.
Utilice una herramienta para volcar la tabla de exportación a partir de una biblioteca compartida (por ejemplo, un archivo .dll como kernel32.dll). Verá los puntos de entrada nombrados y/o los puntos de entrada ordinales. En general, para ventanas, los puntos de entrada nombrados están desactivados (extern "C"). Lo más probable es que necesite echar un vistazo al código de ensamblado y derivar los parámetros (tipos, números, orden, convención de llamadas, etc.) del marco de pila (si hay uno) y registrar el uso. Si no hay un marco de pila, es un poco más difícil, pero aún así factible. Consulte los siguientes enlaces para las referencias:
Echa un vistazo a herramientas como dumpbin para la investigación de las secciones de exportación.
También hay sitios y libros por ahí que tratan de mantener una lista actualizada de las API de Windows indocumentados:
Editar: Estos mismos principios funcionan en una multitud de sistemas operativos, sin embargo, deberá reemplazar la herramienta que está utilizando para volcar la tabla de exportación. Por ejemplo, en Linux puede usar nm para volcar un archivo de objeto y listar su sección de exportaciones (entre otras cosas). También puede usar gdb para establecer puntos de interrupción y recorrer el código de ensamblaje de un punto de entrada para determinar cuáles deberían ser los argumentos.
Observe los archivos DLL del sistema y las funciones que exportan. Cada función API, documentada o no, se exporta en uno de ellos (usuario, kernel, ...).
Para las API de modo de usuario, puede abrir Kernel32.dll User32.dll Gdi32.dll, especialmente ntdll.dll en dependancy walker y encontrar todas las API exportadas. Pero no tendrás la documentación por supuesto.
acaba de encontrar un buen artículo sobre Native APIS por Mark Russinovich
IDA Pro es su mejor apuesta aquí, pero por favor doble por favor en realidad no los use para nada.
Son internos porque cambian; ellos pueden (y lo hacen) incluso cambiar como resultado de un Hotfix, por lo que ni siquiera está garantizado que su API no documentada funcionará para la versión del SO específico y el nivel del Service Pack para el que lo escribió. Si envía un producto como ese, está viviendo en un tiempo prestado.
Y luego, si eres alguien con influencia, Microsoft tiene que mantenerlos para siempre, porque si no lo hacen, el software de Crap Inc se romperá y el usuario equivocado gritará sobre cómo Microsoft apesta y Apple está genial. – Josh
Ni siquiera tiene que ser tan influyente: abre la base de datos de la aplicación AppCompat un día, tenemos aplicaciones como Disney Timon y Puumba. Aprende a escribir allí –
Sí. Uso el SetConsoleFont sin documentar correctamente en Windows XP y Windows 7, pero falla en Windows 7 sp1. – carlos
Todos aquí hasta ahora carecen de algunas funcionalidades sustanciales que comprenden porciones enormemente no documentadas del sistema operativo Windows RPC. Las operaciones RPC (think rpcrt4.dll, lsass.exe, csrss.exe, etc ...) ocurren con mucha frecuencia en todos los subsistemas, a través de puertos LPC u otras interfaces, su funcionalidad está enterrada en los encantamientos de misticismo de varios tipos/subtipos/struct-typedef, etc., que son sustancialmente más difíciles de depurar, debido a la naturaleza asíncrona o al hecho de que están destinados a procesos, que si depurara mediante pasos individuales o lo que tiene, encontraría todo el sistema bloqueo debido al bloqueo del teclado u otras E/S que se pasan;)
ReactOS es probablemente la forma más conveniente de investigar la API no documentada. Tienen un núcleo bastante maduro y otros ejecutivos construidos. La IDA requiere bastante tiempo y es poco probable que encuentre algo que la gente de ReactOS aún no tenga.
Aquí hay una propaganda de la página vinculada;
ReactOS® es un moderno sistema libre, operativo basado en el diseño de Windows® XP/2003. Escrito completamente desde scratch, pretende seguir la arquitectura de Windows® diseñada por Microsoft desde el nivel de hardware hasta el nivel de aplicación . Este no es un sistema basado en Linux , y no comparte ninguna arquitectura Unix .
El objetivo principal del proyecto ReactOS es proporcionar un sistema operativo que es binaria compatible con Windows. Esto permitirá que sus aplicaciones de Windows y controladores se ejecuten como lo harían en su sistema de Windows . Además, se usa el aspecto y la sensación del sistema operativo Windows , de modo que las personas acostumbradas a la interfaz de usuario familiar de Windows® encontrarían que usar ReactOS es sencillo. El objetivo final de de ReactOS es permitirle eliminar Windows® e instalar ReactOS sin que el usuario final note el cambio .
Cuando estoy investigando una construcción de Windows rara vez vista, ReactOS suele ser la única referencia creíble.
Ah, si intentas realizar ingeniería inversa manual del sistema operativo, deberías investigar la utilidad de IDL y cómo ubicar IDL incrustado en DLL, extraer la ubicación de los métodos de implementación. Además, consulte http://en.wikipedia.org/wiki/MSRPC para obtener algunos puntos de partida más decentes. – RandomNickName42
-1 mala pregunta: es * nunca * una buena idea usar API no documentadas; no están documentados por alguna razón, y los riesgos no son para usted, sino para su proveedor de sistema operativo (si se preocupan por la compatibilidad de la aplicación). –
+1 no es una mala pregunta. No hay nada de malo en hurgar en las partes internas de su SO o cualquier otra cosa. La curiosidad es algo bueno. Simplemente no confíes en el comportamiento indocumentado. –