14 replies to this topic

[c0lo]

Bueno hola a todos y yo nuevamente con mis ocurrencias... ocurre que no tengo ni idea de como titular esta pregunta asi que por eso el Title que le puse..

Ocurre que tengo un problemilla o mejor dicho un latoso problema o mmm un enemigo entre mis cosas o algun chiste por ahi..

La cosa en resumen:

Tengo un Programa X que corre y espera que este corriendo mi Programa Y, cuando corre el Programa Y, el Programa X, inyecta una dll al Programa Y, la cual la dll inyectada tiene un par de funciones o alteraciones en el Programa Y, dependiendo de las teclas que son ejecutadas.

Bueno primero decide encontrar la dll que es inyectada lo cual fue rapido y facil... pero al querer analizar la dll con un Debugger (OllyDbg) ocurre que la dll esta protegida, empaquetada o virtualizada con VMProtect. Bueno asi que todo mi alegria de analizarla y ver con el OllyDbg fue hechada.

Asi que pensando un poco en saber que modificaba y de ahi poder saber porque lo hacia, pense en hacer un programa similar a mi Programa Y (similar en espacio de memoria cuando el Programa Y esta corriendo), y que dicho Nuevo Programa Y, me detecte algun cambio en su memoria es decir que si algun programa modifica al Programa Y, en una direccion de su memoria que me lo indique... nose...

delphi

Address: 0x988547
HexValue: F4 F4 F8 44 00 11 00 55 00 55 66

Algo similar que me indique donde se modifico y que se modifico.

Gracias y espero que alguien entienda lo que quise decir y ayudarme.

[escafandra]

Entiendo lo que quieres, pero tu pregunta es demasiado general.

Se puede crear un código que se inyecte en un programa y haga una copia de la memoria del proceso en un archivo, por ejemplo, pero con eso poco podremos hacer si no sabemos lo que buscamos.

Con códigos similares puedes investigar si alguna API fué Hookeada, o Hookearlas tu mismo. Pero tienes que saber que es lo que buscas.

Puedes experimentar inyectando esa dll sobre un programa escrito por tí, cuyo comportamiento conoces y ver los cambios que pueda realizar en el mismo.

En definitiva, una dll puede realizar tantas cosas en un programa que descifrarla sin un debugger  es mas complejo que desensamblar un programa entero. Debes partir de algo concreto para planear una estrategia adecuada.

Saludos.

[c0lo]

En general es hacer un programa que detecte una modificacion hecha en memoria, si algun programa no necesariamente el que se sospecha modifico algo si no otro programa. Y nuestro Programa que hicimos siempre este detectando algun cambio en memoria de si mismo.

PD: Como hago aquello que me mencionas escafandra..? es decir, hacer un dll o un programa que copie toda la memoria en un archivo, porque pensando un poco se podria hacer que dicho programa copia una primera ves y luego cuando yo probando modifico la memoria hago una nueva copia, pero con la modificacion hecha y luego usando el ojo humano detecte algun cambio ... es una idea..

[escafandra]

Como hago aquello que me mencionas escafandra..? es decir, hacer un dll o un programa que copie toda la memoria en un archivo, porque pensando un poco se podria hacer que dicho programa copia una primera ves y luego cuando yo probando modifico la memoria hago una nueva copia, pero con la modificacion hecha y luego usando el ojo humano detecte algun cambio ...

Hacer la copia no es difícil, pero piensa que cuando Windows inicia un proceso, le asigna, toda, y digo, toda la memoria al mismo. Cada proceso tiene asignada toda la memoria disponible. ¿Como puede ser? pues por el sistema de paginado virtual.

Un proceso, no es sólo el código del programa, sino las dll que carga, datos, memoria localizada para trabajar... de forma que ¿como analizarás con el ojo humano todos esos GB de información?

Por eso te decía que debes tener una estrategia de lo que quieres buscar y encontrar.

Saludos.

[c0lo]

Mi idea inicial era ella que la memoria asignada a un proceso sea detectada es decir toda su memoria..., pero ahora que mencionas que Windows Asigna toda la memoria disponible dependiendo el programa como que me saca que quisio o de idea de como atacar.

Haber haber... digamos que tengo un Programa que de automaticamente puros "Ctrl", ojo es un ejemplo, ahora tengamos un tipo virus o algo programa externo que haga algo inyecte una dll o el mismo que modifique el cambio de mi Programa por Ctrl  a Enter, es decir, que haya modificado un valor dentro de la memoria del programa asignado para la tecla Ctrl y lo cambia a la tecla enter, Ahora lo que yo hago o segun yo quiero hacer es ver ese cambio de memoria es decir ese cambio en mi Programa ... que me diga algo asi como un antivirus que se detecte un cambio en Programa:

Se detecto un Cambio en Direccion Tal y el valor modificado fue tal.

Nose si ya captan mi idea...

En si es hacer un tipo Debugger diria yo pero que se vea la memoria del programa continuamente y detectando el cambio y me indique donde se cambio y cual fue el cambio.

[escafandra]

En si es hacer un tipo Debugger diria yo pero que se vea la memoria del programa continuamente y detectando el cambio y me indique donde se cambio y cual fue el cambio.

Te entiendo, pero esos cambios van a ser tan numerosos como accesos, lícitos o ilícitos, tenga ese proceso a la RAM. Un debugger va paso a paso, interrumpiendo el proceso a cada instrucción asm, pero lo que tu pretendes es global y sin detener la aplicación, ya que no sabes cuando ni como esa dll va a actuar y para colmo está protegida... Por eso tienes que concretar la búsqueda a una API que pienses que hookea por ejemplo. Una inyección de dll no tiene porqué hookear una API, puede actuar en otros niveles... O buscar patrones de memoria específicos, cambios de cadenas... Del comportamiento del programa afectado por la dll en estudio, podrás intuir aspectos de cómo trabaja.

En fin este proyecto no puede considerarse como de propósito general sino muy particular a lo que vallas encontrando y debes ir fabricando las herramientas a medida que vallas avanzando en el conocimiento de esa dll.

Saludos.

[c0lo]

Haber empecemos entonces segun mi entendimiento por partes... Digamos que tengo un rango de memoria o de direccion

que lea o analice del 0x40000 -> 0x80000 digamos este ejemplo asi proponiendo esto ahi si se podria hacer?

[escafandra]

...que lea o analice del 0x40000 -> 0x80000 digamos este ejemplo así proponiendo esto ahi si se podria hacer?

Claro que se puede hacer, pero piensa que ese  rango es muy amplio para un análisis visual "a mano".  Por otro lado está la pregunta ¿Cuando actualizamos la lectura de los cambios en memoria? ¿Y si nos perdemos alguno? ¿Sólo queremos ver cambios en la sección de código o queremos ver mas allá?

Para analizar, por ejemplo Hooks, existen utilidades que se pueden descargas de la red. Con ellas podemos saber que APIs tenemos Hookeadas y encontrar un punto de partida. Por ejemplo VICE es una herramienta antirootkit que busca eso precisamente. Pero no todo se resume a los Hooks en las APIs. También tenemos los propios del S.O. SetWindowsHookEx que pueden interceptar el teclado o mensajes... Pero como ya te anuncié, sin Hooks también se puede actuar en el programa...

Quizás lo razonable es que empieces por analizar posibles Hooks, si existen, piensa que programas como VICE te sacará muchos que no tendrán que ver con lo que buscas. Muchos programas y AV los usan. Debes interpretar los que te interesen. Ver que APIs se afectan... Si tienes interceptada alguna API, una buena idea puede ser que tu mismo le hagas un Hook para usmear lo que está pasando...

En definitiva, me parece mas eficaz e inteligente investigar de esta manera que tratar por fuerza bruta leer enormes bloques de memoria con los que será difícil trabajar.

[c0lo]

En si analizando el programa y verificando con un Rootkit no existe ningun hook aplicadado, es decir, no estamos hablando de hook en si solo de cambios en memoria o direccion que queremos notar.

Si no existe hook que se hace entonces para ver la memoria que cambie o algo asi como un detector de movimiento en nuestro programa. 

[escafandra]

Bueno, no tenemos hooks. Entonces habrá que pensar, entre otras cosas, que esa dll envía mensajes Windows (WM_)al programa. Dependiendo del comportamiento alterado podemos intuir que WM_ manda. ¿Esa dll misteriosa es específica para el programa en cuestión o se puede usar con otros? Si no es específica, posiblemente utilice WM_. También puede buscar determinados patrones de memoria para alterarlos...

Los WM_ pueden ser estudiados con winsight, viene con delphi y Builder. Los cambios en patrones son mas difíciles de estudiar, sin saber de antemano donde están las dianas.

Se me ocurre realizar un Hook a las APIs que contolan los permisos de acceso a la memoria virtual, VirtualProtectEx y VirtualQuery. Esas API nos pueden poner en la pista de que algo pasa en la memoria. Normalmente un proceso no necesita cambiar las protecciones de memoria para un trabajo normal. Si lo hace, es probable que sea bajo petición de un código inyectado. Además, esas API trabajan con un bloque de memoria y tamaño conocido con lo que tenemos una pista de que zona de memoria va a ser modificada y establecer, así, unos rangos. Para ampliar podemos hacer otro Hook a WriteProcessMemory y ReadProcessMemory, para ver los cambio producidos. Si bien, la dll puede no necesitar de estas dos últimas APIs para modificar la memoria del proceso, pues al estar inyectada, ya pertenece a proceso. Podemos seguir con esta lógica y Hookear otras APIs que trabajen con la memoria y volcar los bufferes siempre que estén dentro de los rangos que hallamos establecido.

En fin, la estrategia debe ser dinámica de acuerdo con la necesidad del momento. Dado que el tema es trabajoso, se debe valorar la necesidad del esfuerzo con el fin perseguido. En este concepto se basan los sistemas de protección.  :^)

Saludos.

[c0lo]

bueno creo que tengo o ya vi mi error a la hora de explicarme creo yo... en el ejemplo que di creo que no fue el correcto...

Haber nose si podre explicar lo que quiero en si hacer.. Tenemos un Programa X que nosotros por medio de otro Programa Y (dll, exe, etc etc) manipulamos la memoria del Programa X.

Ejemplo:
Pinball -> Programa X
MemEditor -> Programa Y

Entonces lo que hace el Progrmaa Y es modificar la memoria interna del Programa X de tal forma que cuando lo usemos asha habiado cambiso dentro del Programa X. En si cambios usando WPM, ejemplo no es necesariamente ya que se podria trabajar con una dll en la misma memoria y a traves de punteros modificar algun valor dentro del Programa X ..

Bueno ahora yo quiero proteger a mi Progrmaa X, detectando algun cambio dentro de el...

Ahora quiero crear un nuevo Programa X que me detecte o crear otro Programa Z que detecte los cambiso en memoria del Programa X.

[escafandra]

En ese caso, el planteamiento de vigilancia de las APIs de gestión de memoria, mostrado en mi anterior mensaje, sigue siendo válido.

No creo que exista ningún sistema infalible de protección a nivel de cambios en la memoria del proceso. Si bien se podría detectar cambios en la sección de código del programa (revisa el formato de archivo PE), bien por comparación o por vigilancia de las zonas ejecutables, los cambios pueden darse en otras secciones o en memoria de trabajo localizada. Algunos sistemas AV, tratan de vigilar la API CreateRemoteThread, para tratar de controlar las inyecciones, ya que esta vía es casi la mas utilizada. Sin embargo no son infalibles. Los sistemas de protección heurísticos, tampoco son infalibles dando falsos positivos y negativos.

Sin un conocimiento del ataque de ese código inyectado, es difícil una protección total. Sigo viendo razonable, para este propósito, el AutoHooK de las APIs de gestión de memoria para abortar los intentos de cambios de permisos. Pero esto no funcionará si los cambios se hacen desde otro proceso, para lo que se podría establecer un sistema de restauración de permisos periódico, que no sería infalible y consumiría bastantes recursos del programa. La posibilidad de vigilancia desde el Kernel, también se puede plantear, pero eso ya son palabras mayores.

Saludos.

[escafandra]

Tratando de simplificar el tema, y pensando de que te tratas de proteger de esa dll "maléfica", y asumiendo que la conoces, así como su nombre, me pregunto si no será mejor simplemente descargarla de tu proceso. Si tu proceso lo has escrito tu, es fácil con FreeLibrary. En caso contrario, puedes utilizar el ejemplo que puse en este hilo: Inyección directa de código en C y en delphi. Dicho ejemplo realiza una inyección sin dll en un proceso y le obliga a ejecutar FreeLibrary.

Saludos.

[c0lo]

No ya creo que se por donde te vas escafandra, mi problema no es la dll en si, lo que deseo es analizar la dll o saber que cambia en mi Programa que direccion en la memoria modifica y de ahi poco a poco poder reconstruir esos cambios.

[escafandra]

No ya creo que se por donde te vas escafandra, mi problema no es la dll en si, lo que deseo es analizar la dll o saber que cambia en mi Programa que direccion en la memoria modifica y de ahi poco a poco poder reconstruir esos cambios.

Con lo que volvemos al tema de la ingeniería inversa.

Bueno. Si tu ves tan simple el problema de los cambios que esa dll produce en el código de tu programa, y controlas cuando se inyecta, el procedimiento sería este:


1- Creas una dll espía. Esa dll va a hacer una copia de la memoria del ejecutable en un archivo de disco.
2- Creas un programa controlador de tu dll espia que hará lo siguiente:
  a- Inyecta tu dll espia en el programa afecto.
  b- Manda realizar una copia de memoria.
  c- Provocas la inyección de tu dll "misteriosa"
  d- Vuelves a realizar una copia de la memoria de tu programa en otro archivo con tu dll espía.

Ahora debes entrar en el diseño de tu dll espía:

Si crees que sólo te interesa la región de memoria ejecutable, entonces puedes tratar de localizar ese rango desde el PE:

cpp

PIMAGE_OPTIONAL_HEADER pIOH = PIMAGE_OPTIONAL_HEADER((BYTE*)hModule + *(DWORD*)((BYTE*)hModule + 0x3C) + 0x18);
void* ImageBase = (void*)(pIOH->ImageBase); // normalmente el valor será 0x00400000 pero puede ser otro.
DWORD SizeOfImage = pIOH->SizeOfImage;  // Tamaño

Los datos de ImageBase  y SizeOfImage serán los que usarás para copiar los bloques de memoria pues es la región que vamos a limitar.

El siguiente paso es construir las funciones de espionaje de la dll. Define sus funciones pensando que está en el espacio de memoria anfitrión. Luego debes diseñar un interface para otro programa controlador. Este programa se encargará de ordenar a la dll espía que copie la región de memoria descrita. Luego inyectará la dll misteriosa y después ordenará a la dll espía que realice un segundo volcado de memoria.

¿Como mandas las órdenes a la dll espía?. Pues la respuesta la encontrarás aquí.

Espero que esto te sirva de orientación.

Saludos.