Embed and execute native code from memory

Question

I want to do these two things with my application (Windows only):

1. Allow user to insert (with a tool) a native code into my application before starting it.
2. Run this user-inserted code straight from memory during runtime.

Ideally, it would have to be easy for user to specify this code.

I have two ideas how to do this that I'm considering right now:

1. User would embed a native dll into application's resources. Application would load this dll straight from memory using techniques from this article.

2. Somehow copy assembly code of .dll method specified by user into my application resources, and execute this code from heap as described in this article.

Are there any better options to do this? If not, any thoughts on what might cause problems in those solutions?

EDIT

I specifically do not want to use LoadLibrary* calls as they require dll file to be already on hard drive which I'm trying to avoid. I'm also trying to make dissasembling harder.

EDIT

Some more details: Application code is under my control and is native. I simply want to provide user with a way to embed his own customized functions after my application is compiled and deployed.

User code can have arbitrary restrictions placed on it by me, it is not a problem.

Answer 1

The aim is to allow third parties to statically link code into a native application.

The obvious way to do this is to supply the third parties with the application's object files and a linker. This could be wrapped up in a tool to make it easy to use.

As ever, the devil is in the detail. In addition to object files, applications contain manifests, resources, etc. You need to find a linker that you are entitled to distribute. You need to use a compiler that is compatible with said linker. And so on. But this is certainly feasible, and likely to be more reliable than trying to roll your own solution.

Answer 2

Your option 2 is pretty much intractable in my view. For small amounts of self-contained code it's viable. For any serious amount of code you cannot realistically hope for success without re-inventing the wheel that is your option 1. For example, real code is going to link to Win32 functions, and how are you going to resolve those? You'd have to invent something just like a PE import table. So, why do so when DLLs already exist. If you invented your own PE-like file format for this code, how would anyone generate it? All the standard tools are in the business of making PE format DLLs.

As for option 1, loading a DLL from memory is not supported. So you have to do all the work that the loader would do for you if it were loading from file. So, if you want to load a DLL that is not present on the disk, then option 1 is your only choice.

Any half competent hacker will readily pull the DLL from the executing process though so don't kid yourself that running DLLs from memory will somehow protect your code from inspection.

Answer 3

This is something called "application virtualization", there are 3rd party tools for that, check them on google.

In a simple case, you may just load "DLL" into memory, apply relocs, setup imports and call entry point.