FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
le indicas a tu aplicación que incluya la dll implícitamente, esto es, añade código que carga automáticamente la dll muy posiblemente antes de que cualquier código tuyo tenga la oportunidad de detenerlo o decirle dónde buscar. Yo creo que lo más seguro sería, en la medida de lo posible, que te olvides de esa unidad y la hagas tú mismo (creo que son pocas funciones). Esto significa que uses tú mismo LoadLibrary y GetProcAddress para cargar la biblioteca exactamente de dónde la quieres e importar las funciones. De todas formas, no me queda claro cómo esto te puede servir. Vamos a suponer que logras forzar la carga del shfolder.dll que está en el sistema. Pero estamos hablando del sistema del cracker. ¿Qué le impide al cracker reemplazar aunque sea temporalmente la bilbioteca del sistema, localizada en su directorio de sistema por la suya propia? LineComment Saludos |
#2
|
||||
|
||||
Cita:
__________________
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. |
#3
|
||||
|
||||
Cita:
LineComment Saludos |
#4
|
||||
|
||||
Hola,
¡Ya lo creo que hay instrucciones! Pero no es igual que te digan, copia esta DLL en el directorio del programa, a que te digan, sustituye la DLL del sistema X por esta otra... que yo te doy... algunos usuarios se lo pensarían, al menos. Tal vez no mucho. |
#5
|
||||
|
||||
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. |
#6
|
||||
|
||||
Hola,
Muchas gracias Neftalí, tengo que probar ese código. |
#7
|
||||
|
||||
Cita:
LineComment Saludos |
#8
|
||||
|
||||
¡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... |
#9
|
||||
|
||||
De verdad, hay veces que parece que no me leen :
Cita:
|
#10
|
||||
|
||||
Aunque consigas evitar la carga de la dll maliciosa en el arranque de tu app, siempre se puede inyectar con un pequeño ejecutable. Esto quiere decir que no puedes quedarte en la defensa de la carga, has de ir más allá y cambiar el código de protección. Además deberás comprobar, en ese código, que no está cargada una dll no deseada. Puedes usar la API GetModuleFileName para ello pues te da la ruta completa de la dll. También puedes explorar las funciones que exporta. Un hook a la indocumentada ldrLoadDll también te puede ayudar a evitar cargas e inyecciones. Eso puede dificultar al crack en la investigación de un nuevo crack. Pero todo esto no quita para que no fortalezas y ofusques el sistema inicial de protección, es fundamental.
Saludos. |
#11
|
||||
|
||||
Hola a todos,
Cita:
|
#12
|
||||
|
||||
Cita:
Saludos. |
#13
|
||||
|
||||
El siguiente artículo es de recomendable lectura para el tema en cuestión: Carga segura de las bibliotecas para evitar ataques de precarga de DLL
Saludos. |
#14
|
||||
|
||||
Cita:
También he probado (además de con "SetDLLDirectory") probé con "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)", pero, aunque se ejecuta correctamente, no parece surtir el efecto que buscamos, pues la DLL "maliciosa" consigue ser cargada, aunque, ignoro porqué, en este escenario podemos comprobar su existencia y cerrar el programa. La solución de Neftalí se me antoja la más acertada mientras la DLL en cuestión no pueda evitar su correcto funcionamiento: en este caso nos da igual que la DLL se cargue... porque cerraremos el programa en tal caso. En fin, según parece, el "cracker" hasta ahora encargado no puede seguir adelante, tal vez porque quiera ser elegante y encontrar un método que no "toque" los ejecutables de los programas. Ya veremos. Última edición por dec fecha: 14-11-2016 a las 08:11:27. |
#15
|
||||
|
||||
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. |
#16
|
||||
|
||||
¡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! |
#17
|
||||
|
||||
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"... |
#18
|
||||
|
||||
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. |
#19
|
||||
|
||||
Hola,
Eso es. Eso tal vez echaría atrás a algunos usuarios... que por otro lado tampoco es que tengan muchos escrúpulos, tal vez incluso jamás piensen en pagar, así que si pueden usar el programa gratis, bien, y si no, pues tampoco pasa nada... Pero también he comentado en mi post de arriba que esto puede causarle problemas al "cracker", puesto que no sé yo si tendría que añadir a la DLL "original" su propio código... puesto que de otro modo la DLL "original" (ahora su copia) no funcionaría... digo yo... |
#20
|
||||
|
||||
¡Hola a todos!
Cita:
Cita:
¡Y todo esto para conformarme conque tengan que "tocar" el programa! Porque de llegarse a ese punto... allá el usuario que quisiera usar un programa "parcheado". Y además yo no podría hacer más, la verdad sea dicha. Por otro lado, esto está relacionado con esto otro: Cita:
|
|
|
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 |
|