GeoPath Power CAD/CAM - Tutorial

Version 3.00.009, 01 March 2000 Release

Traducción de ^[G]oLe[E]^

Esté es el primer de mis tutoriales sobre DoNgLe y por eso no daño a los autores, he decidido no hacer publico el programa para ser descargado. Si realmente estás interesado en examinar este código, entonces enviame un E-Mail y pondré a tu disposición solamente los archivos necesarios.

Iniciando GeoPath produce un error no sorpresivo y despues parece como que si en un segundo intento de localizar la DoNgLe, el programa termina. Es fácil encontrar el cuadro de Dialogo con un bpx MessageBox (0002:8A26), esto inmediatamente nos incita a examinar la lista muerta. Los programadores sin embargo, evidentemente tenian otras ideas, rastreando la cuadro de dialogo de nivel de código 1, nos lleva a concluir que ese CALL 89D6 es errado, pero rastrenado el mas alto, nos lleva a 9 callers (que son los que hacen la llamada) y muchas referencias a llamadas multiples que siguen siendo altas. No es practico tratar y parchear todas las llamadas, o rastrear cada caller individual.

Hora del SoftICE, un bpio -h 378 rw es lo la linea usual de ataque para cualquier DoNgLe de LPT, y seguramente abrir GeoPath produce una break (ruptura). Resulta que este codigo est{a realmente dentro de algo llamado Centinela, (se ve como un vdx). En este punto, puedes desactivar el break point y comenzar a presionar F12 para encontrar donde está realmente el caller de la aplicación. El programa parece quedar dentro del Centinela por lo menos 10 F12's pero eventualmente regresé a sc16w.dll, el cual es el dll del fabricante.

Rastreé a través del codigo dll de la DoNgLe (aunque no por mucho tiempo), mi consejo es simple - a menos que estes preparado para una seria sesión de crackeo, no te metas con el código de la DoNgLe, mantente presionando F12 hasta que salgas a la aplicación, lo cual hará algo. Eventualmente, despues de un viaje a través de vmm, regresé a scadca.exe. Tu atención está sobre el primer break dentro de scadcam.exe.

:0002.0744 MOV DX,AX <-- BPIO al punto de entrada.
:0002.0746 CMP DX,FFFD <-- DX es 0 aquí.
:0002.0749 JG 0758 <-- Saltar e inicializar la comunicación con la DoNgLe.
:0002.0758 CMP DX,FFFF <-- Ahora compara DX con 1.
:0002.075B JZ 07D4 <-- Posiblemente algun error no relacionado.
:0002.075D PUSH 003F <-- Leer la dirección de la word 3F.
:0002.075F CALL FAR WORD PTR [BP-0A] <-- Leer la DoNgLe.

:0002.0762 MOV DX,AX <-- Retorna el código posiblemente ubicado en AX que fue movido en DX.
:0002.0764 CMP DX,268F <-- Esto se ve como si debe ser un buen retorno de la DoNgLe.
:0002.0768 JNE 07D4 <-- Esto 'se siente' mal.

Haré un alto aqui y explicare mi razonamiento, el chequeo JG se ve como un error no relacionado de alguna descripción, ¿por qué?, bien, para errar este chequeo, necesitaras AX retornado con menos de -3 y entonces es chequeado con -1?, prescindiendo del valor de AX, de cualquier forma el código va a alcanzar 0758. La llamada FAR es una caracteristica regalada de las comunicaciones DoNgLe y para las razones de compilador SoftICE casi puedes garantizar el resultado en (E)AX, es innecesario decir que cuando rastrear sobre este CALL AX es FFFF (-1), 268F es muy abstracto para ser cualquier otra cosa que el buen resultado, asi que parchear aca, es lo que continua.

Continuando.

:0002.076A PUSH 0000
:0002.076C CALL FAR WORD PTR [BP-0A] <-- Leer de nuevo la DoNgLe.
:0002.076F MOV DX,AX <-- Otra Vez, mover el código de retorno en hacia DX.
:0002.0771 CMP DX,1F1F <-- Comparar con 1F1F.
:0002.0775 JNZ 07A8 <-- Saltar aquí.

El código siguiente es realmente furtivo, podrías ser perdonado por creer que 1F1F era un buen código de retorno, de hecho, no lo es, es uno falso y muy bien encubierto. Explicaré, si examinas el código después de esto, se *vé* como si el programa llama dentro de la dongle para hacer otros 2 chequeos, almacenando los resultados en las localidades de memoria [9EFC] y [9EFE], no tener la DoNgLe presenta un problema, porque no tenemos idea de que es lo que supuestamente son estos valores, pero unas poca lineas sobre [9EFC], es probado para FF y la llave es que prescindiendo del resultado, el código procede a 07D4.

En 07D4, el código chequea flags en las localidades BP+06 y BP-14, pero nuestra ruta acá no está fijada por esas flags, esto resulta en el contar de loop [0084], siendo iniciado e incrementado 6 veces atras de donde comenzamos. Esto puede llevar solo a una conclusión, 1F1F es un truco. de hecho, no tener la DoNgLe una ventaja positiva para el chequeo 1F1F, porque lo burlaremos de todos modos.

:0002.07A8 CMP DX,1010 <-- Otro código de retorno.
:0002.07AC JNZ 07B0 <-- Salta aquí y cheque el código de retorno de nuevo.
:0002.07AE JMP 07B6 <-- Salta a la misma localidad que el próximo chequeo.
:0002.07B0 CMP DX,F010 <-- Otro código de retorno.
:0002.07B4 JNZ 07C3 <-- Todavia saltar a otro chequeo.

El código que sigue es también muy interesante, sin embargo, parece que si DX es 1010 o F010, prescindiendo del código alcanza 07B6, y esto resulta en que algunas flags son fijadas. Si ni el código es correcto alcanzamos un chequeo final en 07C3.

:0002.07B6 MOV WORD PTR [BP-14], 0001 <-- Flag.
:0002.07BB MOV WORD PTR [9EFA], 0001 <-- Otra localidad.
:0002.07C3 CMP DX,1210 <-- Ultimo código de chequeo de retorno.
:0002.07C7 JNZ 07D4 <-- Jump (Salto) obviamente malo.
:0002.07C9 MOV WORD PTR [BP-14], 0001 <-- Alguna flag como las que encontramos tempranamente.
:0002.07CE MOV WORD PTR [9EFA], 0002 <-- Localidad marcada como 2.

El flag [BP-14] siempre está marcado con 1 y por lo tanto, no es importante, la pregunta es que calor de [9EFA] es bueno,(1 o 2). Sin la DoNgLe difícil estar seguro, aunque revisando el listado muerto, ví que 1 era mas parecido a la flag correcta, ya que verdaderamente, este es el caso, el flag 2 trabaja como una función que deshabilita el switch para algunas operaciones, aunque solo sabrias esto con conocimiento previo. También parece ser 1 otra localidad donde la DoNgLe es llamada, facilmente puedes localizarla buscando el valor hex para la instrucción DoNgLe que lee CALL FAR. Hacer un parche para esto, es evidentemente facil.

Considero esto como una protección DoNgLe del todo debil, pienso que mas chequeos podrian haber sido hechos y muchas mas trampas añadidas. Sin tener un tester (que pruebe), la flag [9EFA] es el único problema real, aunque evidentemente no es una molestia realmente grande para probar uno u otra. Parchear este codigo es, por supuesto, una tarea bastante rutinaria, aunque deberias aplicar la estetica usual.

Adición Version 3.00.009

Parecería que en esta ultima versión, por lo menos algún esfuerzo ha sido hecho para encubrir las funciones Sentinel cplus de la DoNgLe y mas chequeos son hechos en las words de retorno. Scadcam.exe ahora es un probrama de 32 bits y se llama en la DoNgLe via sc32w.dll, las direcciones de la función RNBOcplus son recuperadas via LoadLibraryA en lugar de importarlas directamente. Sin embargo, los chequeos continuan siendo malos y algunas cosas son demasiado ridiculas :-

:0045F73D PUSH 00000404 <-- 1028 bytes.
:0045F742 PUSH EDX <-- Record de Paquetes CPlus.
:0045F743 CALL [ESP+20] <-- RNBOcplusFormatPacket().
:0045F747 CMP AX,BX <-- Todos los Record de Paquetes estan bien.
:0045F74A JNZ 0045F85C <-- Mal Salto.
:0045F750 MOV AX,[004ED4EC] <-- ID del desarrollador (AX=0).
:0045F756 LEA ECX,[ESP+00000124] <-- Record de paquetes.
:0045F75D PUSH EAX
:0045F75E PUSH ECX <-- Empujar parámetros (por qué?).
:0045F75F CALL [ESP+24] <-- RNBOcplusInitialize().
:0045F763 CMP AX,BX
:0045F766 JNZ 0045F85C <-- Mal Salto.

Esto es posible y absolutamente una increible pieza de codigo, los desarrolladores de GeoPath me escuchan? RNBOcplusInitialize (si es algo como la API SuperPro) no debería tomar cualquier parametro, aún aca vemos un ID de Desarrollador de 0 y un puntero al Record de Paquetes dejados atras (no pude encontrar documentación en el website del Centinela sobre las API cplus, asi que es posible que este errado acá) :-

:0045F778 PUSH 3F <-- Dirección a leer.
:0045F77A PUSH EAX
:0045F77B CALL ESI <-- RNBOcplusRead().
:0045F77D CMP AX,BX <-- Chequear el estado.
:0045F780 JNZ 0045F832 <-- Mal salto.
:0045F786 CMP WORD PTR [ESP+10],268F <-- Chequear la word (palabra) retornada.
:0045F78D JNZ 0045F832 <-- Mal salto.

Mas lecturas son realizadas en las words 0,1,2 y 7 (0 es explicitamente chequeada para 0x1F1F), 1 & 2 son usadas para controlar el menu y las opciones en 3D (Un monton de chequeos en parte baja de la word 1), has una busqueda de las localidades en memoria donde estas words son almacenadas y no puedes perder el chequeo (Word 1 --> 004F7558, Word 2 --> 004F755C), encontré que Word 1 = 0x45 y Word 2 = 0x7 parecen hacer el trabajo.


greenball.gif (835 bytes) Dong
www.000webhost.com