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

¡Hola a todos!

Pues eso. Hace poco me propuse validar las licencias de mis programas "online", de modo que los "keygen" que había por ahí ya no funcionan. Sé perfectamente que la lucha contra la piratería está perdida de antemano, pero, me ha resultado curioso el "crack" que se ha ideado cierto "cracker" (por lo visto español) para saltarse las licencias de mis programas. Veréis.

El "crack" de este hombre consiste en una DLL de nombre "shfolder.dll" que hay que situar al lado de los ejecutables de mis programas. Dicha DLL, en efecto, hace su trabajo, y, mis programas aparecen como "registrados". Pero este no es el tema que yo quiero tratar. El caso es que yo he tratado de contrarestar el "crack" de estos modos:

1º En el formulario principal, en el evento "OnCreate", comprobando que exista cualquier DLL en el directorio del programa, y, si es así, cerrar el programa. Este "contraparche" no tardó nada en saltárselo el "cracker", publicando una nueva versión de su "parche" que hacía inútil mi comprobación.

2º En el bloque "inicialización" de una unidad situada en primer lugar en mi programa, de modo que, según yo (equivocadamente) es el primer código que se ejecuta. De nuevo, se trata de comprobar si existe un archivo DLL, y, cerrar el programa si es así. Pero el "cracker" contrarestó de nuevo y dejó mi intento otra vez en nada.

Ahora bien, entonces, mi pregunta es, ¿qué demonios pasa? ¿Cualquier DLL (de nombre "shfolder.dll" u otra) situada en el directorio de mi programa se cargará sin más antes que mi programa y podrá hacer con el mismo lo que quiera? A mí me da la risa (literalmente), porque, ciertamente, no es algo que pueda evitarse, según me parece.

La DLL en cuestión "shfolder.dll" es en efecto usada en mis programas, puesto que ella se incluye en la unidad "Winapi.SHFolder.pas" de la VCL de Delphi, que sirve para obtener las rutas de ciertos directorios del sistema como "Mis Documentos", etc. Parece ser que, al incluirse dicha DLL sin indicar una ruta absoluta, Windows carga la DLL que se encuentre en el directorio de nuestro programa.

Realmente a mí me llama la atención que nuestro programa no pueda hacer nada contra eso, al menos no tratando de localizar dicha DLL previamente, puesto que, como he indicado arriba, aunque uno compruebe la existencia de la DLL en un código que, supuestamente, será el primero en ejecutarse, en realidad no sucede así y el código de la DLL se ejecuta primero.

Me parece que esta técnica se llama "DLL hijacking", pero, poca información se encuentra en Google en relación a Delphi, sino es que deberíamos indicar las rutas absolutas de las DLL, lo que implicaría tocar el código de la VCL, y, posibles problemas también, puesto que tal vez no sea tan sencillo indicar las rutas de las DLL de forma absoluta para distintas versiones de Windows, por ejemplo.

En fin, ya no os aburro más, porque, como digo, en realidad lo de la piratería es lo que menos me preocupa. En realidad mi "post" surge de la necesidad de saber cómo evitar dichas DLL... pero no tanto por el caso particular del "crack" que han creado para mis programas, sino porque, en efecto, igual que este "crack" podría ser cualquier otro tipo de código "malicioso"...

¡Un saludo a todos, espero que estéis bien y podáis ayudarme en algo! :)

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.

Hola,

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! :)

Vaya, qué curioso. Lucha de titanes :)

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

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

¡Hola!

Je je je... :)

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

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

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.

Interesante la trama. Espero con ansias el desenlace. :)

Hola,

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

Hola,

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

Hola,

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

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

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

¡Hola a todos!

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

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:

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

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

Hola,

¡Ya lo creo que hay instrucciones! :D :D 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. :D :D

Tu programa crakeado, ¿funciona? Entiendo que sí, de lo contrario no sería un crack sino un killer :D 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

Hola,

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! :)

Oye, pero mira que el cracker es decente:

:eek:

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

Hola Román,

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

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

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

¡Hola a todos!

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!

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

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

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

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:

Código Delphi [-]
var
  Handle: THandle;
  ModuleEntry: TModuleEntry32;
  Str1, Str2, Str3:String;
begin
  // Path de todos los módulos cargados
  Handle := CreateToolHelp32SnapShot(TH32CS_SNAPMODULE, 0);
  Win32Check(Handle <> INVALID_HANDLE_VALUE);
  try
    ModuleEntry.dwSize := Sizeof(ModuleEntry);
    Win32Check(Module32First(Handle, ModuleEntry));
    repeat
      // Añadirlo
      Memo1.Lines.Add(ModuleEntry.szExePath);
      // Para todas las DLL's...
      if (UpperCase(ExtractFileExt(ModuleEntry.szExePath)) = '.DLL') then begin
        // Es el mismo directorio del EXE?
        if ExtractFilePath(ModuleEntry.szExePath) = ExtractFilePath(Application.ExeName) then begin
          Str1 := ExtractFilePath(ModuleEntry.szExePath);
          Str2 := ExtractFilePath(Application.ExeName);
          Str3 := ModuleEntry.szExePath;

          // Eliminar el mensaje ··············································.
          ShowMessage('Halt!!'  + sLineBreak +
                      Str1 + sLineBreak +
                      Str2 + sLineBreak +
                      Str3);
          // ···································································
          Halt;
        end;
      end;
    until not Module32Next(Handle, ModuleEntry);
  finally
    CloseHandle(Handle);
  end;
end;

Hola,

Muchas gracias Neftalí, tengo que probar ese código. :)

Creo que hay que tener cuidado aquí. Hasta donde entiendo, el primer directorio donde se busca una dll es el current working directory (CWD) o directorio de trabajo actual, que no necesariamente coincide con el directorio donde se ubica el ejecutable. Por ejemplo aquí, donde se habla del DLL preloading, menciona una prueba abriendo la aplicación haciendo doble clic sobre un archivo asociado a la aplicación (en caso de que la aplicación maneje archivos) en cuyo caso, el CWD será el directorio donde se ubica el archivo.

LineComment Saludos

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

Hola,

Probado el código de Neftalí este funciona como se espera y me convence más que el uso de la función "SetDefaultDllDirectories" y la posterior comprobación de la existencia de la DLL maliciosa. El código podría quedar poco más o menos que como se ve abajo, siendo la unidad en cuestión situada la primera en el "uses" del archivo de proyecto del programa:

Código Delphi [-]
unit Cracker.Welcome;

interface

implementation

uses
  // Delphi
  Winapi.Windows,
  Winapi.TlHelp32,
  System.SysUtils;

var
  H: THandle;
  M: TModuleEntry32;

initialization

  H := CreateToolHelp32SnapShot(TH32CS_SNAPMODULE, 0);
  Win32Check(H <> INVALID_HANDLE_VALUE);
  try
    M.dwSize := Sizeof(M);
    Win32Check(Module32First(H, M));
    repeat
      if LowerCase(ExtractFileExt(M.szExePath)) = '.dll' then
      begin
        if ExtractFilePath(M.szExePath) = ExtractFilePath(ParamStr(0)) then
        begin
          Halt(1);
        end;
      end;
    until not Module32Next(H, M);
  finally
    CloseHandle(H);
  end;

end.

Dicho código supone que en el directorio del ejecutable del programa no debe existir DLL alguna. Me queda la duda de si debo cerrar el "handle" antes del "Halt"...

¡Hola!

Acabo de actualizar todos los programas (pero sin cambiar la versión) para usar el código anterior, en primer lugar, porque creo que puede salvar el "ataque" mediante DLL situadas en el directorio del programa (al menos funciona con el último "crack" conocido), y, en segundo lugar, por jorobar un poco al "cracker", hombre, a ver si ya estaba trabajando sobre el código anterior y su trabajo no sirve para este nuevo código. El que no se consuela es porque no quiere, ¿eh? Je je je. :D :D :D

Una cosa.
Prueba a abrir el programa, ejecutando directamente un fichero .AB (Application Builder File) que tengas en cualquier directorio y colocando junto a ese fichero la DLL "parcheada".
:confused::confused::confused:

Tal vez habrá que añadirle el "Directorio actual" además del de la aplicación.

Ejem:

LineComment Saludos

(Tal como había dicho Román).

Lo he probado y parece que funciona correctamente.
Es decir, carga la DLL del directorio de sistema, no la que hay en el directorio donde se encuentra el fichero .AB.

Hola,

He probado abriendo un archivo "AB" y sigue funcionando bien, esto es, el programa no se inicia si se encuentra la DLL "maliciosa" en el directorio del mismo.