Buenas The Swash,
pues simplemente he buscado qué línea producía el error que impedía al crackme ejecutarse en W7.
Era la línea 0x301848 que pertenece a la función:
Código: Seleccionar todo
0030182F 60 PUSHAD
00301830 33D2 XOR EDX,EDX
00301832 64:8B32 MOV ESI,FS:[EDX]
00301835 AD LODS DWORD PTR [ESI]
00301836 83F8 FF CMP EAX,-1
00301839 74 04 JE SHORT 0030183F
0030183B 8BF0 MOV ESI,EAX
0030183D ^ EB F6 JMP SHORT 00301835
0030183F 8B7E 04 MOV EDI,[ESI+4]
00301842 81E7 0000FFFF AND EDI,FFFF0000
00301848 66:813F 4D5A CMP WORD PTR [EDI],5A4D
0030184D 74 08 JE SHORT 00301857
0030184F 81EF 00000100 SUB EDI,10000 ; UNICODE "=::=::\"
00301855 ^ EB F1 JMP SHORT 00301848
00301857 8BDF MOV EBX,EDI
00301859 035B 3C ADD EBX,[EBX+3C]
0030185C 66:813B 5045 CMP WORD PTR [EBX],4550
00301861 74 02 JE SHORT 00301865
00301863 ^ EB E3 JMP SHORT 00301848
00301865 897C24 1C MOV [ESP+1C],EDI
00301869 61 POPAD
0030186A C3 RET
y generaba el error "Access violation when reading [...]".
Como bien sabes en FS:[0] Windows carga su manejador de excepciones, para que en caso de error en la ejecución del programa el S.O. actúe en consecuencia. El problema viene porque parece que ese manejador difiere entre el WXP y el W7. O sea que si arrancas un programa con el OllyDbg en el XP y vas a "View -> SEH chain", y luego lo sigues en la pila verás algo así:
Código: Seleccionar todo
0012FFE0 FFFFFFFF End of SEH chain
0012FFE4 7C839AC0 SE handler
0012FFE8 7C817070 kernel32.7C817070
mientras que haciendo lo mismo en el 7 verás esto en la pila:
Código: Seleccionar todo
0018FFC4 |FFFFFFFF End of SEH chain
0018FFC8 |772F71D5 SE handler
0018FFCC |0198B283
Vamos, en XP hay dos direcciones del kernel32 y en el 7 una única del ntdll. Y como lo que pretende el código es sacar la dirección dónde está cargado el kernel32 a partir de esa segunda dirección que falta en el Windows 7 ya tenemos el error.
Así que lo único que he hecho es cambiar el código por:
Código: Seleccionar todo
0030182F 60 PUSHAD
00301830 33D2 XOR EDX,EDX
00301832 64:8B32 MOV ESI,FS:[EDX]
00301835 AD LODS DWORD PTR [ESI]
00301836 83F8 FF CMP EAX,-1
00301839 3E:8B7C24 28 MOV EDI,DS:[ESP+28]
0030183E 90 NOP
0030183F 90 NOP
00301840 90 NOP
00301841 90 NOP
00301842 81E7 0000FFFF AND EDI,FFFF0000
00301848 66:813F 4D5A CMP WORD PTR [EDI],5A4D
0030184D 74 08 JE SHORT 00301857
0030184F 81EF 00000100 SUB EDI,10000 ; UNICODE "=::=::\"
00301855 ^ EB F1 JMP SHORT 00301848
00301857 8BDF MOV EBX,EDI
00301859 035B 3C ADD EBX,[EBX+3C]
0030185C 66:813B 5045 CMP WORD PTR [EBX],4550
00301861 74 02 JE SHORT 00301865
00301863 ^ EB E3 JMP SHORT 00301848
00301865 897C24 1C MOV [ESP+1C],EDI
00301869 61 POPAD
0030186A C3 RET
para que EDI en la línea 0x301848 esté apuntando a una zona del kernel32.
Y ese es el único cambio a realizar en el código, pero como todo el mundo ha observado el programa está ofuscado y encriptado. Así que tocó ver cómo se desencriptaba. También muy sencillo: he puesto un HWBP de escritura en 0x301839 y he visto lo que hace para luego invertirlo ya que simplemente para cada dword hace un ADD, un ROL y un XOR con un valor que se incrementa 0x25D4140 cada vez que cambia al siguiente dword. No creo que tengas ningún problema en encontrar esta parte del descifrado en el código y su funcionamiento por si también quiereso necesitas parchear algo más.
De todas formas si tienes cualquier duda no dudes en preguntar que intentaré ayudarte en lo que pueda.
Saludos.
PD: He escrito todo este post como dando por hecho que la diferencia es entre el Windows XP y el Windows 7, pero no estoy para nada seguro. También podría ser una diferencia entre windows de 32 y 64 bits. Así que si alguien lo puede probar en un Windows XP de 64 bits y/o en un Windows 7 de 32 bits le estaría muy agradecido.