CracksLatinoS! 2007 -* *Programa
Download Descripción Herramientas Dificultad Compresor/Compilador Protección Objetivos ¿Cracker? Tutorial nº
DocCF Gestion de instituciones de Educacion Programa para gestionar centros de enseñanza WKTVBDebugger,ExDec,UltraEdit,VB Decompiler Media Visual Basic..P-Code Serial Encontrar serial valido y (opcional)hacer un generador de claves para distintas maquinas. Sequeyo Fecha: 2-1-2007
-** Introducción **-
Hola buena gente. Aquí de nuevo con vosotros para explicar cómo solucioné el registro de éste programa. Es un programa del cual alguien me pidió ayuda. Programado en VisualBasic y compilado en Pcode. En muchas ocasiones puede resultar odioso tracear ó intentar hacer un seguimiento del comportamiento de un PCode, pero despues de mis aventuras con dicho compilador, forma parte esencial la paciencia. En definitiva, regla aplicable en cualquier estudio de una aplicación. En este caso con Pcode, la falta de paciencia puede vencernos y aveces desistimos del intento. Quienes hayan leido mis tutos, sabrán que paciencia si que tengo así no tanto como tiempo.
Así que dicho esto, y agradeciendo la atencion que vais a prestar, comenzamos. Instalamos el programa DocCF y despues de analizar el ejecutable con Peid ó RDGPackerDetector observamos que no tendremos que perder tiempo en desempaquetarlo.
Ahí lo vemos, un Visual Basic compilado en P-Code así que ya sabemos con qué herramienta vamos a trabajar. Sin duda WKTVBDebugger para P-Code es de las mejores alternativas, por no decir de las pocas para depurar la aplicación. Sin duda, la valiosa ayuda de ExDec y VB Decompiler son inestimables. Lo primero que haremos es, sin duda, echar un vistazo al programa y ver el aspecto de las ventanas, botones, etiquetas,cajas de texto...etc. Todo, absolutamente todo, lo que nos pueda servir luego para identificar en el codigo muerto los sitios calientes.Abrimos el programa y lo primero que se presenta, es una nag-formulario, que pide nombre y clave para entrar al programa general. Me imagino que no habría sido demasiado complicado encontrar la clave correcta, pero como ya me la proporcionó el amigo que me pidió ayuda pues....menos trabajo. Si ya tenemos el primer obstaculo salvado, pues nos aprovechamos de ello.
El nombre de usuario es "carlosfv" y la clave es "as". Mientras escribimos, el texto se coloca él solito en mayusculas.
Sin más complicacion, clickamos en Aceptar y entramos de lleno en el programa
En la imagen vemos nuestro estado de registro, y la ruta del menú que debemos seguir para llegar al formulario de registro. Clickamos entonces en "Ayuda" y luego en "Acerca de DocCF..." llegando así al formulario de registro......
Se ve, que consta de dos botones, dos cajas de texto,etiquetas con varios textos.... en fin: un formulario simple y llano. Sabemos ya lo que tendríamos que buscar en un codigo muerto ó decompilado. Las cadenas de texto de las etiquetas, las cajas de texto,etc. Todo cuenta, y a más información, más certera es nuestra busqueda. Yo me serví para dar un vistazo general, la la herramienta VB Decompiler obteniendo este resultado. El decompilado tarda un poco en realizarse:
En esta vista general del decompilado vemos dos ventanas por las que vamos viendo tanto el nombre de los diferentes formularios (izquierda) como su codigo asociado (derecha). Nos servimos de las barras de desplazamiento para ello. De entre los formularios, hay uno que a simple vista nos hace pensar que es el formulario de registro. Vimos antes que llegabamos al formulario de registro, clickeando en "Ayuda" y luego en "Acerca de DocCF". Pues de entre todos los formularios, hay uno llamado "frmAbout". Palabra que nos resultará más que familiar (About=Acerca de...). Haciendo doble click en el frmAbout, automaticamente en la ventana de la derecha aparece todo el codigo asociado a él y a los componentes que lo integran. Vemos por ejemplo:
Creo que es suficiente. Podría haber puesto mas capturas pero desde ya se puede decir que se trata del formulario de registro. Toda esta informacion pertenece al aspecto visual del form de registro. Si nos desplazamos en la ventana de la izquierda más abajo, tendremos disponibles los codigos de los formularios y sus componentes. Un detalle por si alguien se despistó un poco, en las capturas se observa que de los dos botones disponibles, por sus nombres nos hacemos la idea de la función de cada uno. En este caso, "NncmdOk" hace referencia al boton que aparece en el formulario con la etiqueta "Registrar". En la siguiente captura vemos ese boton y su código:
Aquí tienen el boton "Registrar" y su codigo asociado que comienza en la direccion 574F24. Hay veces en las que voy comparando resultados con otros decompiladores y desensambladores. Pido informacion del programa en ExDec y me aporta lo mismo:
Si nos fijamos en la penultima captura, en la ventana de la derecha, linea 11 vemos una instrucción mas que familiar para nosotros: "Get TextBox.Text" que lo que hace es pedir el contenido de la caja de textos. ExDec lo interpreta de otra forma, pero basicamente se refiere a lo mismo. Con todos estos datos, nos podríamos ir directamente a WKTVBDebugger y colocar un BP en la direccion donde empieza el codigo asociado al boton, es decir a la direccion 574F24. Hay un pequeño inconveniente. Si pretendemos cargar la victima en WKT, nos da un error. Simplemente es porque la victima ya se encuentra "abierta" en el decompilador y en el desensamblador. Tendríamos que cerrar tanto el VB Decompiler como el ExDec. Luego de éste detalle ya podremos abrir la victima en WKT. Recomiendo para los que no estan habituados al manejo del WKTVBDebugger, repasen mis anteriores tutoriales. Una vez cargada la victima en WKT, pongo un BP en la direccion 574F24 con lo que se supone que tendríamos que parar, una vez pulsaramos F5, al comienzo de la rutina del boton Registrar. Probemos....
Una vez colocado el BP clickamos F5 en la ventana principal de WKT para empezar a solucionar todo esto.
Zas!! me lanza el sistema operativo un error. Casi no le doy importancia. No envío el error a nadie, y empiezo de nuevo. Pero me vuelve a salir. Si que es raro. Llegué a pensar que WKT estaba jodido, lo reinstalé de nuevo y nada. Así que me dió por intentar averiguar qué provocaba que el sistema me reportara éste error. Cargada de nuevo la victima, busqué de entre los opcodes, alguno que me pudiera ayudar. Existe un opcode, 4B (OnErrorGoto) que al principio pensé que no tendría nada que ver, pero ¿y si la victima manejaba ciertos errores para determinar si la aplicación funcionase o no? Puede ser que la victima de algun modo detectase que la estamos espiando y actuase en consecuencia. Sea como fuere, por probar no vamos a perder nada así que coloco un BP directamente en el opcode:
El punto en verde indica que quedó puesto el BP así que.....F5 para ver que pasa.....
Pues lo que pasa es que simplemente se para en el BP puesto al opcode 4B. Utilizé la tecnica de darle a F5 hasta que me saliera el cartel de error, para así saber de donde procedía el problema. Así que fuí dando F5 hasta contabilizar un total de 13 veces. Bien: analizando el tema. Si despues de darle 13 veces consecutivas a F5, sale el cartel del error, lo que se puede hacer es reiniciar WKT y cargar de nuevo la victima; ponemos el bP al opcode y esta vez le damos a F5 solo 12 veces y cuando se quede en la parada numero 12, se tracea con F8 para averiguar que ocurre.En la siguiente imagen ya nos encontramos en ésa parada numero 12:
Logicamente como está manejando un error, se dirigirá como se ve, a la direccion 599454 y simplemente se trata de ir traceando con F8 linea a linea hasta ver qué demonios ocurre. Está claro que no voy a colocar todas las lineas ni a comentarlas todas, por que sería una locura. Resultaría demasiado pesado y aburrido. Nos quedamos en que tracearíamos linea a linea hasta encontrar algo que nos diera una pista y despues de tracear un poco, llego a ésta zona:
Despues de tracear un poco, el programa llega a la instrucción 557BB0 y si se me ocurriese volver a pulsar F8, el programa rompe y sale el cartel de error. Es la primera vez que me encuentro con ésto. ¿Y cómo solucionarlo? La siguiente linea a 557BB0 la interpreta WKT como invalida así que va a cascarlo todo. La linea existir existe pues el desensamblado con ExDec así lo demuestra:
Donde WKT dice INVALID, tendría que aparecer la linea 557BB3 pero.....no está. ¿Y cómo hago yo para "injertar" una linea en WKT? Pues realmente no se. Aquí reconoceré que me venció ésto, y ni pude injertar nada y no logré saber cómo hace el programa para corromper él mismo una instrucción. Si alguien se decide a investigar, recibiré con mucho agrado sus descubrimientos.
Desde luego que ésto no puede ni debe quedar así. No hay rendición que valga. Y pensé que si no puedo inventar algo de la nada.....¿por qué no cambio lo que ya existe? Lo que se me ocurrió fué estando aún el WKT parado en la linea 557BB0 hecer que de algún modo llegue a la linea 557BB8. ¿Y cómo?...Pues sencillamente saltando. Pero casi saltando a ciegas porque veo lo que hay en la otra orilla, pero no sé si son arenas movedizas y un posible desajuste de la pila me rompa de nuevo todo el traceo. Así que....sin miedo. Se cambia lo que sea y lo que haga falta. Estando en la linea, la edito y el opcode original (04) lo voy a cambiar por el opcode del salto (branch) (1E) y el resto de los bytes los quito. En esta primera imagen se vé la linea con sus bytes originales:
Y en ésta siguiente vemos la modificada ya terminada. Se vé cómo se cambia el opcode 04 por 1E y el resto de bytes todos a cero.
En este momento vemos que la linea 557BB0 despues de alterarle el opcode y ponerle todos los bytes a cero,pasa a intentar saltar a la linea 557B58 que no es ni mas ni menos el comienzo de la rutina donde estamos:
Los saltos, en P-Code, y estemos donde estemos, empiezan a calcularse desde el inicio de la rutina y por ello si queremos ir a la linea 557BB8 pues le restamos a la dirección de destino, la direccion de origen; es decir: 557BB8-557B58=60 Y por lo tanto, hay que añadirle a la linea 557BB0 otro byte más, el 60:
Y despues de clickar en Patch Now obtenemos el salto al lugar correcto:
Pero sigue existiendo un problema. Vemos que la direccion 557BB8 no está y eso es por que en 557BB0, el opcode 1E ocupa 3 bytes a sí que desde 557BB0 y en memoria, la siguiente linea será la 557BB3 que tiene el opcode "00" que ocupa 2 bytes con lo que por logica, la siguiente linea será la 557BB5. Si intentamos hacer F8, logicamente WKT se queja diciendo, que le estamos haciendo saltar a una linea que simplemente no encuentra!!
Lo que nos dice el error es que algo realmente malo ocurrió. La linea 557BB8 no puede ser encontrada y quizas algún opcode tiene un tamaño incorrecto. Eso es lo que venía explicando hasta ahora. Tenemos que reajustar el tamaño de algún opcode para dar con la linea 557BB8 del demonio!! Está claro que la linea 557BB0 no podemos tocarla por que es el salto a nuestra salvación así que se me ocurre buscar ése opcode con ése tamaño necesario, en la linea 557BB3. Buscando en la lista de opcodes, encuentro uno que viene genial para este caso:
Es el opcode "2A" que corresponde a ConcatStr que bien se sabrá, lo que hace es unir cadenas (strings) y que ocupa 1 byte. Osea, a la direccion 557BB3, le vamos a colocar un opcode que ocupa solo un byte, con lo que la siguiente linea pasaría a ser la 557BB4. Ésta última linea seguiría teniendo el opcode "00" que ocupa 2 bytes, siendo la siguiente 557BB6. Ésta a su vez, que tambien tiene el opcode "00" de dos bytes al sumarsele, se llega a la linea 557BB8 y reencontramos la linea perdida. Suena bastante lioso, pero es la logica de los bytes y la logica de la suma. Lo mas elemental. Y aquí está la prueba después de cambiar la linea 557BB3:
Ahora sí, la linea 557BB0 tiene su destino ahí preparado para recibirle Hacemos F8 y el traceo alcanza la dichosa linea:
Al final, la paciencia, es otra herramienta poderosa. :D Damos F5 y ahora sí vemos el programa correr. Lo que sí veo, es que el formulario de entrada aparece de un color distinto que el original y puedo imaginar que, con el parcheo que hemos realizado ó con las paradas iniciales ocurridas cuando corrimos el programa por primera vez, algo a salido mal.Pero al fin y al cabo, ¿eso que mas nos da? Sigue siendo funcional. Sería aconsejable que se hagan los cambios de los bytes, en algun editor hexadecimal, para cuando carguemos de nuevo, carguemos la parcheada.Yo los cambié con UltraEdit, por ejemplo.Le llamé "DocCFWKTOK.exe" Así, ahora cargaré el archivo parcheado en el WKT y le ponemos el BP en la direccion donde comenzaba el evento del NncmdOk (boton Registrar). Dicha direccion era 574F24. Colocado el BP clickamos F5 para que comienze el programa. Entramos el nombre y la clave necesarias para acceder al programa principal, Ayuda,Acerca de DocCF y escribimos el numero que se nos ocurra.
Cuando pulsemos Registrar, WKT se clavará en el BP y comenzamos a tracear.En la siguiente imagen vemos WKT clavado y esperandonos. No se trata de ir explicando paso a paso y linea a linea, por que no acabaríamos nunca. Daré un repaso de las mas importantes y qué hacen para comprender cómo se comporta el programa.
Despues de haber llamado al frmAbout (574F31) y de pedirle el texto al txtSerie,en la direccion 574F3A, entrará en un bloque de código ó rutina que empieza en la direccion 569FDC
Aquí es donde empieza realmente a trabajar con el numero que escribimos. En la imagen siguiente, vemos en la direccion 569FE5,que carga un integro, el numero 2. En 569FED pide 2 (cargado anteriormente) caracteres desde la izquierda, en la cadena que hay en la direccion que marca la pila: 1DC984 que tiene su contenido abajo encuadrado, osea, el numero que escribimos. "rtcLeftCharBstr" se encarga de ello. Y despues de salir de la llamada, tenemos los dos caracteres. El numero 12.
Desde 569FF7 hasta 569FFC, se carga el byte 2, se le suma al 12 anterior y se apila. 14 = "E" en hexa.
Luego se pide el largo del serial que escribimos.
Seguidamente una comparacion entre el largo de la cadena 14h(20) con Eh(14 anteriores del resultado 12+2) y como resultado de la comparacion, no nos tira fuera y sigue con la manipulacion del serial trucho. La comparacion de la linea 56A009 (LtI4 14h,Eh ?) por más que estuve buscando por la red, no encontré su significado. Lo único que puedo aportar es que despues de varias pruebas que hice, si el primer operando (largo de la cadena) es mayor que el segundo operando (valor de los dos primeros caracteres+2), el siguiente salto condicional BranchF (saltar si es falso) no se produce como se ve en la imagen. Por lo tanto se queda que LtI4 nos pregunta si el primer operando es mayor que el segundo. En este caso, obviamente y como se ve en la imagen no salta. Si el salto se produjera, nos lleva a otra zona del programa y ni siquiera se molesta en trabajar con el serial trucho. Por lo tanto seguimos.
En la siguiente imagen se ve lo que hace el siguiente bloque de codigo.
Se pide el valor numerico de una cadena (14) que era el resultado anterior 12+2. Luego se carga un 3 y luego un uno. Al 14 se le suma ese uno con lo que queda 15 que servirá para pedir de nuestro serial trucho los tres(3) caracteres a partir de la posicion 15 obteniendo la cadena 543
A continuacion se carga la cifra 810 y el 7 (en la imagen anterior se aprecian las cifras). Y en esa porcion de codigo lo que se hace es al 810 restarle los 543 obtenidos y al resultado se le divide entre 7 dando el resultado 38.1428571428571
En las siguientes instrucciones, lo que se hace es volver a tomar el valor 14. Se cargará un uno(1) y de nuestro serial trucho se tomará un carácter (1) apartir de la posicion 14 con lo que obtendremos el 6.
Luego, en las siguientes lineas,se vuelve a tomar el numero 14, se carga un 4 al que se le suma el 14 anterior=18. Se toma el seis(6) anterior y del serial trucho se piden (6) caracteres apartir de la posicion 18 con lo que obtendremos el 210. ¿Porqué 210 y pedimos 6? Pues simplemente, por que desde la posicion 18, en el serial trucho solo quedan el "210" así que la Api retorna lo que hay.
Seguidos, se vuelve a tomar el 6 anterior. Se carga un 9. Se multiplica ése 9X6=54 y al 210 obtenidos antes, se le resta el 54 quedandonos como resultado 156.
Seguidamente se vuelve a cargar el 14, acontinuacion se carga un 1, se pide del serial trucho el "6" (desde la posicion 14, 1 carácter), se carga en la pila un 4 al que se le suma el 14 y al resultado se le suma el 6 obtenido anteriormente quedandonos el total de 24. Seguido se pide del serial trucho, 4 caracteres a partir de la posicion 24; pero no obtenemos nada, sencillamente porque el serial trucho solo tiene 20 caracteres. Así que la proxima vez que carguemos la victima, le escribimos más caracteres al serial trcho hasta que complete 24. La siguiente imagen contiene parte de las operaciones realizadas en el codigo antes descrito.
Acto seguido, se restan 4005 menos los numeros obtenidos(nada ó 0) y el resultado se divide entre 3 dando un total de 1335. En la imagen anterior se ven los operandos 4005 y 3 que intervienen en las operaciones.
Ya aquí terminan las operaciones con el serial trucho y a continuacion lo que se hace es unir los resultados numericos obtenidos anteriormente,pasados a String. En la direccion 56A176 se ve por ejemplo cómo se empiezan a unir esas cadenas con la orden "ConcatStr". Dichas cifras eran: 38.1428571428571 , 156 , 1335
Así que nos queda finalmente la cifra 38.14285714285711561335 En las lineas siguientes se sale de la rutina y se entra en otra en la que se va a trabajar con el Numero de Identificación que en mi maquina y según vieron en la imagen del principio es el "09822825828488880073387". Digo lo de mi maquina, por que en maquinas diferentes ése numero es diferente. Puesto en contacto con quien me pidió ayuda con éste software, me mandó el numero que aparecía en su maquina. Bien seguimos con el WKT.
Ahí estan viendo cómo se apunta a la caja de textos "txtNA" del frmAbout y a continuacion se le pide el contenido para finalmente entrar en otra rutina con ése contenido. La linea 574F67 es bastante clara en cuanto a dónde vamos a ir a parar. A la direccion 5664C0
Ahí estamos. Tal como se apuntaba en la imagen anterior. Como ya sabemos la estructura y forma de trabajo del programa a la hora de solicitar los caracteres, puedo obviar muchas imagenes y muchos detalles. Les diré de forma resumida, lo que el programa hace con el Numero de Activacion (txtNA): 09822825828488880073387 1. Se toman del txtNA los dos primeros caracteres (09), se carga un 3 y se suman éstos dos valores.(12) 2. Se carga (empuja a la pila) el numero uno (1) y se le suma al resultado anterior quedando el total 13 3. Se carga un 3, y del txtNA se piden 3 caracteres a partir de la posicion 13, obteniendo el 888. Se carga el 999 y se le restan los 888 y el resultado se divide entre 3. (999-888)/3=37 4. Se vuelve a cargar el 12 del punto 1, se carga un 1, y del txtNA se pide desde la posicion 12, 1 carácter y obtenemos el 4. Se suma 12+4=16 y se pide del txtNA 4 caracteres a partir de la posicion 16 con lo que obtenemos el 8007. Se carga un 3 y se multiplica por 4. 4X3=12. Al 8007 se le resta 12 =7995 5. Se vuelve a cargar el 12 del punto anterior, se empuja un 1 y se vuelve a pedir de txtNA el 4 (a partir de 12, 1 carácter). Se carga un 4 y se suman 12+4+4=20. Se vuelve a cargar un 4 y se pide de txtNA apartir de la posicion 20, 4 caracteres y obtenemos el 3387. Se carga el 5997 y se le restan 3387=2610. Se carga un 5 y se divide 2610/5=522 6. Se unen los resultados que subrayé en rojo,pasados a cadena,con "ConcatStr" quedandonos 377995522 En las siguientes imagenes un resumen visual con los resultados y algunos de los operandos utilizados.
Bueno, despues de éste tremendo mareo de numeros, se sale de ésta rutina y se vuelve al hilo principal (574F6C) donde en la linea siguiente se hace una comparacion directa entre dos cadenas.
Las imagenes anteriores son más que suficientes. Comparacion directa en tre dos cadenas. Dichas cadenas estan en dos posiciones de memoria apuntadas en el stack que luego en el visor de la memoria se ven de qué cadenas se tratan. Los resultados de operar con las cajas de texto. Está claro que toma el patrón de comparacion ,con las operaciones realizadas en el txtNA y luego se compara ése patron, con las operaciones realizadas con el txtSerie. El salto condicional de la linea 574F83 BranchF logicamente se realizará (saltar si es falso) llevandonos fuera y con una patada en el culo. Es entonces momento de analizar qué tenemos que escribir en el txtNA para que cuando el programa opere con él, de como resultado 377995522 y la comparacion resulte exitosa para que nos registre. Si se observa cómo se piden los caracteres del serial trucho vemos que del primer bloque de operaciones, nos tendría que resultar 37 y para que éso fuese posible, los tres caracteres que debería tomar serían: (37x7)-810=-551. Hago las operaciones de la forma inversa a como las haría el programa para averiguar el numero origen. (810-551)/7=37. Por lo tanto, tenemos la primera serie de numeros necesarios:551. En el siguiente bloque, necesitaríamos el 7995 y para conseguirlo necesita-
mos lo siguiente. Desde la posicion 14 se pedía 1 carácter y nos devolvió un 6. Ése 6 se utiliza ba para pedir 6 caracteres desde la posicion 18. Nos devolvía 210. Con los operandos que teníamos ¿qué necesitamos para obtener 7995? Pues para empezar, desde la posicion 18 DEBEN haber cuatro caracteres para que el resultado sea el apropiado. El programa tomó desde la posicion 14, un carácter y tomó un 6. Pero si en vez de tomar un 6 tomase un 4(imprescindible),tomará 4 caracteres desde la posicion 18. Sería: 7995+(9X4)=8031. Aquí está: Desde la posicion 18 se tomará 4 caracteres y se operará con él:8031-(9X4)=7995. Suponiendo que vayamos sustituyendo el serial trucho tendríamos: 123456789098745518031 Ahora necesitamos el resultado 522 y para que sea posible necesitamos: Volvemos a manejar aquí el 4 imprescindible. El programa tomaba el 14 , cargaba un 4 y los sumaba (18) y ahora es donde entra en juego el 4 imprescindible. 18+4=22 y acto seguido se pedirá desde la posicion 22,4 caracteres. ¿Qué caracteres deberían ser? Pues cuatro caracteres que al restarlos con 4005 y luego el total se divida entre tres nos dé 522, no puede ser otro que el 2439. (4005-2439)/3=522. El serial trucho se vuelve a modificar de la siguiente manera para que todas las operaciones se realizen al 100% 1234567890987455180312439 En rojo, los caracteres necesarios para que todo éste puto invento funcione y su largo completo: 25 caracteres ó numeros. Abramos el DocCF original, y en el formulario de registro escribamos la cifra anterior. Clickamos en registrar y
Éste programa me costó bastante. Tengo que reconocerlo.Pero igual reconozco el enorme merito del programador, por que se lo trabajó bastante y de una forma ingeniosa.
Mi enhorabuena para él. Fué un reto magnifico. Les comentaba casi al principio, que puesto en contacto con quien me pidió ayuda, me dió el numero que a él le aparecía en su maquina en el formulario de registro. Ése numero era el 09324233003495117071762 y según todos los calculos realizados, su codigo de registro debe ser el 1234567890416469817311464. Me lo cofirmó él despues de enviarle un generador de claves que hice en .NET con el VS2005. Sabiendo cómo se comporta el programa y conociendo qué cifras debemos obtener, no es demasiado dificil hacer el generador de claves.
Ahí le tienen, que se le introduce el Numero de Identificacion y al clickar en Generar, tenemos el serial necesario para registrar el programa. Curiosamente, los 10 primeros digitos del numero generado,permanecen inalterables sea cual sea la maquina y son numeros de 1 al 0. Bueno, en mi caso me vino fenomenal empezar así. Siempre empiezo con esa cadena de numeros. Seguramente os aburrió todo este rollo. Reconozco que P-Code es odioso en todo el aspecto del traceo. Pero es así. Para terminar, debo decirles que se trata de un programa comercial. Lo que leyeron es simplemente para registrar el programa de forma temporal para que lo puedan probar, pero despues de un tiempo, deben volver a desregistrarse y comprarle el software a su propietario. Por que de lo contrario, pueden colocar sus fotos en la web del autor. Y el FBI les perseguirá. Y bla bla bla bla...... Para des-registrar el programa, simplemente vayan el registro y busquen lo siguiente.
DocCF cuando arranca, viene aquí y verifica que el numero de activacion sea el correcto, y arranca registrado. Con tal que cambien el último numero,
osea, el 9 por un 8 por ejemplo, al no ser ya una cifra correcta, el programa vuelva a estar des-registrado. De nuevo le pido al autor del software que no se me enfade. Como ve, ya avisé a los muchachos que se des-registren y que le paguen si quieren usar su software.........otra cosa es que no me hagan caso. Amigos, creo que esto se puede dar por finalizado. Saludos a tod@s y hasta la proxima!!
Sequeyo
