Técnicas de espionaje/secuestro de API de Windows

Question

Estoy interesado en utilizar el espionaje/secuestro API para implementar algunas características principales de un proyecto en el que estoy trabajando. También se ha mencionado in this question, pero eso no estaba realmente en el tema así que pensé que sería mejor con una pregunta propia para esto.

Me gustaría recopilar la mayor cantidad de información posible sobre este tema , diferentes técnicas/bibliotecas (MS Detours, IAT patching) u otras sugerencias.

Además, sería especialmente interesante saber si alguien tiene experiencia en la producción real del uso de tales técnicas: ¿pueden ser lo suficientemente estables para el código de producción o es estrictamente una técnica de investigación? ¿Funciona correctamente en múltiples versiones de Windows? ¿Cómo es propenso a errores?

Experiencias personales y enlaces externos ambos apreciados.

Answer 1

he implementado syringe.dll (L-GPL) en lugar de MS desvíos (que no nos gustó los requisitos de la licencia o gran pago por el apoyo x64) funciona fantásticamente bien, me portado desde Win32 para Win64, hemos utilizado en nuestro aplicaciones comerciales autónomas desde hace aproximadamente 2 años.

Lo usamos por razones muy simples realmente es proporcionar un trabajo de marco de presentación para volver a empaquetar, cambiar la marca de la misma aplicación compilada que muchos productos diferentes, hacemos el filtrado general y la sustitución de cadena, recurso general, barra de herramientas, y menús.

Siendo L-GPL'd suministramos la fuente, derechos de autor, etc., y solo enlazamos dinámicamente a la biblioteca.

Answer 2

Enganche estándar Las funciones de WinAPI son relativamente seguras, ya que no van a cambiar mucho en un futuro cercano, ya que Microsoft lo hace para mantener el WinAPI compatible entre versiones. El enganche estándar de WinAPI, diría yo, generalmente es estable y seguro.

Enganchar cualquier otra cosa, como en las partes internas del programa objetivo, es una historia diferente. Independientemente del programa de destino, el enganche en sí mismo suele ser una práctica sólida. El eslabón más débil del proceso suele encontrar el lugar correcto, y aferrarse a él.

El cambio más pequeño en la aplicación puede cambiar las direcciones de las funciones, sin mencionar las bibliotecas dinámicas, etc.

En gamehacking, donde enganche es una práctica habitual, este ha sido derrotado en algún grado con "sigscanning", una técnica desarrollada por primera LanceVorgin en los tableros algo infame MPC. Funciona escaneando la imagen ejecutable para las partes estáticas de una función, los bytes de instrucción reales que no cambiarán a menos que se modifique la acción de la función . La exploración de Signs es obviamente mejor que usar tablas de direcciones estáticas, pero también fallará eventualmente, cuando la aplicación de destino se cambie lo suficiente.

Ejemplo de implementación de sigscanning en C++ se puede encontrar here.

Answer 3

He estado utilizando técnicas de enganche IAT estándar desde hace unos años y funciona bien ha sido agradable y estable y portado a x64 sin problemas. Los principales problemas que he tenido han tenido que ver más con la forma en que inyecté los anzuelos en primer lugar, me llevó bastante tiempo encontrar la mejor forma de suspender los procesos gestionados en el punto "correcto" de su inicio para que la inyección fue confiable y lo suficientemente temprano para mí.Mi inyector utiliza la API de depuración de Win32 y, si bien esto facilitó la suspensión de procesos no administrados, se requirió un poco de prueba y error para suspender los procesos administrados en el momento adecuado.

Mis usos para IAT han sido en su mayoría de las herramientas de prueba de escritura, tengo un programa de estancamiento de detección que se detalla aquí: http://www.lenholgate.com/blog/2006/04/deadlock-detection-tool-updates.html, un GetTickCount() Programa de control que está disponible para su descarga desde aquí http://www.lenholgate.com/blog/2006/04/tickshifter-v02.html y una aplicación de cambio de tiempo el cual todavía está en desarrollo.

Answer 4

algo que mucha gente olvida es que Windows DLL se compilan como hot-patchable images (MSDN).

caliente de parches es la mejor manera de hacer desvíos WinAPI, como su limpio y sencillo, y preserva la función original, es decir, sin ensamblado en línea tiene que ser utilizado, los punteros de función sólo ligeramente ajustados.

Se puede encontrar un pequeño tutorial de parches en caliente here.