Menú Principal

Este sitio usa cookies y tecnologías similares.

Si no cambia la configuración de su navegador, usted acepta su uso. Saber más

Acepto

Zona descarga

Análisis Packer 01 - Parte IV

Tamaño de letra:

Las calls intermodular

Si nos detenemos en el OEP y vamos a la sección de código de "protegido.exe" y pulsamos botón derecho Search for -> All intermodular calls veremos cosas como esta:

...
0040876C   call 01C40004
00408774   call 01C60004
00408BEC   call 01CA0004
00408CA4   call 01CC0004
00408CC4   call 01CE0004
00408CD4   call 01BB0000
00408D44   call 01BB0000
00408D5C   call 01D20004
0040910C   call 01D40004
0040915C   call 01BB0000
004091CC   call 01D60004
004093CC   call 01D80004
00409404   call 01DA0004
00409448   call 004085A4        kernel32.GetTickCount
00409472   call 004085D4        kernel32.GlobalAlloc
00409478   call 004085F4        kernel32.GlobalLock
00409483   call 004085FC        kernel32.GlobalHandle
...

Un montón de calls redirigidas al packer, son todas llamadas a API y algunas ¡ni aparecen! ya que OllyDBG no las reconoce como tales, por ejemplo ya sabemos de antemano que en 00407ED4 hay una call 01BB0000 que corresponde a la API GetModuleHandleA. Sin embargo si vemos en All intermodular calls no la reconoce y no existe:

00407E8C   call 0040147C        kernel32.GetVersion
00407EF7   call 00407EDC        kernel32.LocalAlloc
00407F45   call 00407EEC        kernel32.TlsSetValue
00407F71   call 00407EE4        kernel32.TlsGetValue
00407F82   call 00407EE4        kernel32.TlsGetValue

Así que voy otra vez al código y des-analizo(Remove analisis from module) y vuelvo a hacer lo mismo y ya aparecen todas. Realmente, como ya comenté al principio, este packer es muy completo y requiere precisión y entender todo.

 

Reparar los saltos a la IAT

Reparar todas verás que lleva trabajo. La dificultad es descubrir qué dirección y a qué API corresponde y después hay que indicar la dirección de la API en la IAT. Hay varios caminos posibles pero quiero que entiendas lo que vamos a hacer, mira:

1.- Partimos de aquí:
00407ED4   .  E8 27817A01     call 01BB0000
00407ED9   .  0C 8B           or al,8B
00407EDB      C0              db C0
00407EDC   $- FF25 54D37600   jmp near dword ptr ds:[76D354] ; kernel32.LocalAlloc

2.- Ahora debemos encontrar a qué API corresponde, que en este caso ya sabemos que es GetModuleHandleA:
00407ED4   call GetModuleHandleA

3.- Ahora hay que fijarse en la IAT (que debe estar arreglada) para ver dónde está dicha API:
0076D2B0  7C80B731  kernel32.GetModuleHandleA

4.- Finalmente hay que poner el formato adecuado:
00407ED4    - FF25 B0D27600   jmp near dword ptr ds:[76D2B0] ; kernel32.GetModuleHandleA
00407EDA      8BC0            mov eax,eax
00407EDC   $- FF25 54D37600   jmp near dword ptr ds:[76D354] ; kernel32.LocalAlloc

 

1A.- Encontrar las call malas A

Para encontrar todas las llamadas "malas" (como call 01BB0000) algunos recurren a sacar la tabla completa de las calls desde OllyDBG: desde el desensamblado click derecho -> search for -> all commands y ahí pones call 01BB0000 o lo que sea. Después la exportas click derecho -> copy to clipboard -> whole table y así vas encontrando todas las calls malas. Es una buen opción. Otra opción es ver "All intermodular calls" como vimos al principio e ir analizando una a una. Hoy voy a analizar un poquito.

Después de analizar un buen rato descubrí que este packer en general, tiene dos redirecciones de calls malas: una que siempre van a 01BB0000 (calls malas A) y otra que van a otras direcciones del packer (calls malas B). Para empezar a conocerlo vamos a tratar las 01BB0000: vamos a poner un  HBP-W en los bytes de 00407ED4 que forman la call 01BB0000, reinicio OllyDBG y llego a este sitio:

00BB4CBA    45              inc ebp                      ; ebp = 0407ED4
00BB4CBB    8945 00         mov dword ptr ss:[ebp],eax   ; pone call 01BB0000
00BB4CBE    6A 0A           push 0A
00BB4CC0    E8 C3B7FEFF     call 00BA0488

Interesante: TODAS las call 01BB0000 pasan por ahí. Si ponemos un HBP en 0BB4CBA podemos obtener dónde se encuentran todas las call 01BB0000. Analizo ese código, lo traceo con F7 y pierdo tiempo pero no descubro forma de saber a qué API se corresponde, así que decido crear una tabla con todas las call 01BB0000 malas que existen. Para que sepas lo que voy a hacer, voy a crear una tabla del siguiente modo:

00407ED4 - 7C80B731

A la izquierda la dirección donde está y a la derecha (4 bytes más) la dirección de la API que corresponde. Como de momento no sabemos la dirección, le pondré ceros. Voy a crear un sencillo script que cree esta tabla:

//Definir variables
var tabla_calls
var oep
var obtiene_dato
var contador

//Inicializar variables
mov tabla_calls, 680000
mov oep, 01B903DE
mov obtiene_dato, 00BB4CBA

//Hardware breakpoints
bphws oep, "x"
bphws obtiene_dato, "x"

inicio:
run
eob para_en_hbp

para_en_hbp:
cmp eip, oep
jne sigue
mov [tabla_calls], #FFFFFFFF#
msg contador
ret

sigue:
mov [tabla_calls], ebp
add tabla_calls, 4
mov [tabla_calls], #00000000#
add tabla_calls, 4
inc contador

jmp inicio

He puesto la dirección 680000 por probar, no tiene más motivo y el FFFFFFFF para saber el final. Tras el script, me dice que ha encontrado 106 calls 01BB0000. Me voy a esta dirección y ya veo la tabla tan bonita:

00680000 00401314  protegid.00401314
00680004 00000000
00680008 0040131C  protegid.0040131C
0068000C 00000000
00680010 00401324  protegid.00401324
00680014 00000000
00680018 00401344  protegid.00401344
0068001C 00000000
00680020 0040135C  protegid.0040135C
00680024 00000000
00680028 00401374  protegid.00401374
0068002C 00000000
...
00680338 0040915C  protegid.0040915C
0068033C 00000000
00680340 00442F08  protegid.00442F08
00680344 00000000
00680348 00442F68  protegid.00442F68
0068034C 00000000
00680350 FFFFFFFF

 

2A.- Saber a qué API corresponden las calls malas A

Para saber a qué API corresponde cada call 01BB0000 de la tabla anterior, pues voy a fijarme en la que ya conocemos:

006800C0 00407ED4  protegid.00407ED4
006800C4 00000000

Que sabemos que va a GetModuleHandleA. Así que pongo el eip en 407ED4 y empiezo a tracear con F7 y F8 un largo rato y llego al siguiente sitio:

00BB3BE0    50                push eax
00BB3BE1    8D45 CC           lea eax,dword ptr ss:[ebp-34]
00BB3BE4    50                push eax
00BB3BE5    8D45 DC           lea eax,dword ptr ss:[ebp-24]
00BB3BE8    50                push eax
00BB3BE9    8B45 FC           mov eax,dword ptr ss:[ebp-4]
00BB3BEC    50                push eax                                     ; kernel32.GetModuleHandleA
00BB3BED    8B45 F8           mov eax,dword ptr ss:[ebp-8]
00BB3BF0    83C0 04           add eax,4
00BB3BF3    50                push eax
00BB3BF4    8B45 10           mov eax,dword ptr ss:[ebp+10]
00BB3BF7    50                push eax
00BB3BF8    8B45 F4           mov eax,dword ptr ss:[ebp-C]
00BB3BFB    50                push eax

¡Qué bien!, en 00BB3BEC nos da la dirección que buscamos.

 

3A.- Completando la tabla A

Ya podemos completar la tabla A, para ello he creado un simple script:

//Declara variables
var tabla_calls
var hbp_obtiene_api
var fin_tabla

//Inicializa variables
mov tabla_calls, 680000
mov hbp_obtiene_api, 00BB3BEC
mov fin_tabla, 680350

//Hardware breakpoint
bphws hbp_obtiene_api, "x"

//Código
//Ponemos eip en la dirección mala:
Inicio:
mov eip, [tabla_calls]
run

parado_hbp:
add tabla_calls, 4
mov [tabla_calls], eax
add tabla_calls, 4
cmp tabla_calls, fin_tabla
jne Inicio
ret

Ejecuto el script y miro la tabla:

00680000 00401314  protegid.00401314
00680004 7C810EE1  kernel32.GetFileType
00680008 0040131C  protegid.0040131C
0068000C 7C810B07  kernel32.GetFileSize
00680010 00401324  protegid.00401324
00680014 7C812FC9  kernel32.GetStdHandle
00680018 00401344  protegid.00401344
0068001C 7C83205E  kernel32.SetEndOfFile
00680020 0040135C  protegid.0040135C
00680024 7C810E17  kernel32.WriteFile
...
00680334 7E3AD312  user32.DestroyIcon
00680338 0040915C  protegid.0040915C
0068033C 7E3D07EA  user32.MessageBoxA
00680340 00442F08  protegid.00442F08
00680344 7E714C31  shell32.SHGetPathFromIDListA
00680348 00442F68  protegid.00442F68
0068034C 76362563  comdlg32.GetFileTitleA
00680350 FFFFFFFF

Realmente queda una sin reparar porque no sé cuál puede ser. El problema es que si la sigues nos lleva a un sólo ret. Algo curioso pero me dispongo a mostrarte cómo lo solucioné.

 

4A .- Reparando la última call mala tipo A

Como dije, nos queda una sóla call mala tipo A por reparar, es esta:

00680300  0043EAD4  protegid.0043EAD4
00680304  AAAAAAAA

Corresponde a la call que está en 0043EAD4 (ya verás qué curiosa). Vamos a intentar repararla. Desde el packer desde cero, pongo un hbp en 43EAD4 y ejecuto el programa. Se ejecuta pero sale una ventana del packer diciendo que el periodo de prueba ya ha pasado, esto ya lo estudié hace años pero no lo recuerdo exactamente. Al principio dije que simplemente borrando una clave de Windows funcionaría pero ahora no funciona. Es muy sencillo llegar al punto donde se comparan las fechas, así que evito que el programa se detenga por 30 días de uso (esto último no lo voy a explicar aquí porque requiere otro tute completo y no es la intención de éste, si no se hará muy largo y seguramente poco acertado), y empiezo a usar el programa pulsando todos los botones que veo y finalmente (después de probar un buen rato) salta al HBP:

0043EAD3   .  C3                   retn
0043EAD4   $  E8 2B159A01 call 01DE0004
0043EAD9      63                   db 63                                        ; CHAR 'c'
0043EADA      8BC0                 mov eax,eax

Algo me hace sospechar ese código tan extraño de 43EAD9. Umm!. Sigo a la call:

01DE0004    8D9C23 645288C3        lea ebx,dword ptr ds:[ebx+C3885264]
01DE000B    8D6424 04              lea esp,dword ptr ss:[esp+4]
01DE000F    64:EB 02               jmp short 01DE0014                           ; Superfluous prefix
01DE0012    CD20 8D9B9CAD          vxdjump AD9C9B8D
01DE0018    77 3C                  ja short 01DE0056
01DE001A    68 0000DD01            push 1DD0000
01DE001F    C3                     retn

Un poquito de código ofuscado que desofusco rápidamente con Code Doctor:

01DE0004    83C4 04                add esp,4
01DE0007  - E9 F4FFFEFF            jmp 01DD0000

Qué curioso. Quita el retorno de la call 01DE0004 y hace un jump directo a 1DD0000. Lo sigo:

//Código
01DD0000    C3                     retn

//Pila
0012F40C
00668381  RETURN to protegid.00668381 from protegid.0043EAD4

Asombrado veo que retorna a 668381:

00668381    8B55 F8                mov edx,dword ptr ss:[ebp-8]
00668384    8B45 FC                mov eax,dword ptr ss:[ebp-4]
00668387    E8 98F5E1FF            call 00487924 ; protegid.00487924
0066838C    8B45 F8                mov eax,dword ptr ss:[ebp-8]
0066838F    8348 04 0B             or dword ptr ds:[eax+4],0B
00668393    59                     pop ecx
00668394    59                     pop ecx
00668395    5D                     pop ebp
00668396    C3                     retn

La verdad que me quedo un poco perplejo. Por la lógica que estoy viendo, estudia tú también el sencillo código, debería modificar:

0043EAD4    E8 2B159A01            call 01DE0004
por:
0043EAD4    E8 2B159A01            retn

Poniendo el retn ya funciona correctamente todo, pero?? ¿No te preguntas por qué es un retn? Tendría que ser una API. Yo no me voy a quedar con las ganas así que voy a ver un Delphi 7 cualquiera a ver esa zona que es similar en todos y me encuentro con esto:

0042BE87   .  C3                   retn
0042BE88   $- FF25 80B74800        jmp near dword ptr ds:[48B780] ; comctl32.InitCommonControls
0042BE8E      8BC0                 mov eax,eax

Qué curioso, ¿verdad? Me voy a la API InitCommonControls:

58C365CF >  8BC0                   mov eax,eax
58C365D1    C3                     retn

Aquí está toda la investigación. Realmente la API es InitCommonControls que debemos reparar y ya están todas las call malas A reparadas:

0043EAD3   .  C3                   retn
0043EAD4    - FF25 D8DC7600 jmp near dword ptr ds:[76DCD8] ; comctl32.InitCommonControls
0043EADA      8BC0                 mov eax,eax

Genial, ya tengo la tabla A reparada. La guardo en un archivo .txt (binary copy). Ahora queda la tabla más difícil: la tabla B

 

1B.- Encontrar las call malas B

Al igual que hicimos con las A, voy a poner un hbp-w en una call mala y ver cuándo se escribe, por ejemplo aquí tenemos unas call malas tipo B:

00442EE8    E8 17D1A501       call 01EA0004
00442EED    F5                cmc
00442EEE    8BC0              mov eax,eax
00442EF0    E8 0FD1A701       call 01EC0004
00442EF5    4E                dec esi
00442EF6    8BC0              mov eax,eax
00442EF8    E8 07D1A901       call 01EE0004

Voy a poner el hbp en la de 00442EE8 y me encuentro con este código:

00BB4CA2    45                inc ebp                                      ; ebp = dirección donde está la call mala B
00BB4CA3    8945 00           mov dword ptr ss:[ebp],eax
00BB4CA6    8B4424 10         mov eax,dword ptr ss:[esp+10]
00BB4CAA    8B00              mov eax,dword ptr ds:[eax]
00BB4CAC    894424 14         mov dword ptr ss:[esp+14],eax
00BB4CB0    EB 0C             jmp short 00BB4CBE                           ; protegid.00BB4CBE
00BB4CB2    8B43 2C           mov eax,dword ptr ds:[ebx+2C]
00BB4CB5    2BC5              sub eax,ebp
00BB4CB7    83E8 05           sub eax,5
00BB4CBA    45                inc ebp                                      ; Observa que aquí paraba en las calls malas A
00BB4CBB    8945 00           mov dword ptr ss:[ebp],eax
00BB4CBE    6A 0A             push 0A

Simplemente ponemos un hbp-x en 0BB4CA2 y tenemos todas las calls malas tipo B. Como antes, voy a hacer una pequeña tabla con la dirección de la call mala B y su dirección API aunque este último dato todavía no lo conocemos y lo pondré a cero... ¿entiendes todo hasta ahora? Para iniciar la tabla voy a crear otro simple script:

//Definir variables
var tabla_calls
var oep
var obtiene_dato
var contador

//Inicializar variables
mov tabla_calls, 680000
mov oep, 01B903DE
mov obtiene_dato, 00BB4CA2

//Hardware breakpoints
bphws oep, "x"
bphws obtiene_dato, "x"

inicio:
run
eob para_en_hbp

para_en_hbp:
cmp eip, oep
jne sigue
mov [tabla_calls], #FFFFFFFF#
msg contador
ret

sigue:
mov [tabla_calls], ebp
add tabla_calls, 4
mov [tabla_calls], #00000000#
add tabla_calls, 4
inc contador

jmp inicio

Reinicio OllyDBG quito todos los BP, ejecuto el script y voy a 680000:

00680000 00408724  protegid.00408724
00680004 00000000
00680008 0040875C  protegid.0040875C
0068000C 00000000
00680010 0040876C  protegid.0040876C
00680014 00000000
00680018 00408774  protegid.00408774
0068001C 00000000
...
006800E8 00442F70  protegid.00442F70
006800EC 00000000
006800F0 00442F88  protegid.00442F88
006800F4 00000000
006800F8 00442F90  protegid.00442F90
006800FC 00000000
00680100 FFFFFFFF

Ahí está nuestra tabla, esta vez el script me dice que sólo hay 32 calls malas tipo B

 

2B.- Saber a qué API corresponden las calls malas B

Esto es lo más trabajoso de este artículo y requiere precisión. Intenté muchas cosas: buscar algún punto donde apareciera el salto a la API, buscar con Import REconstructor pasándole la IAT en 680000 pero éste último se equivocaba casi siempre y no escontré una rápida solución. Todas estas calls emulan el principio de las API, no usan código ofuscado ni máquina virtual y cuando saltan a alguna API no lo hacen al principio de la misma (ya que está emulada) sino a mitad. Para entenderlo vamos a seguir la primera función: 00408724 y pongo el eip ahí:

00408724    E8 DB787F01       call 01C00004

Sigo la call:

01C00004    8DBC27 20ABB95D   lea edi,dword ptr ds:[edi+5DB9AB20]
01C0000B    8D6424 04         lea esp,dword ptr ss:[esp+4]
01C0000F    81C7 E05446A2     add edi,A24654E0
01C00015    68 0000BF01       push 1BF0000
01C0001A    C3                retn

Sigo hasta el retn y voy como se puede ver hasta 1BF0000:

01BF0000    8BFF              mov edi,edi
01BF0002    55                push ebp
01BF0003    8BEC              mov ebp,esp
01BF0005    56                push esi
01BF0006    8B35 6C12807C     mov esi,dword ptr ds:[7C80126C]              ; ntdll.ZwUnmapViewOfSection
01BF000C    57                push edi
01BF000D    FF75 08           push dword ptr ss:[ebp+8]
01BF0010    6A FF             push -1
01BF0012    FFD6              call near esi
01BF0014    8BF8              mov edi,eax
01BF0016    85FF              test edi,edi
01BF0018    68 1CBA807C       push 7C80BA1C
01BF001D    C3                retn

En 01BF0000 está el comienzo de la API y como ves está emulada literalmente. Sigo naturalmente hasta 7C80BA1C y veo la call entera:

7C80BA04 >  8BFF              mov edi,edi                                  ; kernel32.UnmapViewOfFile
7C80BA06    55                push ebp
7C80BA07    8BEC              mov ebp,esp
7C80BA09    56                push esi
7C80BA0A    8B35 6C12807C     mov esi,dword ptr ds:[7C80126C]
7C80BA10    57                push edi
7C80BA11    FF75 08           push dword ptr ss:[ebp+8]
7C80BA14    6A FF             push -1
7C80BA16    FFD6              call near esi
7C80BA18    8BF8              mov edi,eax
7C80BA1A    85FF              test edi,edi
7C80BA1C    0F8C DE130300     jl 7C83CE00 ; kernel32.7C83CE00
7C80BA22    33C0              xor eax,eax
7C80BA24    40                inc eax
7C80BA25    5F                pop edi
7C80BA26    5E                pop esi
7C80BA27    5D                pop ebp
7C80BA28    C2 0400           retn 4

Como puedes ver hay que tener precisión y no fallar. En este ejemplo la API es UnmapViewOfFile. ¿Se podría haber hecho algo automático? Pues sí, pero puede resultar algo engorroso y en algunos casos no es sencillo, además como son sólo 32 llamadas pues aunque me lleve algo más de 30 minutos me divertiré un rato. (tuve que repasarlo porque me equivoqué en alguna...por eso dije precisión) y hay alguna difícil de buscar.

 

3B.- Completando la tabla B

Empiezo desde cero:

00680000 00408724  protegid.00408724
00680004 00000000
00680008 0040875C  protegid.0040875C
0068000C 00000000
...
006800F0 00442F88  protegid.00442F88
006800F4 00000000
006800F8 00442F90  protegid.00442F90
006800FC 00000000
00680100 FFFFFFFF

La primera:

00680000 00408724  protegid.00408724
00680004 7C80BA04 kernel32.UnmapViewOfFile
00680008 0040875C  protegid.0040875C
0068000C 00000000
...
006800F0 00442F88  protegid.00442F88
006800F4 00000000
006800F8 00442F90  protegid.00442F90
006800FC 00000000
00680100 FFFFFFFF

Y unos 35 minutos más tarde...

00680000 00408724  protegid.00408724
00680004 7C80BA04 kernel32.UnmapViewOfFile
00680008 0040875C  protegid.0040875C
0068000C 7C802530 kernel32.WaitForSingleObject
00680010 0040876C  protegid.0040876C
00680014 7C810E17 kernel32.WriteFile
00680018 00408774  protegid.00408774
...
006800F0 00442F88  protegid.00442F88
006800F4 7637C1C1 comdlg32.ChooseFontA
006800F8 00442F90  protegid.00442F90
006800FC 763846FD comdlg32.PrintDlgA
00680100 FFFFFFFF

Ya tengo todas las call malas B en la tabla. Lo que hago ahora es copy -> binary copy y pongo todas las call malas, tanto A como B juntas y las dejo en un archivo de .txt. Lo guardo como "todas_las_calls_malas.txt".

Ha costado trabajo pero ya están todas guardadas. En el siguiente artículo crearemos por fin el primer dumpeado.

Última actualización: Domingo, 10 Julio 2011

Escribir un comentario

Antes de publicar un comentario, usted debe aceptar nuestras condiciones de uso: Condiciones de uso


 
Visitas: 4698937