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

[dec]

Hola,

Empezado por bitbow

Eso se soluciona encryptando las funciones de la dll y los llamados (si la dll es de tu propiedad y cuentas con el codigo), tambien puedes generar la validacion desde hardware id (disco duro, tarjeta de red u otro).

Saludos.

Gracias por comentar. Ciertamente, la DLL no es mía. Después de probar con una ruta absoluta para la DLL "shfolder.dll" parece que esto tampoco funciona (?) y ahora estoy investigando acerca de la función "SetDefaultDllDirectories", que, parece puede forzar a que se cargen las DLL desde el directorio del sistema. ¡Ya veremos!

[Casimiro Noteví]

Vaya, qué curioso. Lucha de titanes

[dec]

¡Hola a todos!

Na... es un caso perdido Casimiro! Peeeeeeeero.... Gracias a la ayuda del proyecto Inno Setup y de esta su unidad, acabo de cargarme el último "crack", es decir, la DLL "shfolder.dll" no es cargada ya antes que el código que comprueba su existencia... de modo que el programa se cierra si la DLL existe. ¿El próximo paso? Lo dará el "cracker", estoy seguro. ¿Mi objetivo? Ahora no lo tengo tan claro (mira que ponerme a perder el tiempo en esto...), pero, hace unos días pensaba que me conformaría conque el "crack" en cuestión tuviese que "tocar" el programa, de modo que "mi firma" se rompiese. Con esto me conformaba hace unos días. Puesto que a partir de ahí... creo que tengo la batalla completamente perdida.

P.D. Acabo de actualizar todos mis programas ahora mismo... de momento van tres parches y otros tantos "contraataques". A ver qué pasa mañana. Je je je... me lo tengo que tomar a risa esto.

[Casimiro Noteví]

Ya te digo, esto da para una película y todo

[dec]

¡Hola!

Empezado por Casimiro Notevi

Ya te digo, esto da para una película y todo

Je je je...

[dec]

¡Hola a todos!

Siguiendo con el tema... no... todavía no he visto el nuevo "crack", aunque tal vez no se tarde mucho. El caso es que me llama la atención lo siguiente, y, es que incluso llamando a la función "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)", mejor dicho, sólo con esto, la DLL en cuestión hace su trabajo y consigue "registrar" el programa o "anteponerse" al código del mismo.

O sea, que, curiosamente, si después de ejecutar la función de marras, compruebo si existe la DLL, en efecto, parece que la comprobación es correcta y así el programa se cierra. Pero, si no compruebo la existencia de la DLL el programa sigue adelante sin problemas, esto es, cargando la DLL "shfolder.dll" que se encuentra en el directorio de la aplicación y no en el directorio del sistema...

La verdad es que esto desconcierta a cualquiera... esto es, se supone que usando la función "SetDefaultDllDirectories" estamos indicando a Windows que busque las DLL en el directorio del sistema, donde, en efecto, se encuentra una DLL "shfolder.dll", pero, aún y con esas la DLL que copiamos en el directorio del ejecutable del programa parece seguir cargándose antes sin problemas...

Vamos, que me espero al cuarto "crack", pero no tengo muchas esperanzas.

[Casimiro Noteví]

¿Estás haciendo pruebas con un programa mínimo, limpio, sin nada más, solamente hecho para probar eso?

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

Empezado por dec

Siguiendo con el tema... no... todavía no he visto el nuevo "crack", aunque tal vez no se tarde mucho. El caso es que me llama la atención lo siguiente, y, es que incluso llamando a la función "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)", mejor dicho, sólo con esto, la DLL en cuestión hace su trabajo y consigue "registrar" el programa o "anteponerse" al código del mismo.

Yo te iba a proponer el uso de SetDllDirectory, pero imagino que debe ser similar a la que comentas.
Aquí está la documentación.

Por otro lado podrías intentar mirar a otro frente. Imagino que la DLL debe "parchear" en cierta manera el comportamiento del programa en cuanto al registro.
Ese comportamiento normalmente se deduce utilizando debuggers.
¿Has probado a dificultar este paso?
No es imposible, porque como tú bien dices con tiempo al final todo se consigue, pero se puede llegar a complicar, de forma que quien lo está haciendo llegue a desistir si el esfuerzo es demasiado grande.
Esta también va en el mismo sentido.

Tú mismo puedes buscar, pero además de herramientas externas, hay mucha otra documentación al respecto.

[roman]

Empezado por dec

O sea, que, curiosamente, si después de ejecutar la función de marras, compruebo si existe la DLL, en efecto, parece que la comprobación es correcta y así el programa se cierra. Pero, si no compruebo la existencia de la DLL el programa sigue adelante sin problemas, esto es, cargando la DLL "shfolder.dll" que se encuentra en el directorio de la aplicación y no en el directorio del sistema...

La verdad es que esto desconcierta a cualquiera... esto es, se supone que usando la función "SetDefaultDllDirectories" estamos indicando a Windows que busque las DLL en el directorio del sistema, donde, en efecto, se encuentra una DLL "shfolder.dll", pero, aún y con esas la DLL que copiamos en el directorio del ejecutable del programa parece seguir cargándose antes sin problemas...

Vamos a ver si no digo una burrada. Yo creo que no es sorpresivo este comportamiento: cuando tú compruebas que la dll está en el directorio de la aplicación y cierras ésta, lo que estás haciendo es matar un problema que ya estaba presente, es decir, la dll maliciosa ya se había cargado. ¿Por qué? Porque desde el momento en que pones

Código Delphi [-]
uses Winapi.SHFolder.pas;

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