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

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

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;

[dec]

Hola,

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

[roman]

Empezado por Neftali

Código Delphi [-]
        // Es el mismo directorio del EXE?

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

[dec]

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

[dec]

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

[roman]

De verdad, hay veces que parece que no me leen :

Empezado por roman

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

LineComment Saludos

[dec]

Hola a todos,

Empezado por roman

De verdad, hay veces que parece que no me leen :

LineComment Saludos

Sí hombre, sí que se te lee... ejem,... ¿te refieres a que acaso sería bueno comprobar si, además de en el directorio de la aplicación, alguna DLL se ha cargado desde el "directorio actual"? ¿No podría causar esto algún problema que acaso se solucionase cambiando nosotros mismos dicho directorio al principio?

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

Empezado por roman

De verdad, hay veces que parece que no me leen :

Ya sabes que no.
El problema es que en este hilo se nos ha notado mucho...

[[escafandra]]

Aunque consigas evitar la carga de la dll maliciosa en el arranque de tu app, siempre se puede inyectar con un pequeño ejecutable. Esto quiere decir que no puedes quedarte en la defensa de la carga, has de ir más allá y cambiar el código de protección. Además deberás comprobar, en ese código, que no está cargada una dll no deseada. Puedes usar la API GetModuleFileName para ello pues te da la ruta completa de la dll. También puedes explorar las funciones que exporta. Un hook a la indocumentada ldrLoadDll también te puede ayudar a evitar cargas e inyecciones. Eso puede dificultar al crack en la investigación de un nuevo crack. Pero todo esto no quita para que no fortalezas y ofusques el sistema inicial de protección, es fundamental.

Saludos.

[dec]

Hola a todos,

Empezado por escafandra

Aunque consigas evitar la carga de la dll maliciosa en el arranque de tu app, siempre se puede inyectar con un pequeño ejecutable. Esto quiere decir que no puedes quedarte en la defensa de la carga, has de ir más allá y cambiar el código de protección. Además deberás comprobar, en ese código, que no está cargada una dll no deseada. Puedes usar la API GetModuleFileName para ello pues te da la ruta completa de la dll. También puedes explorar las funciones que exporta. Un hook a la indocumentada ldrLoadDll también te puede ayudar a evitar cargas e inyecciones. Eso puede dificultar al crack en la investigación de un nuevo crack. Pero todo esto no quita para que no fortalezas y ofusques el sistema inicial de protección, es fundamental.

Saludos.

Gracias escafandra. La verdad sea dicha, no estoy muy seguro de cómo fortalezer el sistema en cuestión, aunque, al comprobarse las licencias "online", ciertamente los "keygen" que habían creado en el pasado han dejado de funcionar... o sea que igual por ahí esto ya "podría servir". El problema está en que alguien "inyecte" cierto código que se salte dicha comprobación... yo creo que en ese caso lo daría por perdido, porque, ciertamente, este tipo de "usuarios" probablemente nunca serán clientes, así que, igual no merece la pena el tiempo ni el trabajo.

[[escafandra]]

Empezado por dec

Hola a todos,



Gracias escafandra. La verdad sea dicha, no estoy muy seguro de cómo fortalezer el sistema en cuestión, aunque, al comprobarse las licencias "online", ciertamente los "keygen" que habían creado en el pasado han dejado de funcionar... o sea que igual por ahí esto ya "podría servir". El problema está en que alguien "inyecte" cierto código que se salte dicha comprobación... yo creo que en ese caso lo daría por perdido, porque, ciertamente, este tipo de "usuarios" probablemente nunca serán clientes, así que, igual no merece la pena el tiempo ni el trabajo.

El problema es que ese tipo de usuarios son los que publicarán o difundirán el crack. Puedes crear un sistema anti-inyección realizando un control exhaustivo de la carga de dll que impida la carga de la no deseada, al fin y al cabo toda inyección realiza un ldrLoadDll que puedes interceptar, si quieres información sobre el tema te la facilito.

Saludos.

[mamcx]

Empezado por escafandra

El problema es que ese tipo de usuarios son los que publicarán o difundirán el crack.

No creo que sea tan practico intentar "ganar" el pulso.

Me hace recordar a:

http://www.codeproject.com/Articles/...ntional-Wisdom

---
Una forma de verlo es que cada descarga es una perdida. Es cierto que es muy dificil que se conviertan de pago asi como asi.

----
Otra forma de verlo es que es publicidad.

Seria interesante que tantas descargas genera el sitio. Ves forma de estimarlo?

---
Ahora, digamos que en vez de pelear contra un hacker en un area en la que no eres experto, te pones a pelear por "convertir" los clientes de no pago a pago. En este negocio, lograr un <10% en conversiones se considera "normal".

Asi que en vez de invertir en anti-hacking, invierte en un actualizador automatico.

Que NO INTENTE DESACTIVAR EL HACK.

Entonces, empiezas a recolectar algunos datos utiles. (Por ejemplo, sabes cuantos clientes/instalaciones tienes?). Para no hacerlo intrusivo, puedes simplemente hacer el logeo de la informacion en el servidor que tiene la descarga (sino te parece estar haciendo "ping" desde el cliente) en cada vez que haya una actualizacion.

Asi obtienes la primera metrica util: Cuantos clientes hay por ahi vs. Cuanto se supone que has perdido.

Eso te dejara ver si la pelea tiene o no tiene sentido.

Si no tiene sentido, mejor que te sigan distribuyendo la app lo mas posible!

Luego, si tiene sentido, empiezas a utilizar tecnicas de conversion de clientes. Hay que estudiar el tema, en especial si como intuyo no quieres ponerte de spammer sino hacerlo bien.

---

Por lo demas, darle mas publicidad a la app, y quizas mirar la forma de ganar un cliente corporativo (quizas un distribuidor?) terminaria siendo mas rentable a largo plazo.

[dec]

Hola,

Empezado por escafandra

El problema es que ese tipo de usuarios son los que publicarán o difundirán el crack. Puedes crear un sistema anti-inyección realizando un control exhaustivo de la carga de dll que impida la carga de la no deseada, al fin y al cabo toda inyección realiza un ldrLoadDll que puedes interceptar, si quieres información sobre el tema te la facilito.

Saludos.

¡Gracias por comentar escafandra! Yo trataba de indicar el hecho de que, en este caso, el "vector de ataque" (siempre quise decir esto...) se basa en una DLL, pero, mañana puede ser usando otra DLL... o un "parche" desde otro ejecutable, o... en fin, es un camino sin retorno en el que uno debe acompañar al "cracker" hasta el final, y, ciertamente, ¿para conseguir qué?

Sea como sea, si no me equivoco, este "cracker" en concreto, no parece haber sacado aún el crack "cinco", o sea,... igual para él ya no es posible seguir usando el mismo "vector de ataque"... o bien es que sencillamente no encontrado el "crack" todavía pero este ya existe y está publicado por ahí. ¡Ya veremos!

[[escafandra]]

El siguiente artículo es de recomendable lectura para el tema en cuestión: Carga segura de las bibliotecas para evitar ataques de precarga de DLL

Saludos.

[dec]

Empezado por escafandra

El siguiente artículo es de recomendable lectura para el tema en cuestión: Carga segura de las bibliotecas para evitar ataques de precarga de DLL

Saludos.

Gracias escafandra. Leído el artículo se hace hincapié en el uso de "SetDLLDirectory" para eliminar el directorio "actual" de la búsqueda de DLL. Sin embargo, en el mismo artículo se indica que esto no sirve si el "atacante" tiene acceso al directorio de la aplicación, que, es precisamente donde se situaban los "cracks" en mi caso. Claro, no estamos hablando de ningún "atacante", sino de un "crack" con unas instrucciones precisas que indican dónde copiar la DLL "maliciosa": como será el propio usuario (y no un "atacante") el que lo haga, poco podemos hacer para evitarlo.

También he probado (además de con "SetDLLDirectory") probé con "SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)", pero, aunque se ejecuta correctamente, no parece surtir el efecto que buscamos, pues la DLL "maliciosa" consigue ser cargada, aunque, ignoro porqué, en este escenario podemos comprobar su existencia y cerrar el programa. La solución de Neftalí se me antoja la más acertada mientras la DLL en cuestión no pueda evitar su correcto funcionamiento: en este caso nos da igual que la DLL se cargue... porque cerraremos el programa en tal caso.

En fin, según parece, el "cracker" hasta ahora encargado no puede seguir adelante, tal vez porque quiera ser elegante y encontrar un método que no "toque" los ejecutables de los programas. Ya veremos.

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