WIN32: динамически загружаемые функции

yolki

H = LoadModule("a.exe",NULL);

MyProc = GetProcAddress(H,"MyFunc");

maggi14

lera98

bastii

laki

bastii

maggi14

gopnik1994

Marinavo_0507

kokoc88

maggi14

MSDN:
Platform SDK: DLLs, Processes, and Threads
LoadLibrary
The LoadLibrary function maps the specified executable module into the address space of the calling process.
For additional load options, use the LoadLibraryEx function.
HMODULE LoadLibrary(
LPCTSTR lpFileName
);
Parameters
lpFileName
[in] Pointer to a null-terminated string that names the executable module (either a .dll or .exe file). The name specified is the file name of the module and is not related to the name stored in the library module itself, as specified by the LIBRARY keyword in the module-definition (.def) file.
If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\ not forward slashes (/).
If the string does not specify a path, the function uses a standard search strategy to find the file. See the Remarks for more information.
Return Values
If the function succeeds, the return value is a handle to the module.
If the function fails, the return value is NULL. To get extended error information, call GetLastError.
Windows Me/98/95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. If you are attempting to load a 16-bit DLL directly from 32-bit code, LoadLibrary fails. If you are attempting to load a DLL whose subsystem version is greater than 4.0, LoadLibrary fails. If your DllMain function tries to call the Unicode version of a function, LoadLibrary fails.
Remarks
To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function.
LoadLibrary can be used to map a DLL module and return a handle that can be used in GetProcAddress to get the address of a DLL function. LoadLibrary can also be used to map other executable modules. For example, the function can specify an .exe file to get a handle that can be used in FindResource or LoadResource. However, do not use LoadLibrary to run an .exe file, use the CreateProcess function.
If the module is a DLL not already mapped for the calling process, the system calls the DLL's DllMain function with the DLL_PROCESS_ATTACH value. If DllMain returns TRUE, LoadLibrary returns successfully. If DllMain returns FALSE, the system unloads the DLL from the process address space and LoadLibrary returns NULL.
It is not safe to call LoadLibrary from DllMain. For more information, see the Remarks section in DllMain.
Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use — for example, in calling GetProcAddress. The other process must make its own call to LoadLibrary for the module before calling GetProcAddress.
If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.
If no file name extension is specified in the lpFileName parameter, the default library extension .dll is appended. However, the file name string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file. The search order used depends on the setting of the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode value.
Windows 2000/NT and Windows Me/98/95: The SafeDllSearchMode value does not exist.
If SafeDllSearchMode is 1 (the default the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
Windows Me/98/95: This directory does not exist.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable.
If SafeDllSearchMode is 0, the search order is as follows:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
Windows Me/98/95: This directory does not exist.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable.
Windows XP: The default value of HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 0 (the current directory is searched before the system and Windows directories).
The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable.
The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL.
If a path is specified and there is a redirection file for the application, the function searches for the module in the application's directory. If the module exists in the application's directory, LoadLibrary ignores the specified path and loads the module from the application's directory. If the module does not exist in the application's directory, LoadLibrary loads the module from the specified directory. For more information, see Dynamic Link Library Redirection.
If you call LoadLibrary with the name of an assembly without a path specification and the assembly is listed in the system compatible manifest, the call is automatically redirected to the side-by-side assembly.
The Visual C++ compiler supports a syntax that enables you to declare thread-local variables: _declspec(thread). If you use this syntax in a DLL, you will not be able to load the DLL explicitly using LoadLibrary or LoadLibraryEx. If your DLL will be loaded explicitly, you must use the thread local storage functions instead of _declspec(thread).

MSDN:
Platform SDK: DLLs, Processes, and Threads
GetProcA

kamputer

а ЕХЕ всегда грузится по БА 0х00400000 и никуда уходить не собирается, а на этом адресе итак уже висит ЕХЕ, который ее подгрузил...

kamputer

3. Про невозможность использования GetProcAddress в MSDN прямо не скзано, однако непонятно, откуда будет браться этот адрес, если exeшники ничего в .def-файле не экспортируют.

bmostr56

gopnik1994

Во-первых, изначально при сборке екзешника base address можно задать любым (в VS, например, у линкера есть соотв. опция).

Во-вторых, в PE есть такая штука, как relocation table. Та самая, которая в частности используется для того, чтобы dll-ки можно было по любому адресу загружать. Но и в exe она тоже вполне может присутствовать (секция .reloc и тогда его вообще можно (мб, для этого придётся немного поработать ручками) по любому адресу загружать.

gopnik1994

kamputer

kamputer

yolki

Program Project1;



uses

  SysUtils,

  Classes;



{$R *.res}

procedure HelloFunction;

begin

 WriteLn('Very hello world!');

end;

exports

 HelloFunction name 'HelloFunction';



begin

 HelloFunction;

end.

{$APPTYPE CONSOLE}

program loader;

uses sysutils,classes,windows;

var

 HM: THandle;

 p:procedure;

begin

 HM:=LoadLibrary('pr.exe');

 p:=GetProcAddress(HM,'HelloFunction');

 p;

end.

library Project1;



uses

  SysUtils,

  Classes;



{$R *.res}

procedure HelloFunction;

begin

 WriteLn('Very hello world!');

end;

exports

 HelloFunction;

begin

end.

kamputer

kamputer

yolki

V:\XXX>dumpbin /exports pr.exe

Microsoft (R) COFF Binary File Dumper Version 6.00.8168

Copyright (C) Microsoft Corp 1992-1998. All rights reserved.





Dump of file pr.exe



File Type: EXECUTABLE IMAGE



  Section contains the following exports for pr.exe



           0 characteristics

           0 time date stamp Thu Jan 01 03:00:00 1970

        0.00 version

           1 ordinal base

           1 number of functions

           1 number of names



    ordinal hint RVA      name



          1    0 000122AC HelloFunction



  Summary



        1000 .edata

        1000 .idata

        1000 .rdata

        2000 .reloc

        2000 .rsrc

        1000 .tls

        1000 BSS

       12000 CODE

        1000 DATA

yolki

V:\XXX>dumpbin /exports Project1.dll

Microsoft (R) COFF Binary File Dumper Version 6.00.8168

Copyright (C) Microsoft Corp 1992-1998. All rights reserved.





Dump of file Project1.dll



File Type: DLL



  Section contains the following exports for Project1.dll



           0 characteristics

           0 time date stamp Thu Jan 01 03:00:00 1970

        0.00 version

           1 ordinal base

           1 number of functions

           1 number of names



    ordinal hint RVA      name



          1    0 000123C0 HelloFunction



  Summary



        1000 .edata

        1000 .idata

        2000 .reloc

        2000 .rsrc

        1000 BSS

       12000 CODE

        1000 DATA

kamputer

yolki

{$APPTYPE CONSOLE}

Program Project1;



uses

  SysUtils,

  Classes;



{$R *.res}

function FunctionX(x:double):double; cdecl;

begin

 Result:=x*x+x;

end;

exports

 FunctionX name 'FunctionX';

begin

 writeln(FunctionX(10;

end.

kamputer

gopnik1994

gopnik1994

gopnik1994

kamputer

kamputer