Ni fasm ni masm compilan  Ensamblan.

Los codigos ensamblados entre masm y fasm son sumamente similares si es el mismo codigo, y es el mismo programador.

Lo que ocurre, es que se notan los estilos que usa un programador ya que la ejecutable es un reflejo del codigo fuente (mas en fasm, por eso se llama flat assembler)

fasm no es el que usa los jmps, los use yo en esta ocacion por pereza.
Normalmente se coloca las variables/constanes/cadenas  en la sección .data
Y en este crackme use jmps porque no queria subir en el codigo fuente para volver a bajar a donde estaba antes....
Entonces, hice lo que borland con pascal/delphi viene haciendo hace años
La unica gran diferencia entre masm y  fasm, es como manejan las importaciones.
en masm, normalmente tenes :
CALL <JMP.&KERNEL32.GetModuleHandleA>
mientras que en fasm
CALL [<&kernel32.GetModuleHandleA>]

masm ahora 1 byte por cada llamada. Aunque en fasm se puede hacer de cualquiera de las dos maneras.

No se detiene en 00402683 porque el serial no cumple los requesitos minimos.
La 2da y 3er llave maestra generada  a partir del serial  tienen que ser un intervalo (inicial - final) dentro del programa.

El exe que "no funcionaba" si es identico, pero la 2da y la 3ra llave maestra (inicio/fin) varian porque obviamente la ejecutable varia.

Al principio creia que la ejecutable era muy dificil de parchear, pero ahora que lo estoy viendo, sabiendo la info que tienes, es perfectamente factible  realizar un self uncrypt al principio de la ejecutable y llamar la rutina de registro ya decifrada.
 

para hayar el inicio y el fin no es tan complicado como parece, la ejecutable tiene tan solo unos 8-9 bloques que parecen encryptados.

Como pequeña ayuda, añado que los bloques cifrados son enteros, es decir, desde el ret del procedimiento anterior hasta el comienzo del proximo procedimiento.
Esta hecho asi a proposito para facilitar el decifrado.

Sobre cryptool, no hara falta, dentro del bloque encryptado hay cadenas de texto... y sabiendo que son caracteres hexa... las posibilidades son muy pocas, manaualmente con un poco de tiempo se pueden deducir.

Si hay partes de codigo  que son dificil de analizar/obfuscados/muchos saltos Olly deja de analizar esa parte de codigo porque no sabe como hacerlo.

No, no tiene nada que ver con DLL. Es matematica o  matematica booleana/logica pura.


Suponte esta pseudo rutina de generacion:
(usuario 4 letras)
(serial 4 letras)

usuario xor llave = serial.


de ahi se puede deducir:
serial xor usuario = llave
serial xor llave = usuario




la rutina de comprobacion NUNCA DEBE SER
serial valido = usuario xor llave
comparar (serial valido, serial introducido)

Porque no? porque le estas dando la respuesta al cracker.

Lo que si puede hacerse, es:
llave prueba = serial xor  usuario
comprar(llave prueba, llave maestre)


obviamente XOR es solamente simbolico, la rutinas de generacion/validacion suelen ser mas complicadas, mas rebuscadas, etc... Pero el principio basico es el mismo.
NUNCA, NUNCA colocar la rutina de generacion dentro del programa. Si obviamente de comprobacion.

y la regla basica del reverser/cracker:  La rutina de generacion es la inversa de la rutina de comprobacion.
En estos casos, toca pensar un poquito. Si el programa tuviera la rutina de generacion, es ya asunto resuelto.

Espero haberte aclarado la duda y no haberte confundido mas.



Flamer:
En mi crackme, existe solamente un serial valido para cada usuario. Si le cambias 1 letra al usuario, minimo 8 bytes del serial van a cambiar.

Tinki
fijate documentacion sobre alguna de estas funciones: sscanf/wsprintf/sprintf/printf etc...
%X o %iX indica un numero hexadecimal.
8 indica la cantidad de caracteres a devolver
0 antepuesto al 8, indica que si faltan caracteres, en vez de poner espacios, coloca 0 al principio.
es decir 1234 se convierte en '00001234'

Mh...este no es un crackme de tipo visual basic, no vas a encontrar esto:

La regla numero 1 de las protecciones:
Nunca, bajo ninguna circunstancia, NUNCA se coloca la rutina que genera serials validos dentro del programa.


Eso solamente lo hacen programadores inexpertos o perezosos que no son capaces de crear la rutina inversa de la generacion de serials. Es decir, la rutina de comprobacion.

Saludos

Las comprobaciones estan para protegerte y dar pistas.... si te las salteas, 99% seguro que el programa crashee.

Hola flamer, fijate el objetivo del crackme.

Habilitar los menus registrando el programa.
El objetivo no es registrar el programa, sino que habilitar las funciones del menu del programa registrado.
Es decir, si registras, habilitas.
En teoria deberia ser posible registrar parcheando.

Es decir, una vez que te registras, se te van a habilitar los menus. Cuando abras una opcion del menu, en vez de decirte "primero debes registrar"  te va a salir  un mensaje de felicitaciones. Mas preciso, un MessageBox de felicitaciones.

son todos micros de 8 bit, mucha diferencia no hay. Alguno tendra mas instruccioens que otro, pero la diferencia estara mas que nada en intrucciones repetitivas, como poner en 1 cada bit de los flags, etc...

z80 y 8080 son sumamente similares, sino que hasta un punto iguales.

Luego el de la nes, 6800 tampoco es mucho mas diferente a los anteriores.

Sobre emular la NES... No se si desarmaste alguna vez una NES, pero adentro  no esta solamente el 6800...
Si fuera asi, solamente seria un microprocesador y no una consola de juegos. La nes incluye: 6800, PPU, DMA y la tarjeta midi. Y adicionalmente, hay aproximadamente 100 tipos de mappers, practicamente cada juego de nes famoso tiene su propio mapper.


Java? un micro?  si te refieres a implementar el JVM,  tacha ese de la lista.


8080 es casi igual al z80 pero con menos instrucciones, y si encima te lo dan en clase... la mejor opcion.
http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html

Saludos.

Mas que con el fichero, intenta mejor analizar la rutina de verificacion del serial.
No vas a poder resolverlo si no logras generar claves validas.

No obfusque el codigo, ni le hice saltos innecesarios... esto es solamente depurar, analizar, reversear la rutina de generacion, y luego me imagino que algo de suerte^^

y sobretodo recuerda, no hay azar, todo se hace por alguna razón, el código no es aleatorio.. cada comprobación/instrucción es esencial para el correcto funcionamiento de programa.
Si esquivas saltos en la comprobación de la rutina... es probable que termines literalmente en "cualquier lado"

Saludos.