¿Cuan seguro es una DLL?
 

Hola,
Estoy empezando a ver lo que son DLLs con Delphi y encontré mucha información en la búsqueda del Foro, me preguntaba ¿Cuan seguro es crear una DLL donde puedo declarar algunas funciones?. Me hacía esta pregunta ya que cuando se crea una DLL de recursos, vi programas que leen y recuperan esa DLL (ResHacker, Restief, etc) u otros programas que leen DLLs y EXEs como PE Explorer, Hiew, etc., pero, ¿Estos Programas recuperan también el código?, si fuera así como proteger la DLL?
Deiv

No hay forma de recuperar el código original a partir de un ejecutable o dll, como mucho puedes obtener el código ensamblador. Eso es inevitable, pero reconstruir el funcionamiento de una aplicación a partir de su código en ensamblador puede resultar bastante complicado.

Sin embargo los programas como ResHacker no leen el código del ejecutable, sino sus recursos, imágenes, iconos, sonidos, definiciones de formularios, etc. pero no el código fuente. Si necesitas ocultar este tipo de cosas, por ejemplo, porque no quieres que te copien las imágenes que utilizas en tu aplicación, puedes utilizar algún tipo de cifrado, de esta manera aunque alguien consiga extraerlas del ejecutable no le servirían de nada.

A lo que pueden acceder, hasta donde yo sé, es lo que tu exportes de esa dll.

Lo que no se exporte, no hay forma de acceder. El código, es imposible.


Saludos.

La siguiente pregunta, quizá sea tonta (ruego entiendan por los conocimientos limitados que tengo en el tema), pero una DLL puedo crear desde un archivo de texto o desde Delphi verdad? lo compilo, y tengo mi DLL lista para enlazar con mi aplicación u otras.

Dije de repente es tonta la pregunta porque no la he aplicado aún: ¿Puedo editar mi propia DLL? hago esta pregunta ya que si bien "no se puede modificar", entonces ¿cómo el autor modifica su DLL? o es como dijo Lepe, solo cuando se exporta? ¿como?
Deiv

Una DLL no es más que un ejecutable. Es más, si comparas los primeros octetos (bytes) de una DLL con los primeros de un EXE verás que son casi idénticos. Por lo tanto, un autor modifica su DLL de la misma forma que los autores modifican sus EXE...

Y solo solo por curiosidad, ya que crear una DLL es por así decirlo dar un manera de seguridad a un Programa, ¿Como antes Pascal daba seguridad a sus programas con varias Units que debía tener adjuntas? ¿O es que todo estaba incluido en su ejecutable?

He leido que el ejecutable de Delphi TDump genera un reporte de una DLL a Texto de toda la Info?? acaso esta no es una forma de checkar parte del código de la DLL?

Hola,

Eso no tiene porqué ser así. Es decir, que los archivos "DLL" no están pensados para "dar seguridad" a un programa,... a no ser que la "DLL" cuente con recursos que el programa utilize para darse una cierta seguridad... no hablamos en qué, pero, en principio una "DLL" puede servir para eso como para no pocas cosas más.

Por ejemplo, una "DLL" permite compartir recursos. Así las "DLLs" que componen el API de Win32. Tú no distribuyes con tus programas la "DLL" "Shell32.dll", por ejemplo, y, sin embargo, es probable que hagas uso de ella en tus programas. Esa "DLL" está ya en Windows, generalmente en la carpeta "C:\Windows\System32\" (en Windows NT/2000/XP), de modo que te ahorras distribuirla... pero no sólo tú sino cualquiera que la necesite se la encontrará ya en el sistema.

Y es sólo un ejemplo: el de compartir código, compartir recursos entre programas. Pero, una "DLL" también puede servirte, por ejemplo, para no tener que "redistribuir" completamente un programa tuyo en caso de actualización. Es decir, si cierta parte del programa se encuentra en una "DLL" bastaría con que actualizaras dicha "DLL": el resto del programa no tendrías que actualizarlo.

Y sigue siendo sólo un ejemplo... puedes utilizar una "DLL" para almacenar recursos (imágenes, otros archivos), funciones útiles, qué sé yo... lo que se te ocurra a ti (y a algún compañero que sepa más que yo). No se trata por tanto de que las "DLLs" existan para proporcionar cierta seguridad a un programa, a lo menos hasta donde yo lo veo, vamos. ;)

No. El código no podrá ser accedido, sencillamente, porque no está ahí "en claro". El compilador acaso dejará por ahí el nombre de los procedimientos, nombres de clases, tipos, etc., pero, el código fuente de un procededimiento, por ejemplo, no estará disponible. A lo menos esto es así en lenguajes como Delphi, en compiladores "nativos". Por ejemplo en ".NET" no sucede esto, y se tienen que utilizar (si se quiere) técnicas de "ofuscación" del código, puesto que por medio de otras técnicas de "reflexión"que se llaman es posible al código fuente tal cual, o casi tal cual.

Pero esto esto es así porque lo que se obtiene al compilar un "ensamblado" para ".NET" es un lenguaje "intermedio" que puede, como he dicho, llegar a entenderse casi perfectamente (según recuerdo de lo leído sobre el tema). Es la máquina virtual de .NET la que se encarga de compilar dicho lenguaje intermedio a código máquina. Pues bien, con Delphi lo que obtienes, tu DLL, es código máquina, y así, al menos que yo sepa, no hay forma de acceder al código fuente tal cual tú lo puedes ver.

De todos modos reconozco que a mí todo esto me queda un poco grande. No sé exactamente si todo lo que he dicho es así o si he oído campanas y bueno,... trato de ayudar más con voluntad que conocimiento. Si tenéis que corregirme hacedlo tranquilamente. Pero, ya digo, la pregunta "¿cómo obtengo el código fuente de un programa ejecutable de Delphi?", siempre que se ha efectuado en estos Foros ha obtenido las mismas similares respuestas: "No es posible, eso no es posible".

Gracias dec,
Tus explicaciones muy didácticas "tocayo". Entonces preguntaré de otra forma:
Hasta hoy (como novato) había programado valiéndome de un ejecutable que lo crea Delphi, un Pas, dfm, RES, DAT, Íconos e imágenes, me valía de todo ello.
¿Para el empaquetado de un Programa ya sea con InstallShield, InnoSetup, etc, de que otros archivos más son necesarios en un campo de programación?
Bueno quizá sea depende de lo que uno haga, y lo que uno haga siempre va a querer proteger su código, obvio, pero meter todo en un Ejecutable es tan solo engordar el mismo. Entiendo con la explicacíón que das sobre las dlls eso aliviana al ejecutable, y por un momento creí, que así como tengo íconos o imágenes diseñadas por mi mismo en un directorio que iba a necesitar mi programa, pensé que una dll también iba a estar desprotegida para su lectura, y bueno.... ya sé que a los íconos e imágenes se los puede "proteger algo" con RECURSOS, etc, ¿Me estoy perdiendo de algo más para programar de una buena manera? es decir creo que me falta incluir archivos INI, por ejemplo, y si se trata de Base de datos, tales archivos, etc, pero... un buen programador de manera general ¿qué otros archivos debería de manejar además de los que mencioné y así darle un empaquetado final?
Una vez más gracias por vuestra orientación.
Un saludo

Hola,

Bueno. Yo entiendo que no hay una forma de hacer las cosas en este sentido. Es decir, imagina un programa que únicamente constara de un archivo ejecutable y que no fuera necesario nada más para hacer uso del mismo. No haría falta siquiera instalador, ¿verdad?

Puede que lo utilizaráramos para añadir algún icono en el menú de inicio de Windows (o de donde fuese), y/o para copiar el ejecutable de nuestro programa en algún lugar determinado, pero, lo que está claro es que no vamos a meter archivos de imágenes, de audio, de vídeo, si no los vamos a necesitar.

Así lo veo yo también.

Bueno... siempre, siempre... si distribuyes tu aplicación junto con su código fuente (mediante alguna licencia "libre") pues no veo la necesidad de proteger el código, todo lo contrario. No digo que tengas que hacerlo así, pero, digo que no siempre es preciso proteger el código fuente, y, no sólo en el caso de que pienses distribuir este junto a tu aplicación.

Depende otra vez. Si tu ejecutable va a hacer uso de muchos archivos de imágen y estos son muy pesados... es posible que no te interese incluirlos como recursos en tu ejecutable. No sólo para no engordarlo, sino porque tener las imágenes fuera de tu ejecutable puede acaso proporcionarte alguna ventaja: piensa en las actualizaciones de que hablamos más arriba. No es lo mismo actualizar un archivo de imagen de, digamos, 100 KB, que un ejecutable de 2 MB, por ejemplo.

Volvemos a lo de arriba: dependerá de lo que quieras hacer y de lo que necesites para llevarlo a cabo. Si no te es preciso utilizar archivos INI no veo porqué deberías incluirlos en tu programa... quizás como una forma de "despiste", o para "engordar" artificialmente el programa, para hacerlo a la vista "más complejo"... pero, esto, como ves... son hipótesis un tanto extrañas... en general, digo, si no te hace falta utilizar archivos INI para qué vas a incluirlos, para qué vas a preocuparte de hacerlo.

Bueno, gracias, pero de una forma general, solo general como base por favor, imagino un programa debe tener:

Un ejecutable, dlls, en ocasiones archivos TXT, imágenes, íconos, RES, creo que hasta ahí en cierta medida verdad?, algo más?

Pregunto esto ya que por ejemplo antes no le daba para nada importancia a las dlls (para nada) y todo lo realizaba con código adentro, procedures, functions, etc, todo dentro del ejecutable, de haber sabido que una dll es parte importante de un programa, habría hace tiempo empezado a estudiar y munirme de información al respecto, hoy no es tarde, pero mejor hubiera sido hace rato verdad?, lo propio ocurría con los íconos o imágenes que los tenía desparramados por ahí, hasta que entendí que en ocasiones era mejor llevarlo a un archivo de recursos; otro que me ocurrió por ejemplo cuando alguna vez trabajé con un base de datos, pero que Yo creaba arrays dentro del programa y luego me enteré que era mejor realizarlo digamos en Acces y enlazarlo a mi programa. Cosas así me ocurrieron, Por eso pregunté: ¿Me estoy perdiendo de algo mas que un programa deba llevar consigo? de una forma general. please?

Lo que falta es el archivo de ayuda ;). Quizás una demostración en Wink para un proceso engorroso / complejo para el usuario final.

Mis programas tienen el ejecutable, un .ini y se acabó. ¿que los .ini son muy antiguos y sería mejor usar el registro de windows? pues no, ante un borrado del .ini no quiero verme dentro del registro de windows buscando y añadiendo....o haciendo un programa que añada de nuevo las entradas al registro...no gracias.

Creo que "lo que te estas perdiendo" son las diferentes técnicas de obtener lo mismo. Todo tiene sus pros y sus contras.

Ya lo ha dicho dec, yo ofrezco otro punto de vista:

Para que el ejecutable no ocupe demasiado, el logotipo de la empresa, que se muestra de fondo en la ventana principal, lo pongo en un archivo externo.... Cuando hago una visita al cliente me encuentro con Carmen electra en dudosa postura de fondo ...

Un texto grande lo saco del .exe y lo pongo en un archivo.. ring... ring ¿cómo?¿que una ventana sale en blanco?, ¿sin texto? (cinco segundos de silencio incómodo, para mí por supuesto) ¿existe el archivo info.txt en la carpeta? ahhh... ya veo, se ha evaporado :p

Ahora construyo una dll, es una maravilla, mañana para otro proyecto necesito el código de una función... vaya, necesito modificar toda la dll, además tengo 30 dlls, necesito 15 pero solo voy a usar 1 o 2 funciones de cada dll.... me toca distribuir las 15 dlls, no tengo tiempo para crear 1 sola con todo....

Saludos