Empty coverage file on 32-bit Windows

[hatRiot]

While debugging a separate issue, I discovered that the basic example you give for running litecov doesn't appear to work on a 32-bit Windows machine, compiled with Visual Studio 2017. The following produces an empty coverage file:

$ litecov.exe -instrument_module notepad.exe -coverage_file coverage.txt -- notepad.exe

I'm using the latest TinyInst code and version 11.0.1 of xed on a 32-bit Windows machine.

In trying to capture target_function coverage information from another binary (ExampleTarget.exe), I got the following output:

Debugger: Process created or attached
Debugger: Exception 80000003 at address 77BE060D
Debugger: Loaded module ExampleTarget.exe at 00A00000
Debugger: Loaded module ntdll.dll at 77B40000
Debugger: Loaded module kernel32.dll at 75DB0000
Debugger: Loaded module KERNELBASE.dll at 75A80000
Debugger: Loaded module VCRUNTIME140.dll at 68230000
Debugger: Loaded module api-ms-win-crt-runtime-l1-1-0.dll at 0F540000
Debugger: Loaded module ucrtbase.DLL at 0F210000
Debugger: Loaded module api-ms-win-core-timezone-l1-1-0.dll at 0F720000
Debugger: Loaded module api-ms-win-core-file-l2-1-0.dll at 0FDD0000
Debugger: Loaded module api-ms-win-core-localization-l1-2-0.dll at 000E0000
Debugger: Loaded module api-ms-win-core-synch-l1-2-0.dll at 72660000
Debugger: Loaded module api-ms-win-core-processthreads-l1-1-1.dll at 0F5D0000
Debugger: Loaded module api-ms-win-core-file-l1-2-0.dll at 0FF70000
Debugger: Loaded module api-ms-win-crt-heap-l1-1-0.dll at 0FB10000
Debugger: Loaded module api-ms-win-crt-string-l1-1-0.dll at 0FA50000
Debugger: Loaded module api-ms-win-crt-stdio-l1-1-0.dll at 0F870000
Debugger: Loaded module api-ms-win-crt-convert-l1-1-0.dll at 0FE70000
Debugger: Loaded module api-ms-win-crt-math-l1-1-0.dll at 5CD40000
Debugger: Loaded module api-ms-win-crt-locale-l1-1-0.dll at 5CD50000
Debugger: Loaded module ConEmuHk.dll at 7E110000
Debugger: Loaded module USER32.dll at 773F0000
Debugger: Loaded module GDI32.dll at 75E90000
Debugger: Loaded module LPK.dll at 77CB0000
Debugger: Loaded module USP10.dll at 776B0000
Debugger: Loaded module msvcrt.dll at 77600000
Debugger: Loaded module IMM32.DLL at 75C30000
Debugger: Loaded module MSCTF.dll at 763B0000
Debugger: Process entrypoint reached
Target method reached
Instrumented module ExampleTarget.exe, code size: 4096
hello from target
Debugger: Exception c0000005 at address 00000F22
Debugger: Persistence method ended
translated breakpoint: 00a01040 -> 009f8005
Target function returned normally
hello from target
hello from target
hello from target
hello from target
hello from target

Even though the target function is called repeatedly, litecov only seems to hit it once. I additionally have -trace_basic_blocks set (along with -trace_debug_events), but don't seem to see any of that output. Note in the above that I did add some output to Debugger::HandleTargetEnded to check what the breakpoint was and what it was translated to on reset.

Thanks!

[ifratric]

Interesting. I think there might be two separate issues here.

For notepad example, can you run it with -trace_debug_events -trace_module_entries -trace_basic_blocks and provide the output (or the 1st part of the output if it's too large).

For ExampleTarget.exe, could you give the full command line you used?

[ifratric]

And could you also give me the exact windows version you're using?

[ifratric]

Update: I tried a few experiments with this on Windows 10 32-bit (version 2004) and everything appeared to be running normally. But perhaps there is some difference in behavior in earlier Windows.

[hatRiot]

$ litecov.exe -trace_debug_events -trace_module_entries -trace_basic_blocks -instrument_module notepad.exe -coverage_file coverage.txt -- notepad.exe
Debugger: Process created or attached
Debugger: Exception 80000003 at address 77BE060D
Debugger: Loaded module notepad.exe at 00410000
Debugger: Loaded module ntdll.dll at 77B40000
Debugger: Loaded module kernel32.dll at 75DB0000
Debugger: Loaded module KERNELBASE.dll at 75A80000
Debugger: Loaded module ADVAPI32.dll at 77CE0000
Debugger: Loaded module msvcrt.dll at 77600000
Debugger: Loaded module sechost.dll at 75C50000
Debugger: Loaded module RPCRT4.dll at 75C70000
Debugger: Loaded module GDI32.dll at 75E90000
Debugger: Loaded module USER32.dll at 773F0000
Debugger: Loaded module LPK.dll at 77CB0000
Debugger: Loaded module USP10.dll at 776B0000
Debugger: Loaded module COMDLG32.dll at 762E0000
Debugger: Loaded module SHLWAPI.dll at 774C0000
Debugger: Loaded module COMCTL32.dll at 75310000
Debugger: Loaded module SHELL32.dll at 76650000
Debugger: Loaded module WINSPOOL.DRV at 6C390000
Debugger: Loaded module ole32.dll at 75EE0000
Debugger: Loaded module OLEAUT32.dll at 77520000
Debugger: Loaded module VERSION.dll at 74890000
Debugger: Loaded module IMM32.DLL at 75C30000
Debugger: Loaded module MSCTF.dll at 763B0000
Debugger: Process entrypoint reached
Instrumented module notepad.exe, code size: 45056
Debugger: Loaded module cryptbase.dll at 75800000
Debugger: Loaded module uxtheme.dll at 73ED0000
Debugger: Loaded module dwmapi.dll at 73B90000
Debugger: Loaded module duser.dll at 73C40000
Debugger: Loaded module xmllite.dll at 73B60000
Debugger: Unloaded module from 73B60000
Debugger: Process exit
Process finished normally

Currently running a Windows 7 32-bit and building with Visual Studio 2017. I'm going to try rebuilding everything from scratch as well as testing on a Windows 10 machine, though it sounds like that should work fine.

[ifratric]

It almost looks like, on your configuration, the original module code isn't getting marked as non-executable properly, so the original code continues to execute instead of the instrumented one.

[hatRiot]

Building an x86 bin on Windows 10 gives me a working binary that I can capture coverage from. If I take this binary and drop it into a Windows 7 x86 environment, I get an empty coverage file. So the issue appears to be with older versions of Windows.

[ifratric]

Interesting. I actually created a clean Windows 7 32-bit VM to test it, updated it, built TinyInst and, as far as I can tell, everything is working normally. Running litecov.exe -instrument_module notepad.exe -coverage_file coverage.txt -- notepad.exe and getting coverage normally.

Perhaps there's something specific about your system that is causing problems. I suspect an antivirus/antimalware or similar product messing with memory permissions TinyInst sets (either causing it to fail even though it returns success, or changing permissions at a later point).

If you want to take a look at TinyInst code, this is where the target memory permissions for the module get set

TinyInst/Windows/debugger.cpp

Line 541 in cc678d7

if (!VirtualProtectEx(child_handle,