Is it possible to embed a DLL into the EXE file such that only the exe
needs to be distributed?
I need to use a 3rd party protection dongle in my programs. The maker
provides a DLL interface but it means that I must send this DLL along
with my program, which I would rather not do.
Previously we used another maker's dongle and this used a Windows
driver plus an OBJ file which we could link into our exe. Now the
driver is no longer being updated so we need to switch to another
brand of dongle.
But sending a DLL along with the exe seems a risk for hacking, nothing
stops a hacker from replacing the dll with one of his own with
Since this maker does not have an OBJ file to link with I thought I
would ask if it is possible to embed the DLL functionality directly
into the exe?
Or is there some tool that can take a DLL as input and create the OBJ
file, which can then be used to link into the program?
I am looking at FPC 3.0.4 with Lazarus 1.8.4 on Windows 32 bit and
compatibility with Delphi 7-XE5 32 bit.
>> Since this maker does not have an OBJ file to link with I thought I
>> would ask if it is possible to embed the DLL functionality directly
>> into the exe?
>There are a few options:
>1) Include the DLL as a resource and extract it to a temp location
>before loading it
What the pages I found suggest as a solution is to extract the DLL
from the resource to memory in the same place where it would be put
using LoadLibrary. Then it could be called as if loaded from disk but
the disk would not be touched.
Digging down this route makes me hesitant since it involves using a
number of rather big source files to handle the operations. Too big
and involved for me to understand...
Right, but this is just verification of the integrity of the file(s),
which of course could be a good thing. And I have no sources to the
DLL, just the working binary.
Is there some tool that can take a DLL as input and create an OBJ
file, which then can be linked into the application?
That would be the best solution at least for me.
In our previous episode, Zoe Peterson said:
> There are a few options:
> 1) Include the DLL as a resource and extract it to a temp location ...
> 2) Load it directly from memory using a third party unit like this: ...
> 3) Codesign the DLL and executable and verify that they haven't been ...
All three assume the exe will start without the DLL, which is often not a
>> 1) Include the DLL as a resource and extract it to a temp location
>> before loading it
> I have seen these suggestions but the comments indicated that writing
> a binary file to the filesystem on startup and then calling stuff
> inside likely will trigger antivirus detection...
> See: http://www.delphipages.com/forum/showthread.php?t=216147
This behavior raises a warning in the antivirus for sure. Not a good choice.
> This I don't understand, it does not look like they have embedded the
> dll into the application at all...
> In the example both tests use the same code to load the dll from the
> file system:
> ms := TMemoryStream.Create;
> (Paramstr(1) is the required DLL path)
It uses a memory stream, no disk is touched, but in the example, for
simplicity, it reads the DLL from disk instead a resource in the EXE.
In my Delphi times I was using it with good results. I was trying to
port it to FPC but drop the attempt.
Anyway, using a DLL only complicates the distribution. Security is the
same as an OBJ file, a hacker can not simply replace the DLL with an
empty stub as some operations must be performed in the dongle which are
verified in the main code, the DLL is just a tunnel between application