Zen y el Arte de Crackear Dongles
(Un ensayo de algún modo ' general ' sobre los dongles).

por zeezee, (24 de diciembre de 1997 )


Manifiesto: - Yo no publicare aquí ningún nombre de programa protegido por dongles ya que no es mi objetivo tener batallas con abogados, veras sólo recortes del código pertinente. Este tutorial no es sobre un software o dongle especificó. El ejemplo dado no es de un programa real ampliamente disponible. El propio programa no es importante. Así que, empecemos con los fundamentos. Los Dongles son unas pequeñas cajas conectadas al puerto LPT (o a veces al puerto COM) de tu ordenador. Ellos deben ser (de hecho lo son en 99%) invisibles para las impresoras conectadas a este puerto.

Hay variantes de dongles montados dentro del ordenador pero para nosotros, la apariencia exacta del dongle no es importante. Dentro del dongle está un EEPROM o ASIC. Para nosotros esto es sólo una caja negra que recibe / envía datos de nuestra aplicación vía un pedazo de software (dongle API) qué es vendido con el dongle a los diseñadores. Los escritores de la aplicación llaman al API y comprueban que valores son devueltos para hacer saltos del tipo de good/bad.

Los Dongles mas populares son: - Sentinel (gran familia) de Rainbow Technologies (USA) - HASP (no es malo) de Aladdin (Israel) - Fest (si recuerdo bien hecho en Alemania) - Actikey (Francia) y decenas de otros... Mira tu favorito en la página del Dr Dobb.

Las Herramientas necesarias son habituales: -

IDA, SoftICE, Hiew y por supuesto nuestra aplicación.

Ningún analizador lógico, osciloscopio, quizá el monitor LED si realmente lo quieres. Así que, el primer paso en nuestro tutorial es: -

1. Identifica el dongle con el que estás tratando. No es tan difícil en la mayoría los casos. Cualquier mirada al dongle si tienes acceso a él, o mira todos los archivos que se instalan con tu objetivo, entonces puedes investigar todos .DLL, .VXD etc. por el texto del copyright u otra cosa de los autores de la aplicación. Lo encontrarás rápidamente en casi todos casos.

2. Recoge toda la información posible de las páginas WWW de los vendedores del dongle. Esto es UN PASO MUY IMPORTANTE!. Te sorprenderás de cuánta documentación puedes conseguir, el API completo, a menudo con la fuente, el software de demostración, ejemplos de cómo usar el API con tu futuro programa etc. Hazte con todo y estúdialo cuidadosamente. Recuerda: - TODOS los vendedores del dongle están presentes en la Red. Simplemente encuéntralos. No te asustes cuando hayas leído todo sobre la seguridad del dongle. Ellos SON seguros. OK. No puedes crackearlos a menos que estén hechos por completos idiotas. OK. Pero quieres craquear la aplicación, NO el dongle. Cuando leas sobre el encriptado de RSA, las funciones unidireccionales y observes en el API alguna Pregunta/Respuesta interesante desmenuzando funciones, recuerda que es sólo un API. Nadie lo usa. Únicamente son usadas funciones simples como Comprobar/número de serie/Leer y a veces Escribir.

3. También puedes recibir un dongle de evaluación del distribuidor del dongle gratis. Si no gratis pregunta por 14-días de prueba. ¡Funciona! Ellos quieren vender estas cajas. Llama a estos números 0800 o 0130. Ellos querrán ayudarte a menos que digas algo tonto cuando pregunten por el software que quieres proteger. Las personas de Rainbow y Aladdin son _extremadamente_ serviciales.

4. Ahora conoces el dongle/app que quieres crackear y tienes (o no) alguna información adicional. Tiempo para pensar. Imagina una compañía de software que hace un programa. El proyecto casi está terminado, entonces viene el jefe y dice: "OK, estamos listos, ahora es el tiempo de proteger nuestro fantástico producto. Tenemos un kit de demostración del dongle X. Así que, estimados programadores, úsenlo." Y los pobres programadores están estudiando documentación del dongle, API etc. y poniendo algunas llamadas de API en su código. Algunas veces acaba así: -

call DONGLE
or ax, ax
jz buenchico
chicomalo

Sí, no puedes creerlo, sin embargo es real. A veces ellos van un poco más allá pero en la mayoría los casos, yo repito: en la MAYORÍA de los casos la idea es estúpida. Pero la cadena sólo es tan fuerte como su eslabón más débil. Y en todos los 4 programas diferentes que yo probé con dongles diferentes, el eslabón más débil era la interface: -

Aplicación - Dongle API (principalmente contenido en un DLL).

Los fabricantes del dongle son tipos inteligentes, ellos saben encriptar datos, hacer código auto-modificable, trucos anti-debug etc. yo te recomiendo: - Deja su código como está. El lado de la aplicación es mucho más fácil de crackear. La primera cosa en el crack real es encontrar LA llamada (raramente más de una) al dongle API, Usa IDA o W32Dasm y recuerda el nombre del DLL que contiene el dongle API y después de varios minutos (¡pasadas 2 horas y 40Mb de archivo .IDB!) lo tienes.

Debe haber una parte de API estáticamente unida al ejecutable que nosotros estamos crackeando qué llama al DLL, los graciosos de Aladdin hacen un código auto-modificable aquí, así que nuestra meta esta subiendo un poco. Nuestros pobres programadores son perezosos. Todos son perezosos cuando llegan a la llamada del dongle. Así que ellos escriben sus propias funciones como: QuickCheckIfDonglePresent (), GetDongleSerialNumber () ReadDongleByte (addr) - o word, o dword, o incluso la tabla completa WriteDongleByte (addr, valor). ¿Quizá ellos están exportados por nombre? ¿Quizá el nombre es ReadDongle o similar? Mira cuidadosamente las referencias que IDA te da. Lo encontrarás seguramente.

Debes encontrar procs llamados una sola vez - ellos deben ser interfaces entre la aplicación/API. ¿Quién escribe dos envolturas para una función? El dongle API está muy bien estructurado en la mayoría los casos, el número de la función está dado explícitamente, 0 - comprueba, 1 - consigue número, 2 - lee, 3 - escribe, etc... Identifica donde están los parámetros/resultados. Y esta es la cosa que nos ayuda a crackear. ¡Nosotros también podemos tener los docs del API! Los productores del API quieren hacer el API lo más fácil de usar. Ellos también lo hacen más fácil de crackear...

Nosotros podemos encontrar rápidamente lo que el app espera del dongle estudiando las llamadas del API y los ' cmp ax' que lo siguen.

5. Entonces viene la parte activa (puedes necesitar el dongle por un periodo corto de tiempo) parchea el código insertando un byte CC en el lugar(es) del Interface del 'App-API'. Ejecuta SoftICE con BPINT 3. Reemplaza INT 3 con el byte original, entonces pon un BPX a esta dirección, rastrea... Mira lo que pasa cuando allí no hay ningún dongle. Puedes tener suerte y puedes encontrar rápidamente un checkpoint con un interruptor del tipo de bad/good. Intenta ir de la otra manera y ver lo que pasa (quizá tu objetivo comienza a correr). Intenta parchear el código para emular la función de QuickCheckIfDonglePresent. Simplemente devuelve un valor que satisfaga al proc llamado. Esto puede ser suficiente en la mayoría de los estúpidos casos. Entonces intenta emular la rutina GetSerial #. Recuerda que el # de serie del dongle puede guardarse y ser usado para visualizarse en el apartado About. Mira las referencias que IDA te da. No todos los dongles tienen el proc GetSerial #. A veces los # de serie son leídos como datos normales desde el dongle. Esto puede ser suficiente en la mayoría los casos no-tan-estúpidos. Y entonces viene al dongle a leer. Varios bytes son leídos, yo asumo que encuentras el lugar donde ellos se guardan y todas las referencias a este lugar.

Varios controles pueden ocurrir y ciertamente ocurrirán en programas con opciones diferentes habilitadas / desactivado por el dongle. (Ej. un ejemplo real de uno de los principales programas de SCADA): -

cmp eax, some_value1
je is_model_1
cmp eax, some_value2
je is_model_2

O quizá (ejemplo real de un programa israelita con dongle israelita): -

test eax, mask_1
jz lab1
call enable_option_1

lab1: etc.

O quizá (electrical engineering tools hechas en Francia con dongle francés): -

12 palabras leídas por el dongle se guardan desde [ebx]

mov ecx, 12

lab1: cmp word ptr [ebx], 1
jne lab2
call enable_option(cx)

lab2: inc ebx
loop lab1

Créeme. Es real. Si tienes un dongle trabajando, lees todo los valores de él, y sabes qué emular (pon un BPX después de que el API lee la función que hace el trabajo y toma notas). Y aquí el ejemplo real. Este app es inútil para ti, no está libremente disponible, así que estudiemos el desensamblado que yo preparé para ti.

1. Nuestros dongle son que Actikey francés y el DLL son CCNMMNT.DLL.

2. Hacemos un desensamblado de nuestro objetivo (40 Mb) y miramos en la sección .idata. Lleva un poco más de tiempo que un cocktail... El resultado es asombroso, pero yo esperé hasta que TODAS las referencias fueron expuestas.

3. Ctrl-s y vamos a la sección .idata. Encontré importaciones externas desde CCNMMNT.DLL Vamos a la referencia de ello.

00594510 ; Imports from CCNMMNT.dll
00594510 00594510 extrn CCNMM:dword ; DATA XREF: j_CCNMMr Solo una referencia!

¡El nombre j_CCNMM es asignado por IDA! entonces: 00408770 ; S u b r u t i n a 00408770

00408770 j_CCNMM proc near ; CODE XREF: key_io+6Fp 00408770 jmp ds:CCNMM ; Salta a Dongle DLL 00408770 j_CCNMM endp

El nombre key_io y el otro de debajo son asignado por mí, ellos no se exportan; -) subimos un paso. Mira: Sólo una referencia. ¡Luz verde! Estamos en el buen camino. entonces: -

0040BA10 key_io proc near ; CODE XREF: main_key_check+8 0040BA10 ; main_key_check+18Cp.
0040BA10 ; key_check2+45p

Después del control, yo encontré que key_check2 es llamado sólo desde el main_key_check, así que nosotros todavía tenemos sólo una referencia aquí. Todavía estamos dentro del código del dongle API. Subamos: -

0040B840 ; S u b r o u t i n e 0040B840 0040B840 main_key_check proc near ; CODE XREF: key_fun_00+4Dp 0040B840 ; keyfn_18_sernum+68p
0040B840 ; keyfn_02_write+5Bp
0040B840 ; keyfn_03_read+56p
0040B840 ; key_fun_1b+50p
0040B840 ; key_fun_1c+54p
0040B840 ; key_fun_1d+5Cp

Por supuesto puedes preguntar, ¿cómo sé yo que esto es el API y no nuestra aplicación? Respuesta rápida: ¡Las funciones 1b, 1c y 1d no son llamadas! ¿Te imaginas escribiendo envolturas que nunca se llaman? Ellos fueron escritos por los fabricantes del dongle y se enlazaron al app. De hecho keyfn_02_write tampoco es llamado. Esto son buenas noticias, la clave siempre debe responder con los mismos datos. Los nombres de los llamadores son auto explicativos. ¿Desde dónde los conseguí yo? Estudiando el procs, eso es todo, mira un ejemplo :-

0040A250 keyfn_18_sernum proc near ; CODE XREF: (varios)

0040A250 0040A250 arg_0 = dword ptr 8 0040A250
0040A250 push esi
0040A251 call key_fun_00
0040A256 cmp ax, 1
0040A25A jnz short skc110
0040A25C mov ax, 1 ; 1 - error?
0040A260 pop esi
0040A261 retn 0040A262

skc110:
0040A262 mov word ptr ds:key_fun, 18h ; funcion 18!!!
0040A26B xor eax, eax
0040A26D mov esi, [esp+4+arg_0]
0040A271 mov word ptr ds:key_result_1, magic1
0040A27A mov word ptr ds:key_par3, ax
0040A280 push offset key_par4
0040A285 mov word ptr ds:key_par4, ax
0040A28B push offset key_par3
0040A290 mov word ptr ds:key_par1, magic2
0040A299 mov word ptr ds:key_par2, magic3
0040A2A2 push offset key_par2
0040A2A7 mov [esi], eax
0040A2A9 push offset key_par1
0040A2AE push offset key_result_1
0040A2B3 push offset key_fun
0040A2B8 call main_key_check ; aquí nuestra llamada
0040A2BD mov word ptr ds:main_result, ax
0040A2C3 add esp, 18h ....guarda results...

Los valores mágicos están identificando el dongle y el producto, así que yo los quité... ellos son insignificantes para nuestro cracking. Ahora es tiempo para identificar lo que el API está esperado devolver. Varios ' cmp ax, something' y yo pude emular las funciones del API 00 (control rápido) y 18 (consegir el serial). Yo apliqué un pequeño parche usando Hiew para emular estas funciones. Después de que mi programa empezó con todas las opciones desactivadas. Analizando otro ' cmp ax, something' era casi insignificante. Así que yo escribí un pequeño emulador de key_fn_02_read y ahora el proggy abre todas las opciones para mí.

Conclusiones: - crackear los Dongles no es mucho más complicado que craquear numeros de serie. Necesitas más fondo teórico de los productores del dongle, un desensamblador bueno que encuentre todas las XRefs y SoftICE por supuesto. Las protecciones shareware son a menudo mucho más sofisticadas que las simples llamadas del dongle en caras apps comerciales. Hay programas mejor protegidos por supuesto, pero ellos son excepciones.

* No empieces crackeando desde BPIO en puertos de LPT. Intenta encontrar El Eslabón más Débil!.

* Recuerda, los programadores son perezosos cuando vienen a poner código exterior dentro del suyo propio. No todas las llamadas del API se usan. Comprueba las funciones más simples primero y ve lo que pasa.

* Permite a tu programa crackeado correr durante varios minutos. Casi siempre hay un control del dongle realizado cada 1 minuto o así. Tu crujido debe sobrevivir a esto. Prueba todas las acciones que el programa debe realizar. Selecciona cada artículo del menú. O, si lo prefieres, estudia el desensamblado entero para las llamadas del dongle...

* Ten cuidado cuando crackees con el dongles real conectado. Allí está teóricamente la posibilidad de destruir un dongle. Sólo usa los dongles para leer sus contenidos y quítalos cuando craquees con SoftICE. Ellos no son necesarios en éste momento: -) Sin embargo yo nunca encontré ningún procedimiento de auto-destrucción al estudiar varios dongles API. ¡No obstante, estás advertido! ¡Buena suerte!

zeezee


Traducido por Txeli 

http://club.telepolis.com/txelienlinea/index.htm

www.000webhost.com