DynamoRIO
Unexpected result from pipe! expected 'P', instead received 'C'
Hi I followed an issue here and I'm pretty sure that it's related to DR. I checked other versions, but nothing has changed. It works perfectly on Windows 10, but it has some issues on Windows 11. Is there any update to address this issue?
OS: Windows 11 Pro 24H2 10.0.26100.4061
DR: DynamoRIO-Windows-11.0.20071
Visual Studio 2022 Developer Command Prompt v17.7.5
C:\Users\user\Desktop\Fuzzing\1\winafl\build64\bin\Release>afl-fuzz.exe -i D:\tmp\gdiplus_input -o D:\tmp\gdiplus_output -D "C:\Users\user\Desktop\Fuzzing\1\DynamoRIO\bin64" -t 2000000 -- -coverage_module gdiplus.dll -fuzz_iterations 5000 -target_module test_gdiplus.exe -target_offset 0x10E0 -nargs 2 -- "C:\Users\user\Desktop\Fuzzing\1\winafl\build64\bin\Release\test_gdiplus.exe" @@
WinAFL 1.17 by <[email protected]>
Based on AFL 2.43b by <[email protected]>
[+] You have 32 CPU cores with average utilization of 0%.
[+] Try parallel jobs - see afl_docs\parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[+] Process affinity is set to 1.
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'D:\tmp\gdiplus_input'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...
[-] PROGRAM ABORT : Unexpected result from pipe! expected 'P', instead received 'C'
Location : run_target(), C:\Users\user\Desktop\Fuzzing\1\winafl\afl-fuzz.c:2920
Related issue: https://github.com/googleprojectzero/winafl/issues/466
Thank you for the bug report.
I followed an issue here and I'm pretty sure that it's related to DR.
Do you have any useful DynamoRIO logs around the failure (try enabling DR logs: https://dynamorio.org/page_logging.html)? The logs you shared seem to be only from the tool using DR, not DR itself.
[-] PROGRAM ABORT : Unexpected result from pipe! expected 'P', instead received 'C'
Location : run_target(), C:\Users\user\Desktop\Fuzzing\1\winafl\afl-fuzz.c:2920
Looking at https://github.com/googleprojectzero/winafl/blob/31c0b17aed592f429c2ded00fbe315dcee8bc52c/afl-fuzz.c#L2920. So is it not a crash where you can get a stacktrace, but some subtle corruption of app state?
Quoting a comment from https://github.com/googleprojectzero/winafl/issues/466#issuecomment-2801286392:
It seems there are some issues with DynamoRIO on the latest windows where calling some Windows API functions (e.g. OpenFileMapping which is needed for coverage map) results in the process crashing.
Can you reproduce this issue on a smaller app that calls some Windows API function (like OpenFileMapping) to show the error? This would help narrow down the issue.
It works perfectly on Windows 10, but it has some issues on Windows 11.
I did find some Windows 11 related issues in our issue tracker in a quick search: https://github.com/DynamoRIO/dynamorio/issues/5726 https://github.com/DynamoRIO/dynamorio/issues/6962. But without more information it's hard to say if they are related.
Hi,
Allowed me to tag along this topic.
I managed to create a minimal test case to reproduce the issue. Here is the source code for the minimal test case, derived from the empty.c:
#include <Windows.h>
#include "dr_api.h"
#include "drx.h"
#include "drreg.h"
#include "utils.h"
#pragma comment(lib, "drx.lib")
#pragma comment(lib, "drmgr.lib")
#pragma comment(lib, "drreg.lib")
static void
event_exit(void);
static void
event_init(void*);
static file_t logfile = NULL;
DR_EXPORT void
dr_client_main(client_id_t id, int argc, const char *argv[])
{
/* empty client */
CHAR currentDir[MAX_PATH];
CHAR outPath[MAX_PATH];
drreg_options_t ops = { sizeof(ops), 1 /*max slots needed: aflags*/, false };
if (!drmgr_init() || !drx_init() || drreg_init(&ops) != DRREG_SUCCESS)
DR_ASSERT(false);
dr_set_client_name("DynamoRIO Sample Client 'empty'", "http://dynamorio.org/issues");
drmgr_register_thread_init_event(event_init);
drmgr_register_exit_event(event_exit);
GetCurrentDirectoryA(MAX_PATH, currentDir);
logfile = drx_open_unique_appid_file(currentDir, dr_get_process_id(), "debug", "log",
DR_FILE_ALLOW_LARGE, outPath,
BUFFER_SIZE_ELEMENTS(outPath));
}
static void
event_init(void *drcontext)
{
HANDLE hMap = NULL;
dr_fprintf(logfile, "Calling OpenFileMapping...\n");
hMap = OpenFileMappingA(FILE_MAP_ALL_ACCESS, // read/write access
FALSE, // do not inherit the name
"shm"); // name of mapping object
dr_fprintf(logfile, "OpenFileMapping handle: 0x%x...\n", hMap);
}
static void
event_exit(void)
{
dr_close_file(logfile);
}
Here is the platform information I used to test the custom tool:
OS: Windows 11 25H2 (Build 26200.6584)
DR: 11.90.20381
Command line: C:\dr_11.90.20381\bin64\drrun.exe -debug -loglevel 6 -c samples\empty.dll -- notepad.exe
Looking into the custom tool's log, the debug message Calling OpenFileMapping... was printed in the log files (e.g. debug.Notepad.exe.11896.0000.log) without the last debug message printed after OpenFileMappingA Windows API call. While for the DR's log, not sure what are the anomalies to look for, some pointers would be helpful.
As already mentioned by OP, this issue started to appear on the later version of Windows, most likely 25H and above. I can confirm this as I run the same custom tool shown above on Windows 11 23H2 and the target application did not crash.
Appreciate your help to investigate this. I would be happy to dig further if you could give some pointers.
If you run in a debugger what do you see? Are there exceptions raised (that aren't DR's internal "safe reads")? What happens inside OpenFileMappingA? See https://dynamorio.org/page_debugging.html#autotoc_md157 for library symbols. A problem inside app library code called by a client won't show up in DR logs.
Private libraries (i.e., clients using application libraries safely via copying and isolating the libraries) are challenging to support across Windows versions. It looks like CreateFileMappingA is redirected to a safer function as you can see here: https://github.com/DynamoRIO/dynamorio/blob/master/core/win32/drwinapi/kernel32_redir.c#L127 (implementation at https://github.com/DynamoRIO/dynamorio/blob/master/core/win32/drwinapi/kernel32_file.c#L880). But OpenFileMapping* is not redirected.
I would try redirecting OpenFileMapping* by adding entries to the table at that link and adding implementations, using DR's internal NtOpenSection code.
Looking briefly at the logs: they are quite difficult to read at level 6; level 4 is better. I would expect a fatal problem in a client thread init event to result in zero managed code run: yet the initial thread does run some code -- it seems to start in the exception dispatcher which is weird, and ending with NtRaiseException, instead of running regular init code.
As Derek already pointed out, private libraries can be challenging to support.
Can you confirm that if OpenFileMappingA() is removed, the client works fine?
