Ayuda para entender uso de olly (especifico)

Hola a todos, espero que esten bien....

bueno entrando directo a tema, estoy estudiando el CRACK o PATCH de programas, pero al llegar a la comparacion del JE, no parece como en el manual, aun que cabe decir que el manual , solo indica algo como esto

004026D4 . 0F84 33040000 JE 00402B0, asi es como esta en el manual

pero al no tener el archivo de ejemplo me he generado un simple archivo...
y me parece de esta manera:

004026D4 . 0F84 33040000 JE Crackme.00402B0>

entonces es muy diferente al manual.

Alguien podria crear el manual usando el ollydbg para este ejemplo en el cual me indique el ultimo paso para convertir el JE por JMP (es lo que decia al menual, pero solamente no le entendi...), ya que cuando lo he intentado me genera 3 NOP despues de la linea... :confused: y cuando ejecuto el programa ya nada ni el serie correcto me lo acepta....

El metodo de generar el serial es el siguiente:

si tenemos la palabra "hola mundo"
la forma de sacar el serial es...

tomamos la ultima letra del NOMBRE en este caso seria la "o"
despues tomamos la longitud del NOMBRE, en este caso "10"
y por ultimo tomamos la primera letra del NOMBRE, seria "h"
Ahora solo la pasamos a mayusculas y listo el serial valido
seria como se muestra en el siguiente ejemplo:

"ejemplo" -> "O7E"
"Hola Mundo" -> "O10H"
"bye" -> "E3B"

y ahora lo que ocupo que me ayuden por favor es que la comparacion sea valida con todo lo demas menos el serial correcto, lo que hace un PATCH ;)

bueno agradesco su atencion, los detalles del archivo:
Nombre: Crackme.exe
Tamaño: 24.0 KB (24,576 bytes)
Compilado: Visual basic 6
Sin Empaquetar o algun tipo de proteccion.

Aqui el archivo: http://rapidshare.com/files/201838117/Crackme.rar
pesa solo 4.33kb (4,440 bytes)

Espero me puedan ayudar con este pequeño paso para uds, una grande ayuda para mi, se los agradesco.

Buenas! Te comento...

El motivo de los nops (90h), es porque la arquitectura x86 es una arquitectura tipo CISC, por lo que las instrucciones son de tamaño variable (Al contrario de lo que ocurre en arquitecturas RISC, que suelen ser de tamaño fijo, es decir todas las instrucciones ocupan el mismo número de bytes).

Traduciendo ésto, si tienes una instrucción que ocupa por ejemplo 2 bytes (como puede ser un add reg32, reg32), y lo cambias por una instrucción que ocupa 1 byte (como puede ser un push reg32), quedaría un byte libre por ocupar en ese espacio de memoria de instrucciones, y que para "rellenar" y evitar solapamientos y demás historias se introduce un nop (que es una instrucción que ocupa 1 byte y no hace nada). Del mismo modo si lo sustituimos a la inversa, es decir, el caso en el que sustituimos una instrucción menor por otra mayor (por ejemplo sustituir un push reg32, por un add reg32, reg32), el resultado provocaría un solapamiento de instrucciones que acabaría probablemente en excepción durante el tiempo de ejecución.

De ahí el motivo de los nops cuando se trata de sustituir instrucciones de un tamaño específico por otra(s) de menor tamaño sin sobrepasar. En resumen... lo sustituido debe ocupar exactamente lo mismo que lo que ya existe. Esta es una de las cosas más importantes en el tema de ingeniería inversa.

En segundo lugar, he visto el crackme y bueno, realmente el punto clave es:

004026D4 0F84 33040000 JE Crackme.00402B0D

(Te faltó el dígito hexadecimal al final: "D")

Simplemente se trata de buscar las cadenas de texto: "Numero de serie correcto" y la llamada a la API MessageBox, la cual, siguiendo el estandar stdcall, muestra el mensaje contenido en la pila (previamente introducido por algún push).

Si observas, simplemente introduces un breakpoint en ese punto, para parar la ejecución, y traceando con F8, llegarás al punto clave. Si observas justo después, aparece la llamada a MessageBox:

004026E3 . C785 FCFEFFFF 881E4000 MOV DWORD PTR SS:[EBP-104],Crackme.00401E88 ; UNICODE "Numero de serie correcto."

Y el contenido de la dirección apuntada por la instrucción JE (anterior) apunta hacia la otra llamada a MessageBox con el mensaje incorrecto:

00402B16 . C785 FCFEFFFF 481F4000 MOV DWORD PTR SS:[EBP-104],Crackme.00401F48 ; UNICODE "El numero de serie es incorrecto."

Pues bien, el crackme simplemente se resuelve cambiando el JE inicial por su instrucción negada (JNE), la cual ocupa exactamente lo mismo que JE:

004026D4 0F84 33040000 JE Crackme.00402B0D -> se sustituye por:
004026D4 0F85 33040000 JNZ Crackme.00402B0D (JNZ equivale en este caso a JNE, ya que lo que se comprueba si el flag Z está a 0).

Le das a "Follow in dump" con el botón derecho del ratón copias la cadena hexadecimal y lo editas desde un editor hex y lo guardas. (Si te fijas sólo cambia un 84 de JE por un 85 de JNZ). Y ya tendrás tu crackme listo para cualquier serial que se introduzca.


Un saludo

Correcto, no lo habia notado, gracias ;) ya que no es lo mismo sin una D

Cita:

---

Iniciado por hystd

004026D4 0F84 33040000 JE Crackme.00402B0D

---

mmm solo eso era me lo imaginaba, lo que pasa es que el manual decia cambiar el JE por una JMP nunca habia pensado en otra cosa, cambiar un 84 por un EB, pero ya me ha queado claro gracias.

Cita:

---

Iniciado por hystd

un 84 de JE por un 85 de JNZ

---

La guia me sirvio de mucho ahora falta que las aplicaciones tengan JE para cambiarla por un JNZ en algunos casos, pero me queda estudiar aun mas el ensamblador :)

Ahora de nuevo, quize cambiar un poco el codigo anterior, la manera de sacar el serial es el mismo, solo que la sentencia cambio un poco, y tambien los TEXT STRING, hace mucho que no me acordaba de ello y lo aplique, me podrias(an) ayudar porque al pasarlo por el OLLY, ya no le encontre.... :$

Detalles del archivo:
Nombre: Crackme2.exe
Peso: 36.0 KB (36,864 bytes)
Compilador: Visual Basic 6

Detalles del archivo comprimido:
Archivo: Crackme2.rar
Peso: 6.36 KB (6,522 bytes)

sin compactar ni nada.

Link de descarga:
http://rapidshare.com/files/202243259/Crackme2.rar

Gracias de antemano por su atencion nuevamente.

La explicación de Hystd es muy buena y poco más hay que añadir.

Sólo hay una cosa que no entiendo en tu razonamiento: 'ahora falta que las aplicaciones tengan JE para cambiarla por un JNZ'

Porqué ese razonamiento? Lo más normal es cambiar una condicional por su contraria u opuesta (JE por JNE, JZ por JNZ) puesto que te dará muchísimos menos dolores de cabeza y sólo fallará si introduces un serial válido, cosa bastante difícil aleatoriamente, además te evitas los saltos condicionales y los relativos...

Cita:

---

Iniciado por SxR

Sólo hay una cosa que no entiendo en tu razonamiento: 'ahora falta que las aplicaciones tengan JE para cambiarla por un JNZ

---

y agrego en algunos casos, claro que con esta enseñanza no se ya crackear todo lo existente en internet, pero si me da motivacion para seguir estudiando.

Cita:

---

Iniciado por SxR

La explicación de Hystd es muy buena y poco más hay que añadir.

---

, lo mismo dije en respuesta al mensaje.

Ahora la surge cuando el programa aplico algo que usaba hace mucho, y al compilarlo no me aparece ningun TEXT REFERENCE al mensaje de SERIAL CORRECTO o SERIAL INCORRECTO, y a lo que he estado leyendo es necesario para lograr hacer un crack, pero si no las encuentro porque no aparecen que puedo hacer, y si el programa no esta empaquetado ni nada, ahi es donde pido me guien nuevamente.

Disculpen si soy incistente pero ya saben como es uno cuando va iniciando en algo nuevo, y va saliendo bien :D

Puede que el text reference no esté por ningún lado puesto que puede ser compilado y ordenado en tiempo real, yo que tu probaría con breakpoints...

hombre gracias, haber como me va :D

el cambio que hice fueron:
Msgbox "Clave correcta"

por
Msgbox chr$(67)+chr$(108)+chr$(97)+.......

eso puede dificultar algo al momento de usar el ollydb o algun otro programa,.. ya que uno tendria que avanzar linea por linea.. o como podria buscar los SALTOS que interesan habiendo menos TEXT REFERENCE

Buenas! A ver... en el segundo crackme no puedes ver las cadenas tal vez porque no están presentes como unas constantes. Si lo quieres ver de esta manera, son cadenas que se forman en tiempo de ejecución, a saber, pueden estar contenidas en un vector de caracteres y el resultado final, un puntero a caracter será quien referencie el primer caracter de la cadena, la cual se va formando mediante concatenaciones de los caracteres (En ollydbg lo pudes observar cuando se llama a la función vbaStrCat, función típica de VB).

Así mismo otra función interesante para comenzar un ataque podría ser la función vbStrCmp la cual compara dos cadenas para ver si son iguales... y etc...

En ingeniería inversa (y en ingenieria NO inversa también xD), las cosas no suelen ser como una receta de cocina... hay que entender las cosas y por qué.

En tu crackme tienes que el punto de entrada hacia las instrucciones del botón "validar" (las que se ejecutan en su evento "OnClick()"), comienzan en la dirección 402090h:

00402090 > 55 PUSH EBP
00402091 . 8BEC MOV EBP,ESP


El PUSH EBP; MOV EBP,ESP es el preámbulo de la función llamada (En este caso el comienzo del evento OnClick()). Puedes establecer un breakpoint aquí y comenzar a tracear para ver el comportamiento cuando el serial es incorrecto.

Haciendolo, observas algunos saltos importantes, que conviene ir anotando en un papel o en un notepad que tengas abierto...

Por ejemplo, tienes que en la dirección:

004024A6 . 0F84 300A0000 JE Crackme2.00402EDC

El cual valida si has introducido o no un nombre en el cuadro de texto.

Procediendo de esta manera los saltos claves se encuentran en:

004031CD 0F84 77070000 JE Crackme2.0040394A

00403C55 0F84 E7130000 JE Crackme2.00405042

Los cambias por sus negados, (JNE) y ya tendrás que siempre se llamará a MessageBox con el parámetro "Numero de serie correcto".

Evidentemente esta no es la única forma, ni puede que tampoco sea la más elegante, pero si eficiente. Es lo que ocurre en temas de ingenieria (inversa o no), y lo que distingue a un buen ingeniero de un ingenierillo, o a un buen cracker de uno mediocre (como yo :p).


Un saludo.

jajaja Hystd... muy currada la respuesta :P My bien.

En cuanto a los patch's que propones, como comentas no son los más eficientes, pero sí son eficaces :P

En esto, como en todo, hay gustos y sabores para todos.

Woow gracias por la informacion y tiempo para contestar, y a seguir estudiando se ha dicho....

Ya por ultimo (lo prometo, en este post, para darlo por terminado)

Cita:

---

Existe alguna forma de ocultar los eventos... o situaciones parecidas OnClick, MsgBox, vbSrtCmp, etc... sin necesidad de empaquetar el exe... o si en caso no ocultar sino hacer un tanto mas complicado..... (si o no, y alguna pista)

Si uso un Label, Picture, o alguno otro objeto de y uso su OnClick para pasar a la comparacion es igual o semenejante al OnClick de un Command (si o no)

que opinan si despues de un OnClick corro un Timer para que cuente o espere algunas milesimas y se despues evalue cuanto tardo, pero si se tarda mas de lo necesario Probablemente este en un debbuger, y haga otra opcion, antes de mostrar los mensajes o comparacion de cadenas (aun que antes haria la comparacion del tiempo). (Respuestas a discrecion.)

---

Uff jejeje, no son triviales las respuestas... pero bueno, intentaré dar una pequeña referencia o ideas...

A ver, para lo primero, ocultar código y demás sin empaquetar el binario (.exe), por supuesto que existen. Puedes ir desde ofuscación de código hasta polimorfismo.

Para el caso de polimorfismo, o más genéricamente "cambiar código en tiempo de ejecución", puede hacerse de muchas formas, por ejemplo usando inyección de código estática o dinámica. La inyección estática hace que una instrucción que se encuentra en una zona de memoria sea modificada al ejecutar otra instrucción que se encuentra en otra dirección. La causa principal de ésto se debe a que un programa cualquiera puede ser escrito en un lenguaje computable de infinitas maneras. Piensa por ejemplo en el caso de traducir a lenguaje máquina un bucle for... Seguro que si tu lo haces, lo hace SxR y lo hago yo, ninguno de los 3 coincidimos en el resultado xD, a pesar de que los 3 códigos estén bien.

De esto último, también se apoyan los compiladores para generar códigos ensamblador mas eficientes que otros... (debido por ejemplo a factores de la arquitectura hardware). Por ejemplo si pones ese bucle for en Visual Basic, yo lo pongo en Delphi y SxR en C, el código generado en lenguaje máquina por los 3 compiladores es totalmente distinto, y unos serán más eficientes que otros, a pesar de que los 3 bucles for escritos en alto nivel son exactamente iguales. Lo que ocurre es que a lo mejor C hace más optimización de memoria que Visual Basic reduciendo por ejemplo los accesos a pila, pero este a su vez prefiere reducir los tiempos de ejecución de las instrucciones basándose en predicciones de salto y demás historias... y a su vez a lo mejor Delphi prefiere cambiar un JNE por un JNZ porque esta última utiliza menos ciclos de reloj (CLK's) para ejecutarse debida la arquitectura en la que se ejecuta, consiguiendose así que el bucle sea más rápido, o simplemente recorriendo el bucle descendentemente para así lograr que cuando se llegue a un CMP, JNZ, el valor del índice del bucle ya es cero. OJO!!! me he inventado los compiladores y las formas de optimización, y no quiere decir que sea así para cada uno de ellos xD, que os estoy viendo venir :D:D:D


La inyección dinámica es algo más a nivel del SO y consiste en acceder al espacio de memoria de un proceso en ejecución e inyectar para ese hilo un código que se encuentra almacenado en una librería.

Tanto para un caso como para otro, existen multiples e infinitas formas de llevarlas a cabo...


Para lo segundo que comentas no entiendo bien a qué te refieres.

Y para lo tercero, acabas de deducir una técnica que se basa en lanzar un segundo hilo de ejecución, (el hilo del Timer), para llevar a cabo una tarea diferente a la hora de realizar cierta comprobación. Aunque la comprobación de esperar un tiempo para ver cuanto se tarda en realizar algo, no es nada efectivo xD.

Existe mucha documentación al respecto sobre cómo proteger un fichero para evitar ser debugeado. La más simple consiste en usar una llamada a la función IsDebuggerPresent() contenida en Kernell32.dll. Pero si buscas sobre el tema o sobre esa función, verás que existen muchas formas de saltar la protección, por ejemplo ollydebug posee un plugin para ello.

Por lo demás, piensa que siempre o casi siempre, cuando haces cracking de software, te vas a encontrar software que utlicen técnicas combinadas y a la vez simultaneas. Por ejemplo, podría darse el caso de un ejecutable que creara un hilo de ejecución, llamando a la función de la API CreateThread(...) del kernell32.dll, el cual se encargará de acceder al espacio de direcciones de una página de memoria del proceso en cuestión y que se desea modificar (llamando a la función VirtualProtect(...) de la API, para dar permisos de escritura a esa página o segmento de ella), consiguiendo así que el código sea polimorfico. Y si todo ésto a su vez se combina con cosas que ya he comentado antes al final dificultas bastante la tarea al cracker... pero en absoluto será imposible...

Un saludo.

muchas gracias a ambos, para hacerme ver mas alla :)

y a estudiar se ha dicho, sino de plano vere el registro por ONLINE, y poner un server en casa y ya, para que el programa no tenga que tener codigo de registro, espero y se puede haber, gracias por todo, entre con dudas salgo con respuesta y mayor motivacion a continuar.