DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.63k stars 557 forks source link

drcov: empty log-file is generated when the target app crashes under fuzzing #4421

Open shakibrezapor opened 4 years ago

shakibrezapor commented 4 years ago

Describe the bug an empty log file is generated when the target application crashes.

I’m running the below command to execute a 32-bit application (on Windows 10): <<bin32\drrun.exe -t drcov -dump_text --example.exe>>

It starts working, and executing the "example.exe", and keep running till the target app crashes under fuzzing, the log file (drcov.example.exe.17264.0000.proc.log) is also generated, but the log file is empty (zero kb).

However, if the app exits normally (e.g. CTRL+C) and dont crashes, then the generated log file is fine and not empty

To Reproduce Run the below command: bin32\drrun.exe -t drcov -dump_text --example.exe

Please also answer these questions:

Expected behavior a log file which is not empty

Screenshots or Pasted Text If applicable, add screenshots to help explain your problem. For text, please cut and paste the text here, delimited by lines consisting of three backtics to render it verbatim, like this:

```
paste output here
```

Versions

Additional context Add any other context about the problem here.

shakibrezapor commented 4 years ago

The target app I'm using for this test is "vulnserver.exe":

https://github.com/stephenbradshaw/vulnserver

derekbruening commented 4 years ago

On Linux, running a 32-bit DR test which has an app crash:

$ suite/tests/bin/common.segfault
Segfault about to happen
Got a seg fault
Aborted
$ echo $?
134

Under drcov it seems to produce data just fine:

$ bin32/drrun -t drcov -- suite/tests/bin/common.segfault
Segfault about to happen
Got a seg fault
Aborted
$ ll -t drcov*
-rw-r----- 1 xxx xxx 18797 Aug 27 13:32 drcov.common.segfault.595770.0000.proc.log
-rw-r--r-- 1 xxx xxx   207 Aug 27 09:53 drcov.drrun32

On Windows it works too with 8.0.0-1:

% ~/dr/releases/DynamoRIO-Windows-8.0.0-1/bin32/drrun -stderr_mask 15 -t drcov -- suite/tests/bin/common.segfault.exe
<Starting application D:\derek\dr\git\build_x86_dbg_tests\suite\tests\bin\common.segfault.exe (4564)>
Segfault about to happen
Got a seg fault
<Stopping application D:\derek\dr\git\build_x86_dbg_tests\suite\tests\bin\common.segfault.exe (4564)>
Segmentation fault
% ls -lt drcov*
-rwxrwx---+ 1 derek None 37564 Aug 27 13:38 drcov.common.segfault.exe.04564.0000.proc.log
-rwxrwx---+ 1 derek None   211 Aug 27 09:58 drcov.drrun32

Does it work for you with 8.0.0-1?

derekbruening commented 4 years ago

I hope this is what your fuzzing caused the app to do (i.e., this is the expected app crash)?:

<Application tried to execute from unreadable memory 0x41414141.

derekbruening commented 4 years ago

8.0.18494 has the same correct behavior, and so does -dump_text, on Win10 2004: so it seems there is no problem with all app crashes and there is something specific about your app or platform.

If you make a trivial app that crashes, does drcov correctly produce output?

shakibrezapor commented 4 years ago

thanks for your reply, all the tests I can see above are done on linux (even the one you mentioned windows).

yes, when the application crashes, the below is expected result: <Application tried to execute from unreadable memory 0x41414141>

I tried one other application and the same thing happened again, the log file is not empty when the application is closed (even forcefully) but it is empty when the application crashes. I tested with another application and the result was the same. I haven't tested with linux so the result may be different in linux.

derekbruening commented 4 years ago

No, the Windows output I pasted is indeed on WIndows but in a cygwin shell.

If you run with -stderr_mask 15 in a shell window, is there a Stopping ... message (or -msgbox_mask 15 for a popup)?

Unfortunately it is sounding like this may not be easily reproducible if small apps that work in our tests are not working for you. Next questions would be is it specific to Win10 1703, or just one machine, or related to some other software on the machine (app crash reporting software?).