Custom Query (39 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (4 - 6 of 39)

1 2 3 4 5 6 7 8 9 10 11 12
Ticket Resolution Summary Owner Reporter
#51 fixed DATADIR conflicts with MinGW objidl.h header Sam Hocevar guest
Description

mingw/include/objidl.h, lines 92-95: typedef enum tagDATADIR {

DATADIR_GET=1, DATADIR_SET

} DATADIR;

libcaca/tools/Makefile.am, lines 3-4: AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/caca -I../caca \

-I$(top_srcdir)/caca -DDATADIR=\"$(pkgdatadir)\"

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../caca -I../caca -I../caca -DDATADIR=\"/usr/local/share/libcaca\" -fno-common -mms-bitfields -IC:/msys/local/include/pango-1.0 -IC:/msys/local/include/freetype2 -IC:/msys/local/include -IC:/msys/local/include/glib-2.0 -IC:/msys/local/lib/glib-2.0/include -g -O2 -g -O2 -fno-strength-reduce -fomit-frame-pointer -Wall -Wpointer-arith -Wcast-align -Wcast-qual -Wstrict-prototypes -Wshadow -Waggregate-return -Wmissing-prototypes -Wnested-externs -Wsign-compare -MT makefont-makefont.o -MD -MP -MF .deps/makefont-makefont.Tpo -c -o makefont-makefont.o test -f 'makefont.c' || echo './'makefont.c In file included from c:\mingw\bin\../lib/gcc/mingw32/4.3.0/../../../../include/objbase.h:73,

from c:\mingw\bin\../lib/gcc/mingw32/4.3.0/../../../../include/ole2.h:9, from c:\mingw\bin\../lib/gcc/mingw32/4.3.0/../../../../include/windows.h:114, from c:\mingw\bin\../lib/gcc/mingw32/4.3.0/../../../../include/winsock2.h:22, from makefont.c:29:

c:\mingw\bin\../lib/gcc/mingw32/4.3.0/../../../../include/objidl.h:95: error: expected identifier or '(' before string constant make[2]: * [makefont-makefont.o] Error 1

How to fix: Change DATADIR to something else, like CACADATADIR or remove it completely (used only in demo.c and it's #if 0 anyway).

#63 fixed Extra space before external links carmie Sam Hocevar
Description

Il y a trop d'espace avant les liens externes:

#62 invalid Finish the Win32 port Sam Hocevar Sam Hocevar
Description

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
1 2 3 4 5 6 7 8 9 10 11 12
Note: See TracQuery for help on using queries.