Custom Query (39 matches)

The new version of sed somehow broke the test suite: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533977

As reported in ​http://bugs.gentoo.org/show_bug.cgi?id=282573, libcaca failes to compile with freeglut-2.6, as freeglut itself does not need libGLU.so anymore. As libcaca uses it, it should add '-lGLU' to the GL_LIBS. A patch, which solved it for me as available at ​http://mirror.hamakor.org.il/pub/mirrors/gentoo-portage/media-libs/libcaca/files/libcaca-0.99_beta16-freeglut-2.6.patch

Best regards, Steffen Hau

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 ​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 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 libzzuf.c contains a DllMain entry that calls _zz_init upon load, which in turn causes _zz_sys_init to be called.
• zzuf's 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:

#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