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

[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?

[dec]

Hola,

Empezado por Casimiro Notevi

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

Ciertamente no, Casimiro, aunque, mis programas (porque ojo, hablamos de seis de ellos...) no hacen nada raro con las DLL ni nada... de hecho se distribuyen sin empaquetar siquiera. Creo yo que en un programa "limpio" ocurriría igual, pero, no lo he probado. Fíjate que el proyecto Inno Setup, así como otro instalador, NSIS, se preocupan de esto... en efecto, una simple DLL como "shfolder.dll" pude interponerse en el código de nuestro programa, sin modicar ningún ejecutable, y, conseguir, pues... lo que quiera, digo yo...

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

[orodriguezca]

Interesante la trama. Espero con ansias el desenlace.

[dec]

Hola,

Empezado por orodriguezca

Interesante la trama. Espero con ansias el desenlace.

Sí, je je je. De momento no he visto un cuarto "crack", pero, seguramente no tardará.

[dec]

Hola,

Empezado por Neftali

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.

Gracias por comenar Germán. En efecto, probé con la función que indicas, pero, sin resultados. Pudiera ser que tampoco la usase bien, pero, el proyecto Inno Setup hace uso de la otra función, yo creo que porque puede ir un poco más allá que la primera. De hecho esta segunda función, en principio, no debería "tirar" de la DLL del directorio del programa, puesto que se está indicando que se haga desde el directorio del sistema, donde además se encuentra también dicha DLL.

Sin embargo, como he dicho, no parece funcionar del todo bien... es cierto que el último "crack" de que tengo constancia no funciona, pero, está lo que no me cuadra: tengo que comprobar que la DLL exista, cuando, en teoría (hasta donde yo llego) no sería necesario, puesto que dicha DLL no se cargaría, puesto que lo haría la que se encuentra en el directorio del sistema. Curiosamente, la función en cuestión se ejecuta sin errores, de modo que tampoco puedo ver si algo falla.

Respecto de ponérselo más difícil al "cracker", en efecto, podría intentarse, por ejemplo, usando algún programa "empaquetador" y "protector". Pero, hete aquí que cualquier programa de este tipo que uno busque está a su vez "crackeado"... entonces, ¿qué confianza me ofrece un programa que se supone va a proteger mi ejecutable, si el propio programa no puede protegerse a sí mismo? Ninguna. Por otro lado, me constan programas que usan este tipo de protectores y que están "crackeados".

Pudiera ser que este "cracker" en concreto no supiese ir más allá... pero posiblemente otro podría hacerlo. En todo caso, el sistema que uso ahora no me disgusta, en el sentido de que los keygen, por ejemplo, no fucnionan. Como ahora compruebo las licencias "online", ya no sólo vale que uses un número de serie "formalmente" válido, porque este no se encontrará en la base de datos remota. Mi objetivo, como he dicho arriba, es que al menos tengan que "parchear" los propios ejecutables...

De este modo la firma de mis ejecutables se perderá, y, bueno, yo con eso me medio conformo, aunque, tengo que reconocer que el medio conformo viene de que no sabría ir más allá: si el "cracker" es capaz de meterse en el código del programa y saltarse la función que valida la licencia "online"... creo que no sabría cómo contrarestarlo. Pero ya digo, al menos tendría que parchear el programa, cosa que ahora mismo (bueno, ya veremos si hay cuarto "crack") no necesita, puesto que con poner al lado del programa una DLL ya le basta y le sobra al cabrito.

[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

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

Empezado por roman

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?

Entiendo que eso valdría para probar, pero no serviría para distribuir el crack a otros usuarios.

[roman]

Empezado por Neftali

Entiendo que eso valdría para probar, pero no serviría para distribuir el crack a otros usuarios.

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

LineComment Saludos

[dec]

Hola,

Empezado por roman

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

LineComment Saludos

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

[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,

Empezado por Neftali

Entiendo que eso valdría para probar, pero no serviría para distribuir el crack a otros usuarios.

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

[dec]

¡Hola a todos!

Empezado por Román

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

... el caso es que la comprobación de la DLL se realiza después de usar la función "SetDefaultDllDirectories", y, además sin errores. Si no se usa esta función, aunque compruebe la existencia de la DLL, el "crack" hace su trabajo, o sea, la DLL "maliciosa" se carga y "pasa" de la comprobación que yo pueda hacer. Actualmente y usando la función "SetDefaultDllDirectories" la DLL se sigue cargando (?) pero la comprobación funciona y así puedo cerrar el programa.

Empezado por Román

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.

Sé que la unidad SHFolder.pas es bastante "sustituible", pero, ¿quién nos dice que el "cracker" no hará uso de otra DLL? Ha elegido dicha DLL, pero, ¿quién nos dice que no podrá elegir otra cualquiera? En ese caso igual el asunto se complica, puesto que hablamos ya de sustituir código de la VCL... en este caso una pequeña unidad, pero, ¿y en los siguientes casos?

¡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:

Empezado por Román

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?

En primer lugar, no se trata de las mismas DLL. Es decir, el cracker usa una DLL del mismo nombre, pero, el contenido de las mismas difieren, de modo que creo que aquí sería él quien tendría un problema: su DLL tendría que "emular" toda la otra DLL... Por otro lado, hay que tener en cuenta que no hablamos del sistema del "cracker", sino del usuario del "crack"... de hecho el "crack" se distribuye con instrucciones (muy útiles para mí también) y en este caso se indica que se copie la DLL en el directorio de los programas. Yo creo que no podría sustituir la DLL del directorio del sistema, pero, si fuese así, allá el usuario que quisiera hacer algo así...

[roman]

Empezado por dec

En primer lugar, no se trata de las mismas DLL. Es decir, el cracker usa una DLL del mismo nombre, pero, el contenido de las mismas difieren, de modo que creo que aquí sería él quien tendría un problema: su DLL tendría que "emular" toda la otra DLL...

Tu programa crakeado, ¿funciona? Entiendo que sí, de lo contrario no sería un crack sino un killer Esto quiere decir que sigues pudiendo buscar rutas y folders y demás, es decir, sigue existiendo la funcionalidad de la dll original. Así que sí, ya hizo la emulación. Muy posiblemente desde su dll carga la original para ejecutar el código original después del suyo.

LineComment Saludos

[dec]

Hola,

Empezado por roman

Tu programa crakeado, ¿funciona? Entiendo que sí, de lo contrario no sería un crack sino un killer Esto quiere decir que sigues pudiendo buscar rutas y folders y demás, es decir, sigue existiendo la funcionalidad de la dll original. Así que sí, ya hizo la emulación. Muy posiblemente desde su dll carga la original para ejecutar el código original después del suyo.

LineComment Saludos

Sí; en efecto el programa funciona. También pensé en ello Román... y es cierto, al ser una DLL tan "pequeña" (a tenor de la unidad de Delphi que la envuelve, que puede no estar completa...) tal vez el "cracker" "simplemente" la reemplace toda. Pero, ¿usa las funciones que incluye para su propósito? Yo creo que no... sino que en la DLL el "cracker" incluye otro código que es el que hace "algo" que acaso no tenga que ver con la DLL ni con las funciones de la misma... no estoy seguro.

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!