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

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

[roman]

Oye, pero mira que el cracker es decente:

Empezado por el cracker

Support the developer if u can. The Deserve it.

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

[dec]

Hola Román,

Empezado por roman

Oye, pero mira que el cracker es decente:





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

Je je je... no lo he leído en este "crack", pero, sí en otros. Sea como sea sobre esto hay mucha tela que cortar. A mí me consta que las páginas "warez" usan "bots" para estar al tanto de cada publicación de mis programas: y no sólo de mis programas, lógicamente. Con esto consiguen que sus sitios web aparezcan "actualizados" y atractivos para los usuarios. Ahora bien, estos sitios "warez", el mejor de ellos, se conforma con ponerte publicidad en la web, o bien usar enlaces "de pago" a servidores "de pago" también... el peor de los sitios "warez" puede acaso colarte de matute algo que haga lo que no esperas en tu ordenador...

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

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

Empezado por dec

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

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