googleprojectzero / googleprojectzero/TinyInst

Empty coverage file on 32-bit Windows

Open
#13 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
1.4k
Forks
140
PR merge metrics
No merged PRs in 30d

Description

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!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the litecov command and the 32-bit Windows reproduction, then trace Debugger::HandleTargetEnded and the -trace_basic_blocks and -trace_debug_events paths. Compare the notepad.exe and ExampleTarget.exe behavior; done means repeated target calls produce coverage data and the expected basic-block trace instead of an empty file or a single hit.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
devtools, operating-systems, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.