id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	product
62	Finish the Win32 port	Sam Hocevar	Sam Hocevar	"== Strategies ==
There is no such thing as `LD_PRELOAD` on Win32. Several strategies exist to mimic the Unix functionality:
 * Use the `AppInit_DLLs` registry key (not acceptable: it affects all executables and requires a reboot for changes to be taken into account, although there is at least one interesting [http://fy.chalmers.se/~appro/nt/DLL_PRELOAD/ use of this feature])
 * Act as a kernel debugger (not acceptable: we want to remain in userland)
 * DLL injection: inject code into the subprocess so that it overwrites the desired function addresses

== Code already in zzuf ==
The bases for DLL injection are already here:
 * libzzuf's [/browser/zzuf/trunk/src/sys.c sys.c] contains the following:
   * A `LoadLibraryA_orig` pointer that should be filled with the address of the real `LoadLibraryA` function
   * A `LoadLibraryA_new` function that calls `LoadLibraryA_new` and displays a debug message
   * An `insert_func` function that replaces a given function address in the current process' address space
   * Code in `_zz_sys_init` that calls `insert_func` for each function we want to overwrite (currently only LoadLibraryA is affected; in the future, this will iterate over a global array)
 * libzzuf's [/browser/zzuf/trunk/src/libzzuf.c libzzuf.c] contains a `DllMain` entry that calls `_zz_init` upon load, which in turn causes `_zz_sys_init` to be called.
 * zzuf's [/browser/zzuf/trunk/src/zzuf.c zzuf.c] contains the following:
   * A `dll_inject` function that writes bytecode into the subprocess' address space which basically does `LoadLibraryA(""libzzuf.dll"")`
   * A `get_entry` function that gets the entry point address of a given executable file
   * Code in the `run_process` function that tries to fork a subprocess in paused state, inject the desired code, and resume it

All these functions seem to be consistent, but their combination does not seem to work (yet).

== Expected workflow ==
What should happen in zzuf:
 * zzuf enters `run_process()` to call the target binary
 * `run_process` calls `get_entry()` to retrieve the target binary's entry point
 * `run_process` runs the binary in suspended mode
 * `run_process` calls `dll_inject()` to inject our dll-loading code at the target binary's entry point
 * `run_process` resumes the binary's execution

What should happen in the target binary:
 * we get started in suspended mode
 * 78 bytes of code containing a DLL loader are allocated in our address space by zzuf
 * our entry point is overwritten by zzuf with the DLL loader's address
 * our execution is resumed by zzuf

== Current behaviour ==
The real zzuf diversions are not implemented for Win32. For now, only LoadLibraryA is diverted, for debugging purposes.

The expected result: any program that calls LoadLibraryA should display a warning message. What happens: nothing. I tested it with a simple program such as this one:

{{{
#!c
#include <windows.h>

int main(void)
{
    AllocConsole();
    fprintf(stderr, ""before\n"");
    LoadLibraryA(""whatever"");
    fprintf(stderr, ""after\n"");
    getchar();
}
}}}

And the command line:

{{{
zzuf.exe -d test.exe
}}}
"	defect	closed	major		port: Windows	SVN	invalid			zzuf