LoadLibrary from byte array?

How long is the array? What format is the data in it expressed in?

The array is 126,462 bytes and it's a DLL binary file.

This is a non-trivial exercise. You could try the instructions here, but honestly it's just easier to have it as a separate file.

Thanks a lot for the link, I really appreciate the help.

Why not just store the byte array to a temporary dll file and load that file?
Some single exe tools (such as RegMon from sysinternal, if I remember correct) does same to load drivers.

I worded my question pretty badly, I want to get the address of a function stored in a DLL through a byte array. This is absolutely 100% for learning purposes which is why I don't want to use a blatantly simpler method. There are 100 ways I know how to do this differently but I want to learn how to do it this specific way.


DWORD GetAddressFromBinary( unsigned char *pData )
{
// Sort through data here
HMODULE MemDll = reinterpret_cast<HMODULE>pData;
DWORD Address = GetProcAddress( MemDll, "TestFunction" );

return Address;
}

int main( unsigned char *pData )
{
// Read file for array of bytes
unsigned char *pData = ReadFile(/*Parameters here*/);
GetAddressFromBinary( pData );
}


Then you only want to get the function address? Then you need to learn PE format.

An In-Depth Look into the Win32 Portable Executable File Format

Also google for more articles.

Thanks, keep the information coming guys.

I am incredibly interested in learning Windows programming bottom to top and this is one of the things at the moment that I'm most interested in learning.

HMODULE MemDll = reinterpret_castpData;
[/quote]
No. Just... no.

A HMODULE is a handle. A handle is an opaque type given to you by an API. You're not supposed to assume anything about it. You are assuming that it is a pointer to the first byte in memory of a loaded DLL.

SiCrane in #4 post linked good article about how to do it. You will find source code in that link that will load dll from memory, and provide function address getting from it: https://github.com/fancycode/MemoryModule

HMODULE MemDll = reinterpret_castpData;

No. Just... no.

A HMODULE is a handle. A handle is an opaque type given to you by an API. You're not supposed to assume anything about it. You are assuming that it is a pointer to the first byte in memory of a loaded DLL.
[/quote]

The reason I posted it in the code was I was trying to just show a very simple example of what I am attempting to do, which is turn a byte array into an HMODULE that can be loaded by GetProcAddress() to return the address of the requested function in the DLL.

You are assuming that it is a pointer to the first byte in memory of a loaded DLL.

http://msdn.microsoft.com/en-us/library/aa383751(v=vs.85).aspx
HMODULE A handle to a module. The is the base address of the module in memory.

That's quite a safe assumption to make. LoadLibraryEx can return HMODULEs that point to a byte array where that definition isn't strictly true, but these don't work with any PE related functions like GetProcAddress. So both you and the code are kinda right.

They, and the first byte of any array that contains a dll/exe, do work with the Image* api's. The addresses of exported functions can be gotten at by parsing the return value of ImageDirectoryEntryToData(arrayBase, FALSE, IMAGE_DIRECTORY_ENTRY_EXPORT, &size) which is spelled out in the link wqking posted. Gratuitous use of ImageRvaToVa is required to turn the relative addresses in the structures to actual ones.

I am the author of MHS. The full source to MHS is available on the forums (but due to spambots I have disabled registration temporarily so ask here if you have questions) and includes the correct implementation of GetProcAddress(), including proper search-path ordering etc. It can be studied and used for your own purposes.

If the function you want to find is exported from the DLL, you can find it easily by loading the DLL and using the real GetProcAddress() or my own (both return the same value) to find its address within the module.
If the DLL is actually stored within another process you can use that offset, along with the address of the DLL in the target process, to determine exactly where it is in that process.

If it is not exported, you can determine its location within any given process only if you have a byte signature of the function.
A byte signature is a special encoding of the function in which the machine-code commands of the function are encoded so that the ops are raw values and the offset-based operands are variables. In the MHS disassembler, you can view the ops and the operands separately, enabling you to create this type of string. Once created, the string is used in searching by looking for exact matches on the ops, and allowing any values for the offset-based operands.


Additionally, I can assure that HMODULE is always the actual address of the DLL in any given process (in reference to the case refuted by rip-off; naturally you could just assign any value to an HMODULE but that is not under dicussion here). If this fact was not reliable, my software simple could not run (and I am not careless; I rely on this only because it is in fact reliable). It is always guaranteed to be true.


L. Spiro