En la parte 1 identificamos la función Dispatcher del controlador, así como dos funciones que inicializaban algunas variables para el controlador ( fn_InitDispatchMethodArray y fn_ObtainKernelFunctions ). Vamos a revertir cada uno de ellos y analizar rápidamente qué están haciendo. Esto nos ayudará a comprender las funciones de Dispatcher implementadas en este controlador.
¿Por lo que pasaremos?
- Algunos mecanismos básicos de inicialización de este controlador
- Identifique lo que parece ser una estructura personalizada utilizada para indexar y almacenar todos los métodos disponibles.
- Identifique cómo se ubican las direcciones de función en la memoria. Por ejemplo,
Porfavor, Acceder o Registrarse to view URLs content!. Vamos a hablar de esto en las siguientes publicaciones.
El código original para esta función se puede encontrar aquí:
Porfavor,
Acceder
o
Registrarse
to view URLs content!
y
Porfavor,
Acceder
o
Registrarse
to view URLs content!
. Y el resultado final
Porfavor,
Acceder
o
Registrarse
to view URLs content!
(trata de no consentirte aún).Vamos a ver ahora en esta función que se está inicializando una especie de estructura personalizada:
C++:
Porfavor,
Acceder
o
Registrarse para ver el contenido de los códigos!
Podemos resolver esto, porque si prestamos atención al ensamblaje, veremos que primero asignan un valor int a una dirección de memoria en particular, y luego mueven 8 bytes más para escribir un puntero a una función dentro del binario. . Llamaremos a esta estructura IOCTLFunctionArray. ¿Una matriz? solo sigue leyendo =) Esta matriz desempeñará un papel importante al enviar una solicitud.
La estructura sería algo como esto:
C++:
Porfavor,
Acceder
o
Registrarse para ver el contenido de los códigos!
Y en IDA Pro:
C++:
Porfavor,
Acceder
o
Registrarse para ver el contenido de los códigos!
Este proceso se repite varias veces en esta función, 25 veces exactamente. Es por eso que lo llamamos matriz , se almacenan 25 veces la misma estructura (con diferentes valores, por supuesto) dentro de una matriz.
El valor 25 también se está almacenando en una variable que decidí renombrar de dword_14000A240 a FunctionsCount :
C++:
Porfavor,
Acceder
o
Registrarse para ver el contenido de los códigos!
Más adelante veremos cómo se usa esta variable en el Dispatcher, pero podemos intentar adivinarla. En función de esta función, podemos deducir que el controlador tiene una lista de todos los métodos disponibles que se pueden invocar, y si se proporciona algún tipo de valor de índice, podría ser posible invocarlos.
El resultado final sería algo como
Porfavor,
Acceder
o
Registrarse
to view URLs content!
. Tenga en cuenta que algunas funciones han cambiado de nombre desde que comencé a invertirlas antes. Veremos algunos interesantes en las siguientes publicaciones.fn_ObtainKernelFunctions (0x140002A18)
La siguiente función es simple. Para continuar con la inicialización, el controlador necesita la dirección de algunas rutinas particulares:
Al hacer esto, pueden asegurarse de que esas funciones estén disponibles en la versión en ejecución de Windows y obtener un puntero a ellas. Solo necesitan almacenarlos en una variable y luego usarlos para llamar a cualquiera de esas rutinas convirtiéndolas en la definición de función adecuada. Puede detectar esto fácilmente también en la función de ensamblaje:
C++:
Porfavor,
Acceder
o
Registrarse para ver el contenido de los códigos!
No hay mucha diferencia entre el código original y el resultado final. El código era algo obvio para esta función.
Próximos pasos
- Analizar la función de envío (fn_DriverIOCTLDispatcher)
- Análisis del registro de notificaciones y rutinas de devolución de llamada (fn_InitRegistrationNotifyAndCallbackRoutines y fn_RegisterCreateProcessNotifyRoutine)
Niemand
Enlace original
Porfavor,
Acceder
o
Registrarse
to view URLs content!
Porfavor,
Acceder
o
Registrarse
to view URLs content!