The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,782 other followers

Delphi: interesting unit uExecFromMem from start an executable from binary memory image

Posted by jpluimers on 2014/08/12

A long while ago, (they are hosted on Google Sites) posted a very interesting via: uExecFromMem unit. It was only a code snippet, not much usage info.

One of the things you can do with this unit, is load the memory image of an executable from a database BLOB, then execute that.

bummi showed this as an uExecFromMemory example on StackOverflow including a small memory leak fix.

It opens way for some interesting deployment scenarios. Not for the everyday ones, but for the occassional situation where a regular deployment is impractical.


via: uExecFromMem by steve10120 – fixed for Win7x64 by testest – DelphiBasics.

Comment by Craig Peterson at G+:

It’s a handy looking unit, but has a licensing bomb in it: The PerformBaseRelocation routine is lifted directly from BTMemoryModule.pas, which is only licensed LGPL without the binary linking exception.  That means providing your DCUs so anyone can relink your app.  It’s also a bit less maintainable than BTMemoryModule, since they replaced a bunch of declared constants with magic numbers.

4 Responses to “Delphi: interesting unit uExecFromMem from start an executable from binary memory image”

  1. David Heffernan said

    Nope. Not a good idea. Unless you want your app to attract the attention of anti-malware tools. Or enjoy the excitement of standing on unsupported implementation specific hacks that could fail under OS updates.

  2. Nick Ring said

    There are a few other libraries around which do a similar thing: and

  3. abouchez said

    …. and interesting deployment nightmares, IMHO…
    Such low-level hacking can easily be identified as a potential thread, and just blocked, without further notice…

    If you want to load and execute some code at runtime, you have .dll libraries for that!
    Or just call CreateProcess() or ShellExecute() APIs.

    • Kmorwath said

      I agree – it also needs high privileges assigned to the user using those APIs, or they will fail. This could be a technique to be used for very specific applications needing for some good reason them, and able to run with the proper privileges on a system without creating havoc. Most security tools will recognize such a patter as being used by a malware, and unless the application is whitelisted, it will be blocked.
      Also storing an executable in a database and then run it on a remote system without any check can open a Pandora box on its own…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: