ESTUDIO COLECTIVO DE DESPROTECCIONES

INTRODUCCION

Hola a todos. Mi nick es KeopS. Llevaba algún tiempo queriendo hacer un tutorial sobre el SafeDisc 2 (a partir de ahora SD2) pero no ha sido hasta ahora cuando, animado por varios colegas, me he decidido a escribir algo. No es un tutorial que pretenda destripar el SD2 sino una pequeña introducción a esta protección.

OBJETIVO

Como todo el mundo sabrá a estas alturas (y si no para eso estamos aquí ;-) los chicos de Macrovision utilizan el algoritmo TEA (Tiny Encription Algorithm) para encriptar los productos protegidos con SD2. TEA es de dominio público, lo cual significa que se puede utilizar libremente, y su funcionamiento se basa en encriptar cada vez 64 bits de datos utilizando una llave de 128 bits.

El programa principal de la aplicación protegida con SD2 (el fichero .exe normalmente) es encriptado utilizando el algoritmo TEA. Esta encriptación evita que la aplicación pueda ser ejecutada directamente, y obliga a que tenga que ser desencriptada por el lanzador ó cargador SafeDisc (SafeDisc Launcher) para funcionar correctamente. Dicho lanzador verifica que un CD con una "firma SafeDisc" auténtica y correcta esté presente en el lector de CD-ROM. Si dicha firma es encontrada, desencripta y ejecuta la aplicación, si no aparecerá un bonito mensaje diciéndonos que introduzcamos el CD original.

Después de leer lo anterior parece claro que:

1. No es posible ejecutar un programa protegido con SD2 sin saber la llave TEA, y además se puede intuir que la llave TEA es generada mediante algún tipo de dato cargado del CD original; 2. Es imposible hacer funcionar un programa protegido con SD2 sin el CD original.

Sin embargo, a lo largo de este tutorial se pretende demostrar que:
1. La llave TEA es generada sin ayuda de ningún dato cargado desde el CD original.
2. Una vez obtenida dicha llave es posible ejecutar el juego sin el CD original.

Para demostrar todas estas afirmaciones utilizaré los juegos HITMAN y SACRIFICE, así como el debugger TRW2000. Si no dispones de estos juegos no importa, ya que todas las afirmaciones aquí expuestas son extensibles a todos los juegos protegidos con la versión 2.05.030 del SD2 (Alice, No One Lives Forever, NBA Live 2001, ... ). Actualmente ya hay una nueva versión del SD2, la 2.10.030, (parche 2 del Sacrifice, Black& White, Undying, ... ) que difiere de la anterior en algunas cosas, aunque en lo esencial sigue siendo igual ;-)

Quizás alguien se esté preguntando, ¿y para qué me interesa a mi conocer la llave TEA y poder arrancar el juego sin el CD original? Estuve dándole vueltas a la forma de plantear el tutorial, y llegué a la conclusión de que esta era la mejor forma de que la gente se interese por esta protección. Con este tutorial te doy la oportunidad de que puedas estudiar el SD2 a fondo sin necesidad de poseer un CD original, basta disponer de una copia normal del juego en cuestión. Obviamente, yo no estoy haciendo apología de la piratería sino que todo lo expuesto aquí es con propósitos educativos únicamente. Así que por favor si un juego te gusta CÓMPRALO ya que es la mejor manera de que se sigan haciendo juegos de calidad.

OBTENIENDO LA LLAVE TEA

1. La llave original

Denomino así a la llave que originalmente se encuentra dentro del archivo ~DE18B0. TMP (HITMAN) (que en realidad es el archivo AuthServ. dll), y que sirve como base para generar la verdadera llave TEA. Esta llave siempre está situada en la dirección: Image Base del archivo AuthServ. dll + 02D660h. En mi caso, la dll tiene una Image Base de B70000, y por lo tanto la llave original se encuentra en la B9D660:

00B9D660 48 26 8D 5C C2 2E F5 51 A2 A3 2C 95 77 78 48 87 H&°\ Â. õQ¢£,° wxH*
Por otra parte, esta llave original es siempre copiada a la dirección 100500F0, según se puede ver en la siguiente rutina:


100049EF MOV WORD [EBP-04], 00 ; coloca a 0 la variable contador 100049F5 JMP SHORT 10004A03
100049F7 MOV AX,[ EBP-04] 100049FB ADD AX, 01
100049FF MOV [EBP-04], AX 10004A03 MOV ECX,[ EBP-04]
10004A06 AND ECX, FFFF 10004A0C CMP ECX, BYTE +10 ; ¿hemos copiado los 10h bytes?
10004A0F JNC NEAR 10004AA8 ; SI -> Acaba la rutina 10004A15 CMP DWORD [EBP+ 08], BYTE +00 ; NO -> ¿Es [EBP+ 08] igual a 0?
10004A19 JZ 10004A66 ; SI -> Vete a la rutina 2 10004A1B MOV EDX,[ EBP-04] ; NO -> EDX= 00, 01, 02, ..., 0E, 0F
10004A1E AND EDX, FFFF 10004A24 MOV EAX,[ EBP+ 08] ; EAX= B9D660 (dirección origen)
10004A27 MOV CL,[ EAX] ; CL= byte que hay en B9D660, B9D661,... 10004A29 MOV [EDX+ 100500F0], CL ; EDX+ 100500F0 (dirección destino)
10004A2F MOV EDX,[ EBP+ 08] 10004A32 ADD EDX, BYTE +01 ; Incrementa la dirección origen en 1
10004A35 MOV [EBP+ 08], EDX [Código Basura]
10004A64 JMP SHORT 10004AA3 10004A66 MOV EAX,[ EBP-04] ; Esta rutina coloca en la dirección
10004A69 AND EAX, FFFF ; 100500F0 los valores 000102... 0E0F 10004A6E MOV CL,[ EBP-04] ; que es la llave TEA que se utiliza
10004A71 MOV [EAX+ 100500F0], CL ; para desencriptar los archivos tmp [Código Basura]
10004AA3 JMP 100049F7

2. XOReos con 5 llaves de 32 bits

Una vez que la llave original ha sido copiada a la dirección 100500F0 se la somete a 5 operaciones XOR con 5 llaves distintas de 32 bits. Pero la gracia del asunto radica en que estas llaves son ¡¡¡¡¡ SIEMPRE LAS MISMAS!!!!! :-O


1001E160 MOV BYTE [EBP-08], 00 ; coloca a 0 la variable contador 1001E164 JMP SHORT 1001E16F
1001E166 MOV DL,[ EBP-08] 1001E169 ADD DL, 04
1001E16C MOV [EBP-08], DL 1001E16F MOV EAX,[ EBP-08] 2.
1001E172 AND EAX, FF 1001E177 CMP EAX,[ EBP+ 0C] ; [EBP+ 0C]= 10h ¿hemos XOReado los 10h bytes?
1001E17A JNC 1001E194 ; SI -> Acaba la rutina 1001E17C MOV ECX,[ EBP-04] ; NO -> ECX= 100500F0
1001E17F MOV EDX,[ ECX] ; EDX= contenido de la 100500F0 1001E181 XOR EDX,[ EBP+ 10] ; [EBP+ 10] = llave de 32 bits
1001E184 MOV EAX,[ EBP-04] ; EAX= 100500F0 1001E187 MOV [EAX], EDX ; Coloca el nuevo valor en la 100500F0
1001E189 MOV ECX,[ EBP-04] ; ECX= 100500F0 1001E18C ADD ECX, BYTE +04 ; Incrementa la dirección de ECX en 4
1001E18F MOV [EBP-04], ECX 1001E192 JMP SHORT 1001E166

Los valores que la dirección [EBP+ 10] va teniendo son:
1ª llave de 32 bits:
0064ECEC AC FE 94 E0 0B 00 00 00 30 ED 64 00 CD 1C 66 00 ¬þ" à.... 0íd. Í. f.
2ª llave de 32 bits:
0064ECEC 3E FA 27 98 0B 00 00 00 30 ED 64 00 CD 1C 66 00 >ú'~.... 0íd. Í. f.
3ª llave de 32 bits:
0064ECEC AD DE 16 52 0B 00 00 00 30 ED 64 00 CD 1C 66 00 Þ. R.... 0íd. Í. f.
4ª llave de 32 bits:
0064EC94 FC AE AB 3E 0B 00 00 00 D8 EC 64 00 CD 1C 66 00 ü®«>.... Øìd. Í. f.
5ª llave de 32 bits:
0064ECEC 3D 36 A2 42 0B 00 00 00 30 ED 64 00 CD 1C 66 00 =6¢ B.... 0íd. Í. f.
Después de estas 5 operaciones la llave tiene un valor de:
100500F0 B6 64 21 0A 3C 6C 59 07 5C E1 80 C3 89 3A E4 D1 ¶d!.< lY.\ á€ Ã‰: äÑ

3. XOReos con 2 llaves de 64 bits y 2 de 128 bits

Quizás esta sea la parte más complicada del tortuoso camino hacia la llave TEA final. Vayamos por partes. La llave que se ha obtenido es ahora sometida a 4 operaciones XOR con 2 llaves de 64 bits y 2 de 128 bits. Esta es la rutina correspondiente:


1001E30B MOV DWORD [EBP-14], 00 ; coloca a 0 la variable contador 1001E312 JMP SHORT 1001E32F
1001E314 MOV ECX,[ EBP-14] 1001E317 ADD ECX, BYTE +04
1001E31A MOV [EBP-14], ECX 1001E31D MOV EDX,[ EBP-10] ; EDX= dirección a XORear (100500F0)
1001E320 ADD EDX, BYTE +04 1001E323 MOV [EBP-10], EDX
1001E326 MOV EAX,[ EBP-08] ; EAX= dirección con la llave del morph 1001E329 ADD EAX, BYTE +04
1001E32C MOV [EBP-08], EAX 1001E32F MOV ECX,[ EBP-14]
1001E332 CMP ECX,[ EBP-18] ; [EBP-18]= 10h ¿hemos XOReado los 10h bytes? 1001E335 JNC 1001E374 ; SI -> Acaba la rutina 3.
1001E337 MOV EDX,[ EBP-0C] ; NO -> Rutina que controla la longitud de 1001E33A ADD EDX,[ EBP+ 14] ; la llave del morph:
1001E33D CMP [EBP-08], EDX ; [EBP+ 14]= 08h para las llaves de 64 bits 1001E340 JC 1001E34D ; [EBP+ 14]= 10h para las llaves de 128 bits
1001E342 MOV EAX,[ EBP-08] ; Si la llave del morph es de 64 bits: 1001E345 SUB EAX,[ EBP+ 14] ; llave TEA: wwww xxxx yyyy zzzz
1001E348 MOV [EBP-08], EAX ; XOR 1001E34B JMP SHORT 1001E337 ; llave morph: aaaa bbbb aaaa bbbb
1001E34D MOV ECX,[ EBP+ 08] ; Esta rutina controla la longitud de la 1001E350 ADD ECX,[ EBP+ 0C] ; llave TEA, pero [EBP+ 0C]= 10h, por lo
1001E353 CMP [EBP-10], ECX ; tanto no tiene mucho sentido puesto 1001E356 JC 1001E363 ; que la llave TEA siempre tiene una
1001E358 MOV EDX,[ EBP-10] ; longitud de 10h ... entonces el JC 1001E35B SUB EDX,[ EBP+ 0C] ; siempre se ejecuta :-?
1001E35E MOV [EBP-10], EDX 1001E361 JMP SHORT 1001E34D

1001E363 MOV EAX,[ EBP-10] ; EAX= dirección a XORear 1001E366 MOV ECX,[ EBP-08] ; ECX= dirección con la llave
1001E369 MOV EDX,[ EAX] ; EDX= contenido de la dirección a XORear 1001E36B XOR EDX,[ ECX] ; [ECX] = llaves de 64 y 128 bits
1001E36D MOV EAX,[ EBP-10] ; EAX= dirección a XORear (100500F0) 1001E370 MOV [EAX], EDX ; Coloca el nuevo valor en la 100500F0
1001E372 JMP SHORT 1001E314
Los valores de las llaves en la dirección [ECX] son los siguientes (HITMAN):
1ª llave de 64 bits:
00773F70 D7 7A 47 A7 FC 9F 88 2B D7 7A 47 A7 00 00 00 00 ×zG§ üYˆ+× zG§....
2ª llave de 64 bits:
007732B0 D7 52 47 A7 D4 9F 88 03 D7 52 47 A7 00 00 00 00 ×RG§ ÔYˆ.× RG§....
1ª llave de 128 bits:
007736C0 E5 2E 25 7E A4 42 5D AB 85 FA A3 A0 D0 0C A4 2E å.%~¤ B]«… ú£ Ð.¤.
2ª llave de 128 bits:
00773930 F1 CA ED 83 CC 79 D0 D2 B7 77 E0 C6 31 07 CB 60 ñÊíƒ ÌyÐÒ· wàÆ1. Ë`

Ahora viene la pregunta del millón: ¿estas llaves están ya en memoria o son cargadas del CD original?
Y si la respuesta es que ya están en memoria, ¿dónde están y cómo se generan?
Preguntas interesantes ¿verdad? Pues continúa leyendo y desvelaremos el misterio ;-)

A pesar de lo que se pueda pensar en un principio, estas llaves se encuentran en memoria
dentro del mismo archivo que la llave original AuthServ. dll, pero están encriptadas.
En concreto, las llaves originales se encuentran en la dirección Image Base + 78AEh 
en este caso –HITMAN-B778AE ya que la dll tiene una Image Base de B70000):

00B778AE 80 EB 00 86 CB 2E AF 6A C0 83 40 C6 23 6E 6F 82 €ë.* Ë. ¯jÀƒ@ Æ# no‚ 00B778BE 26 DB 2A 22 7B 48 77 13 20 26 67 27 46 76 AC 61 &Û*"{ Hw. &g'Fv¬ a
00B778CE B2 BF 62 5F 93 F3 7A EA 92 2B A4 C1 27 FD 43 AF ²¿ b_" ózê'+¤ Á'ýC¯
y, mediante la siguiente rutina se copian a una memoria intermedia para proceder a su desencriptación: 

00B77E12 MOV EDX,[ 00BA1250] ; EDX= 30h 00B77E18 PUSH EDX ; Nº de bytes a copiar
00B77E19 MOV EAX,[ EBP-1C] ; EAX= B778AE 00B77E1C PUSH EAX ; Dirección origen
00B77E1D MOV ECX,[ EBP-04] ; ECX= CC1BD0 00B77E20 PUSH ECX ; Dirección destino
00B77E21 CALL 00B88BB0 ; Copia de origen a destino con nº de bytes

Ya tenemos los valores originales de nuestras llaves colocados en memoria para su
desencriptación, así que vamos a averiguar dónde está y cómo funciona la rutina que
realiza dicha tarea. En realidad es la continuación de la rutina anterior:

00B77E45 MOV EDX,[ 00BA124C] ; EDX= C32FB757 (valor mágico) 00B77E4B MOV [EBP-18], EDX [Código Basura]
00B77E72 MOV BYTE [EBP-0C], 00 ; coloca a 0 la variable contador 00B77E76 JMP SHORT 00B77E80
00B77E78 MOV AL,[ EBP-0C] 00B77E7B ADD AL, 01
00B77E7D MOV [EBP-0C], AL 00B77E80 MOV ECX,[ EBP-0C]
00B77E83 AND ECX, FF 00B77E89 CMP ECX,[ 00BA1250] ; [BA1250]= 30h ¿hemos XOReado los 30h bytes?
00B77E8F JNC 00B77EC9 ; SI -> Acaba la rutina 00B77E91 MOV EDX,[ EBP-18] ; NO -> EDX= C32FB757 (valor mágico)
00B77E94 AND EDX, FF 00B77E9A MOV EAX,[ EBP-0C]
00B77E9D AND EAX, FF 00B77EA2 MOV ECX,[ EBP-04] ; ECX= CC1BD0 (dirección origen)
00B77EA5 XOR EBX, EBX 00B77EA7 MOV BL,[ ECX+ EAX] ; BL= byte que hay en CC1BD0, CC1BD1, ...
00B77EAA XOR EDX, EBX ; ¿Estos tipos sólo saben hacer XOReos? ;-) 00B77EAC MOV EAX,[ EBP-0C]
00B77EAF AND EAX, FF 00B77EB4 MOV ECX,[ EBP-08] ; ECX= CC1BA0 (dirección destino)
00B77EB7 MOV [ECX+ EAX], DL ; DL= nuevo valor en CC1BA0, CC1BA1, ... 00B77EBA MOV EDX,[ EBP-18]
00B77EBD IMUL EDX,[ 00BA124C] ; Generación de un nuevo valor mágico 00B77EC4 MOV [EBP-18], EDX
00B77EC7 JMP SHORT 00B77E78
Al final tenemos en la dirección destino las llaves desencriptadas:
00CC1BA0 D7 7A 47 A7 FC 9F 88 2B D7 52 47 A7 D4 9F 88 03 ×zG§ üYˆ+× RG§ ÔYˆ.
00CC1BB0 F1 CA ED 83 CC 79 D0 D2 B7 77 E0 C6 31 07 CB 60 ñÊíƒ ÌyÐÒ· wàÆ1. Ë`
00CC1BC0 E5 2E 25 7E A4 42 5D AB 85 FA A3 A0 D0 0C A4 2E å.%~¤ B]«… ú£ Ð.¤.
Por otra parte cabe preguntarse si el valor mágico con el que se desencriptan las
llaves está en memoria o es cargado del CD. Y aquí de nuevo tengo que decir que ese
valor ya se encuentra en memoria. Vamos a verlo. La variable que lo almacena es
la BA124C, así que si vamos en sentido inverso al del flujo del programa llegaremos
a una rutina con el siguiente código:

00B839F0 MOV EDX,[ EBP+ 10] ; EDX= C32FB757
00B839F3 MOV [00BA124C], EDX ; Mete el valor mágico en nuestra variable 5.

pero necesitamos seguir investigando para saber donde es colocado ese valor
en la dirección correspondiente a la [EBP+ 10], y si ese valor depende de algún otro
dato o rutina. Al final llegamos al siguiente código:

00B74813 PUSH EAX 00B74814 JMP SHORT 00B7481E
00B74816 ADD [EAX], AL 00B74818 ADD [EAX], AL
00B7481A ADD [EAX], AL 00B7481C ADD [EAX], AL
00B7481E PUSH DWORD C32FB757 ; El valor mágico no depende de NADA! ;-) 00B74823 POP EAX

Después de las operaciones anteriores nuestra llave tiene un valor de:
100500F0 A2 A8 E9 F7 7C 57 D4 56 6E 44 C3 A5 40 31 8B B7 ¢¨é÷| WÔVnDÃ¥@ 1‹·

4. XOReo con un CRC

Finalmente, la llave es de nuevo sometida a otra operación XOR (y ya van... lo siento, he perdido la cuenta de cuantas van ya ;-). Ahora le toca el turno a un CRC que es calculado a partir de los datos de las secciones .text y stxt774 del archivo original. La rutina que se encarga de calcular dicho CRC se encuentra en la dirección 1001C28A. Veamos cómo funciona. Básicamente, la rutina va tomando bloques de datos de las secciones que he mencionado con una longitud igual a 1000h bytes. Si la longitud original de la sección o el número de bytes que faltan por procesar es menor que 1000h bytes toma un bloque de esa longitud:



1001C308 CMP DWORD [EBP+ 10], BYTE +00 ; [EBP+ 10]= longitud de la sección 1001C30C JZ NEAR 1001C4F8
1001C312 CMP DWORD [EBP+ 10], 1000 ; ¿Quedan más de 1000h bytes? 1001C319 JNC 1001C326 ; SI -> Salta a la 1001C326
1001C31B MOV EAX,[ EBP+ 10] ; NO -> EAX= nº de bytes restantes 1001C31E MOV [EBP+ FFFFEFE4], EAX ; Mete nº bytes a procesar
1001C324 JMP SHORT 1001C330 1001C326 MOV DWORD [EBP+ FFFFEFE4], 1000 ; Mete 1000h bytes a procesar
1001C330 MOV ECX,[ EBP+ FFFFEFE4] 1001C336 MOV [EBP-08], ECX ; [EBP-08] = longitud del bloque
; de datos a procesar y a restar ; a la longitud original de la
; sección contenida en [EBP+ 10]
Esos bloques de datos son copiados a una memoria intermedia donde se procede a calcular el CRC de esos datos.
Después se van sumando los CRCs de todos los bloques y al final se obtiene el CRC de la sección completa:

1001C45F MOV CX,[ EBP+ FFFFEFEC] 1001C466 PUSH ECX ; Número de bytes a procesar (WORD)
1001C467 MOV EDX,[ EBP+ FFFFEFF0] 1001C46D LEA EAX,[ EBP+ EDX+ FFFFEFF8]
1001C474 PUSH EAX ; Dirección origen del bloque de datos 1001C475 CALL 1001C558 ; Rutina que genera el CRC

Después de procesar la sección completa, se almacena el valor del CRC obtenido en una dirección:
1001C543 MOV EDX,[ EBP+ 18] ; EDX= dirección de almacenamiento 1001C546 MOV EAX,[ 1004F2A0] ; [1004F2A0]= CRC
1001C54B MOV [EDX], EAX 6.

CRC para la sección .text:
1004F2A0 E2 3F E4 2F 00 00 00 00 00 00 00 00 00 00 00 00 â? ä/............
CRC para la sección stxt774:
1004F2A0 EA B7 76 FA 00 00 00 00 00 00 00 00 00 00 00 00 ê· vú............

Pero ahora te estarás preguntando, ¿no se calculaba el CRC con los datos de las secciones .text y stxt774? Sin embargo ¡la rutina anterior sólo calcula el CRC de una sección! Efectivamente, lo que ocurre es que el valor obtenido de la sección .text (que es la primera que se procesa) es copiado a otra dirección de memoria para utilizarlo posteriormente. De esta forma vuelven a utilizar la rutina anterior, pero esta vez con los datos correspondientes a la sección stxt774, para finalmente sumar ambos valores y obtener el CRC final con el siguiente código:

10017816 MOV EAX,[ EBP-10] ; [EBP-10]= CRC de la sección anterior ; (0 para la primera vez)
10017819 ADD EAX,[ EBP-18] ; [EBP-18]= CRC de la sección actual 1001781C MOV [EBP-10], EAX ; CRC FINAL

En mi caso el CRC final se encuentra en la dirección:

0064FA14 CC F7 5A 2A 88 02 00 00 01 00 66 00 00 C0 00 00 Ì÷ Z*ˆ..... f.. À..

Una vez obtenido este valor se procede a XORear la llave utilizando la misma rutina con la que se realizaron los 5 XOReos con las llaves de 32 bits (ver el apartado 2. XOReos con 5 llaves de 32 bits). Ahora la dirección [EBP+ 10] tiene el CRC que nosotros ya habíamos obtenido:

0064FA58 CC F7 5A 2A 0B F7 5A 2A A8 FA 64 00 CD 1C 66 00 Ì÷ Z*.÷ Z* ¨úd. Í. f.

Así que ya tenemos nuestra bonita llave TEA final que será utilizada en la rutina de desencriptación para obtener las correspondientes secciones en limpio: 100500F0 6E 5F B3 DD B0 A0 8E 7C A2 B3 99 8F 8C C6 D1 9D n_³ Ý° ?|¢³™° OEÆÑ°

5. Conclusión

Acabamos de demostrar que ningún dato de los necesarios para calcular la llave TEA es cargado del CD original. Los accesos al CD original se hacen exclusivamente con el fin de determinar que un CD con un nombre y una firma SafeDisc correcta se encuentra en el lector de CD-Rom.

6. Sorpresa!

Este apartado es simplemente un ejercicio que os propongo para ver que tal habéis asimilado lo que acabáis de aprender. El hecho de que haya elegido el juego HITMAN para hacer este tutorial no es casual. En este juego además de estar protegido el archivo principal (Hitman. exe) también lo está una de las dlls (System. dll). Así que mi propuesta consiste en que averigüéis todos los datos anteriores pero para el archivo System. dll. ¡Vale, vale! No voy a ser malo y os voy a dar una pequeña ayuda, pero no vale mirar la solución antes de que lo hayáis intentado al menos unas cuantas veces ;-)

6.1 La llave original

Archivo temporal: ~DE4335. TMP (Image Base= 01E80000)
Valor de llave original: 7.
01EAD660 8C C7 0C 2B 06 CF 74 26 66 42 AD E2 B3 99 C9 F0 OEÇ.+. Ït& fB â³™ Éð
La llave original se copia a la dirección 019600F0.
Rutina localizada en la dirección:
01914A29 MOV [EDX+ 019600F0], CL

6.2 XOReos con 5 llaves de 32 bits

Las llaves de 32 bits son las mismas que para el Hitman. exe.
Rutina localizada en la dirección:

0192E181 XOR EDX,[ EBP+ 10]
Valor llave TEA:
019600F0 72 85 A0 7D F8 8D D8 70 98 00 01 B4 4D DB 65 A6 r… }ø° Øp~.. ´MÛe¦

6.3 XOReos con 2 llaves de 64 bits y 2 de 128 bits

Las llaves de 64 y 128 bits son las mismas que para el Hitman. exe.
Rutina localizada en la dirección:
0192E36B XOR EDX,[ ECX]
Valor llave TEA:
019600F0 66 49 68 80 B8 B6 55 21 AA A5 42 D2 84 D0 0A C0 fIh€ ¸¶ U!ª¥ BÒ„ Ð. À

6.4 XOReo con un CRC

Valor CRC:
0064F5AC 08 16 DB 5D 0B 16 DB 5D FC F5 64 00 CD 1C 97 01 .. Û].. Û] üõd. Í.—.
Rutina localizada en la dirección:

0192E181 XOR EDX,[ EBP+ 10]
Valor llave final TEA: (umh ... esta llave me suena ;-)
019600F0 6E 5F B3 DD B0 A0 8E 7C A2 B3 99 8F 8C C6 D1 9D n_³ Ý° ?|¢³™° OEÆÑ° 8.
[ Ejecutando un juego protegido con SD2 sin el CD original ]
Una vez que hemos determinado todo lo anterior, nos queda por demostrar que es posible ejecutar un juego protegido con SD2 sin el CD original. Para ello vamos a utilizar el juego SACRIFICE.

Este "truco" fue, originalmente, publicado por R! SC en el foro de ArthaXerXes (http://arthaxerxes.datablocks.net/forum); yo únicamente lo publico aquí un poco más extendido y con un ejemplo. Así que, una vez hechos los reconocimientos, empecemos con el asunto. La rutina que se encarga de todos los asuntos relacionados con el acceso al CD original para validar su autenticidad está en la misma dll que la llave original (AuthServ. dll). La llamada a dicha rutina siempre se encuentra situada en la dirección: Image Base del archivo AuthServ. dll + E812h. En mi caso, la dll tiene una Image Base de C50000, y por lo tanto la llamada a la rutina se encuentra en la C5E812:

00C5E812 CALL 00C54940 ; A la vuelta de esta rutina, EAX tiene 1 00C5E817 ADD ESP, BYTE +04 ; Si EAX= 0 entonces el programa se acaba
00C5E81A TEST EAX, EAX 00C5E81C JNZ 00C5E82D

Si anulamos ese CALL estamos anulando todos los accesos que se hacen al CD y, por lo tanto, podríamos arrancar el juego sin el CD. Pero también es verdad que anulando esta rutina no podemos obtener la llave TEA final porque no se realizan los XOReos con las llaves de 32, 64 y 128 bits, sólo se realiza el XOReo con el CRC. Así que tenemos un pequeño problema. Pero como nosotros acabamos de aprender cómo obtener la llave TEA podemos engañar a la rutina SafeDisc introduciendo la llave final "a mano", es decir, obtenemos primeramente la llave TEA correcta y después ya no necesitamos el CD original para nada. Vamos a analizar estas operaciones una a una para el SACRIFICE:

-bpx C5E812 (punto de ruptura en la rutina que chequea el CD)

-x (continuar con el flujo del programa)
-e eip B8 (cambiar el CALL (E8) original por un MOV EAX (B8))
-bpm 100500F0 (punto de ruptura en acceso a la memoria de llave TEA)
-x (continuar con el flujo del programa)
-pret (tracear el programa hasta que se encuentre un RET)
-bc * (borrar todos los puntos de ruptura)
-e 100500F0 0A 66 9F 51 AE AE FF 6D 5A F2 37 86 86 34 2F 10 (engañar al
SafeDisc introduciendo en memoria la llave TEA correcta)
-x (continuar con el flujo del programa)

¡¡¡ GENIAL, FUNCIONA!!! Hemos conseguido ejecutar un juego protegido con SD2 sin necesidad de que el CD original esté en la unidad lectora de CD-ROM. Por lo tanto eso significa que podéis DESTRIPAR el SD2 sin necesidad del CD original. Así que ya estáis metiendo horas como locos para averiguar donde están y cómo solucionar todas y cada una de las trampas que os tienen preparados los amigos de Macrovision (jejeje ;-) ¡Suerte! 9.

[ Palabras finales ]

Bueno espero que hayáis disfrutado leyendo este tutorial tanto como yo he disfrutado escribiéndolo. Mi idea es seguir haciendo tutoriales sobre el SD2, pero todo depende de la respuesta de la gente frente a este tutorial. Así que me gustaría que me hicieseis llegar vuestras críticas o vuestras sugerencias para mejorar, así como temas que os interesaría que tocase en próximos tutoriales.
Existen temas muy interesantes sobre el SD2 como:

-Los archivos añadidos al ejecutable. Cómo se gestionan.
-Rutina de desencriptación TEA. Prepasada con rutinas morph.
-Redireccionamiento de la IAT. Encriptación de los imports.
-CALLs "trucados" en la sección .text. CALLs cambiados a JMPs.
-En ciertos juegos utilización de la API SafeDisc, es decir, trozos de código encriptados dentro de la sección .text que se desencriptan en tiempo de ejecución. (Por ejemplo en el Black& White ;-)

Espero tocar estos temas poco a poco con tutoriales como este. Así que permanece en sintonía.... jejeje ;-)

[ Agradecimientos ]
Me gustaría saludar a:

-Mr.Ocean y Mr.Snow por ser unos tíos tan enrollados. ;-) -Portia y Risc por ayudarme cuando lo he necesitado.
-Toda la gente del canal #crackers en el IRC-Hispano. -y, en general, a todo la gente que está en esto del cracking.

¡Un saludo compañeros!

Críticas, sugerencias y ayudas pueden ser enviadas a: KeopS

[ Entrada | Documentos Genéricos | WkT! Web Site ]

[ Todo el ECD | x Tipo de Protección | x Fecha de Publicación | x Orden Alfabético ]