¿Cómo evitar que una DLL se ejecute antes que cualquier otra cosa de mi programa?

[Neftali [Germán.Estévez]]

Empezado por roman

Claro, pero nada me impide publicar la dll maliciosa junto con las instrucciones de uso.

¿El problema es que entonces estás invalidando la DLL de sistema, no?
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?

[dec]

¡Hola a todos!

Empezado por Neftali

¿El problema es que entonces estás invalidando la DLL de sistema, no?
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?

Apuntas a algo que yo no había pensado, ciertamente. Sustituir la DLL original implica también "cambios" para otros programas y no sólo para el nuestro. Siempre será mejor un "crack" que no tenga que tocar para nada los archivos del sistema a otro "crack" que tenga que meterse en esos berengenales.

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!

[dec]

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"...

[Neftali [Germán.Estévez]]

Empezado por dec

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.

Pues parece que es así, aunque parece raro.
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-).

[dec]

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.