| 18 | | All these functions seem to be consistent, but their combination does not seem to work. 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: |
| | 20 | All these functions seem to be consistent, but their combination does not seem to work (yet). |
| | 21 | |
| | 22 | == Expected workflow == |
| | 23 | What should happen in zzuf: |
| | 24 | * zzuf enters `run_process()` to call the target binary |
| | 25 | * `run_process` calls `get_entry()` to retrieve the target binary's entry point |
| | 26 | * `run_process` runs the binary in suspended mode |
| | 27 | * `run_process` calls `dll_inject()` to inject our dll-loading code at the target binary's entry point |
| | 28 | * `run_process` resumes the binary's execution |
| | 29 | |
| | 30 | What should happen in the target binary: |
| | 31 | * we get started in suspended mode |
| | 32 | * 78 bytes of code containing a DLL loader are allocated in our address space by zzuf |
| | 33 | * our entry point is overwritten by zzuf with the DLL loader's address |
| | 34 | * our execution is resumed by zzuf |
| | 35 | |
| | 36 | == Current behaviour == |
| | 37 | The real zzuf diversions are not implemented for Win32. For now, only LoadLibraryA is diverted, for debugging purposes. |
| | 38 | |
| | 39 | 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: |
