FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
||||
|
||||
Cita:
LineComment Saludos |
#22
|
||||
|
||||
Hola,
Cita:
Si veo el cuarto "crack"... que todavía no he visto, pero, no quiere decir que no exista ya, entonces tal vez mi próximo contraataque pase por usar otras funciones en lugar de las incluidas en "SHFolder.dll", pero, tengo para mí (ojalá me equivocase) que al "cracker" le da igual esta DLL que otra cualquiera... y uno no sabe ni las DLL que usa su programa, quiero decir que la VCL de Delphi envuelve un buen número entre su código y vaya usted a saber... Por otro lado, qué demonios... ¿es que no se puede evitar que una DLL extraña completamente a nuestro programa no sólo se cargue con nuestro programa pero logre cambiar su comportamiento? ¿No es esto ya de por sí un fallo de seguridad, más allá de "crackers" y demás? En fin... de momento podemos esperar al cuarto "crack"... ¡tal vez con el último contraataque el "cracker" no sepa ir más allá usando esta técnica! ¡Veremos! |
#23
|
||||
|
||||
Oye, pero mira que el cracker es decente:
Cita:
En fin, dentro de lo malo yo creo que puedes rescatar lo más positivo: tu aplicació ya es crackeable. Esto no se hace por cualquier aplicación. LineComment Saludos |
#24
|
||||
|
||||
Hola Román,
Cita:
O sea, lo que quiero decir es que esta gente no trabaja por amor al arte... que estoy seguro de que hacen su buen dinerito entre publicidad, enlaces y servidores de pago, amén de otras cosas que se me escapen. Lo cierto es que uno no puede luchar contra la piratería. Si todos los programas, empezando por Windows, pasando por Photoshop y terminando por Delphi, están "crackeados"... ya me dirás qué puede hacer uno para evitarlo. Estoy seguro de que no se trata de algo personal (tal vez por parte del "cracker"... un poco...) sino de ganar dinero, en este caso atrayendo a visitantes con las últimas versiones de los programas "crackeados". Pero yo lo veo como toda una industria... "bots" preparados para rastrear los sitios web de los programas, que saben (miran en la base de datos) si el "crack" actual funciona o tal vez toque esperar un poco para publicar la nueva versión, etc., etc. En definitiva, el número mayor posible de visitas a la página warez de marras con el único y exclusivo fin de ganar el máximo de dinero posible. No hay más. No hay romanticismo ni "compra el programa si te va bien" ni nada de eso... porque además los usuarios "warez" sean acaso usuarios más o menos jóvenes que se dedican a probar todo programa que cae en sus manos: seguramente lo desinstale a continuación y no se sepa más. Por eso preocuparte demasiado o en exclusiva por este tipo de usuarios puede ser garantía de fracaso seguro, vaya... Última edición por dec fecha: 09-11-2016 a las 18:58:50. |
#25
|
||||
|
||||
Cita:
Por lo que yo he entendido, al copiar la DLL hackeada en el directorio de la aplicación, el resto del sistema sigue funcionando correctamente, porque nadie más usa esa DLL, el resto de aplicaciones usan la correcta (que está en el directorio de sistema). Si sustituimos la del directorio de sistema (la correcta) por esta, entiendo que el resto del sistema utilizará también la librería modificada. ¿Qué pasa con la original? ¿Se mantiene? ¿La renombras? ¿La modificada llama a la original?
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#26
|
||||
|
||||
Eso es bastante fácil de averiguar si necesitas hacerlo. Hay utilidades que te dan la lista (y creo que las funciones de cada una).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#27
|
||||
|
||||
¡Hola a todos!
Cita:
Sin embargo estamos hablando de una DLL particularmente "pequeña" (tres o cuatro funciones), os sea que acaso podría hacerse lo que apuntó Román arriba: que el "cracker" sustituya toda la DLL, de modo que igual no habría problema en situar la DLL en el directorio del sistema y sustituir con ella la DLL original. Ya veremos cuando "salga" el cuarto "crack"... Lo que me preocupa bastante es el hecho de que aún llamando a la función "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)" la DLL del "crack" sigue funcionando, a no ser que compruebe su existencia: en este caso parece que dicha función hace "algo" (que no logro entender) permite al programa al menos comprobar la existencia de la DLL. Yo creo que los tiros van por lo que apuntó Román arriba: la DLL se carga antes que cualquier código de mi programa, esto es, antes de la llamada a la función "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)", y eso que esta función es llamada a partir de la cláusula "initialization" de una unidad situada en primer lugar en el programa. Se me ocurre usar la propia cláusula o bloque "initialization" en lugar de llamar a nada desde ahí, aunque probablemente esto no evite que la DLL se cargue y ejecuta antes que cualquier otro código del programa. ¡Os mantendré informados a todos de lo que vaya ocurriendo! |
#28
|
||||
|
||||
Hola a todos,
Dándole vueltas a este tema, digo que uno piensa que el código "initialization" de la primera unidad que se incluye en el programa es lo primero que se ejecuta, pero, ¿no será que antes de eso se incluyen las DLL que el programa necesita? De este modo, la DLL "maliciosa" siempre podrá hacer "algo" que impida a nuestro propio código funcionar como se espera. Si lo de arriba es cierto, me pregunto si una posible solución (que no tomaré al menos hasta descubrir el siguiente "crack"... si es que al final sale) sería usar nosotros una DLL, de modo que esta sea además la primera que se cargue (no estoy muy seguro, pero, tal vez, importando una función de la DLL en la primera unidad del programa) y así poder tomar medidas ahí mismo. Creo que puede funcionar: siempre que nuestra DLL sea la primera que se cargue, ya podremos comprobar la existencia de otras DLL "maliciosas" y podremos borrarlas (supongo) sin problemas antes de que dichas DLL se lleguen a cargar siquiera. Creo que el razonamiento es válido a no ser que Windows cargue primero las DLL "del sistema"... |
#29
|
||||
|
||||
Cita:
yo he realizado una sencilla prueba y no he conseguido que ese código se ejecute antes de la carga de la DLL, pues siempre se accede a los métodos de la DLL modficada. Una solución sencilla en este caso, que creo que ya has comentado, es cargar esta DLL de forma dinámica, en lugar de estática. A tí te sería sencillo, pues como sólo hay 2 funciones, puedes hacerlo fácilmente. Se supone que si la carga es dinámica, antes ya puedes haber ejecutado el método en cuestión y ya no debería cargar la "modificada". Esto le obligará a repetir todo el proceso con otra DLL, con el trabajo que eso conlleva, contando que como has dicho esta es sencilla y lleva 2 métodos (no pasa eso con otras -supongo que por eso debe haber escogido esta-).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#30
|
||||
|
||||
Hola a todos,
Gracias por comentar Neftalí. Acabo de probar yo también con mi propia DLL con resultados dispares. No he conseguido ejecutar ningún código en dicha DLL antes que el código de la primera unidad del programa, pero, parece que esta DLL sí que consigue cargarse antes que la del "cracker". Claro, ahora habría que pensar que quizás él podría reemplazar mi propia DLL por la suya o intentar el asunto de otro modo. De momento, puesto que no he visto un cuartro "crack", quiero pensar que el uso de "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)" está consiguiendo el objetivo: al menos puedo comprobar si existe la DLL del "cracker" y parar el programa. Pero todo este asunto de las DLL es muy interesante, por lo menos a mí me lo parece vaya. |
#31
|
||||
|
||||
Supongo que el resultado es similar al que finalmente has utilizado, pero otra cosa que podrías hacer aprovechando que tu programa (por ahora) no utiliza DLL's diseñadas por ti, es lo siguiente:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#32
|
||||
|
||||
Hola,
Muchas gracias Neftalí, tengo que probar ese código. |
#33
|
||||
|
||||
Cita:
LineComment Saludos |
#34
|
||||
|
||||
¡Hola a todos!
Gracias al código de Neftalí acabo de descubrir que la función "SetDefaultDllDirectories" no funciona, o, mejor dicho, no lo hace como se espera. Esto se demuestra situando la DLL del "crack" en el directorio del programa: incluso después de ejecutar la función susomentada (recordemos que sin errores, o sea, se ejecuta correctamente) la DLL del "crack" (situada en el directorio del programa) aparece listada por el código de Neftalí. * O sea, aunque usando la función que no funciona... puedo comprobar si existe la DLL en el directorio del programa, ya he dicho que esto no me convence y que creo que el siguiente "crack" podría con ello. El código que propone Neftalí me parece mejor que usar la función "SetDefaultDllDirectories" (ojo, al menos en mi caso particular) puesto que el "cracker" no consiguiese saltárselo de otra forma que no fuese tocando el propio ejecutable. *También se lista la DLL "shfolder.dll" del directorio del sistema, pero, más abajo en el listado... |
#35
|
||||
|
||||
Hola,
Probado el código de Neftalí este funciona como se espera y me convence más que el uso de la función "SetDefaultDllDirectories" y la posterior comprobación de la existencia de la DLL maliciosa. El código podría quedar poco más o menos que como se ve abajo, siendo la unidad en cuestión situada la primera en el "uses" del archivo de proyecto del programa:
Dicho código supone que en el directorio del ejecutable del programa no debe existir DLL alguna. Me queda la duda de si debo cerrar el "handle" antes del "Halt"... |
#36
|
||||
|
||||
¡Hola!
Acabo de actualizar todos los programas (pero sin cambiar la versión) para usar el código anterior, en primer lugar, porque creo que puede salvar el "ataque" mediante DLL situadas en el directorio del programa (al menos funciona con el último "crack" conocido), y, en segundo lugar, por jorobar un poco al "cracker", hombre, a ver si ya estaba trabajando sobre el código anterior y su trabajo no sirve para este nuevo código. El que no se consuela es porque no quiere, ¿eh? Je je je. |
#37
|
||||
|
||||
Una cosa.
Prueba a abrir el programa, ejecutando directamente un fichero .AB (Application Builder File) que tengas en cualquier directorio y colocando junto a ese fichero la DLL "parcheada". Tal vez habrá que añadirle el "Directorio actual" además del de la aplicación.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#38
|
||||
|
||||
Cita:
Cita:
|
#39
|
||||
|
||||
Cita:
Cita:
Es decir, carga la DLL del directorio de sistema, no la que hay en el directorio donde se encuentra el fichero .AB.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#40
|
||||
|
||||
Hola,
He probado abriendo un archivo "AB" y sigue funcionando bien, esto es, el programa no se inicia si se encuentra la DLL "maliciosa" en el directorio del mismo. Última edición por dec fecha: 10-11-2016 a las 18:16:39. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Como evitar q se ejecute el Explorer.exe | ing_arismendy | API de Windows | 3 | 02-02-2009 06:13:08 |
Como evitar que una apicacion se ejecute dos veces. | manitoba | C++ Builder | 4 | 28-05-2007 16:50:04 |
Como evitar que se ejecute el msn | JODELSA | Varios | 7 | 26-12-2005 14:17:22 |
Cualquier cosa me puede servir | cmgenny | Conexión con bases de datos | 1 | 02-07-2003 22:27:24 |
|