Mensajes

[FC]

A qué te refieres con comparar: ¿Comparar byte a byte las dos dll y ver las diferencias?
Si es así tienes muchos programas, puedes utilizar por ejemplo Hex Comparison, que a mí me gusta bastante y además tiene una opción para trabajar con datos hexadecimales muy útil: pegar valores hexadecimales

Su página web es la siguiente:
http://www.exeicon.com/hex-comparison/
No es gratuito, pero está bien y se va actualizando.

También puedes mirar gratuitos:
http://usuarios.lycos.es/visualdiego/programas/Diego-Comparador/Diego-Comparador.exe
http://www.elguille.info/colabora/vb2006/cristianfa2_COMPARADOR.htm

Y este ejemplo igual no lo conoces: comando FC en la Consola de Windows:

Código [Seleccionar] Expandir


C:\Documents and Settings\usuario>help FC
Compara dos archivos o conjuntos de archivos y muestra las diferencias
entre ellos


FC [/A] [/C] [/L] [/LBn] [/N] [/OFF[LINE]] [/T] [/U] [/W] [/nnnn]
   [unidad1:][ruta1]archivo1 [unidad2:][ruta2]archivo2
FC /B [unidad1:][ruta1]archivo1 [unidad2:][ruta2]archivo2

   /A     Muestra sólo la primera y última línea de cada grupo de
          diferencias.
   /B     Ejecuta una comparación binaria.
   /C     Omite mayúsculas y minúsculas.
   /L     Compara archivos como texto ASCII.
   /LBn   Establece el máximo número de diferencias consecutivas como
          el número de líneas especificadas.
   /N     Muestra los números de línea en una comparación ASCII.
   /OFF[LINE] No omite archivos con el atributo "sin conexión"
          establecido.
   /T     No expande tabulaciones a espacios.
   /U     Compara archivos como archivos de texto UNICODE.
   /W     Comprime espacios en blanco (tabulaciones y espacios) por
          comparación.
   /nnnn  Especifica el número de líneas consecutivas que deben
          coincidir después de una diferencia.
  [unidad1:][ruta1]nombre-archivo1
             Especifica el primer archivo o conjunto que se comparará.
  [unidad2:][ruta2]nombre-archivo2
             Especifica el segundo archivo o conjunto que se comparará.



C:\Documents and Settings\usuario>

Un ejemplo que acabo de hacer de este último caso. He creado dos archivos y sus respectivos bytes son los siguientes:
Archivo 1.dll --> 01 02 03 04
Archivo 2.dll --> 11 02 33 44 55 66

Código [Seleccionar] Expandir

C:\Documents and Settings\usuario> FC C:\1.dll C:\2.dll /b
Comparando archivos C:\1.dll y C:\2.dll
00000000: 01 11
00000002: 03 33
00000003: 04 44
FC: C:\2.DLL es mayor que C:\1.dll

Prueba éste:
http://www.rdgsoft.8k.com/

[Enlaces - Opinión personal]

Enlaces - Opinión personal

Como hemos aprendido, lo que siempre y en toda aplicación hay que evitar son las comparaciones directas tanto de serial malo-serial bueno como comparación registrado-no registrado. Eliminando asímismo las referencia a cadenas de texto haremos que nuestra aplicación ya no esté al alcance de todo Newbie. Después para aprender más recomiendo leer tutoriales de Ingeniería Inversa y así se aprenderán nuevas técnicas más complejas. Tal vez tú que estás leyendo esto seas un futuro programador de packers.
Podemos valernos de métodos sencillos que incorporan algunos compiladores para hacer que nuestra aplicación pueda ser algo más segura, por ejemplo en Visual Basic podemos compilar nuestra aplicación con P-Code que es bastante más difícil de manejar que el Código Nativo y mucha gente incluso no sabrá ni por dónde empezar.

Existen gran número de aplicaciones para empaketar nuestro programa, hay bastantes gratuitos pero siempre hay que leerse las condiciones porque en la mayoría ponen que si tu aplicación es comercial el packer no es gratuito.
Yo estoy asimismo trabajando actualmente en un "compresor/protector" que quiero hacer gratuito para todo el mundo. Ciertamente tengo pensadas millones de ideas anti-cracking.

El packer más conocido en todo el mundo es probablemente UPX.
Como ya sabrás, UPX es excelente para disminuir tu ejecutable de forma extraordinaria, por contra es muy fácil descomprimirlo: para Newbies recién comenzados en este Arte.

Intenté hacer una lista de packers, pero es tantísima la información y la gran cantidad de packers existentes, que me ha sido imposible continuar investigando uno por uno para poner enlaces de descarga o páginas web.
Así que he encontrado un enlace que seguro que os sorprende. Ojalá el enlace dure mucho tiempo:

http://sac-ftp.externet.hu/pack1.html



Opinión personal:

karmany: personalmente siempre he estado en desacuerdo con aquellas personas que crackean programas y luego distribuyen el crack por la red. No entiendo esta finalidad. Es tan amplio el mercado, que a día de hoy casi cualquier programa que se necesite, se puede encontrar gratuito por la red.

Siempre he creído y cada día más, que no hay desperdiciar muchísimo tiempo en intentar proteger nuestra aplicación, porque solamente que haya un cracker de nivel medio-bajo con ganas de crackear lo conseguirá en poco tiempo, pero tampoco hay dejar que un Newbie recién iniciado sepa hacerlo.
También es cierto que el uso de packers hacen aumentar considerablemente la dificultad, pero como ya se comentó, hará aumentar también el precio de la aplicación. Sin embargo, packers difíciles han sido muy analizados, Armadillo es un claro ejemplo.

Por otro lado, también ocurre que si la protección es difícil, el cracker puede cansarse de analizarla y dejarla apartada. Lo digo por experiencia.
A fin de cuentas, es el programador el que tiene que pensar todo esto.

Finalmente creo que una de las cosas positivas que hacen los cracks es que la aplicación sea utilizada por mucha gente y así distribuida. Si un programa fuera incrackeable sólo lo utilizarían los usuarios registrados ya que mucha gente lo desecharía por sólo usarlo un determinado tiempo.

Después de todo esto, espero que hayas obtenido información que no sabías y puedas decidir lo que quieres o no hacer.

Un saludo
karmany




PD. Bueno este tema que publiqué en poco tiempo, y faltan muchísimas cosas que añadir es posible que sea ampliado en un futuro y posiblemente eliminado de aquí ya que he obviado muchísimas cosas que son importantes. Así que es posible que en breve lo elimine.

[Quiero hacer yo mismo mi propia protección]

Quiero hacer yo mismo mi propia protección

Este apartado lo podríamos llamar consejos de gente que trata con "Ingeniería Inversa". Consejos para que tu aplicación sea más difícil de analizar.

Cuando se implanta una licencia, hay que tener presente que esa licencia es para un usuario y normamente es así:
1-Nombre del usuario
2-Contraseña del usuario

Ambas tienen una relación que sólo debe conocer el autor de la aplicación. Hay otros programas que simplemente con poner un serial ya está registrado correctamente. Me basaré en el primer caso: Nombre y contraseña.


Caso 1 - Protección (0 a 10): 1

Muchos programadores ponen la relación nombre-contraseña muy difícil de analizar: pasan los datos de nombre al valor ASCII que corresponda y realizan infinidad de operaciones matemáticas. Hasta aquí muy bien, pero...
después de realizar esas operaciones matemáticas comprueban directamente ese resultado con el serial. Ahí está la debilidad: si se compara directamente con el serial será muy fácil encontrarlo, simplemente hay que pararse en la comparación y veremos la contraseña correcta.
Puedo asegurar que infinidad(requetemuchísimos) de programas hacen esto comentado.

¿Cómo se puede arreglar?
Pues bien, todo programador debe saber una cosa lo más básico de todo: si el serial verdadero aparece directamente en memoria por cualquier causa, en menos de lo que canta un gallo será encontrado por cualquier Newbie.
Hay que evitar sea como sea la comparación directa del serial. Hay muchas formas, una por ej. sencilla es poner el valor ASCII también al serial y realizar otra serie de operaciones matemáticas...


Caso 2 - Protección (0 a 10): 2
Imaginemos un programa que la licencia para mi es:
Nombre: karmany
Serial: 1234
El chequeo que hace para la comprobación es:

Código [Seleccionar] Expandir

Nombre: karmany --> pasa a valor ASCII --> operaciones matemáticas --> resultado final: 564
Serial: 1234    --> pasa a valor ASCII --> operaciones matemáticas --> resultado final: 564
Como se observa. ya no se compara el serial directamente pero tiene asímismo una gran debilidad: debe comparar esos resultados: 564
Esto en ensamblador aparecerá también como una comparación y aunque no tengamos el serial podemos modificar directamente el resultado de la comparación porque es una comparación: registrado- no registrado. Estaría crackeado en poco tiempo por un Newbie recién iniciado.
Hay que evitar esas comparaciones.



Caso 3 - Protección (0 a 10): 2-3
Imáginemos que tenemos el caso 2 en el que cuando introducimos una contraseña falsa nos aparece un mensaje que dice: "Contraseña no válida"
Sabemos que para el registro hay que comparar los 564 pero ¡hay que encontrarlos primero!
Lo primero que hace un cracker es ver: las 'string references', es decir, las cadenas de texto. Normalmente cualquier cadena de texto que se utilice en un programa, aparece literalmente en el mismo. Por este motivo, si cuando un usuario pone una contraseña correcta, aparece un mensaje que dice: "Gracias por registrarse" no dude ni un segundo que lo que primero va a buscar el cracker son esas palabras. Y cuando las encuentre irá directamente a parar a la comparación de 564 con 564.
Por todo esto que estoy comentando, hay que evitar las cadenas de texto literales.
Tú eres programador, esto te lo dejo a tí, hay mil formas.

Si partimos del Caso 2 y hemos eliminado toda referencia de texto, ya estamos protegiendo nuestra aplicación contra un número de Newbies. Sin embargo, este último, aunque tenga muy poca experiencia, con el tiempo encontrará esa comparación 564 con 564 y la modificará.



Caso 4 - Protección (0 a 10): 2-3
Partimos del Caso 3.
¿Qué ocurre cuando hemos introducido un código correcto? Muchos programas modifican cierto byte de ellos mismos de tal modo que si está el registro correcto el byte es 1 y si no está registrado el byte es 0.
Estamos en el Caso 4 y ya no resulta fácil encontrar un nombre-serial válido, pues el programador hace millones de operaciones matemáticas para obtener esos 564.
El cracker puede optar por dos sencillas opciones:
-modificar la comparación de 564 para que cualquier nombre-serial valga
-ver después cuál es el byte que se pone a 1 cuando nos registramos.

Sabiendo esta segunda forma, el cracker directamente modificará permanentemente ese byte a 1 y ya no hay que poner ningún nombre-serial porque ya será una versión registrada.


Caso 5 - Protección (0 a 10): 5-...
Cada persona es diferente así que lo que a mí me parece fácil a otro le parecerá difícil y viceversa.
Para mí un protección 5 ya es un tema para estrujarse las neuronas.
Partimos del caso anterior pero cuando está registrado ya no depende sólo de un byte. Para hacer esto podemos hacer que de vez en cuando sea comparado el nombre-serial, pero tenemos el problema de siempre: llegamos a la comparación de antes: 564 que hay que eliminar.
En ensamblador las comparaciones directas suelen hacerse con la instrucción cmp y después viene un salto por ejemplo "je" o "jne". El cracker lo primero que probará será modificar tras la comparación el "je" por un "jne" o viceversa.

Sólo pensando un poco se le pueden ocurrir a uno muchísimas formas de evitar que se compare directamente 564 con 564. Por ejemplo, con el nombre realizamos operaciones, con el serial lo mismo. Después realizamos operaciones con los valores obtenidos dando un valor de resultado. Con ese resultado podemos descifrar parte de código. El problema de esto es que ese valor es siempre el mismo para cualquier nombre-serial.

Se pueden también realizar diversos chequeos, por ej. se puede examinar si la comparación 564 con 564 ha sido modificada, en tal caso no mostrar un mensaje inmediato ya que alerta al cracker y el mensaje le sirve de guía.

Se pueden realizar chequeos CRC, se pueden utilizar archivos para la licencia (keyfiles) donde cada archivo licencia es diferente según usuario.

Si no se te ocurre ninguna forma de ocultar la comparación 564 puedes hacer una cosa y es hacer esa comparación en memoria dinámica ya que ahí el cracker no puede modificar el "je" por "jne" porque en el ejecutable no existe todavía.

Si tu programa requiere actualizaciones de cualquier tipo, lo tienes bastante fácil porque según el usuario-serial tú puedes permitir la descarga o no de actualizaciones, aunque el programa esté crackeado.


Hay muchas formas que deben salir de tu imaginación. Cada programa es un mundo, como cada persona. Incluso para saber proteger una aplicación puedes analizar tutoriales de cracking, que te enseñarán las protecciones más comunes que se suelen utilizar.

[Herramientas para la depuración]

Herramientas para la depuración

Yo sé que todo esto que estoy explicando, si el lector nunca ha trabajado con Ingeniería Inversa, pues puede resultar complicado... de todos modos lo más difícil ya ha sido explicado, ahora vienen cosas "menos técnicas" 

Muchas herramientas para el cracking ya reconocen estos métodos comentados.

Para tener una idea de la "fuerza" de algunos programas explicaré el archiconocido OllyDBG:
OllyDBG es un debugger a 32 bits (en ring3) potentísimo. Yo casi me atrevo a decir que para ring3 es el mejor. Desde su aparición, que al principio no causó buena sensación, fue sumando adeptos y su despegue ha sido brutal. Tiene una opción que es la posibilidad de insertar plugins... así que programadores de todo el mundo han hecho millones de plugins para este debugger. Unos plugins que hacen que OllyDBG sea una herramienta esencial e invisible a todo: sólo con un click de ratón, es posible anular ¡todas las protecciones anti-debugger que vimos en el apartado anterior!.
Con esto demuestro la magnitud de este programa. Es impresionante.

Hasta ahora sólo he comentado la existencia de dos herramientas: debuggers y desensambladores, sin embargo, existen muchísimas más que hacen que todo cracker tenga las cosas bien fáciles.

No todas estas herramientas están preparadas para detectar los trucos anti-debugger/desensambladores que vimos en el apartado anterior, así que es bueno por este motivo poner siempre algún tipo de protección de las ya vistas.

Hay herramientas específicas incluso para cada lenguaje de programación con que la aplicación haya sido compilada. Por ejemplo para programas compilados con Visual Basic hay aplicaciones como VB Decompiler, VB Reformer, SmartCheck (de verdad éste último es impresionante) etc.. para compilaciones con Delphi o Borland C++ tenemos Dede, E2A, MiniDe etc...
Todos estos programas ofrecen una ayuda al debugger muy precisa, con lo cual, el cracker rápidamente llega a la "zona caliente" que le interesa. Excepto Smartcheck que también actúa como "debugger", los demás normalmente trabajan analizando el código, por lo cuál determinadas protecciones anti-debugger no valen para nada.

Cada programa, cuando está ya compilado hay que tratarlo de forma muy diferente, por ej. un programa que haya sido compilado con Visual Basic ya se sabe que necesita de su librería de apoyo para funcionar , un programa en Delphi tiene bastante código ya que incorpora todo lo necesario en él para funcionar, los programas en NET suelen resultar muy requetefáciles de romper e incluso encontrar seriales también suele ser tarea relativamente sencilla.
Personalmente los programas en Delphi o Borland C++ me resultan los más difícultosos a la hora de analizar ya que cuando se realiza alguna función no se realiza directamente, sino que se envía un valor (normalmente 0 o 1) a un lugar de la memoria y posteriormente ese valor será tratado, me explico:
Si nosotros queremos activar un botón, por ej. en ensamblador haremos:
Call Activar_botón
Simplemente ejecutando esa subrutina (Activar_botón) el botón se activará.

Si ahora lo hacemos en Delphi o en Borland C++:
Call Activar_botón
Al pasar esa subrutina el botón NO se activa!! simplemente en un lugar de la memoria se habrá puesto un 1 y ese 1 será el que haga activar el botón más tarde.

Como se observa cada programa y según con qué lenguaje de programación fue escrito hay que tratarlo de forma muy diferente.

En todos estos casos, debes ver con qué lenguaje de programación trabajas y de este modo puedes implementar en tu aplicación alguna medida contra estas herramientas.

Como comenté antes existen debuggers (OllyDBG por ejemplo) que son invisibles a todo. Incluso algunos utilizan drivers para ejecutarse por debajo de donde las aplicaciones trabajan: ring3.
Yo pienso que es por este motivo que, como comenté al principio, los software especializados en protecciones no se preocupan tanto de poner trampas anti-debugger sino en "romper" el ejecutable para que no sea recompuesto... esta es la misión del cracker: recomponer el ejecutable que ha sido desmenuzado por un packer.

Voy a bajar el "listón" para que se entienda perfectamente:
-Un packer tiene dentro de sí mismo al ejecutable que se ha protegido. El packer se va descomprimiendo poco a poco, desencriptándose, realizando chequeos anti-debugger etc... hasta que llega un momento, cuando se ha descomprimido del todo que pasa la ejecución al programa que se ha protegido... y ¡zas! ahí entra el cracker a jugar. En ese mismo momento es cuando el cracker para todo y reconstruye poco a poco el puzzle. Como ya se sabe hay puzzles fáciles, y muy difíciles. Sin embargo, con tiempo todo puzzle se puede hacer.

Ese momento en el que ya se ha descomprimido todo y pasa a ejecutarse la aplicación protegida, es diferente también según qué compilador hayamos utilizado, por ej. en Visual Basic suele ser muy fácil llegar a este punto.

LLegados hasta aquí, ya sé que muchos se preguntan... pero yo quiero hacer mis protecciones y quiero fabricar un programa DEMO y licencia y.... ahora lo veremos en el siguiente apartado.

[Ingeniería Inversa]

Hiice un nuevo crackme para que se diviertan en los momentos de ocio. Es anti -bad injections.

http://wikisend.com/download/470810/crackme.rar

Lo he analizado desde el punto de vista de Ingeniería Inversa, y has sido un poco malévolo. Si no me equivoco lo has programado en Dev-C++ 4.9.9.2 (tal vez) y lo has hecho en consola simulando que lo habías programado en Batch. He visto que llamas a la función time y seguidamente haces unas pequeñas operaciones y te sale un número. Ese es el número de contraseña. Por eso difiere en cada ejecución.
Me ha parecido muy interesante.

Un saludo

[Protecciones contra debuggers/desensambladores]

Protecciones contra debuggers/desensambladores

Sea cual sea la opción elegida de las dos mostradas, se suelen implementar distintas medidas contra el desensamblado del código o contra debuggers.



Protección de packers:

A día de hoy, los softwares para empaquetar aplicaciones están muy avanzados y no hace falta decir que existen empresas que dedican su tiempo en seguir investigando estos métodos. De este modo, y cada vez más a menudo, los nuevos packers que aparecen son obras de arte muy difíciles de romper y seguramente toda protección que se te ocurra ya ha sido investigada hasta la saciedad.
Sin embargo, cada protección, sea hecha por el usuario o sea utilizando software especializado es un mundo diferente y cada una tiene su complejidad.

Por otro lado, como los software de protección han avanzado tanto, pues también los que depuran las aplicaciones han avanzado tanto o más camino; conocen la mayoría de protecciones utilizadas y cada vez aparecen más herramientas de ayuda que hacen la depuración de programas una tarea muy sencilla. No hace falta decir que hay personas con unos conocimientos muy elevados y no solamente en el ámbito donde se mueven generalmente los software (ring3) sino a niveles donde trabaja el Sistema Operativo o incluso ¡por debajo de él!.


Desde hace muchos años se vienen estudiando formas para que sea más complicado acceder al código y poder utilizar dicha información; sin ir más lejos recuerdo perfectamente juegos de aventuras conversacionales de mi antiguo ZX Spectrum a 128K donde se encriptaban las cadenas de texto para que con un debugger no fuera tan sencillo encontrar la "palabra clave".

Actualmente, según mi opinión y mi experiencia, los software para empaquetar aplicaciones no se preocupan tanto en evitar que se pueda desensamblar/debuggear el código, sino lo que hacen es:
-Uso de Máquinas Virtuales para la creación del código
-Creación de zonas dinámicas de memoria donde se ejecutará parte de código.
-Código ofuscado: con mucho código inútil de más para evitar que se entienda el desensamblado. Esto hará aumentar de tamaño tu aplicación.
-Emulan la funciones y por consiguiente las llamadas a las mismas, por ejemplo si en nuestro código hemos hecho una llamada a MessageBox, pues la API MessageBox será totalmente emulada y posiblemente ofuscada.
-El mismo packer ejecuta las primeras instrucciones de tu programa y devuelve el control al mismo después, por lo tanto, conocer todo ese código que ya se ha ejecutado es un problema grandísimo. Si son sólo unos bytes los que han desaparecido se denomina Stolen Bytes, si por el contrario es gran parte de código se denomina Stolen Code.
-Suele ser muy fácil llegar a la comprobación de Nombre-Serial, pero han creado tantísimo código y tal complejidad a la hora de analizar un nombre-serial válido que es dificilísimo encontrarlo y por tal motivo se prefiere reparar el programa.
-Y algunas cosas más que iré añadiendo...

El lector dirá, y ¿qué consiguen con todo eso? Pues está muy claro:
1º- Hacen tan difícil encontrar un nombre-serial que el cracker seguramente desestimará esta opción porque requiere muchas horas y días de análisis.
2º-Imaginemos que al cabo solamente de 2 minutos encontramos un salto (que en ensamblador puede ser "je") que salta cuando estamos registrados pero que no salta cuando no lo estamos. Bien, sabiendo esto podríamos modificar el salto y se puede pensar que el asunto está arreglado... Aquí está la dificultad, que como la aplicación está empacada tú no puedes modificar ese "je" por un "jne" porque ese "je" todavía no existe y probablemente sea ejecutado en una memoria dinámica (que con cada ejecución varía) que el packer crea a la hora de descomprimirse.
3º-Al emular la funciones (IAT - Tabla de Importaciones), es muy difícil saber cuáles son y por lo tanto al intentar reconstruirlo puede resultar extremadamente complicado.
4º-El uso de Máquinas Virtuales hace muy difícil saber el camino que el packer está tomando.
5º-Como cada packer es un mundo diferente pues también sus protecciones.

En resumen de todo esto:
Para descomprimir un programa empacado, es necesario llegar y pararse en el punto de entrada del programa original (OEP), arreglar la IAT, reparar los Stolen Code o Stolen Bytes, el código que se ejecuta fuera de la memoria de la aplicación introducirlo dentro etc... Se trata de quitar el packer de la aplicación y dejar solamente esta última.
Es decir, un trabajo muy laborioso pero que en determinados casos como es un trabajo repetitivo con la práctica lo puedes resolver en unas cuantas horas.

Seguro que después de haber metido toda esta parrafada algunos no saben ni de lo que he hablado, bueno solamente hay que quedarse con lo más importante y si de verdad quieres indagar en el tema releer todo lo que he escrito o preguntar en el foro. Todo lo comentado suelen ser las protecciones habituales de packers comerciales. Y... a nivel de implementar uno mismo su protección ¿cómo se puede evitar el desensamblado/debugger?



Proteger uno mismo su aplicación:

Después de lo que se ha comentado, alguno pensará... pero si está todo estudiado ¿qué protección puedo yo poner a mi aplicación?
Aquí viene la invención de cada persona. Hay gente que tiene muy buenas e innovadoras ideas.

Siempre se han utilizado técnicas muy conocidas por todo el mundo como pueden ser:
-Uso de la API IsDebuggerPresent que se encuentra en la librería kernell32.dll. Es la más conocida por todo el mundo, simplemente se llama a esta API y si el resultado de la misma es 1 hay debugger, si es 0 no hay debugger.
-Retardo en la ejecución de código: es decir, si por ej. en cargar tu aplicación tiene que pasar solamente 1 segundo y han pasado 45 segundos --> ¡hay debugger!. Esto se suele hacer de varias formas: usando la función GetTickCount o usando funciones que te devuelven la fecha actual, incluídos segundos: GetLocalTime, GetSystemTime. Seguro que tú conoces muchas más formas. Te puedo indicar una muy curiosa que yo he usado de prueba y funciona perfectamente y es en ensamblador con la instrucción RDTSC. Esta última instrucción es interesante ya que si se ejecuta dos veces una detrás de otra, verás que el resultado de ambas es prácticamente igual, sin embargo, si ha pasado determinado tiempo entre la ejecución de la primera RDTSC y la segunda los valores son totalmente diferentes.
-En Window, el registro FS apunta hacia una estructura llamada Thread Information Block (TIB). Esta compleja estructura tiene otras y más complejas estructuras y en ella podemos tener información de si un Debugger está depurando la aplicación o no.
Ejemplos: GlobalFlags sería en ensamblador implementado de la siguiente forma:

mov eax, dword ptr fs:[30h]
mov eax, dword ptr ds:[eax+68h]

Si el resultado es cero --> no hay debugger
Si el resultado es distinto de cero --> hay debugger
Del mismo modo hay otras formas similares: ProcessHeap Flag, PEB_LDR_DATA etc...

-Podemos hacer uso de distintas API: ZwQueryInformationProcess, ZwSetInformation Thread, ZwQuerySystemInformation... Hay cosas muy curiosas incluso utilizando la función CsrGetProcessId que se encuentra ni más ni menos que en ntdll.dll. De este último ejemplo tengo uno hecho en ASM por si alguien quiere analizarlo.

-Podemos también investigar si se está usando algún debugger examinando los procesos que se están ejecutando. Esto se suele hacer de dos formas:
    *Utilizando la API CreateToolhelp32Snapshot desde el primer proceso Module32First y después yendo uno por uno con Process32Next.
    *Utilizando EnumProcesses que devuelve un array con el PID de cada uno de los procesos. Hay que observar que podemos también ver los procesos que cada proceso está ejecutando.

-Podemos buscar por el nombre o clase de ventana. Para esto utilizamos la API FindWindow.

-Evitar el uso de Breakpoints. Los Breakpoints, utilizados por un debugger, son lugares en donde el debugger para porque el usuario ha modificado una instrucción por INT3 (interrupción). Esto es una ayuda considerable, ya que se pueden poner muchos BP (breakpoints) en lugares adecuados para el análisis del código. En tu código si programas en ASM, puedes comprobar en sitios determinados, si se ha modificado la instrucción por un INT3. También es posible llamar a la API VirtualProtect y modificar las propiedades de determinada sección. Los BP serán borrados.

-Detección de Hardware Breakpoints. Un debugger puede poner infinidad de BP, pero solamente puede poner 4 HBP (Hardware Breakpoints). Son muy útiles, más cuando los BP normales fallan. Muchos packers lo que hacen es detectar estos HBP para saber si hay debugger o no. Para esto hay que entender antes las SEH o manejo estructurado de excepciones. De este tema tan interesante, hice un tutorial bastante completo para entender las SEH:
http://foro.elhacker.net/index.php/topic,173855.msg823053.html
Después de que hayas leído ese tute, ya puedo seguir con la explicación de cómo se detectan los HBP. Un packer normalmente hace lo siguiente:
   *Crea una excepción cualquiera
   *Se ejecuta el manejador de excepciones que él mismo tiene preparado
   *Desde el manejador de excepciones puede acceder directamente a los HBP.
   *Si hay HBP --> hay debugger

-Bugs. Este tema es obvio. Al igual que hay bugs en grandes proyectos, pues también hay bugs en herramientas para la depuración de programas. Determinados programas hacen uso de estos bugs para que el programa crashee.
Sin ir más lejos, OllyDBG 1.10 tiene un bug archiconocido por todo el mundo que es el siguiente: Utilizar la API OutputDebugStringA y pasarle como parámetro una cadena "%s....." de tamaño igual a 100, es decir, cien %s. OllyDBG 1.10 no puede continuar. Como véis hay gente que también estudia todas estas cosas.

Bueno, estas son las más conocidas técnicas antidebugging. Realmente existen muchísimas, que seguro ni yo conoceré, pero para entender un poco todo este misterio con las anteriores sobra.

Estas técnicas son las más habituales y que todo el mundo más o menos conoce. Entonces, ¿no es bueno ponerlas en nuestra aplicación? ¿van a ser siempre detectadas? En el siguiente apartado lo veremos...

Bueno, parece ser que quitando la dll molesta ya has hecho funcionar al Olly.
Todo es cuestión de probar y examinar lo que estás haciendo. Modificar saltos sin sentido no suele tener éxito, debes examinar para qué pueden ser dichos jne, je...

Si no lo tienes muy claro modifica uno por uno y ve el resultado en pantalla.

Si está empacado es distinto, debes primeramente desempacar llegando al OEP y después dumpear y probablemente después arreglar la IAT.

También puedes intentar descubrir nombre-serial por si se comparan directamente.

De todos modos, te recomiendo que visites estos enlaces:
http://foro.elhacker.net/ingenieria_inversa/taller_de_cracking_desde_cero_27julio2008_ultima_actualizacion-t180886.0.html
http://ricardonarvaja.info/WEB/INTRODUCCION%20AL%20CRACKING%20CON%20OLLYDBG%20DESDE%20CERO/EN%20FORMATO%20DOC/

Hola chatiel, yo te voy a dar mi opinión.

Primeramente te voy a contar que me he enfrentado a dos mochilas Hasp HL. A las dos las he vencido insertando la mochila en su USB y después tratando al programa como si fuese un packer normal y corriente.
De una de las mochilas, hice incluso un tutorial:
Descargar tute HASP HL por karmany

Ahora bien, yo en este tema de mochilas intenté como tú bien dices emularla y después de fracasar en un montón de intentos decidí hablar con gente experimentada en estos lances que me respondió lo siguiente:

-"Mira karmany, para emular la mochila, no basta con conocer el contenido de esos 128 bytes que comentas. Con eso sólo solucionas las llamadas a la memoria que pueda realizar el programa con las funciones ReadBlock (32h) y ReadWord (3h). Pero existen dos funciones (3C EncodeData y 3D DecodeData) que utilizan un algoritmo de cifrado que creo que es función de una tabla interna que tiene la pastilla y no de esa memoria a la que haces referencia. Por lo tanto no basta con conocer el contenido de esa memoria para llevar a cabo la emulación."

Entonces yo te respondo, después de la experiencia que tuve hace unos años, y según tú has respondido: "Puedo ayudarlos a crear los emuladores y no cobro nada por hacerlo", nos sería de muy gran ayuda si nos demostrases que se pueden emular las mochilas actuales. Yo por lo menos no he podido y te prometo que he investigado muchas cosas.
Si nos puedes suministrar esa información haciendo un simple mini-tute en este foro, cambiaré de opinión, pero yo pienso que con las mochilas actuales es muy difícil emularlas. Espero tu respuesta...

Un saludo
karmany

Hola Xen11.

1.- Si pones imágenes modifícales el nombre o dí que es un CrackMe pero no pongas fotos originales ni digas qué programa es. Se trata de aprender Ingeniería Inversa y saber depurar programas y aprender siempre algo nuevo... me entiendes... Aunque ya he visto que has analizado el "CrackMe" en Visual Fox 7 muy bien.

2.- Mira este enlace en donde se analiza un "CrackMe" hecho en Visual Fox:
ENLACE TUTE

Verás que es utilizada una herramienta denominada ReFox, que te puede ayudar muchísimo.