| Empieza la acción. Hay que buscar la llamada a la función
de la API RegQueryValueEx que
es la responsable de cargar en memoria el contenido de una clave del registro.
Siguiéndole la pista sabremos donde se modifica y podemos EVITARLO.
La sintaxis de esta función es como sigue:
LONG RegQueryValueEx(
HKEY hKey,
// handle of key to query
LPTSTR lpValueName, //
address of name of value to query
LPDWORD lpReserved, //
reserved
LPDWORD lpType,
// address of buffer for value type
LPBYTE lpData,
// address of data buffer
LPDWORD lpcbData
// address of data buffer size
);
Se suceden muchas llamadas a esta función, aunque después
de trazar un poco se hace evidente que las de interés suceden en
:
* Reference To: advapi32.RegQueryValueExA,
Ord:0000h
|
:0045210A E83150FBFF
Call 00407140
:0045210F 85C0
test eax, eax
:00452111 742E
je 00452141
:00488D8D B1B4
mov cl, B4
:00488D8F E8B09EF7FF
call 00402C44 --> Modificación
:00488D94 FF45EC
inc [ebp-14]
Para poner un breakpoint a la que nos interesa hacemos:
Bpx 0045210A IF *(*(ESP+4))==6568744F
El segundo argumento de la función, ya en la pila, debe apuntar
a ôOther Flagsö, 6568744f son los codigos ascii de los primeros 4 caracteres
invertidos (ôehtOö.)
El valor de la clave leído por RegQueryValueExa
es apuntado a la salida por el 5º argumento y en esa posicion de memoria
instalamos un BPM [address] W para detectar escritura...
El resultado no es muy sorprendente. El CALL en 488D8F es el responsable
de las actualizaciones. Para poder neutralizar este CALL, primero comprobamos
que la pila permanece igual despues de la ejecución. A continuación
procedemos a escribir un crack que cambie:
:00488D8F E8B09EF7FF
call 00402C44
por
:00488D8F 9090909090
nop nop nop nop nop
Hacemos los chequeos de rigor y comprobamos que restaurando el registro
al valor original de æOther FlagsÆ y ejecutando esi.exe parcheado
como se ha indicado disponemos del programa como si fuera SIEMPRE la primera
vez...:o)
|
