| ESTUDIO COLECTIVO DE DESPROTECCIONES Última Actualizacion: 25/10/2001 |
Programa | Unpacker del PeCompact 1.41 | W95 / W98 / NT
Descripción | Se trata del código que inyecta el compresor en los programas empaquetados con el, para que se puedan descomprimir en memoria.
Tipo | Packer
Tipo de Tutorial | [X]Original, []Adaptación, []Aplicación, []Traducción
Url | http://www.collakesoft.com
Protección | Encriptación/Compresión
Dificultad | 1) Principiante, 2) Amateur, 3) Aficionado, 4) Profesional, 5) Especialista
Herramientas | OllyDbg 1.03, WinHex, PeBuild
Objetivo | Desentrañar cómo se descomprimen los programas comprimidos con PeCompact.
Cracker | Mr. Khaki
Grupo | www.whiskeykontekila.org
Fecha | 20 de Septiembre de 2001
INTRODUCCION
La historia empezó a la hora de querer proteger un poco más mi primer crackme, aquel famoso que servía para obtener “registro” en el canal #crackers del Irc-Hispano. Si hubo por lo que me decidí a hacerlo con el PeCompact fue porque lo dejaba realmente compacto, y eso me gustó. A medida que la gente fue estudiando el crackme, y al ver sus respuestas cada vez me llamó más la atención. Alguno llegó a pensar que el crackme estaba comprimido en varias capas (¿?). Otros tenían auténticos problemas a la hora de desempaquetarlo, pues un script que había por ahí para el ProcDump no funcionaba. A medida que la gente me iba diciendo todo esto, yo realmente descubría que mi crackme, atacarlo, no era tan difícil, es más, mi mayor empeño estaba dirigido al algoritmo del serial, que eso fue lo que trajo después de cabeza a muchos... mucho más que el antidebugging (por llamarlo de algún modo), o que el packer. A la hora de estudiar cómo funciona el PeCompact (especialmente el unpacker que va inyectado en los exe's comprimidos) lo hice del siguiente modo. Cogí mi crackme, y lo comprimí con el PeCompact aplicándole diversas opciones: el algoritmo de compresión, la razón de compresión (ratio), algoritmo “fast” o “small”, etc... y después empecé a estudiarles 1 a 1.
AL ATAQUE
Lo primero que hice nada más comprimir mi crackme, fue echar una ojeada a las cabeceras (sí, cabeceras, porque no podéis olvidar que los PE también llevan cabecera MZ). Lo primero que vi al ojear la cabecera del crackme comprimido con el PeCompact fue una especie de signatura (firma), que deja al inicio del fichero, concretamente en el offset 0CAh. La signatura consiste en un word (supuestamente un checksum?), y los caracteres “PECO” (figura 1). Y lo primero que intenté, fue cambiar esa signatura, y ver que el fichero comprimido seguía funcionando.... y así fue. Por tanto es una signatura que el compresor pone ahí, pero la podemos cambiar..... es decir, una signatura que no nos va a servir para identificar los archivos que están comprimidos con PeCompact. Fig. 1. La signatura del compresor en la cabecera Otra de las cosas que pronto se ven al analizar las cabeceras, es que las secciones de la cabecera PE la va nombrando como “.pecn” y “.rsrc”. Esto tampoco nos debería servir para identificar el compresor, pues si renombramos las secciones del PE, el unpacker no lo va a detectar, y eso provocará un despiste mayúsculo. Así, pues, si queremos buscar una signatura real par el PeCompact, lo que tenemos que hacer es ojear el código ejecutable en la zona del Entry Point, es decir, el código que supuestamente tiene que descomprimir el exe comprimido. Esto es un problema, pues por la cantidad de opciones que tiene el PeCompact pronto supuse que tendría varios unpackers internos, así que fui mirando todas las posibilidades. Realmente la única diferencia está en si se usa el algoritmo aPLiB o si se usa el JCALG1. Yo todo el estudio lo he hecho sobre el algoritmo aPLiB, aunque seguramente el aspecto del unpacker para el JCALG1 es igual, salvo la rutina propia que descomprime los datos. Al mirar los ficheros en la zona donde sitúa el Entry Point, observé que los primeros 178 bytes son prácticamente iguales, salvo alguna ligera modificación. Y es partir de esa zona donde la rutina del JCALG1 se diferencia. Podríamos por tanto coger cualquier cadena un poco larga como signatura... especialmente que en su representación ASCII sea fácil de localizar. Hay una parte que es tremendamente diferenciadora: “SSSSX-p” (figura 2). Fig. 2. Los 178 bytes primeros de la zona de Entry Point los podemos considerar como la verdadera signatura del unpacker del PeCompact. Bien, pues vista esta parte interesante del unpacker, vamos a empezar a estudiar su código, y el modo en que va reconstruyendo el fichero original.
TRAZANDO CÓDIGO
Normalmente los unpackers trabajan del modo siguiente: desencriptan un pequeño bloque que es realmente el verdadero corazón del unpacker, desde ese kernel del unpacker desempacan todo el código original del exe, alineándolo en memoria, desempacan la tabla de importaciones, y construyen la IAT (Import Address Table / Tabla de Direcciones de Importación),este trabajo normalmente lo hace el loader de Windows al cargar el exe en memoria, finalmente obtiene el Entry Point original del programa (OEP), y salta a ese lugar para ejecutar el fichero reconstruido en memoria.
    00404600 >EB 06            jmp short FAST_APL.00404608
    00404602 68 00100000       push 1000
    00404607 C3                retn
Estas son las 3 primeras líneas de código del unpacker de PeCompact. Sencillo, ¿verdad?. Un jmp incondicional, un push y un ret. Si nos olvidamos del jmp, ya sabemos lo que haría esto... al meter 1000 en la pila, y provocar un ret, el ultimo dato de la pila (1000) se tomaría como dirección de retorno... y sería como poner un jmp 1000. Como dato ya preeliminar, decir que el número que acompaña al push es el RVA del OEP. Si a ese numero le sumamos la ImageBase, ya tendríamos el OEP (vaya con el PeCompact!!)
    00404608 9C                pushfd
    00404609 60                pushad
    0040460A E8 02000000       call FAST_APL.00404611
    0040460F 33C0              xor eax,eax
    00404611 8BC4              mov eax,esp
    00404613 83C0 04           add eax,4
    00404616 93                xchg eax,ebx
    00404617 8BE3              mov esp,ebx
    00404619 8B5B FC           mov ebx,dword ptr ds:[ebx-4]
    0040461C 81EB 0FA04000     sub ebx,40A00F
    00404622 87DD              xchg ebp,ebx
    00404624 8B85 A6A04000     mov eax,dword ptr ss:[ebp+40A0A6]
    0040462A 0185 03A04000     add dword ptr ss:[ebp+40A003],eax
    00404630 66:C785 00A04000 >mov word ptr ss:[ebp+40A000],9090
    00404639 0185 9EA04000     add dword ptr ss:[ebp+40A09E],eax
    0040463F BB C3110000       mov ebx,11C3
    00404644 039D AAA04000     add ebx,dword ptr ss:[ebp+40A0AA]
    0040464A 039D A6A04000     add ebx,dword ptr ss:[ebp+40A0A6]
    00404650 53                push ebx
    00404651 53                push ebx
    00404652 53                push ebx
    00404653 53                push ebx
    00404654 58                pop eax
    00404655 2D 70A04000       sub eax,40A070
    0040465A 8985 71A04000     mov dword ptr ss:[ebp+40A071],eax
    00404660 5F                pop edi
    00404661 8DB5 70A04000     lea esi,dword ptr ss:[ebp+40A070]
    00404667 B9 55040000       mov ecx,455
    0040466C F3:A5             rep movs dword ptr es:[edi],dword ptr ds:[esi]
    0040466E 5F                pop edi
    0040466F C3                retn
Bien, analicemos ahora todo este bloque de código hasta el retn. Con las 2 primeras instrucciones guarda los valores de los registros en la pila, y con el call siguiente lo que hace es, meter en la pila el valor 40460F (dirección de retorno), y saltar a 404611. Desde 404611 hasta 404619 no hace más que recuperar el dato que hay en la pila poniéndolo en el registro EBX, y resituar el valor de ESP. Aquí viene un tema un poco complejo... fijaos que el unpacker se va a cargar en diferentes zonas de memoria, dependiendo de la longitud que ocupe el programa previamente empaquetado. Ello obliga a que todos los offsets sean relativos (código relocalizable), pero casi todas las instrucciones de tipo mov usan direcciones absolutas, por eso los unpackers lo que hacen es utilizar un registro (normalmente ebp), como índice para acceder a los datos que estarían en falsas posiciones relativas. Fijaos que a ese calor de retorno que ha sacado de la pila (40460F) después le resta 40A00F, de este modo obtiene en EBP un valor negativo, que después lo usa como índice para acceder a las variables que están en direcciones absolutas. Por ejemplo: mov eax,dword ptr ss:[ebp+40A0A6] , al utilizar un EBP negativo, está accediendo realmente a la dirección 4046A6. En el unpacker inicialmente hay 3 pequeñas rutinas que no están ni encriptadas ni comprimidas: la inicial que estamos analizando ahora, la que desempaca el kernel del unpacker, y la que contiene el algoritmo de descompresión. Junto a estas 3 pequeñas rutinas se sitúan 5 datos necesarios: la dirección real donde se encuentra la rutina de descompresión (la suele situar al final de la sección de la tabla de importación), la ImageBase del fichero original, la ImageSize del fichero original, y la RVA de la sección que contiene el unpacker. Concretamente en 4046A6 lo que está cogiendo es la ImageBase.
    00404624 8B85 A6A04000     mov eax,dword ptr ss:[ebp+40A0A6]
    0040462A 0185 03A04000     add dword ptr ss:[ebp+40A003],eax
    00404630 66:C785 00A04000 >mov word ptr ss:[ebp+40A000],9090
    00404639 0185 9EA04000     add dword ptr ss:[ebp+40A09E],eax
Estas líneas son muy curiosas, pues parchean el Entry Point del unpacker. Con “9090” está nopeando el primer jmp, y con los add lo que hace es sumar la ImageBase al RVA del OEP que está en el push. Con esto lo que ocurre es que la entrada del unpacker se queda parcheada de este modo:
    00404600 >90               nop
    00404601 90                nop
    00404602 68 00104000       push 401000
    00404607 C3                retn
Si en este momento nosotros hacemos un dump de la memoria a un fichero, el unpacker ya no funcionará, pues estamos provocando que salte al OEP (esto es una gran ventaja, pues a la hora de desempaquetar a mano nos va a evitar tener que modificar el Entry Point por el OEP.
    0040463F BB C3110000       mov ebx,11C3
    00404644 039D AAA04000     add ebx,dword ptr ss:[ebp+40A0AA]
    0040464A 039D A6A04000     add ebx,dword ptr ss:[ebp+40A0A6]
    00404650 53                push ebx
    00404651 53                push ebx
    00404652 53                push ebx
    00404653 53                push ebx
    00404654 58                pop eax
    00404655 2D 70A04000       sub eax,40A070
    0040465A 8985 71A04000     mov dword ptr ss:[ebp+40A071],eax
En esta zona se vuelve a calcular un nuevo EBP relativo, para poder trabajar más adelante con offsets y tomar valores de las variables. En EBX va sumando 11C3, le suma la ImageSize del fichero original, y también la ImageBase. Con estas sumas calcula una dirección en una zona de memoria donde va a realojar código ejecutable. Con el mov dword ptr ss:[ebp+40A071],eax, está modificando código en tiempo de ejecución que ahora veremos.
    00404660 5F                pop edi
    00404661 8DB5 70A04000     lea esi,dword ptr ss:[ebp+40A070]
    00404667 B9 55040000       mov ecx,455
    0040466C F3:A5             rep movs dword ptr es:[edi],dword ptr ds:[esi]
    0040466E 5F                pop edi
    0040466F C3                retn
Finalmente, realoja parte del código en una zona de memoria que está libre. (parte del código que ha realojado corresponde al kernel del unpacker. Finalmente, con el retn salta al código que acaba de realojar... (usa muchos datos tomados de la pila, que los guardó con todos los push ebx). Ahora analizaremos el trozo de código que ha realojado, y que también ha modificado en tiempo de ejecución.
    00404670 BD 0000000        mov ebp, 0
    00404675 57                push edi
    00404676 5E                pop esi
    00404677 83C6 42           add esi,42
    0040467A 81C7 53110000     add edi,1153
    00404680 56                push esi
    00404681 57                push edi
    00404682 57                push edi
    00404683 56                push esi
    00404684 FF95 9EA04000     call dword ptr ss:[ebp+40A09E]
    0040468A 8BC8              mov ecx,eax
    0040468C 5E                pop esi
    0040468D 5F                pop edi
    0040468E 8BC1              mov eax,ecx
    00404690 C1F9 02           sar ecx,2
    00404693 F3:A5             rep movs dword ptr es:[edi],dword ptr ds:[esi]
    00404695 03C8              add ecx,eax
    00404697 83E1 03           and ecx,3
    0040469A F3:A4             rep movs byte ptr es:[edi],byte ptr ds:[esi]
    0040469C EB 14             jmp short FAST_APL.004046B2
Se trata de un bloque muy pequeño, pero muy importante. Es precisamente el que se encarga de desempaquetar el kernel del unpacker, y pasarle a él el control. Este bloque se encuentra duplicado, pues se ha realojado en otra zona de memoria (después veremos gráficamente qué galimatías ha hecho el unpacker). El mov ebp,0 se ha modificado previamente en tiempo de ejecución, justo antes de realojarlo en otra zona de memoria, de este modo el 0 lo cambia por un numero calcula que nuevamente lo usa como índice para referirse a offsets de variables. A la entrada de esta rutina, edi contiene la dirección donde ha sido realojada, por lo que se pasa a esi (push edi, pop esi), y se le suma 42 (longitud en bytes de este bloque de código, más 5 dwords que son variables que ya se han usado anteriormente). A edi le suma 1153, colocándolo en una zona de memoria libre y amplia. El call, es una llamada a la rutina que contiene el algoritmo de descompresión, y como parámetros solo hay que pasarla en esi la dirección del código comprimido, y en edi la dirección del buffer donde va a colocar el código descomprimido. El algoritmo de descompresión devuelve en eax la longitud de bytes descomprimidos. Lo que hace después del call es tapar el código comprimido del kernel del unpacker con el código que hay descomprimido ya en el buffer. Y a continuación, mediante el jmp, salta al kernel de unpacker, que ya está descomprimido y realojado (figura 3). Fig. 3. Gráfica con todos los bloques de código y buffers que mueve. Según la gráfica anterior, podríamos hacer un breve resumen: En “Inicializaciones y parcheo”, el código simplemente parchea el Entry Point, poniendo en él un salto al Original Entry Point, y copia la memoria que hay en 404670-404A36 en 4061C3, saltando después a ejecutar el bloque de “Desempaca el Kernel”. El bloque “Desempaca el Kernel” sencillamente desempaca el “Kernel del unpacker empaquetado” en “Buffer para desempacar el Kernel”, y acto seguido sobrescribe “Kernel de unpacker empaquetado” con lo que ha desempacado en “Buffer para desempacar el Kernel”. Finalmente se haría un salto a la zona “Kernel del unpacker empaquetado”, que ahora tiene el kernel de unpacker desempacado. Veamos pues el contenido del kernel del unpacker, es decir, el corazón real del unpacker.
ESTO SE PONE SERIO
Bien, si hemos entendido hasta aquí todo lo que hemos ido trazando, veremos que aún falta lo más complicado del unpacker. Pensemos un poco cómo es un fichero PE, cómo se estructura el fichero cargado en memoria, y qué significa la palabra “empaquetar” (pack). Debido a la propia estructura PE, y debido al alineamiento que existe dentro del fichero, hay muchos bytes que se pierden, es decir, espacio en el fichero que realmente no es útil y suele estar rellenada con 0. El packer, por tanto, debe quitar todo ese espacio, para que realmente esa información inútil no ocupe espacio en el fichero final comprimido. Por tanto el unpacker debería reorganizar toda esa información inútil que aunque no esté comprimida en el fichero final, sí que debe mantenerla. Aquí ha salido una palabra que va a ser clave para entender cómo funciona el loader y el unpacker, a saber: alineamiento. Si estamos acostumbrados a trabajar con ficheros PE, sabremos que estos están formados por secciones. Cada sección es un bloque de datos, que tienen una cabecera especificando las características de cada sección. Dentro de esas características hay: Physical RVA, Physical Size, Virtual RVA, y Virtual Size. Los datos “physical” hacen referencia a los offset del fichero. Así pues, si una sección tiene Physical RVA igual a 400h, significa que los datos de esa sección empiezan en el offset 400h del fichero. Los datos “Virtual” hacen referencia a dónde se organizará esa sección en el mapeado de memoria (empezando siempre desde la ImageBase). Así, si la sección anterior tiene Virtual RVA igual a 3000h, significa que esa sección se cargaría en la zona de memoria ImageBase+3000h (figura 4). Y aquí viene el meollo del alineamiento... Si el fichero tiene un alineamiento de 200h, significa que las secciones tienen que tener un tamaño que sea múltiplo de 200h. Así si una sección tiene un Physical RVA de 500h y un Physical Size de 35h, realmente ocuparía 200h, ya que por el alineamiento la siguiente sección debería empezar en 500h+200h. Si su Physical Size fuera de 235h, ocuparía 400h (el número más próximo múltiplo de 200h). El espacio “montante” que se añade para alinear el fichero normalmente se rellena con 0. Y ahora viene el problema real.... normalmente el alineamiento del fichero suele ser muy pequeño. Pero no ocurre lo mismo con el alineamiento de memoria (Object Alignment), que normalmente suele ser de 1000h. Normalmente los compiladores y el linker suelen asignar bloques consecutivos para posicionar cada sección, aunque siempre respetando el alineamiento. Fig. 4. Esquema de carga de una sección del fichero a la memoria. Bueno, pues visto esto... veamos ahora el kernel del unpacker.
    00406205 8BB5 A6A04000  mov esi,dword ptr ss:[ebp+40A0A6]
    0040620B 56             push esi
    0040620C 03B5 AEA04000  add esi,dword ptr ss:[ebp+40A0AE]
    00406212 57             push edi
    00406213 83C6 14        add esi,14
    00406216 03B5 11A64000  add esi,dword ptr ss:[ebp+40A611]
    0040621C 8DBD 15A64000  lea edi,dword ptr ss:[ebp+40A615]
    00406222 B9 06000000    mov ecx,6
    00406227 F3:A5          rep movs dword ptr es:[edi],dword ptr ds:[esi]
    00406229 5F             pop edi
    0040622A 6A 04          push 4
    0040622C 68 00100000    push 1000
    00406231 FFB5 2DA64000  push dword ptr ss:[ebp+40A62D]
    00406237 6A 00          push 0
    00406239 FF95 1DA64000  call dword ptr ss:[ebp+40A61D]
    0040623F 8BF8           mov edi,eax
    00406241 5B             pop ebx
    00406242 019D 38A34000  add dword ptr ss:[ebp+40A338],ebx
    00406248 8DB5 43A64000  lea esi,dword ptr ss:[ebp+40A643]
    0040624E 60             pushad
    0040624F 8D85 C3AD4000  lea eax,dword ptr ss:[ebp+40ADC3]
    00406255 8B95 A6A04000  mov edx,dword ptr ss:[ebp+40A0A6]
    0040625B FFD0           call eax
    0040625D 61             popad
    0040625E 57             push edi
    0040625F AD             lods dword ptr ds:[esi]
    00406260 0BC0           or eax,eax
    00406262 74 6C          je short FAST_APL.004062D0
    00406264 8BD0           mov edx,eax
    00406266 0395 A6A04000  add edx,dword ptr ss:[ebp+40A0A6]
    0040626C AD             lods dword ptr ds:[esi]
    0040626D 56             push esi
    0040626E 8BC8           mov ecx,eax
    00406270 57             push edi
    00406271 52             push edx
    00406272 8BF2           mov esi,edx
    00406274 8B85 15A64000  mov eax,dword ptr ss:[ebp+40A615]
    0040627A 8B9D 19A64000  mov ebx,dword ptr ss:[ebp+40A619]
    00406280 E8 910A0000    call FAST_APL.00406D16
    00406285 5A             pop edx
    00406286 5F             pop edi
    00406287 52             push edx
    00406288 57             push edi
    00406289 FF95 9EA04000  call dword ptr ss:[ebp+40A09E]
    0040628F 0BC0           or eax,eax
    00406291 74 07          je short FAST_APL.0040629A
    00406293 8BC8           mov ecx,eax
    00406295 5E             pop esi
    00406296 5F             pop edi
    00406297 EB C5          jmp short FAST_APL.0040625E
El bloque anterior la que hace es ir descomprimiendo cada sección con nombre “.pecn”. El modo en que accede a ellas es mediante una tabla interna, por lo que no es necesario que las secciones conserven ese nombre. Veamos cómo lo hace: Desde 406205 hasta 406229 lo que hace es copiar las direcciones reales de las funciones de la tabla de importación a una tabla propia y por tanto más accesible por el unpacker, y que posteriormente van ser utilizadas. De este modo tienes una tabla de direcciones de las APIs y no tiene que estar buscándolas en la IAT del fichero comprimido. Las direcciones que carga de la IAT son las de las siguientes funciones (en el mismo orden que él las carga): LoadLibraryA, GetProcAddress, VirtualAlloc, VirtualFree, ExitProcess, GetModuleHandleA. Un problema de las rutinas que tienen que descomprimir código es que se necesita un buffer donde descomprimir, por lo que necesita crear un buffer. Para crearlo llama a la API VirtualAlloc, haciéndolo del modo siguiente: desde 40622A hasta 406237 mete los argumentos en la pila (en orden inverso ;o), para posteriormente hacer un call al address directo de la API (que se encuentra en la tabla que acaba de crear antes). Los argumentos pasados son: 0, una variable que se encontraba comprimida con el kernel, 1000h, y 4. Veamos cuáles son los argumentos de esa API:
    LPVOID VirtualAlloc(
          LPVOID lpAddress, // address of region to reserve or commit
          DWORD dwSize, // size of region
          DWORD flAllocationType, // type of allocation
          DWORD flProtect // type of access protection
    );
lpAddress si tiene valor NULL (0), deja que el propio sistema busque una zona de memoria, y lo asigne, devolviéndonos en eax la dirección de inicio del bloque alojado. Como dwSize se le ha pasado la variable que estaba comprimida con el unpacker, por lo que presumiblemente debe ser el tamaño máximo que tiene que descomprimir. Como flAllocationType se le ha pasado un valor fijo, 1000h, que si miramos en las definiciones de windows.inc corresponde a MEM_COMMIT, y como flProtect se le ha pasado 4, que mirando en windows.inc corresponde a PAGE_READWRITE. Por tanto aquí se asigna un bloque de memoria para lectura y escritura de un tamaño en bytes suficientemente grande como para servir de buffer a cada sección (luego veremos que esto no es del todo cierto, porque el buffer se usa de almacenamiento temporal y no como buffer para descomprimir en él). A partir de este momento lo que hace es ir descomprimiendo cada sección sobre sí misma. De este modo deja todo el trabajo sucio al propio sistema. Es decir, a cada sección le asigna en el fichero comprimido un VirtualSize suficiente como para poder alojar ahí el código comprimido. De este modo es el loader de Windows quien asigna la memoria. El modo en que va a descomprimir las secciones es el siguiente: primero copia la sección comprimida en el buffer y después descomprime el buffer sobre la propia sección (figura 5). Fig. 5. Los 2 pasos que hace con cada sección para descomprimirla. Analicemos esto sobre el código: Después del call que llama a VirtualAlloc hace una de las operaciones más importantes en el unpcker... parchea las últimas instrucciones del unpacker, sumando al RVA del OEP la ImageBase. Justamente con este comando add dword ptr ss:[ebp+40A338],ebx cambia el push que contiene el RVA del OEP. Justo después de este push ejecuta un retn, es decir, que en el push está realmente el OriginalEntryPoint. El PeCompact permite comprimir los archivos incluyendo diversos plugins. Existen varios tipos de plugins... encrypt, decrypt, pre-operative, post-operative, GPA (GetProcAddress Hook), y ExtraData. Justo después de haber alojado el buffer en memoria, haber situado el OEP, y antes de empezar a desempaquetar las secciones debería ejecutar el plugin pre-operative. Esto lo hace desde 406248 hasta 40625D. Fijémonos que antes del call eax guarda todos los registros en la pila, para recuperarlos después del call. Si no existe ningún plugin, eax apuntará a una parte del unpacker que está rellenada con 0C3h (retn), de tal modo que estas lineas no hacen nada. A partir de ese momento la rutina sitúa esi apuntando a una tabla que tiene todas las RVA de las secciones que tienen datos comprimidos, y la longitud (en bytes) de cada sección (longitud real, no alineada). Y mediante un bucle que se van leyendo los datos de esa tabla, hasta que encuentre una RVA que sea 0. Un dato importante de la rutina que tiene el algoritmo de descompresión es que si hay un error del código empaquetado en eax devuelve 0, mientras que si no hay errores devuelve la longitud en bytes de lo que ha descomprimido. Veamos este bucle parte a parte:
    0040625F AD             lods dword ptr ds:[esi]
    00406260 0BC0           or eax,eax
    00406262 74 6C          je short FAST_APL.004062D0
Este es el inicio del bucle. Lee un dato de la tabla que tiene las RVA de las secciones empaquetadas (la llamaremos por ejemplopecRVA_list). Si el dato leído es 0, terminaría el bucle, saltando a 4062D0, si el RVA leído no es 0, entra en el bucle. La tabla pecRVA_list es una tabla de dwords que tendría 2 dword por cada sección comprimida, en el primero estaría la RVA de la sección, y en el segundo dword estaría la longitud en bytes de código comprimido en la sección.
    00406264 8BD0           mov edx,eax
    00406266 0395 A6A04000  add edx,dword ptr ss:[ebp+40A0A6]
    0040626C AD             lods dword ptr ds:[esi]
    0040626D 56             push esi
    0040626E 8BC8           mov ecx,eax
    00406270 57             push edi
    00406271 52             push edx
En este momento mete en edx el RVA que ha leído de la tablapecRVA_list, para sumarle la ImageBase (add edx,dword ptr ss:[ebp+40A0A6]), a continuación carga en eax el siguiente dword de la pecRVA_list, que correspondería a la longitud en bytes de datos empaquetados en esa sección, pasándolo a eax. Finalmente guarda esi (apunta al siguiente dato en pecRVA_list) y edx (dirección de la sección) en la pila. A continuación carga en eax y en ebx 2 valores de la tabla que creó anteriormente desde la IAT. Concretamente carga en eax la dirección de LoadLibraryA y en ebx la dirección de GetProcAddress, llamando posteriormente a 406D16. Hemos de tener en cuenta que justamente después de este call está el call a la rutina que tiene el algoritmo de descompresión. Si nos fijamos, hemos dicho que uno de los plugins es de tipo Encrypt... pues aquí nos encontramos justamente con el plugin Decrypt (:o). En la dirección 406D16 de hecho no hay más que una pequeña rutina que simplemente copia los datos de la sección empaquetada al buffer que hemos creado con VirtualAlloc. Una rutina, eso sí, seguida por un motón de 0C3h (retn).
    00406D16 8BC1           mov eax,ecx
    00406D18 C1F9 02        sar ecx,2
    00406D1B F3:A5          rep movs dword ptr es:[edi],dword ptr ds:[esi]
    00406D1D 03C8           add ecx,eax
    00406D1F 83E1 03        and ecx,3
    00406D22 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[esi]
    00406D24 C3             retn
Finalmente, después de llamar a la rutina 406d16 que desencripta con el plugin (si existe), y copia la sección en el buffer, se llama a la rutina que tiene el algoritmo de descompresión. Esta rutina, recordemos, devuelve eax a 0 si hay algún error, y si no hay error devuelve en eax la longitud en bytes de lo que se ha descomprimido. Si por alguna extraña circunstancia se produce un error al descomprimir los datos de las secciones, se llama a una rutina que apenas comentaré, pues con los comentarios que añade el propio OllyDbg creo que queda muy claro qué es lo que hace.
    0040629A 8D9D 97A54000  lea ebx,dword ptr ss:[ebp+40A597] ; EBX='USER32.DLL'
    004062A0 53             push ebx
    004062A1 FF95 15A64000  call dword ptr ss:[ebp+40A615] ; LoadLibraryA
    004062A7 8D9D A2A54000  lea ebx,dword ptr ss:[ebp+40A5A2] ; MessageBoxA
    004062AD 53             push ebx
    004062AE 50             push eax
    004062AF FF95 19A64000  call dword ptr ss:[ebp+40A619] ; GetProcAddress
    004062B5 8D9D B8A54000  lea ebx,dword ptr ss:[ebp+40A5B8] ; 'This executable is corrupt![...]'
    004062BB 8D8D EEA54000  lea ecx,dword ptr ss:[ebp+40A5EE] ; 'Authentification Check Failure'
    004062C1 6A 10          push 10
    004062C3 51             push ecx
    004062C4 53             push ebx
    004062C5 6A 00          push 0
    004062C7 FFD0           call eax ; MessageBoxA
    004062C9 FFA5 25A64000  jmp dword ptr ss:[ebp+40A625] ; ExitProcess
Y una vez acabado el bucle, saltaría a 40625E, donde se lee una nueva RVA de pecRVA_list, y si no es 0 volvería a ejecutar el bucle. Cuando encuentra una RVA que es 0, interpreta que es el final de la lista, y continua en 4062D0. En la dirección 4062D0 nos encontramos una rutina muy similar a la que acabamos de ver. Una de las opciones al empaquetar un fichero con el PeCompact es unir varias secciones en una sola. De este modo podemos reducir el tamaño de alineamiento del fichero original, y lo que hace el unpacker en esta rutina que vamos a analizar ahora es exactamente eso, reordenar las secciones que han sido empaquetadas juntas en cada sección. En 4062D0 encontramos el siguiente bloque de código:
    004062D0 58             pop eax
    004062D1 8DB5 C3A64000  lea esi,dword ptr ss:[ebp+40A6C3]
    004062D7 AD             lods dword ptr ds:[esi]
    004062D8 0BC0           or eax,eax
    004062DA 74 74          je short FAST_APL.00406350
    004062DC 0385 A6A04000  add eax,dword ptr ss:[ebp+40A0A6]
    004062E2 8BD8           mov ebx,eax
    004062E4 AD             lods dword ptr ds:[esi]
    004062E5 0385 A6A04000  add eax,dword ptr ss:[ebp+40A0A6]
    004062EB 8BD0           mov edx,eax
    004062ED AD             lods dword ptr ds:[esi]
    004062EE 8BC8           mov ecx,eax
    004062F0 57             push edi
    004062F1 56             push esi
    004062F2 8BF3           mov esi,ebx
    004062F4 57             push edi
    004062F5 51             push ecx
    004062F6 8BC1           mov eax,ecx
    004062F8 C1F9 02        sar ecx,2
    004062FB F3:A5          rep movs dword ptr es:[edi],dword ptr ds:[esi]
    004062FD 03C8           add ecx,eax
    004062FF 83E1 03        and ecx,3
    00406302 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[esi]
    00406304 59             pop ecx
    00406305 5E             pop esi
    00406306 8BFA           mov edi,edx
    00406308 8BC1           mov eax,ecx
    0040630A C1F9 02        sar ecx,2
    0040630D F3:A5          rep movs dword ptr es:[edi],dword ptr ds:[esi]
    0040630F 03C8           add ecx,eax
    00406311 83E1 03        and ecx,3
    00406314 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[esi]
    00406316 5E             pop esi
    00406317 AD             lods dword ptr ds:[esi]
    00406318 8BC8           mov ecx,eax
    0040631A 8BD0           mov edx,eax
    0040631C 33C0           xor eax,eax
    0040631E C1F9 02        sar ecx,2
    00406321 F3:AB          rep stos dword ptr es:[edi]
    00406323 03CA           add ecx,edx
    00406325 83E1 03        and ecx,3
    00406328 F3:AA          rep stos byte ptr es:[edi]
    0040632A 8B7E F0        mov edi,dword ptr ds:[esi-10]
    0040632D 03BD A6A04000  add edi,dword ptr ss:[ebp+40A0A6]
    00406333 8B4E F4        mov ecx,dword ptr ds:[esi-C]
    00406336 038D A6A04000  add ecx,dword ptr ss:[ebp+40A0A6]
    0040633C 2BCF           sub ecx,edi
    0040633E 8BD1           mov edx,ecx
    00406340 C1F9 02        sar ecx,2
    00406343 F3:AB          rep stos dword ptr es:[edi]
    00406345 03CA           add ecx,edx
    00406347 83E1 03        and ecx,3
    0040634A F3:AA          rep stos byte ptr es:[edi]
    0040634C 5F             pop edi
    0040634D EB 88          jmp short FAST_APL.004062D7
Prácticamente todo el bloque es un bucle, concretamente desde 4062D7 hasta 40634D es el bucle que va reorganizando cada sección que se ha descomprimido. El modo de hacerlo es sencillo. Al entrar en 4062D0 en la pila ha quedado como último dato la dirección donde está el buffer que hemos alojado en memoria previamente. Y en 4062D1, con posiciona esi sobre una tabla de dwords que contiene los datos para reorganizar todas las secciones (a esta tabla la llamaremos mergedObjects_list). En esta lista se encuentran 4 dwords por cada sección que se ha mezclado en cada sección. Explicaré esto un poco más detalladamente. Lo que hace el PeCompact es coger las secciones originales, y quitándolas la alineación propia de fichero, colocarlas secuencialmente, empaquetarlas, y guardar esa información en una sola sección. El problema es que para reorganizar eso de nuevo necesita saber, en qué posición y qué longitud tiene cada sección una vez desempaquetada esa sección, y qué RVA (y su alineamiento) le corresponde a cada sección de las que ha mezclado en esa sección. Todos esos valores los guarda en la tabla mergedObjects_list. En 4062D7, carga un dword de la tabla mergedObjects_list, y si es 0, sale del bucle saltando a 406350. Si no es 0, a ese valor le suma la ImageBase., metiendo su valor en ebx. Lee un nuevo dword de la tabla, al cual le suma la ImageBase también y mete ese valor en edx. Si a esos valores les suma la ImageBase podemos suponer ya que son RVA's (Relative Virtual Addresses). En 4062ED carga de la mergedObjects_list un nuevo dword, cuyo valor lo guarda en ecx. En la zona de 4062F0 a 406305 lo que hace es copiar memoria al buffer. Pero ¿qué es lo que copia? Bien sencillo. Hemos dicho que el PeCompact mezclaba las secciones secuencialmente en una sola sección. Pues bien, lo que hace es copiar en el buffer una de esas secciones que está mezcla en la sección ya desempaquetada. Para ello ha tomado varios valores de megedObjects_list, concretamente ha tomado un RVA que indica dentro de la sección ya desempaquetada dónde empieza la sección; el siguiente dato que ha leído de mergedObjects_list ha sido el VirtualRVA real que le correspondía a esa sección, para realojarla en memoria; y el siguiente dato que ha leído de mergedObject_list es la longitud en bytes que ocupa la sección desempaquetada (tamaño que no se corresponde al PhysicalSize de la sección original, pues aquí quita ceros finales, y otras cosas que son innecesarias). En 406317 se lee otro dword de mergedObjects_list, que es usado como longitud en bytes a rellenar con ceros (0h), después de realojar la sección en su VirtualRVA original. Si nos fijamos todo este proceso se podría hacer sin usar el buffer como intermediario en los movimientos de memoria, pero se hace para que no se solape en ningún momento la sección que tiene todas las secciones mezcladas, con cada una de las secciones que se va colocando. Finalmente, desde 40632A hasta 40634C lo que se hace es poner a 0 la sección mezclada. Para que en ningún momento haya solapamiento, ni se sobrescriba ninguna sección el unpacker las va realojando empezando por la sección cuyo RVA es más alto (está más abajo en la memoria). (figura 6). Fig. 6. En este diagrama se muestran los significados de cada valor tomado de la tabla mergedObjects_list. En la lista se guardan en el siguiente orden: RVAMerged, RVAOriginal, Longitud, Alineo. Hay que tener en cuenta que cada sección (sección1, sección2 y sección3) necesitarían tomar estos datos de la tabla. Según lo que acabamos de ver daría la sensación que una vez realojadas todas las secciones en sus RVA originales podríamos volcar el proceso que está en memoria ya directamente sobre un fichero, pues una de las secciones que se han desempaquetado ha sido la que contiene la tabla de importaciones. Sin embargo esto no es del todo correcto, pues una de las cosas que hace el PeCompact antes de empaquetar el código, es modificar los argumentos de los opcodes que son de tipo call y jmp. Por tanto, una vez desempaquetadas las secciones debe rastrear el código, para restablecer los argumentos de esos opcodes. Eso es precisamente lo que hace a partir de 406350. Otra de las cosas que está pendiente por hacer, es rellenar la IAT (ImportAddressTable), ya que esto normalmente lo hace el loader de Windows, y en esta ocasión el loader sólo ha llenado la IAT del unpacker, pero no de la Tabla de Importaciones que estaba empaquetada, y que era la original del fichero. Analicemos, pues, lo que hace a partir de 406350:
    00406350 57             push edi
    00406351 8BBD D7A44000  mov edi,dword ptr ss:[ebp+40A4D7]
    00406357 03BD A6A04000  add edi,dword ptr ss:[ebp+40A0A6]
    0040635D 8B8D DBA44000  mov ecx,dword ptr ss:[ebp+40A4DB]
    00406363 33D2           xor edx,edx
    00406365 33DB           xor ebx,ebx
    00406367 33F6           xor esi,esi
    00406369 03FE           add edi,esi
    0040636B 03DE           add ebx,esi
    0040636D 49             dec ecx
    0040636E 74 72          je short FAST_APL.004063E2
    00406370 78 70          js short FAST_APL.004063E2
    00406372 66:8B07        mov ax,word ptr ds:[edi]
    00406375 2C E8          sub al,E8
    00406377 3C 01          cmp al,1
    00406379 76 38          jbe short FAST_APL.004063B3
    0040637B 66:3D 1725     cmp ax,2517
    0040637F 74 51          je short FAST_APL.004063D2
    00406381 3C 27          cmp al,27
    00406383 75 0A          jnz short FAST_APL.0040638F
    00406385 80FC 80        cmp ah,80
    00406388 72 05          jb short FAST_APL.0040638F
    0040638A 80FC 8F        cmp ah,8F
    0040638D 76 05          jbe short FAST_APL.00406394
    0040638F 47             inc edi
    00406390 43             inc ebx
    00406391 EB DA          jmp short FAST_APL.0040636D
    00406393 B8 8B470290    mov eax,9002478B ;Código ofuscado
    00406398 90             nop ; Realmente es :
    00406399 90             nop ; db B8
    0040639A 90             nop ; mov eax,dword ptr ds:[edi+2]
    0040639B 90             nop ; Fijarse bien en la linea que lo invoca
    0040639C 90             nop ; desde 40638D
    0040639D 90             nop
    0040639E 90             nop
    0040639F 90             nop
    004063A0 90             nop
    004063A1 90             nop
    004063A2 90             nop
    004063A3 90             nop
    004063A4 2BC3           sub eax,ebx
    004063A6 8947 02        mov dword ptr ds:[edi+2],eax
    004063A9 BE 06000000    mov esi,6
    004063AE 83E9 05        sub ecx,5
    004063B1 EB B6          jmp short FAST_APL.00406369
    004063B3 8B47 01        mov eax,dword ptr ds:[edi+1]
    004063B6 3C 01          cmp al,1
    004063B8 75 D5          jnz short FAST_APL.0040638F
    004063BA 66:C1E8 08     shr ax,8
    004063BE C1C0 10        rol eax,10
    004063C1 86C4           xchg ah,al
    004063C3 2BC3           sub eax,ebx
    004063C5 8947 01        mov dword ptr ds:[edi+1],eax
    004063C8 BE 05000000    mov esi,5
    004063CD 83E9 04        sub ecx,4
    004063D0 EB 97          jmp short FAST_APL.00406369
    004063D2 0157 02        add dword ptr ds:[edi+2],edx
    004063D5 BE 06000000    mov esi,6
    004063DA 83EA 04        sub edx,4
    004063DD 2BCE           sub ecx,esi
    004063DF 41             inc ecx
    004063E0 EB 87          jmp short FAST_APL.00406369
    004063E2 5F             pop edi
    004063E3 E8 8D010000    call FAST_APL.00406575
    004063E8 68 00400000    push 4000
    004063ED 6A 00          push 0
    004063EF 57             push edi
    004063F0 FF95 21A64000  call dword ptr ss:[ebp+40A621]
    004063F6 E8 97000000    call FAST_APL.00406492
    004063FB 73 79          jnb short FAST_APL.00406476
    004063FD 8D9D 97A54000  lea ebx,dword ptr ss:[ebp+40A597] ; USER32.DLL
    00406403 53             push ebx
    00406404 FF95 15A64000  call dword ptr ss:[ebp+40A615] ; LoadLibraryA
    0040640A 8985 D7A44000  mov dword ptr ss:[ebp+40A4D7],eax
    00406410 8D9D AEA54000  lea ebx,dword ptr ss:[ebp+40A5AE] ; wsprintfA
    00406416 53             push ebx
    00406417 50             push eax
    00406418 FF95 19A64000  call dword ptr ss:[ebp+40A619] ; GetProcAddress
    0040641E 8D9D C3A74000  lea ebx,dword ptr ss:[ebp+40A7C3]
    00406424 53             push ebx
    00406425 83BDE7A4400001 cmp dword ptr ss:[ebp+40A4E7],1 ; Es nombre u ordinal?
    0040642C 74 08          je short FAST_APL.00406436
    0040642E 8D8D 45A54000  lea ecx,dword ptr ss:[ebp+40A545] ; 'Procedure couldn't be found'
    00406434 EB 06          jmp short FAST_APL.0040643C
    00406436 8D8D 01A54000  lea ecx,dword ptr ss:[ebp+40A501] ; 'Ordinal couldn't be located'
    0040643C 8B95 DFA44000  mov edx,dword ptr ss:[ebp+40A4DF] ; Funcion del error
    00406442 8BBD E3A44000  mov edi,dword ptr ss:[ebp+40A4E3] ; Modulo del error
    00406448 57             push edi
    00406449 52             push edx
    0040644A 51             push ecx
    0040644B 53             push ebx
    0040644C FFD0           call eax ; wsprintfA
    0040644E 8D9D A2A54000  lea ebx,dword ptr ss:[ebp+40A5A2] ; MessageBoxA
    00406454 53             push ebx
    00406455 FFB5 D7A44000  push dword ptr ss:[ebp+40A4D7]
    0040645B FF95 19A64000  call dword ptr ss:[ebp+40A619] ; GetProcAddess
    00406461 5B             pop ebx
    00406462 8D8D EBA44000  lea ecx,dword ptr ss:[ebp+40A4EB] ; 'Entry point not found'
    00406468 6A 10          push 10
    0040646A 51             push ecx
    0040646B 53             push ebx
    0040646C 6A 00          push 0
    0040646E FFD0           call eax ; MessageBoxA
    00406470 FFA5 25A64000  jmp dword ptr ss:[ebp+40A625] ; ExitProcess
    00406476 8BB5 15A64000  mov esi,dword ptr ss:[ebp+40A615]
    0040647C 8BBD 19A64000  mov edi,dword ptr ss:[ebp+40A619]
    00406482 E8 8F0C0000    call FAST_APL.00407116
    00406487 61             popad
    00406488 9D             popfd
    00406489 50             push eax
    0040648A 68 00104000    push FAST_APL.00401000
    0040648F C2 0400        retn 4
En primer lugar esta rutina carga en el registro edi la RVA y la longitud la sección que antes de ser empaquetada fue semiencriptada, modificando los argumentos de los opcodes call y jmp. Debido a que toma el valor de la RVA, debe añadirla la ImageBase. La longitud del código lo almacena en el registro ecx, que usará como contador. A partir de este momento se entra en un bucle que sólo sale cuando ecx es menor o igual a 0. Dentro del bucle hay que observar que edi es usado como puntero que apunta al código que se tiene que examinar, esi se usa como un offset para resituar más rápidamente el puntero. Los registros ebx y edx se usan para cálculos de posiciones relativas, y con ellos se van a ir modificando los argumentos de los opcodes call y jmp. Concretamente el registro ebx lleva la posición relativa que se está leyendo. El registro eax se usa para cargar ahí el código que se examina, word a word. En 406372 se carga en eax secuencialmente cada uno de los word. Y a partir de este momento se chequea si ese word contiene alguno de los opcodes que nos interesa modificar. De 406375 a 406379 se mira si el opcode es E8h o E9h, es decir call o jmp long. Si es uno de estos dos se salta a 4063B3, donde invierte el orden del argumento (dirección), y le resta la posición relativa actual. En 40637B comprueba si el opcode es 2517h+E8h= 25FFh (= jmp dword ptr[NN]). Lo que hace en este caso es saltar a 4063D2 donde le suma al argumento (NN) el valor del registro ebx, este registro se inicializa a 0, y cada vez que es usado se le resta 4. Por tanto la primera vez que ocurre encuentra este opcode su argumento permanece inalterado, pero la siguiente vez se le resta 4, la siguiente 8, la siguiente 0Ch, etc... Este opcode aparece casi de modo exclusivo para indexar los valores de la IAT. De 406381 a 40638D se comprueba si el opcode es un salto relativo, verificando para ello que el opcode sea de tipo 0F80h .. 0F8Fh, los cuales corresponden a: jo, jno, jb, jnb, je, jne, jbe, ja, js, jns, jpe, jpo, jl, jge, jle, jg (todos ellos de tipo long). Al ser de dipo long, el argumento es una dirección realtiva de 32bits, igual que con call y con jmp, aunque en esta ocasión los argumentos no están invertidos, y por ello lo único que hace es restarles el valor de ebx. Una vez rastrea todo el código lo último que le queda por hacer es construir la tabla de la IAT, tarea que normalmente hace el loader. Sin embargo, al salir de este último bloque, en 4063E2 y 404063E3 hace un call. Uno de los plugins que vimos al inicio que tenía como opción el PeCompact era el pre-operative, pero también tiene uno post-operative. Precisamente es este call el encargado de llamar al plugin post-operative. Si no hay ningún plugin post-operative el call salta a una zona que está rellenada con 0C3h (retn). Inmediatamente, al retornar del call llama a en 4063F0 a VitualFree, liberando el buffer de memoria que fue creado anteriormente. El siguiente call que aparece llama a una rutina que se encuentra en 406492. Esta rutina es la encargada de rellenar la IAT. Antes de entrar en su análisis adelantar solamente que la rutina devuelve el flag carry a 1 si hubo algún error al cargar la IAT, y si no hay ningún error vuelve con el flag carry a 0. Si hay algún error en la construcción de la IAT se ejecuta todo el código comprendido entre 4063FD y 406470, que sencillamente muestra un MessageBoxA con el módulo y la función API donde se ha producido el error (normalmente se debe a que no se puede encontrar esa función en ese módulo), llamando finalmente a ExitProcess (ver los comentarios del código añadidos por OllyDbg para clarificar la rutina). Si no ha habido ningún error al cargar la IAT nuevamente se llama a una rutina de carga de pulgins, situando previamente en esi y en edi LoadLibraryA y GetProcAddress. Finalmente, recupera todos los registros mediante popad y popfd. En 406489 mete en la pila el valor de eax pasado por el loader (normalmente es el EntryPoint), y el OEP (que ha sido modificado anteriormente), para salta finalmente a ese OEP mediante el retn 4. Realmente el meter eax en la pila no sirve de nada, pues el retn 4 lo saca al saltar al OEP. Analicemos ahora la rutina que construye la IAT. Antes de analizar qué hace esta rutina deberíamos entender qué es y como funciona la Import Table. Muy por encima decir que hay 2 tipos de tablas para las importaciones. Una tabla que la Import Table Address (Tabla de direcciones de importaciones), y la Import Table como tal (Tabla de Importaciones). En la segunda hay información sobre qué módulos necesita el fichero exe, y qué funciones de esos módulos utiliza el fichero exe. La primera tabla (IAT) inicialmente en el fichero está vacía, ya que es rellenada/construida por el loader del sistema. La estructura de la Import Table es muy sencilla, ya que consta de 20 bytes por cada módulo que importa, añadiendo como marcador de final otros 20 bytes puestos a 0. Aunque en winnt.h existen multitud de estructuras definidas que hacen referencia a la Import, no hay ninguna que defina esta estructura. Los nombres y la definición lo he tomado de un documento de Johannes Plachy, por parecerme bastante clarificador.
    Typedef struct tagImportDirectory
    {
         DWORD dwRVAFunctionNameList;
         DWORD dwUseless1;
         DWORD dwUseless2;
         DWORD dwRVAModuleName;
         DWORD dwRVAFunctionAddressList;
    }
Este tag/estructura, se repite consecutivamente por cada uno de los módulos que el fichero exe necesite. Es esta estructura la que marca el tamaño de la Import. Es decir, si hay 4 módulos a importar, corresponderían 20 bytes de estructura a cada módulo, 20 * 4 = 80 bytes, a esto habría que sumarle una estructura de 20 bytes puestos a 0 (que es la que marca el final), y por tanto sería 80 + 20 = 100 bytes. Por tanto el tamaño de Import para ese fichero sería de 100 bytes (64h). dwRVAModuleName es la RVA que apunta al nombre del módulo que se debe cargar (el nombre del DLL). El primer valor que aparece en la estructura es la RVA que apunta a una lista de RVAs que a su vez apuntan a los nombres de las funciones que tiene que importar de este módulo. En este punto hay que tener cuidado, pues mientras que dwRVAModuleName apunta directamente al primer carácter del nombre del módulo, los RVAs de los nombres de las funciones que hay en la lista no apuntan al primer carácter, sino a 2 caracteres antes. Finalmente, dwRVAFunctionAddressList apunta a la zona de la IAT donde se deben poner las direcciones reales que le corresponden a cada función (figura 7). Pues bien, esta tarea, que normalmente la hace el loader del sistema, es la que hace ahora la rutina que vamos a analizar. Fig. 7. Esquema de la estructura que forma la ImportTable. Obviamente cada módulo asigna una zona distinta dentro de la ImportAddressTable. La rutina que tiene que hacer todo este trabajo en el unpacker del PeCompact hemos visto que es llamada en último lugar, y que empieza en 406492. Veamos su aspecto...
    00406492 8BB5 37A64000      mov esi,dword ptr ss:[ebp+40A637]
    00406498 0BF6               or esi,esi
    0040649A 74 18              je short FAST_APL.004064B4
    0040649C 8B95 A6A04000      mov edx,dword ptr ss:[ebp+40A0A6]
    004064A2 03F2               add esi,edx
    004064A4 E8 0F000000        call FAST_APL.004064B8
    004064A9 72 0B              jb short FAST_APL.004064B6
    004064AB 83C6 14            add esi,14
    004064AE 837E 0C 00         cmp dword ptr ds:[esi+C],0
    004064B2 75 F0              jnz short FAST_APL.004064A4
    004064B4 F8                 clc
    004064B5 C3                 retn
    004064B6 F9                 stc
    004064B7 C3                 retn
    004064B8 C785 0DA64000 000> mov dword ptr ss:[ebp+40A60D],0
    004064C2 8B0E               mov ecx,dword ptr ds:[esi]
    004064C4 8B7E 10            mov edi,dword ptr ds:[esi+10]
    004064C7 0BC9               or ecx,ecx
    004064C9 75 02              jnz short FAST_APL.004064CD
    004064CB 8BCF               mov ecx,edi
    004064CD 03CA               add ecx,edx
    004064CF 03FA               add edi,edx
    004064D1 8B46 0C            mov eax,dword ptr ds:[esi+C]
    004064D4 0BC0               or eax,eax
    004064D6 0F84 95000000      je FAST_APL.00406571
    004064DC 03C2               add eax,edx
    004064DE 51                 push ecx
    004064DF 52                 push edx
    004064E0 8985 E3A44000      mov dword ptr ss:[ebp+40A4E3],eax
    004064E6 50                 push eax
    004064E7 FF95 29A64000      call dword ptr ss:[ebp+40A629]
    004064ED 5A                 pop edx
    004064EE 59                 pop ecx
    004064EF 0BC0               or eax,eax
    004064F1 0F84 7C000000      je FAST_APL.00406573
    004064F7 8985 33A64000      mov dword ptr ss:[ebp+40A633],eax
    004064FD 8B19               mov ebx,dword ptr ds:[ecx]
    004064FF 83C1 04            add ecx,4
    00406502 0BDB               or ebx,ebx
    00406504 74 6B              je short FAST_APL.00406571
    00406506 8BC3               mov eax,ebx
    00406508 F7C3 00000080      test ebx,80000000
    0040650E 74 18              je short FAST_APL.00406528
    00406510 81E3 FFFF0000      and ebx,FFFF
    00406516 C785 E7A44000 010> mov dword ptr ss:[ebp+40A4E7],1
    00406520 899D DFA44000      mov dword ptr ss:[ebp+40A4DF],ebx
    00406526 EB 14              jmp short FAST_APL.0040653C
    00406528 C785 E7A44000 000> mov dword ptr ss:[ebp+40A4E7],0
    00406532 03DA               add ebx,edx
    00406534 43                 inc ebx
    00406535 43                 inc ebx
    00406536 899D DFA44000      mov dword ptr ss:[ebp+40A4DF],ebx
    0040653C 51                 push ecx
    0040653D 52                 push edx
    0040653E 80BD C3A74000 C3   cmp byte ptr ss:[ebp+40A7C3],C3
    00406545 74 14              je short FAST_APL.0040655B
    00406547 53                 push ebx
    00406548 FFB5 33A64000      push dword ptr ss:[ebp+40A633]
    0040654E FFB5 19A64000      push dword ptr ss:[ebp+40A619]
    00406554 E8 BD030000        call FAST_APL.00406916
    00406559 EB 0D              jmp short FAST_APL.00406568
    0040655B 53                 push ebx
    0040655C FFB5 33A64000      push dword ptr ss:[ebp+40A633]
    00406562 FF95 19A64000      call dword ptr ss:[ebp+40A619]
    00406568 5A                 pop edx
    00406569 59                 pop ecx
    0040656A 0BC0               or eax,eax
    0040656C 74 05              je short FAST_APL.00406573
    0040656E AB                 stos dword ptr es:[edi]
    0040656F EB 8C              jmp short FAST_APL.004064FD
    00406571 F8                 clc
    00406572 C3                 retn
    00406573 F9                 stc
    00406574 C3                 retn
Aunque parece una rutina larga, se trata de una pequeña rutina que un par de bucles, que se encargan de ir cargando los módulos en memoria con LoadLibraryA, y posterior ir rastreando la lista de funciones y cargándolas en la IAT mediante GetProcAddess. Bueno, veamos por partes cómo lo hace. En primer lugar lo que hace es usar esi como un puntero apuntando a la tabla de importaciones. El valor RVA de la Import Table lo toma en 406492, y es un valor que nos va a ser tremendamente útil a la hora de reconstruir el fichero que obtengamos al volcar la memoria. Una vez toma la dirección de la Import Table, inicia un bucle pequeño que comprende de 4064A4 a 4064B7. En este bucle lo que hace es ir cogiendo del inicio de la Import Table los tags/estructuras, terminando el bucle cuando alguna de ellas tenga dwRVAModuleName (esi+0C) a 0. El el bucle se llama a la subrutina 4064B8, que ahora veremos qué hace. Solo saber que esa subrutina devuelve el flag carry puesto a 1 si ha habido un error. La subrutina 4064B8 es la que se tiene que encargar de leer dwRVAModuleName, dwRVAFunctionNameList e ir cargando las funciones en dwRVAFunctionAddressList .Veamos cómo lo hace. En 4064C2 y 4064CB hace que ecx sea dwRVAFunctionNameList, y que edi sea igual a dwRVAFunctionAddressList. Si por cualquier causa dwRVAFunctionNameList es 0, hace que ecx sea igual a dwRVAFunctionAddressList. A continuación a ambos valores les suma la ImageBase, para calcular su dirección real. Lo siguiente es cargar el dwRVAModuleName en el registro eax. Si por cualquier causa extraña este valor fuera 0, salta a 406571 poniendo el flag carry a 0, es decir, no hay error (este chequeo no tiene mucho sentido, pues este chequeo se hace en el bucle principal que lee las estructuras). A este RVA también le suma la ImageBase que está en edx, para obtener la dirección real. Debido a que el unpacker si hay un error debe mostrar información, debe guardar qué módulo se está tratando en cada momento. Eso lo hace guardando ciertos valores en una zona de memoria. En 4064F7, por ejemplo, guarda el registro eax (que en ese momento está apuntando al nombre del módulo), de tal modo que si después se produce un error, se tomará información de ese valor guardado (ver código de las direcciones 406436 a 40644C anteriormente explicado). Después mediante GetModuleHandleA toma el valor de esa librería, si existe algún problema con esta API deja eax a 0, saltando a 406573, donde pone el flag carry a 1 (error). Una vez hecho esto se inicia un nuevo bucle que va rastreando los RVA que hay en dwRVAFunctionNameList+ImageBase. En el momento que encuentra un RVA que sea 0 interpreta que la lista de RVAs a los nombres de funciones ha terminado. Con cada RVA calcula la dirección real del nombre de la API, para obtener su dirección y ponerla en la IAT.
    004064FD 8B19      mov ebx,dword ptr ds:[ecx]
    004064FF 83C1 04   add ecx,4
    00406502 0BDB      or ebx,ebx
    00406504 74 6B     je short FAST_APL.00406571
Enebx mete la RVA de la lista de RVAs que apuntan a los nombres de funciones, posiciona ecx al próximo RVA de la lista, y si el RVA leído es 0, salta a 406571, donde pone el flag carry a 0 (no error). Lo siguiente que se hace con el RVA leído de la lista chequear si el bit 31 está a 1 o a 0.
    00406508 F7C3 00000080   test ebx,80000000
    0040650E 74 18           je short FAST_APL.00406528
Si el bit 31 está a 0 se interpreta que es un Import por nombre, y si el bit 31 está a 1 se entiende que el Import se hace por ordinales. Si es por ordinales mete un 1 en[ebp+40A4E7], y si es por nombres, mete un 0. Esta variable se usa en caso de error, para mostrar el mensaje de error (error en la función %s, o erro en el ordinal %d). Si la importación se hace por ordinales mete el valor del ordinal (limitado a FFFFh) en ebp+40A4DF, que es la variable usada también para imprimir la cadena de error si lo hubiere. Si es por nombre, salta a la dirección 406528, donde calcula la dirección real sumando al RVA la ImageBase. A continuación mediante dos inc ebx posiciona el puntero en el primer carácter del nombre de la función (hay que recordar que la tabla de RVA apuntando a los nombres de las funciones no apuntan realmente al primer carácter, sino 2 bytes antes). Una vez posiciona bien el puntero lo guarda en [ebp+40A4DF] (esto es para poder mostrar el mensaje de error si se diera el caso).
    00406510 81E3 FFFF0000      and ebx,FFFF ;ordinales limitados a 0FFFFh
    00406516 C785 E7A44000 010> mov dword ptr ss:[ebp+40A4E7],1 ;importaciones por ordinales
    00406520 899D DFA44000      mov dword ptr ss:[ebp+40A4DF],ebx ;ordinal actual que se está tratando
    00406526 EB 14              jmp short FAST_APL.0040653C
    00406528 C785 E7A44000 000> mov dword ptr ss:[ebp+40A4E7],0 ;importaciones por nombre de función
    00406532 03DA               add ebx,edx
    00406534 43                 inc ebx
    00406535 43                 inc ebx ;posiciona el puntero en el primer char
    00406536 899D DFA44000      mov dword ptr ss:[ebp+40A4DF],ebx
Antes de cargar la dirección real de la función API con GetProcAddess, debemos fijarnos que uno de los plugins del PeCompact es el GPA, es decir, un hook para el GetProcAddess. Eso es precisamente lo que se hace en la zona comprendida desde 40653E hasta 406559.
    0040653E 80BD C3A74000 C3  cmp byte ptr ss:[ebp+40A7C3],C3
    00406545 74 14             je short FAST_APL.0040655B
    00406547 53                push ebx
    00406548 FFB5 33A64000     push dword ptr ss:[ebp+40A633]
    0040654E FFB5 19A64000     push dword ptr ss:[ebp+40A619]
    00406554 E8 BD030000       call FAST_APL.00406916
    00406559 EB 0D             jmp short FAST_APL.00406568
En este pequeño bloque lo que se hace es chequear si existe el plugin instalado (mira si la primera instrucción de la rutina del plugin es 0C3h (retn). Si no es retn el primer opcode de esa rutina mete 3 datos en la pila, y salta a la rutina del plugin, que se encuentra en 406916. Los 3 datos que mete en la pila antes de llamar al plugin son: Handle, Handle del móudlo, y ebx (que contiene el ordinal o el puntero al nombre de la función a cargar). Al volver del plugin con el jmp 406568 salta el siguiente bloque, que es la rutina normal de GetProcAddess. La rutina normal de GetProcAddess es la siguiente:
    0040655B 53              push ebx
    0040655C FFB5 33A64000   push dword ptr ss:[ebp+40A633]
    00406562 FF95 19A64000   call dword ptr ss:[ebp+40A619]
Consiste tan solo en dospush, que meten en la pila los argumentos para llamar después a la API GetProcAddess. Los argumentos que mete en la pila son el handle del módulo, y el puntero al nombre de la función (u ordinal de la función). Finalmente la rutina chequea el valor devuelto por el plugin o por GetProcAddess en eax. Si eax ha vuelto con un valor igual a 0 significa que se ha producido un error al cargar esa función, saliendo de todo el bucle y poniendo el flag de carry a 1 (stc). Si no ha habido error eax contiene la dirección de la API, la cual mediante stos dword ptr es:[edi] es guardada en la posición que le corresponde de la IAT. Y esto sería lo que hace todo el bucle que reconstruye la IAT.
CONCLUSIONES
Bien, quizás esta sea la parte que muchos pensabais que iba a hacer al principio. Explicar rápidamente cómo se hace un dump de un fichero comprimido con este packer, y como reconstruirlo para que sea operativo. Para reconstruirlo lo ideal sería poder hacer un volcado una vez haya desempaquetado toda la sección con la Tabla de Importaciones, pero antes de que genere los datos con la IAT. Sin embargo sí que deberíamos tener la información de dónde ha desempacado la Tabla de Importaciones. La idea es bien sencilla. Si nos fijamos bien, todas las secciones se encuentran desempaquetadas al llegar al call que genera la IAT. En mi ejemplo ese call está en 4063F6. Se trata de un call que es fácilmente localizable, pues justo después tiene un salto condicional si no hay carry (jnc/jnb). El salto va inmediatamente a la rutina que llama al plugin post-operative, y al salto que nos lleva al OEP. La idea para el dump sería detener el packer justo en ese call a la rutina que genera la IAT, y no ejecutar la llamada a esa rutina (podemos nopear el call). Lo que sí debemos ejecutar antes de hacer el volcado es el call a la rutina del plugin post-operative. Por tanto deberíamos hacer el dump del proceso cuando estemos situados sobre el popad. Antes de hacer el volcado debemos mirar el dword que hay en la dirección ebp+40A637. De esa dirección es donde lee la rutina que genera la IAT la RVA de la Tabla de Importaciones. Es decir, de esa dirección obtenemos la RVA de la Tabla de Importaciones. Para calcular su longitud es sencillo. Y podemos hacerlo antes de dumpear el proceso. Bien, pues apuntamos esa RVA, y sobre el popad podemos parchear el famoso jmp eip. Los que uséis el OllyDbg tenéis la ventaja que podéis volcar sin necesidad de parchear ;o). Y una vez volcado tendremos que editar la cabecera PE. En la parte de “Data Directory” de la cabecera PE debéis editar la variable “Import”, poniendo ahí la RVA que habéis obtenido leyendo el dword de ebp+40A637. Para calcular la longitud de la Import es sencillo. Debeis mirar los datos que corresponden a la Import. Una vez vistos, hay que ir mirándolos de 20 en 20 bytes. Y cuando encontréis un bloque de 20 bytes que sean todos 0, ese es el final del Import. La longitud también debe contar esos 20 bytes a 0. Por tanto la longitud mínima de una Import es de 20 bytes (todos a 0). Para calcular la longitud de la Import podéis volver a leer la parte de este tutorial donde he explicado la estructura de la Tabla de Importaciones.
PARA LOS ERUDITOS: EL ALGORITMO DE DESCOMPRESIÓN aPLiB
Cuando empecé a mirar los algoritmos que usaba el PeCompact en la compresión observé que había una pega principalmente: Jeremy Collake (el autor del packer) había usado 2 algoritmos distintos: el suyo propio (JCALG1), y otro algoritmo de Joergen Ibsen (aPLiB). El JCALG1 no es ningún problema, pues es un algoritmo abierto, del cual J. Collake ha publicado fuentes, pero la pega principal estaba en el aPLiB, pues J. Ibsen ha publicado una librería que es pública, para comprimir y descomprimir con su algoritmo, pero no hay fuentes (por tanto no es un algoritmo abierto). Así pues me puse manos a la obra, para desentrañar los misterios del algoritmo aPLiB. Primero deberíamos entender qué es lo que hace un empaquetador de datos. Cosa, que imagino todos sabemos, es que todos los algoritmos de compresión intentar quitar los datos que se van repitiendo, sustituyéndolos por un código de control que indica que es un dato repetido que ya se ha almacenado en otro lugar (ese dato de control debe ocupar menos que el propio dato). Esto, que en teoría es muy bonito, en la práctica es una lucha constante por encontrar un algoritmo que ocupe poco, que consuma pocos recursos en memoria, que no tenga procesos muy reiterativos, y encima que tenga un buen ratio de compresión. El modo en que esto se hace en el aPLiB es sencilla. Podemos decir que hay unos datos que los consideraremos como datos propiamente, y otros que son datos de control. El packer lo que hace es ir intercalando esos datos de control entre los datos propiamente... Ahora veremos como funciona el algoritmo de descompresión, y lo entenderemos mucho mejor. He de advertir que prácticamente todo el código ASM del algoritmo consiste en comprobaciones de flags, y de rotaciones. A decir verdad cuando vi el código desensamblado fui yo el primer sorprendido... solo me vino un pensamiento: “¡¡¿¿esto es la rutina??!!” Bueno, pues veamos su aspecto:
    004090E2 C8 000000  enter 0,0
    004090E6 55         push ebp
    004090E7 8B75 08    mov esi,dword ptr ss:[ebp+8]
    004090EA 8B7D 0C    mov edi,dword ptr ss:[ebp+C]
    004090ED FC         cld
    004090EE B2 80      mov dl,80
Estas primeras líneas lo que hacen es inicializar los valores. En esi sitúa la dirección que contiene los datos empaquetados, y en edi la dirección donde se tienen que desempaquetar. Después limpia el flag de dirección, y mete 80h en dl (este dato es lo que va a usar como contador de 8 bits - 80h = 10000000b)
    004090F0 8A06       mov al,byte ptr ds:[esi]
    004090F2 46         inc esi
    004090F3 8807       mov byte ptr ds:[edi],al
    004090F5 47         inc edi
    004090F6 02D2       add dl,dl
    004090F8 75 05      jnz short FAST_APL.004090FF
El primer dato es copia desde esi a edi literalmente, es decir, el primer byte es interpretado como dato literal que se tiene que copiar. Después se actualiza el puntero edi para seguir descomprimiendo. La suma del registro dl consigo mismo es como si rotásemos ese registro de 8 bits a la izquierda. Hay que tener en cuenta que esta primera vez al sumar 10000000b con 10000000b se produce un resultado de 00000000b, poniendo el flag carry a 1.
    004090FA 8A16       mov dl,byte ptr ds:[esi]
    004090FC 46         inc esi
    004090FD 12D2       adc dl,dl
    004090FF 73 EF      jnb short FAST_APL.004090F0
Si al rotarse el registro dl se observa que su valor pasa a ser 0, se entiende que se ha leído un código completo de control. Los códigos de control son bytes, que después son interpretados bit a bit. Bien, analicemos esta operación. Inicialmente el registro dl vale 80h, pero al hacer una suma sobre sí mismo provoca que el carry pase a valer 1 (es lo que va a usar como marca de que ha leído 8 bits) y que el registro en sí pase a valer 0. En esta situación lo que hace el algoritmo es leer un byte del código empaquetado, interpretándolo como un código de control. A ese código de control le rota a la izquierda (con adc), de tal modo que el bit 7 de dl para a ser el carry actual, y el carry anterior es puesto en el bit 0. Ese carry anterior metido en el bit 0 es lo que se usará como marca para saber que se han leído los 8 bits que contiene el código de control cargado en dl. En este primer bloque, desde 4090F0 hasta 4090FF lo que se hace es leer un bit del código de control (de izquierda a derecha). Si ese bit es 0, interpreta que debe ser leído un byte como dato, y añadido a la cadena desempaquetada (si el bit es 0 se produce el salto de 4090FF). Por tanto, si tenemos 3 bytes que deben ser leídos y copiados de este modo, tenemos que realmente no ocuparían 24 bits (8 bits cada uno), sino que además hay que añadir un bit “0” a cada de uno, que es el que indica que deben ser copiados de este modo... es decir, que 24 bits serían interpretados con 27 bits. Este sería el caso más nefasto, es decir, que todos los bytes sean diferentes, y deban ser leídos como argumentos. El peor de los casos sería una secuencia a comprimir de 255 bytes (2040 bits), cuyos valores fueran (1,2,3,4...255). En ese caso cada byte se debería guardar como argumento literal, lo que implicaría que a cada byte se le añadiera el código de control “0”... dicha secuencia al “comprimirla” ocuparía los 2040bits, más 255 bits más de códigos de control. El byte 0 no lo he añadido a posta, ya que se codifica siempre con 7 bits. Hemos de tener en cuenta que la lectura de cada bit del código de control se hace pasando ese bit por el flag carry. Y por cada lectura de un bit hay que leer si es el último y está a 1 (la marca que hemos metido con 80h para marcar el final del código de control), ya que en este caso hay que leer un nuevo código de control. Cada vez que veamos un bloque similar a este...
    00409101 02D2       add dl,dl
    00409103 75 05      jnz short FAST_APL.0040910A
    00409105 8A16       mov dl,byte ptr ds:[esi]
    00409107 46         inc esi
    00409108 12D2       adc dl,dl
...podemos traducirlo como que se ha leído un nuevo bit del código de control, y se chequea por si es el último.
    0040910A 73 4A      jnb short FAST_APL.00409156
Hasta este punto se ha leído un nuevo bit (el previo leído es “1”), y ahora la comparación hace que si el segundo bit leído es “0” se salte a 409156... si el segundo bit leído es “1” se continúa la ejecución del programa.
    0040910C 33C0           xor eax,eax
    0040910E 02D2           add dl,dl
    00409110 75 05          jnz short FAST_APL.00409117
    00409112 8A16           mov dl,byte ptr ds:[esi]
    00409114 46             inc esi
    00409115 12D2           adc dl,dl
    00409117 0F83 E1000000  jnb FAST_APL.004091FE
Aquí se mira el valor del tercer bit leído. Si es 0 (leído en total “110” se salta a 4091FE), y si es 1 (leído “111”) se continúa la ejecución.
    0040911D 02D2           add dl,dl
    0040911F 75 05          jnz short FAST_APL.00409126
    00409121 8A16           mov dl,byte ptr ds:[esi]
    00409123 46             inc esi
    00409124 12D2           adc dl,dl
    00409126 13C0           adc eax,eax ;primer bit del argumento
    00409128 02D2           add dl,dl
A continuación se va a ejecutar este trozo de código 4 veces, para leer 4 bits consecutivos, y metiéndolos en eax. De este modo podemos decir que se ha leído “111” del código de control, y 4 bits más como argumento que se guarda en eax.
    0040912A 75 05          jnz short FAST_APL.00409131
    0040912C 8A16           mov dl,byte ptr ds:[esi]
    0040912E 46             inc esi
    0040912F 12D2           adc dl,dl
    00409131 13C0           adc eax,eax ;segundo bit del argumento
    00409133 02D2           add dl,dl
    00409135 75 05          jnz short FAST_APL.0040913C
    00409137 8A16           mov dl,byte ptr ds:[esi]
    00409139 46             inc esi
    0040913A 12D2           adc dl,dl
    0040913C 13C0           adc eax,eax ;tercer bit del argumento
    0040913E 02D2           add dl,dl
    00409140 75 05          jnz short FAST_APL.00409147
    00409142 8A16           mov dl,byte ptr ds:[esi]
    00409144 46             inc esi
    00409145 12D2           adc dl,dl
    00409147 13C0           adc eax,eax ;cuarto bit del argumento
    00409149 74 06          je short FAST_APL.00409151
Finalmente en el último bit leído y guardado en eax, se comprueba si el argumento es 0. Si el argumento es 0 se entiende que se debe añadir un byte 0 en la cadena desempaquetada (por tanto el byte 0 se codificaría de este modo: “111”, “0000”; es decir, ocupa 7 bits). Si el argumento es distinto de 0 es interpretado como un offset relativo y negativo desde el cual hay que tomar el dato de la cadena ya desempaquetada. Por ejemplo, si el código de control es “111”, y el argumento es “0110”, se entiende que que el dato que hay que añadir a la cadena desempaquetada es el mismo que hay en la cadena ya desempaquetada en la posición actual menos 0110b (=6h).
    0040914B 57             push edi
    0040914C 2BF8           sub edi,eax ;calcula la posicion actual-argumento
    0040914E 8A07           mov al,byte ptr ds:[edi] ;lee el dato que hay ahí
    00409150 5F             pop edi
    00409151 8807           mov byte ptr ds:[edi],al ;añade el dato a la cadena desemp.
    00409153 47             inc edi
    00409154 EB A0          jmp short FAST_APL.004090F6 ;lee un nuevo bit de control
Si lo que se lee es el código de control “110” salta a 4091FE. Donde hace las siguientes operaciones:
    004091FE 8A06           mov al,byte ptr ds:[esi]
    00409200 46             inc esi
    00409201 33C9           xor ecx,ecx
    00409203 C0E8 01        shr al,1
    00409206 74 12          je short FAST_APL.0040921A
Se lee en al un byte de las secuencia de datos comprimidos. Y mediante shr se saca el bit0 del registro al pasándolo al flag carry. Por tanto al pasa a ser un valor significativo de 7 bits. Si ese valor de al es 0, se interpreta que es el final de los datos empaquetados, saltando al final de la subrutina, que se encuentra en 40921A. Por tanto, la secuencia que indica que se ha llegado al final de los datos empaquetados sería “110”, situando en el siguiente byte un valor que será 0 ó 1 (posibles valores del valor binario “0000000x”)
    00409208 83D1 02        adc ecx,2
    0040920B 8BE8           mov ebp,eax
    0040920D 56             push esi
    0040920E 8BF7           mov esi,edi
    00409210 2BF0           sub esi,eax
    00409212 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[edi]
    00409214 5E             pop esi
    00409215 E9 DCFEFFFF    jmp FAST_APL.004090F6
Este ultimo bloque de código es sencillo. Mediante adc ecx,2 pone a ecx con un valor de 2+carry. Si seguimos examinando un poco veremos que al se usa como offset relativo para tomar el valor que hay que añadir a los datos desempaquetados, los cuales son copiados de esi a edi mediante un rep. Por tanto ecx es el counter del número de bytes que hay que copiar. Luego ya podemos interpretar la secuencia de control. La cual tendría esta forma “110”+byte_siguiente. Siendo el byte siguiente de este modo “dddddddc”. Los bits marcados con “d” indican el desplazamiento hacia atrás de la posición actual del desempaquetado de donde hay que coger los datos. Y el bit “c” indica el valor que hay que añadir a ecx (inicializado por defecto a 2). Por tanto, si c es 0 ecx vale 2, y si c es 1 ecx vale 3. Hay que tener en cuenta una cosa. Que el valor relativo que toma del argumento (el valor de 7 bits) queda también guardado en el registro ebp, este dato es importante. Pues el rango que guarda es porque da supuesta la posibilidad de que los datos dentro de ese rango se repitan nuevamente. Este valor de ebp se usa en otros códigos de control que ahora veremos. Fijémonos que este código de control con su argumento de 8 bits son en total 11 bits. En el peor de los casos es para copiar 2 bytes (16 bits), y en el mejor de los casos es para copiar 3 bytes (24 bits). Resumiendo, ¿qué ocurre si el desempaquetador se encuentra el código de control “110”? Lee el siguiente byte, y eso es lo que toma como argumento. De ese argumento saca 1 bit que le indica si tiene que copiar 2 ó 3 bytes. Y de los 7 bits restantes del argumento saca el valor del desplazamiento relativo de donde tiene que copiar esos 2 ó 3 bytes. Ahora veamos qué ocurre si el código de control no es “111”, ni “0”, ni “110”, sino “10”...
    00409156 B8 01000000    mov eax,1 ;inicializa eax con 1
    0040915B 02D2           add dl,dl
    0040915D 75 05          jnz short FAST_APL.00409164 ;lee un 1 bit más
    0040915F 8A16           mov dl,byte ptr ds:[esi]
    00409161 46             inc esi
    00409162 12D2           adc dl,dl
    00409164 13C0           adc eax,eax ;el cual es añadido a eax
    00409166 02D2           add dl,dl ;lee otro bit
    00409168 75 05          jnz short FAST_APL.0040916F
    0040916A 8A16           mov dl,byte ptr ds:[esi]
    0040916C 46             inc esi
    0040916D 12D2           adc dl,dl
    0040916F 72 EA          jb short FAST_APL.0040915B ;si ese bit es 1 vuelve a 40915B
Bien, ahora viene una parte un poco complicada, pues hasta ahora hemos visto códigos de control de longitud fija, pero ahora entramos en códigos de control de longitud variable. Lo que hace en este punto el desempaquetador es, después de haber leído del código de control “10”, lee el siguiente bit, y lo añade a eax. Lee un bit más, el cual indica si debe continuar bits para eax, o si ya ha acabado. Si el bit que lee es 1, significa que aun quedan más bits por leer para eax, si el bit que lee es 0, indica que ya ha acabado. Por tanto la forma de este código de control sería así: “10w1x1y...z0” De tal modo que cuando acaba la lectura de los argumentos, eax terminaría con la forma: “1wxyz” (siendo w,x,y, y z valores binarios). Por ejemplo, si se lee del código de control “10 011100”, eax valdría “1010” (se toman los valores subrayados, acabando de tomar valores cuando acaba con 0.).
    00409171 83E8 02        sub eax,2
    00409174 75 28          jnz short FAST_APL.0040919E
Lo siguiente que se hace es mirar qué valor tiene eax. Para ellos a eax se le resta 2. Fijémonos que la longitud mínima del código de control anterior sería “10x0”. Ya que el bit x lo lee siempre para añadirlo a eax, y es después de leer ese bit cuando comprueba si el siguiente bit es el final (bit puesto a 0). Por tanto, si al llegar a este punto eax vale 2, es porque el código de control anterior ha sido necesariamente “1000”.
    00409176 B9 01000000    mov ecx,1 ;inicializa ecx con 1
    0040917B 02D2           add dl,dl ;lee un bit
    0040917D 75 05          jnz short FAST_APL.00409184
    0040917F 8A16           mov dl,byte ptr ds:[esi]
    00409181 46             inc esi
    00409182 12D2           adc dl,dl
    00409184 13C9           adc ecx,ecx ;lo mete en ecx
    00409186 02D2           add dl,dl ;lee un bit
    00409188 75 05          jnz short FAST_APL.0040918F
    0040918A 8A16           mov dl,byte ptr ds:[esi]
    0040918C 46             inc esi
    0040918D 12D2           adc dl,dl
    0040918F 72 EA          jb short FAST_APL.0040917B ;si es 1 sigue leyendo para ecx
Este bloque es similar a lo que hemos visto antes para leer en eax, salvo que aquí los bits son leídos para ecx. Se van leyendo bits, y después se lee el siguiente. Si el siguiente está a 1, significa que hay que leer un bit más para ecx, y si está a 0 significa que ya se han leído todos los bits para ecx. Por tanto la forma quedaría de este modo: “x1y1...z0”, pasando ecx a tener el valor “1xyz”.
    00409191 56             push esi
    00409192 8BF7           mov esi,edi
    00409194 2BF5           sub esi,ebp
    00409196 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[esi]
    00409198 5E             pop esi
    00409199 E9 58FFFFFF    jmp FAST_APL.004090F6
Este bloque final ya nos suena mucho... lo que hace es tomar el valor relativo del offset del registro ebp (este registro queda establecido por el código de control “110”), y usa ecx como contador del numero de bits que hay que copiar. Fijémonos que ahora como el valor ebp ya está establecido podemos pedir que copie 3 bytes gastando menos bits... “1000” sería el código de control mínimo. Después deberíamos indicarle cuántos bytes tiene que copiar. El mínimo son 2 (para que ecx valga 2 [10 en binario] deberíamos pasar como argumento 00), y el máximo podría ser lo que nosotros consideremos.... como valor máximo ecx podría tener un valor de 32 bits. Si nos fijamos por cada bit que metamos en ecx debemos añadir uno más de control (o 1 para indicarle que siga leyendo, o 0 para indicarle que ya ha leído todos). Es decir, que como ebp ya está establecido podemos reducir 2 bytes (16 bits) a 6 bits. Es decir, en lugar de repetir el comando “110” con el argumento de 8 bits, podríamos colocar este código de control, ya que el argumento de 8 bits de “110” quedó preservado en ecx, y en este caso solo tendríamos que indicarle el numero de bytes a copiar. En el peor de los casos sería representar ecx = 2, que nos ocuparía 2 bits... [en 6 bits representaríamos 16 bits] en el mejor de los casos sería representar que ecx = FFFFFFFFh, que nos ocuparía 64 bits [en 68 bits representaríamos 34.359.738.360 bits]). La otra opción para este código de control es bien distinta. A este punto (40919E) se llega si eax no es 2 (y con el valor restado ya). El valor mínimo sería si el código de control fue “1010”, en cuyo caso a este punto eax llegaría con un valor igual a 1.
    0040919E 48             dec eax
    0040919F C1E0 08        shl eax,8
En este punto el valor que hemos leído del código de control como argumento que se pasa al registro a eax es rotado a la izquierda 8 bits. Hemos de tener en cuenta que a ese valor de eax se le ha restado ya 3, aunque realmente solo es significativo que se le ha restado 1, ya que eax es inicializado con “1”, lo cual significa que ese bit se da ya por supuesto a 1..
    004091A2 8A06           mov al,byte ptr ds:[esi]
    004091A4 46             inc esi
El valor de al es leído directamente como un argumento literal de 8 bits, con lo cual, mediante el argumento previo de eax
    004091A5 02D2           add dl,dl ;lee un bit
    004091A7 75 05          jnz short FAST_APL.004091AE
    004091A9 8A16           mov dl,byte ptr ds:[esi]
    004091AB 46             inc esi
    004091AC 12D2           adc dl,dl
    004091AE 13C0           adc eax,eax ;lo mete de argumento en eax
    004091B0 8BE8           mov ebp,eax ;el valor lo guarda en ebp
Lo que se hace hasta aquí es sencillo. El valor que quiere recuperar como desplazamiento es un valor de 16 bits. Para ellos los 7 primeros los saca del argumento inmediato a “10”. Los 8 siguientes los lee como argumento literal, y el último bit lo lee también como argumento inmediato. Es un sistema un poco extraño, pero la verdad es que sí que es resultón, pues con este método el byte más significativo del número de 16 bits puede ser representado con apenas un solo bit (en el mejor de los casos), y con 14 (en el peor). Es decir, un número de 16 bits con este método queda representado con tan solo 10 bits en el mejor de los casos... pero con 23 bits en el peor...
    004091B2 B9 01000000    mov ecx,1
    004091B7 02D2           add dl,dl
    004091B9 75 05          jnz short FAST_APL.004091C0
    004091BB 8A16           mov dl,byte ptr ds:[esi]
    004091BD 46             inc esi
    004091BE 12D2           adc dl,dl
    004091C0 13C9           adc ecx,ecx
    004091C2 02D2           add dl,dl
    004091C4 75 05          jnz short FAST_APL.004091CB
    004091C6 8A16           mov dl,byte ptr ds:[esi]
    004091C8 46             inc esi
    004091C9 12D2           adc dl,dl
    004091CB 72 EA          jb short FAST_APL.004091B7
Este ultimo bloque aun nos suena... pues usa el método de ir leyendo en ecx varios bits, que le van a indicar el counter de bytes que tenemos que copiar. La rutina es como las anteriores.. lee un bit, y lee el siguiente para ver si está a 0 o a 1. Si está a 1 sigue leyendo bits para ecx, y si está a 0 interpreta que ya no tiene que leer más bits para ecx.
    004091CD 3D 007D0000    cmp eax,7D00
    004091D2 73 1A          jnb short FAST_APL.004091EE
    004091D4 3D 00050000    cmp eax,500
    004091D9 72 0E          jb short FAST_APL.004091E9
    004091DB 41             inc ecx
    004091DC 56             push esi
    004091DD 8BF7           mov esi,edi
    004091DF 2BF0           sub esi,eax
    004091E1 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[esi]
    004091E3 5E             pop esi
    004091E4 E9 0DFFFFFF    jmp FAST_APL.004090F6
El resto de la rutina es clara. Si 500h<=eax<7D00h se añade 1 al counter, y eax es interpretado como un desplazamiento relativo, desde el que se van a copiar los ecx bytes. Si eax es un valor mayor o igual a 7D00hh, se salta a 4091EE, donde sencillamente se le suman 2 al numero de bytes que hay que copiar, caso que también ocurre cuando eax es menor o igual a 7Fh.
    004091E9 83F8 7F        cmp eax,7F
    004091EC 77 03          ja short FAST_APL.004091F1
    004091EE 83C1 02        add ecx,2
    004091F1 56             push esi
    004091F2 8BF7           mov esi,edi
    004091F4 2BF0           sub esi,eax
    004091F6 F3:A4          rep movs byte ptr es:[edi],byte ptr ds:[esi]
    004091F8 5E             pop esi
    004091F9 E9 F8FEFFFF    jmp FAST_APL.004090F6
En cualquier otro caso (si 500h>eax>7Fh) se copian el número de bytes indicado por ecx. Bien, pues esto es todo... como veis es un buen galimatías de bits, en donde se ha medido milimétricamente todo... desde la longitud de los códigos de control, hasta la longitud máxima y mínima de un argumento variable. Si estáis pensando en hacer algún algoritmo de compresión, este es uno que como veis es bien sencillo de implementar, e incluso os puede dar pistas para mejorarlo.... ¿te atreves? Toda la información contenida en este documento es meramente educativa. En ningún momento se ha pretendido violar ningún derecho ni ninguna ley de protección de datos. Los algoritmos aPLiB y JCALG1 son propiedad intelectual de sus autores. PeCompact es un producto cuyo copyright pertenece a Jeremy Collake.
[ Entrada | Documentos Genéricos | WkT! Web Site ]
[ Todo el ECD | x Tipo de Protección | x Fecha de Publicación | x Orden Alfabético ]
(c) Whiskey Kon Tekila [WkT!] - The Original Spanish Reversers. Si necesitas contactar con nosotros , lee esto antes e infórmate de cómo puedes ayudarnos