Solución propuesta
En el proceso de instalación podemos ver la ruta en donde el Keylogger es instalado (la carpeta junto con sus respectivos archivos se encuentran ocultos):
Una vez instalado el Keylogger procedemos a registrarlo, para ello hacemos clic derecho en el icono al costado a la derecha y seleccionamos la opción Register:
Hacemos un File Attach. Aquí la duda MCKSys Argentina tuve que hacer el attach a causa de que no puedo correr el Keylogger desde el inicio (protección anti-debugger creo), inclusive luego de atachar el ejecutable si le doy run y presiono el botón para registrar no me muestra el mensaje de Key Invalid! queda corriendo pero no hace nada (a ver si logras encontrar cómo el ejecutable afecta a OllyDbg):
Como comenté anteriormente no es posible a causa de la protección anti-debugger presionar el botón mientras se está ejecutando el Keylogger desde Olly por lo cual una vez atachado ponemos un BP condicional en TranslateMessage con la condición de que se detenga al momento de recibir un mensaje con valor 202:
Una vez presionado el botón para registrar ponemos un BP on Execution en la sección .CODE y veremos lo siguiente:
Luego utilicé Analize This! (Plugins de Olly recomendado hace años por Apuromafo) el cual permite una mejor visualización del código y si bajamos podremos ver el algo muy interesante
):
Podemos ver que la comprobación se realiza en CALL 00404A10 en donde siempre debe retornar 0 para que la validación sea válida. Si ingresamos dentro de la CALL podremos visualizar las referencias que posee:
Ya sabiendo que función es la encargada de realizar la comprobación, cuantas veces es llamada y que valor debe retornar, solo queda parchear. Como solución propuesta decidí cambiar la siguiente instrucción de la CALL 00404A10 (en todas las llamadas):
Ya sabiendo que modificar, reiniciamos y procedemos a realizar los cambios pero nos llevaremos una sorpresa una que nunca me había tocado solucionar
:
Vemos un ejecutable automodificable (estilo packer) por lo cual la única manera de poder parchear el ejectuable es alterar los bytes que serán escritos en las instrucciones siguientes de los llamados a las CALL 00404A10 o dumpear el ejecutable una vez que esté en ejecución el Keylogger, reparar IAT y posteriormente nopear las funciones encargadas de escribir los bytes, vamos por la 1era opción.
Ponemos un Hardware Breakpoint on Write en 0040640B para ver que función es la encargada de escribir esa sección del código:
Como vemos el resultado de la operación XOR EAX,ECX es lo que se almacena en la sección CODE por lo cual si reiniciamos y ponemos un BP en en 0040233B y damos RUN veremos que el valor de ECX es 73h
Si logeamos el valor de ECX en el address 0040233B registrará siempre 73h por lo que el proceso de descifrado se realiza siempre bajo un XOR con la constante 73h.
Teniendo todos estos datos, sabemos que los bytes que son insertados en la sección CODE deben estar almacenados en la sección DATA y cifrados bajo un XOR ?,73h por lo tanto la solución sería encontrar estos datos y reemplazarlos por los bytes (tras realizar un XOR 73h) del mnemónico de instrucción XOR EDX,EDX y XOR EAX,EAX respectivamente.
quedando como solución:
En palabras simples modificamos estos 12 Bytes:
Por:
Nos quedará:
En el proceso de instalación podemos ver la ruta en donde el Keylogger es instalado (la carpeta junto con sus respectivos archivos se encuentran ocultos):
Una vez instalado el Keylogger procedemos a registrarlo, para ello hacemos clic derecho en el icono al costado a la derecha y seleccionamos la opción Register:
Hacemos un File Attach. Aquí la duda MCKSys Argentina tuve que hacer el attach a causa de que no puedo correr el Keylogger desde el inicio (protección anti-debugger creo), inclusive luego de atachar el ejecutable si le doy run y presiono el botón para registrar no me muestra el mensaje de Key Invalid! queda corriendo pero no hace nada (a ver si logras encontrar cómo el ejecutable afecta a OllyDbg):
Como comenté anteriormente no es posible a causa de la protección anti-debugger presionar el botón mientras se está ejecutando el Keylogger desde Olly por lo cual una vez atachado ponemos un BP condicional en TranslateMessage con la condición de que se detenga al momento de recibir un mensaje con valor 202:
Una vez presionado el botón para registrar ponemos un BP on Execution en la sección .CODE y veremos lo siguiente:
Luego utilicé Analize This! (Plugins de Olly recomendado hace años por Apuromafo) el cual permite una mejor visualización del código y si bajamos podremos ver el algo muy interesante
):Podemos ver que la comprobación se realiza en CALL 00404A10 en donde siempre debe retornar 0 para que la validación sea válida. Si ingresamos dentro de la CALL podremos visualizar las referencias que posee:
Ya sabiendo que función es la encargada de realizar la comprobación, cuantas veces es llamada y que valor debe retornar, solo queda parchear. Como solución propuesta decidí cambiar la siguiente instrucción de la CALL 00404A10 (en todas las llamadas):
Citar0040618D . 0FBED0 MOVSX EDX,AL
0040640B . 0FBED0 MOVSX EDX,AL (XOR EDX, EDX)
00406920 . 0FBED0 MOVSX EDX,AL (XOR EDX, EDX)
004069CD . 0FBEC0 MOVSX EAX,AL (XOR EAX,EAX)
Ya sabiendo que modificar, reiniciamos y procedemos a realizar los cambios pero nos llevaremos una sorpresa una que nunca me había tocado solucionar
:Vemos un ejecutable automodificable (estilo packer) por lo cual la única manera de poder parchear el ejectuable es alterar los bytes que serán escritos en las instrucciones siguientes de los llamados a las CALL 00404A10 o dumpear el ejecutable una vez que esté en ejecución el Keylogger, reparar IAT y posteriormente nopear las funciones encargadas de escribir los bytes, vamos por la 1era opción.
Ponemos un Hardware Breakpoint on Write en 0040640B para ver que función es la encargada de escribir esa sección del código:
Como vemos el resultado de la operación XOR EAX,ECX es lo que se almacena en la sección CODE por lo cual si reiniciamos y ponemos un BP en en 0040233B y damos RUN veremos que el valor de ECX es 73h
Si logeamos el valor de ECX en el address 0040233B registrará siempre 73h por lo que el proceso de descifrado se realiza siempre bajo un XOR con la constante 73h.
Teniendo todos estos datos, sabemos que los bytes que son insertados en la sección CODE deben estar almacenados en la sección DATA y cifrados bajo un XOR ?,73h por lo tanto la solución sería encontrar estos datos y reemplazarlos por los bytes (tras realizar un XOR 73h) del mnemónico de instrucción XOR EDX,EDX y XOR EAX,EAX respectivamente.
quedando como solución:
CitarMOVSX EDX,AL XOR 73h
0F BE D0 7C CD A3
XOR EDX,EDX XOR 73h
33 D2 90 40 A1 E3
XOR EAX,EAX XOR 73h
33 C0 90 40 B3 E3
Instrucción XOR EDX,EDX
Original Byte Origi. MNEMONICO Byte Ori XOR 73h con XOR 73h
0040618D . 0FBED0 MOVSX EDX,AL 7C CD A3 40 A1 E3
0040640B . 0FBED0 MOVSX EDX,AL 7C CD C6 40 A1 86
00406920 . 0FBED0 MOVSX EDX,AL 7C A8 A3 40 C4 E3
004069CD . 0FBEC0 MOVSX EAX,AL 7C CD B3 40 B3 E3
En palabras simples modificamos estos 12 Bytes:
Citar0040618D . 7C CD A3
0040640B . 7C CD C6
00406920 . 7C A8 A3
004069CD . 7C CD B3
Por:
Citar0040618D . 40 A1 E3
0040640B . 40 A1 86
00406920 . 40 C4 E3
004069CD . 40 B3 E3
Nos quedará:
. Imagínate que lo hiciste en un día todo este avance, si siguieras en esto llegarías muy lejos. Saludos