Mensajes

1)No he depurado el programa, pero por un vistazo rapido del tutorial creo que:
Como en este caso son "stolen kilobytes", es decir, una buena parte del codigo ha sido movida, para el caso, la rutina de inicio.
Entonces, en vez de redirigir el programa a la verdadera rutina de inicio (cambiando EP, por el OEP) que es lo que normalmente se hace, y se colocan los stolen bytes, en este caso, como los stolenbytes no estan "escondidos" sino simplemente movidos a otro lado sin saltos inecesarios, el autor del articulo decidio  mover esos stolen bytes al EP del programa.

Es decir, en vez de buscar el OEP y remplazar alli los stolen bytes, mueve  la rutina inicial (stolen kilobytes) al EP de la ejecutable, es decir, EntryPoint ejecutable empaquetada que ahora fue desempaquetada.


Creo que lo que permitio hacer esto fue que el programador del unpackme, remplazo la rutina inicial de la oep por otra rutina.  Y escondió toda la rutina inicial.
Entonces, marciano colocó la rutina completa en el EP del programa y de seguro que esta rutina inicializa la ejecutable, y luego hacen un salto far o un call far a una direccion de memoria absoluta, por eso el codigo se pudo seguir ejecutando.

2)hablando de saltos absolutos, cambiamos a CALL NEAR. Son saltos a rutinas que se encuentran dentro del mismo segmento del codigo, por ende, su direccion es relativa a la posicion actual. Una call near repetido dos veces nunca tiene el mismo opcode.
ej:

0040102A     E8 1E000000    call    KeyMeNoD.0040104D
0040102F     E8 19000000    call    KeyMeNoD.0040104D
00401034     E8 14000000    call    KeyMeNoD.0040104D
00401039     E8 0F000000    call    KeyMeNoD.0040104D
0040103E     E8 0A000000    call    KeyMeNoD.0040104D
00401043     E8 05000000    call    KeyMeNoD.0040104D
00401048     E8 00000000    call    KeyMeNoD.0040104D ;call inutil, llama instruccion siguiente
0040104D     E8 FBFFFFFF    call    KeyMeNoD.0040104D ;call imposible, se llama a si mismo generando stackoverflow
00401052     E8 F6FFFFFF    call    KeyMeNoD.0040104D
00401057     E8 F1FFFFFF    call    KeyMeNoD.0040104D
0040105C     E8 ECFFFFFF    call    KeyMeNoD.0040104D
00401061     E8 E7FFFFFF    call    KeyMeNoD.0040104D
00401066     E8 E2FFFFFF    call    KeyMeNoD.0040104D
0040106B     E8 DDFFFFFF    call    KeyMeNoD.0040104D
00401070     E8 D8FFFFFF    call    KeyMeNoD.0040104D
00401075     E8 D3FFFFFF    call    KeyMeNoD.0040104D
0040107A     E8 CEFFFFFF    call    KeyMeNoD.0040104D

Son todos llamados contiguos.
Cada llamado ocupa 5 bytes.
Casualidad que cada vez que  se genera el opcode E8 VVXXYYZZ,  VV disminuye en 5 (cada vez se acerca en 5 bytes a donde se hace el salto)

Al hacer copy past de los stolen bytes, en el lugar donde NO corresponden, las direcciones relativas de los OPCODES en los CALL NEAR no sirven, son distintas.
Es decir, CALL    miprograma._mifuncionX sigue siendo la misma intruccion (texto) pero los opcode son diferentes (binary past no sirve)



0)Del primer punto no estoy seguro, no me he puesto a desempaquetar programas, no tengo experiencia en el area,  pero por lo que pude ver, tendria que ser eso. Es la única

saludos.

Te falto un detalle importante.

lodsb y stosb incrementan esi y edi respectivamente (Si NO esta puesto DF, si DF esta puesot, decrementa esi y edi respectivamente)


muy comodo a la hora de mover cadenas si se esta haciendo un auto-keygen.

Código [Seleccionar] Expandir



  mov esi, cadena_original
  mov edi, cadena_destino
  mov ecx, tamano_cadena
label:
  lodsb
  stosb
  loop label



por cierto und3r, lodsb y stosb no son opcodes. "AC" y "AA" son los opcodes.
stosb y  lodsb son MNEMONICOS,  o mejor aun  INSTRUCCIONES del ensamblador.

Es lo que hace el ensamblador, convertir "stosb" en  "AA"
saludos

Buenas:

0)Los buffer generalmente son multiplos de 2^2: 2, 4, 8, 16, 32, 64, 128, 256, 512 etc.. La optimizacion es mejor de esta forma.

2) 30 no es 30decimal, es 30h hexadecimal. Lo mismo 46h
codigo ascii 30h  = '0'
codigo ascii 46h =  'F'
es decir, son valores ascii de numeros hexadecimales.


etc..)No es un foro de criptografia, sino de ingenieria inversa que no es lo mismo.
HACE FALTA LA EJECUTABLE, que abre ese archivo, de lo contrario es dificil ayudar.

pero por el nombre del archivo, parece ser simplemente una firma digital.

saludos.

Na hombre, yo lo decia porque es la conclusi'on que podía sacar con la info que tenia xD

mientras que te funcione ^^.

Lee tu primer post.

(la que tengo es del 2003 y me apaño)

yo no fui el que creo la confusion  

tampoco sabia que le habias pasado vos el instalador, no estaba en los post, as'i que supuse que under busco algun instalador por ahi y consigi'o el 2002.

muy sencillo.... el parche es para la version del 2002,  y tu tienes la del 2003.

si hubieras subido el instalador, ya lo tendrias solucionado 

Si vas a leer algo, y puedes leer en ingles:

http://www.intel.com/products/processor/manuals/
Volume 1: Basic Architecture
Volume 3A: System Programming Guide, Part 1

y amd:
http://developer.amd.com/documentation/guides/pages/default.aspx#developer_guides
Manual Volume 2: System Programming   
Manual Volume 1: Application Programming

saludos.

Buenas y Felicitaciones!!!!

Luego un dia de estos, sube un tuto que me gustaria saber como fue que hiciste la segunda parte.
Nunca tuve que hacerlo, me imagino como debe ser la tecnica, pero no la puedo probar con mi keygenme porque forzozamente, si se el key.

El keygenme mas que nada lo hice para practicar cifrado básica usando las macros de fasm.
Si te fijas en el codigo fuente, la rutina que esta cifrada dentro de fuente no esta hardcoded.
Y mantuve las rutinas bien solidas para no confundir. Por eso el lvl 4 de 5.
Ahora estoy trabajando en un keygenme con un lvl 3+ de 5. (Casi lvl 3 xd, ya habra noticias)


Desde ya gracias por intentarlo^^

Es que hay una cosa que estas ignorando creo...

asm 32 bit no es invoke MessageBoxA, [hwnd], szMsg, szMsg, MB_ALERT


El modo protegido (32 bit) es mucho mas completo que el real (16bit).
Lo unico que no puedes hacer en 32bit es ejecutar interrupciones de la Bios porque la BIOS funciona en modo real.

Lo que ocurre, es que si programas para Windows terminas usando la WinApi y el codigo no es mucho mas distinto de lo que se ve en C.


Si usas Debug.exe en WinXP estas usando un emulador de DOS.
Para que realmente puedas comprar ambas modos, tendrias que  hacerlo en una maquina virtual con tu propio SO, de lo contrario son llamadas a la winapi.

Basicamente, asm 32bit sobre windows, es como si fueras a un tenedor libre, pero solo te dejan comer ensalada de pepino, cebolla y tomate.

En WinXp32, el modo real está emulado. Cuando ejecutas un programa de 16 se esta ejecutando sobre un especie de emulador.
En Win7 de 64 no. Y en Win7 de 32 creo que tampoco, tengo la duda.

La solucion mas facil, es usar DosBox para correr los programas de 16 bit.

Aunque claro, no le veo la razon de estar aprendiendo con  Tasm16, Masm16 etc...Al fin y al cabo, estamos en el 2011.