Karpoff Spanish Tutor

Cracking desde cero para súper newbies 8

Un gran paso adelante!!!

 

 

 INTRODUCCION

      

hola a todos!. que tal el manual 7?. crackearon los programas que les dejé?. espero que si, y que no tengan dificultades con el sice. es fácil sacar seriales!. se preguntarán por que puse "un gran paso adelante!!!" de subtítulo. es que vamos a dar un gran paso adelante con este manual. cada vez se hace más necesario saber lo que voy a enseñar aquí. deben saber lo más posible de este tema ya que es imprescindible a la hora de crackear algunos programas. será como el primer manual, una completa iniciación a una parte del cracking.

los temas que trataremos serán:

 

 

 al atake

¿que es todo esto?

supongo que alguna vez les pasó que intentaban desensamblar un programa y que el w32dasm: 

viñeta no respondía (se atracaba)
viñeta no se mostraba el código del ejecutable del programa
viñeta no habían string references
viñeta tampoco habían funciones importadas
viñeta ni exportadas
viñeta o simplemente no había nada

        estos y otros más son los síntomas más comunes en los archivos comprimidos y/o encryptados. ¿que son los archivos comprimidos o encryptados?. si eres un programador, debes saberlo. alguna vez habrás querido guardar una imagen muy grande en un diskett pero no pudiste porque ocupaba mucho espacio. esto es exactamente el mismo inconveniente que tienen los programadores. al crear sus programas en lenguajes visuales, éstos ocupan mucho espacio. esto es un grave problema ya que con las conexiones lentas que hay no podríamos bajar muchos programas. entonces alguien inventó algo llamado compresor y/o encryptador. el compresor hace exactamente lo que hace el winzip (espero que lo hayan crackeado, es muy fácil) pero de una manera distinta ya que comprime los ejecutables. el encryptador se hace por ejemplo para encryptar datos de manera de hacerlos ilegibles. por ejemplo la f podría equivaler al 76 la s=43 la a=77 y así infinitamente, dependiendo de lo que quiera hacer el programador que creó el encryptador. los compresores o encryptadores podrían resultar ser buenas protecciones para crackers inexpertos. el winzip reduce el tamaño de archivos, si nos mandan un zip por mail y no tenemos instalado el winzip, no podremos verlo. pero ¿porque?. para poder ver un archivo comprimido con el winzip necesitamos descomprimirlo, es como si encryptamos un mensaje que diga "k-for is the best" y nos queda 545465416547654657. el mensaje es totalmente ilegible. para poder verlo correctamente necesitamos un descompresor o desencryptador que nos vuelva el mensaje o lo que sea que hayamos comprimido a su estado original.

        esto pasa también con los programas. al comprimirlos (desde ahora a los programas comprimidos les llamaremos empaketados o empakados) los programas necesitan ser descomprimidos para ser ejecutados correctamente. de otro modo el procesador no podrá interpretar correctamente la secuencia de 0 y 1 y el programa no funcionará bien. o sea que para poder ejecutar un programa empaketado necesitamos un desempaketador o descompresor.

        pero los programas no los vas a bajar de internet con un desempaketador adjunto que diga: ejecútame sino no podrás ver el programa. la gente que no tiene idea de lo que es una pc no sabrá que hacer y además el programa resultaría muy fácil de crackear. así que la única solución que les quedó fue "incluir" el desempaketador dentro del ejecutable del programa. no entiendo, ¿como se ejecutará el desempaketador si es una parte del ejecutable y dijimos que el ejecutable estaba empakado?. pues muy fácil, el compresor comprime solo una parte del ejecutable y deja una que descomprima el resto en la memoria o sea cuando el programa se esté ejecutando. aquí hay un punto muy importante, el ejecutable empakado se descomprime en la memoria para hacer posible la ejecución del programa. se descomprime en la memoria, pero cuando lo cerramos, el ejecutable continúa empakado. para desempakar un ejecutable tenemos 2 maneras:

    viñeta desempakarlo con un programa llamado procdump o con un desempakador exclusivo para cada compresor
    viñeta hacer esto "manualmente" traceando con el sice y por supuesto con el procdump

       desempakarlo manualmente es más divertido que hacerlo con el procdump solo. me gusta más (es un vicio j).  en algunos casos es más difícil pero es esencial saber hacerlo para algunos programas en los cuales el programador creó el empaketador exclusivamente para su programa o cuando no hay desempaketador para el empakador usado. si el empakador es "corriente" (que se distribuya gratuitamente o como shareware por internet y que mucha gente los utilice) bastará con usar el desempakador exclusivo para el compresor que se le haya aplicado. aquí una lista de los principales empaketadores usados:

hasiuk/neolite
peshield
shrinker 3.x
wwpack32
petite 1.3
vbox dialog
vbox std
shrinker 3.2
upx
aspack1.08
softsentry
codesafe 3.x
aspack1.08.04
aspack1.08.2
petite 2.0
pklite
pcshrink
pcguard v2.10
aspack1.08.3
pcshrink ii
vgcrypt 0.75
aspack 2000
crunch 1.0

        aquí algunos, debe haber más ya que siempre se nos escapa uno. están las diferentes versiones de los empakadores, seguramente dentro de poco saldrá una nueva versión de alguno por lo que tendremos que aprender desempakados manuales. estos son los más comunes y los que puede desempakar el procdump, su uso lo veremos más abajo.

 

 una breve introducción a los pe

antes que nada deberíamos decir que son los archivos pe. pe significa portable ejecutable. pe es el formato adoptado por windows 32 bits para sus ejecutables, dlls, vxd, etc. todos los ejecutables están divididos en secciones. las secciones son las encargadas de cumplir una determinada función o de almacenar ciertos datos. por ejemplo, las instrucciones de los ejecutables usualmente están en una sección llamada .text, los recursos en .rsrc, las importaciones en .idata, las exportaciones en .edata, las secciones de datos son .bss, .rdata y .data. si quieren súper-profundizar en este tema tan interesante pueden leer los documentos de numit_or sobre los archivos pe. los pueden encontrar en la página de karpoff. ahora vamos a recalcar dos puntos importantes:

viñeta todo ejecutable tiene que empezar a ejecutarse por algún lugar. ese lugar es llamado entry point o punto de entrada del programa. si el programa está empaketado, lo primero que se deberá ejecutar será la rutina de descompresión para que luego pueda ejecutarse el programa en si. por lo tanto el entry point de los ejecutables del mismo programa con un ejecutable empakado y otro desempakado será distinto. como vimos que las secciones del ejecutable eran para cumplir diversas funciones o almacenar ciertos datos, debe haber una selección encargada de ejecutar la rutina de descompresión. generalmente, por ejemplo si el compresor es aspack que pienso que es uno de los más comunes lo usual sería que hubiera una sección llamada aspack y que fuera la encargada de descomprimir el ejecutable. si no hay ninguna sección llamada aspack, deberán ver el entry point del programa, y luego mirar las virtual address o los virtual offset de los ejecutables y si alguno de estos coincide con el entry point es porque estamos frente a la sección encargada de desempakar el programa.
viñeta ¿como saber si un programa está empaketado?. es muy fácil. podemos hacerlo de dos maneras. 1) si el programa presenta las características mencionadas arriba lo más común es que esté empaketado. 2) hay un magnífico (el mejor que he visto hasta ahora) analizador de archivos llamado file inspector creado por viper de [k-for]. lo puedes descargar de esta página. este programa nos brindará muchísimos datos sobre la cabecera pe de un archivo. tabla de importaciones, tabla de exportaciones, secciones que presenta el ejecutable, casi todo o todo lo que se pueda decir sobre éstas, casi todos o todos los datos pe, en que lenguaje de programación se creó el programa, el empaketador/encryptador usado, traducción de direcciones virtuales en direcciones físicas (las rva a offset, por ejemplo ponemos 00453620 y nos da su offset), y muchas cosas más!. con este mega-fantástico programa ya es mucho más que suficiente y enseguida podremos darnos cuenta si el programa está empaketado.

reitero, para tener un completo conocimiento de la cabecera pe de un archivo, de lo que quiere decir rva, imagebase, etc. y para saber que es lo que hace cada selección es imprescindible leer los documentos de numit_or sobre "descabezando archivos ejecutables portables" así que bájenlos ya!(para leerlos les doy tiempo ya que son largos j)

 

lo nuevo

íbamos a dar un gran paso adelante, pues el paso son los empaketados, pero ahora que tenemos una idea general de los empaketados tenemos un nivel suficiente como para conocer y entender la mayoría de las protecciones de software que hay. además en determinado momento tendremos que enfrentarnos a algunas de ellas si todavía no lo hicimos.

veamos las que yo conozco:

  • cd checks
  • limitaciones de tiempo
  • numero de ejecuciones limitado
  • anti-copia (laserlock por ejemplo)
  • mediante molestas nags o anuncios publicitarios
  • mediante hardware, también llamadas mochilas.
  • anti-debugging (anti-sice, anti-trw, anti-todos los depuradores que hay)
  • anti-dasm (no se puede desensamblar)
  • compresión y/o encryptación
  • anti-dumping
  • anti-monitoring (no podemos "tracear" el programa con filemon o regmon)
  • funciones deshabilitadas
  • el típico número de serie
  • crc check (chequeo de integridad de los datos, puede detectar cualquier variación en el código del ejecutable como un je a un jne o alguna mínima variación en el tamaño del exe, por eso cuando se puede, es mejor tratar de encontrar el serial válido para no liarnos con estas protecciones).
  • otros métodos raros como la creación de un archivo "escondido" en el hd, encryptado y/o empaketado y que el ejecutable del programa lo que haga sea desencryptar y/o desempakar este archivo, el que en realidad es el verdadero ejecutable del programa (si le implementaran la mayoría de las protecciones aquí mencionadas más la protección anti-monitoring esto sería una pesadilla para todos los crackers).
  • sistemas de protecciones comerciales (rainbow sentinel, asprotect, armadillo, etc.)
  • algunos otros que no conozco

 

algunas de estas las podemos atacar pero otras no, como las de anti-monitoring. incorporaremos algunas herramientas nuevas, son las siguientes:

  • frog's ice: herramienta programada por +frog's print & +spath. se usa para esconder el sice de los programas con protección anti-debugg. muy útil en algunos casos pero no siempre funciona. si no funciona podremos usar el bang! de r!sc.
  • regmon y filemon: se usan para rastrear lo que hacen otros programas. el regmon rastrea los cambios que hace un programa en el registro de windows y el filemon rastrea los archivos que crea un programa. descartados ambos si el programa a crackear tiene protección anti-monitoring, cosa que es muy poco común (el único programa que conozco que tiene protección anti-monitoring es un crackme!). los dos programas son interesantes para rastrear programas de instalación o para saber donde un programa almacena nuestro número de serie.
  • smartcheck: de la reconocida compañía numega technologies. es un debugger para programas hechos en visual basic. es muy fácil de usar y nos ahorra mucho trabajo a la hora de crackear programas hechos en visual basic.
  • exescope o resource hacker: a veces son una buena alternativa para enfrentarnos a las funciones deshabilitadas. sirven para editar los recursos de los programas. es decir, se pueden añadir menús, quitarlos, hacerlos invisibles, activar botones, quitarlos, hacerlos invisibles, desactivarlos, cambiar texto de por ejemplo un mensaje, cambiar el título de los cuadros de diálogo, y muchas cosas más. útiles si queremos eliminar un menú que diga register cuando el programa ya esté crackeado. pero como todo, no siempre funcionan.
  • apis32: herramienta que nos dice las apis que utiliza un programa por ejemplo para mostrar un cuadro de diálogo o para hacer cualquier cosa.
  • dede: herramienta creada por dafixer. es el mejor decompilador de delphi que hay. usualmente nos brinda más información que los desensambladores. es muy útil para programas hechos en delphi.
  • procdump: ni que hablar que esta herramienta nos será imprescindible!!!. su uso lo veremos más abajo.
  • file inspector: lo mismo, imprescindible!!!

todas las herramientas disponibles en la página de [k-for].

 

 uso del procdump

ahora si, aprenderemos lo básico de la utilización de esta fantástica herramienta. ejecuten el procdump, ahora vean la para que sirve cada botón:

no utilizaremos todos por ahora. utilizaremos el botón de unpack y pe editor. de options no modifiquen nada hasta tener un conocimiento de los pe y de algo de desempakados manuales.

el procdump también nos muestra los procesos activos del sistema. si hacemos clic sobre alguno de ellos con el botón derecho nos aparecerá un menú. aquí su uso:

no es tan difícil. ahora veremos como desempakar un archivo.

 

desempakando un archivo

verán que fácil que es en algunos casos. es fácil como cambiar un je a un jne aunque no lo parezca. el programilla que desempakaremos será el ya mencionado magnífico file inspector v3.0. siempre hacemos una copia del ejecutable antes de desempakarlo, es probable que algo salga mal a veces. cuando hayamos hecho la copia del ejecutable la analizamos con el file inspector para ver que empaketado tiene y ohhh, sorpresa!!, empaketado con upx v1.01. además si miramos las secciones del ejecutable veremos dos secciones llamadas upx0 y upx1. de esta manera nos damos cuenta si el ejecutable está empakado. abrimos el procdump, le damos al botón de y seleccionamos la opción upx:

   

 

ahora presionamos ok y el procdump nos abre una ventana para que seleccionemos el ejecutable que queremos desempakar. seleccionamos la copia del ejecutable de file inspector y el procdump nos mostrará un mensaje que dice "please hit ok when task is loaded (check taskbar)", cuando se ejecute el file inspector presionamos aceptar y esperamos hasta que procdump termine de descomprimir todos los procesos y cuando acabe nos abrirá una ventana para guardar el ejecutable descomprimido, le ponemos un nombre, por ejemplo descomprimido.exe y lo guardamos en el mismo directorio que el file inspector. ahora si!, yea!. observen la diferencia en el tamaño de los ejecutables, el comprimido ocupa 218 kb y el descomprimido ocupa 618 kb. entre otras cosas, esto nos demuestra la efectividad del upx j.

una de las protecciones que mencionamos anteriormente es la protección anti-dasm, con la que no podemos desensamblar el ejecutable del programa. el file inspector no tiene esta protección pero es bueno saber como enfrentarnos a ella, ya que es muy común en los archivos empaketados. aquí lo muestro con un ejecutable cualquiera con un empaketado aspack y una protección anti-dasm. para deshacernos de esta protección vamos al procdump, pulsamos el botón, seleccionamos un ejecutable y luego nos aparecerá el pe structure editor. pulsamos el botón y aparecerá esto:

si ven, todas las secciones del ejecutable tienen en characteristics el valor de c0000040. si leen los documentos de numit_or verán lo siguiente: 

el campo characteristics indica las propiedades de la sección, es decir, si se trata de código objeto, de datos inicializados o no inicializados, si se puede escribir y leer sobre la sección, si es
ejecutable, si es compartible, etc. procdump llama a este campo "characteristics". a continuación las equivalencias:

· 000000020h = código.
· 000000040h = datos inicializados.
· 000000080h = datos no inicializados.
· 040000000h = sección cacheable.
· 080000000h = sección paginable.
· 100000000h = sección compartida.
· 200000000h = ejecutable.
· 400000000h = se puede leer.
· 800000000h = se puede escribir en la sección.

por ejemplo, si las características es e0000020h, entonces se trata de una sección en la que

 

1. se pueden escribir datos                                        80000000h
2. se pueden leer datos   40000000h
3. se pueden compartir datos 10000000h
4. hay código 00000020h
------------
e0000020h

¿y que quiere decir esto?. que si en characteristics tenemos c0000040h tenemos lo siguiente:

 

1. selección paginable 080000000h
2. datos inicializados 000000040h
3. se puede leer 400000000h
-------------
c0000040h

 

 

o sea que como no tenemos 20h, no hay código, ni se pueden compartir datos, ni escribir datos. lo cambiamos a e0000020 para indicarle que tenemos código ejecutable entre otras cosas. yo siempre cambio la sección que esté primero. para cambiar c0000040 a e0000020 tenemos que hacer clic con el botón derecho del mouse sobre la sección que queramos cambiar (en este caso es la sección code) y luego pulsamos edit section. luego modificamos lo siguiente:

presionamos ok, y salimos del procdump. los cambios quedarán hechos y ya podremos desensamblar el programa correctamente.


es bastante fácil lo que hemos visto. espero que hayan disfrutado del tutorial tanto como yo disfruté escribiéndolo. si practican un poco más están a punto de pasar a un nivel intermedio. otra cosa que por favor quiero pedir es que pregunten solo cosas relacionadas con cracking, si supieran las preguntas que me han llegado!!!. y otra cosa, que antes de preguntar se pasen por los excelentes foros de wktkut. si no obtienen respuesta ahí pueden contar conmigo.

me despido, nos vemos en el siguiente tutorial!

saludos a:

  • todo [k-for] (profe x quiero crackear!!!j)

  • mr.jade

  • skuater

  • act mago

  • xasx

  • karpoff

 

 

a s t a l a v i s t a


página oficial del grupo k-for: http://pagina.de/kfor
mi dirección de e-mail: dek_oin@hotmail.com

 

karpoff spanish tutor: pagina dedicada a la divulgacion de informacion en castellano, sobre ingenieria inversa y programacion. email "colabora con tus proyectos"
www.000webhost.com