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

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

2) Load it directly from memory using a third party unit like this: https://github.com/Fr0sT-Brutal/Delphi_MemoryModule

3) Codesign the DLL and executable and verify that they haven't been modified. There's code to do that on Stack Overflow, though it wasn't tested on Lazarus:
https://stackoverflow.com/questions/5993877/checking-digital- signature-programmatically-from-delphi

Zoe Peterson schrieb am Sa., 7. Juli 2018, 10:04:

Of course one will need to make sure that the own binary wasn't modified as well (e.g. patching the code that checks the signature).

Regards,
Sven

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

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

2) Load it directly from memory using a third party unit like this: https://github.com/Fr0sT-Brutal/Delphi_MemoryModule

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;
      ms.LoadFromFile(ParamStr(1));

(Paramstr(1) is the required DLL path)

I found another MemoryModule at GitHub named BTMemoryModule: https://github.com/nedich/memorymodule
But it too looks rather involved, and is pretty old...

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.

Conversion tool?
----------------
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.

I have found objconv: http://www.agner.org/optimize/#objconv But it does not have an option to use a DLL as input file... Maybe it is not possible to do such a conversion I am after?

In our previous episode, Zoe Peterson said:

All three assume the exe will start without the DLL, which is often not a given.

There are still dongles that work with .objs (e.g. Dinkey Pro).

Hello,

This behavior raises a warning in the antivirus for sure. Not a good choice.

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.

I found another MemoryModule at GitHub named BTMemoryModule: https://github.com/nedich/memorymodule But it too looks rather involved, and is pretty old...

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