Comments (9)
@mxmssh What is the blocking issue with adding return value printing, if any? If DynamoRIO supports most of the pieces we need to put this together, then if you pointed me in the right direction for how to get started, I may be able to give it a shot!
from drltrace.
@jtesta I am trying to remember what was an issue. Basically, there are no technical limitations to implement that. It shouldn't be as simple as
- Add post handler here
drltrace/drltrace_src/drltrace.cpp
Line 317 in 6b1d4dd
- Use drwrap_get_retval() to get and print return value after the function exits.
However, when we trace API calls, there is one problem. Let's say our program calls CreateFileA and we want to trace all low API names from kernel32.dll/kernelbase.dll/ntdll.dll called by CreateFileA. In this case, we will print
- CreateFileA + args,
- Then all APIs called by CreateFileA
- return value of CreateFileA
So, we need somehow to handle this situation and notify a user that function has exited and we print its return values. For example:
kernel32dll!CreateFileA
args
kernelbasedll!APICallA
args
ntdll!APICallB
args
returnvalue of APICallB is X
return value of APICallA is Y
return value of CreateFileA is Z
Intentations are not required, I just listed them to make it simpler to read.
from drltrace.
Right. I was thinking the only real solution is to cache the function calls until the return value is received, then print it all out at once. Any other approach would be impossible for a human to follow, and would also cause the log file to grow even larger than it already is.
Thanks for the pointer! I'll see about experimenting with it in the next few days.
from drltrace.
Good luck, feel free to ask me if you have any questions regarding DynamoRIO or drltrace.
from drltrace.
So I gave it a shot, and got it working well under Linux. Then I tried it on Windows and it consistently crashed. It turns out that calling dr_get_thread_id()
or drwrap_get_retval()
during certain post-function callbacks causes it.
Here's a small patch to drltrace.cpp which reproduces the issue:
diff --git a/drltrace_src/drltrace.cpp b/drltrace_src/drltrace.cpp
index d8959c0..64aa9d2 100644
--- a/drltrace_src/drltrace.cpp
+++ b/drltrace_src/drltrace.cpp
@@ -377,6 +377,19 @@ lib_entry(void *wrapcxt, INOUT void **user_data)
}
static void
+lib_exit(void *wrapcxt, void *user_data)
+{
+ const char *function_name = (const char *)user_data;
+ void *drcontext = drwrap_get_drcontext(wrapcxt);
+
+ DR_TRY_EXCEPT(drcontext, {
+ dr_fprintf(outf, "Return value for %s (thread ID %u): %p\n", function_name, dr_get_thread_id(drcontext), drwrap_get_retval(wrapcxt));
+ }, {
+ dr_fprintf(outf, "Exception thrown when processing thread ID/return value for function %s\n", function_name);
+ });
+}
+
+static void
iterate_exports(const module_data_t *info, bool add)
{
dr_symbol_export_iterator_t *exp_iter =
@@ -405,13 +418,13 @@ iterate_exports(const module_data_t *info, bool add)
if (func != NULL) {
if (add) {
IF_DEBUG(bool ok =)
- drwrap_wrap_ex(func, lib_entry, NULL, (void *) sym->name, 0);
+ drwrap_wrap_ex(func, lib_entry, lib_exit, (void *) sym->name, 0);
ASSERT(ok, "wrap request failed");
VNOTIFY(2, "wrapping export %s!%s @" PFX NL,
dr_module_preferred_name(info), sym->name, func);
} else {
IF_DEBUG(bool ok =)
- drwrap_unwrap(func, lib_entry, NULL);
+ drwrap_unwrap(func, lib_entry, lib_exit);
ASSERT(ok, "unwrap request failed");
}
}
Here's a screen shot of the crash when run as drltrace.exe -logdir . -- calc.exe
:
(Note that the screen shot shows references to Cygwin, but I didn't use that to compile; I only used it for git operations. I compiled it with VS 2013, just as the instructions say.)
I found that a partial work-around is skipping the callbacks for ZwCallbackReturn
, KiUserCallbackDispatcher
, and ExpInterlockedPopEntrySListResume
. The program will run for longer in that case, but still ultimately crashes.
If we can get this bug fixed, then we'll have return value printing for both Linux & Windows, which would be a huge improvement!
P.S. If you want to see what I have so far (which would be ready for merging if not for this Windows bug), see here: https://github.com/jtesta/drltrace/tree/retval
from drltrace.
It seems like an issue with DynamoRIO itself. Since they have shifted the focus from Windows to Linux&MacOS + AMD64, Windows platform is low priority now, so I am not sure they will fix it... Anyway, it makes sense to open an issue in DynamoRIO official repo. In the meantime, I will try to debug it and see what we can do. Do you work with the latest DynamoRIO?
from drltrace.
Yes, I did also try it with the master branch of DynamoRIO from a couple days ago. Same results. I'll open an issue on their repo.
Here's a quick question: are calls to the pre- and post-function callbacks thread-safe? If not, I'll need to add some locking functionality.
from drltrace.
It should be thread-safe (I bet DynamoRIO knows how to handle it)
from drltrace.
Spent some time debugging it today. We have NULL pointer dereference. Take a look into my comment for DynamoRIO/dynamorio#4068
from drltrace.
Related Issues (20)
- Failed to build 32-bit version of drltrace in Linux (-mpreferred-stack-boundary=2)
- Error: Unable to inject HOT 7
- question about call addresses HOT 2
- drltrace does not output logs HOT 1
- The problem with the arguments HOT 2
- drltrace can't output the trace of child process HOT 4
- DLTrace ails to start packed PE HOT 1
- drltrace on Windows 10 HOT 3
- DynamoRIO crashes with 32-bit drltrace (RelWithDebInfo) HOT 1
- Starter script for Windows HOT 1
- adding system call tracing and anti-analysis detection HOT 7
- I can't find out trace log file HOT 1
- Where is this python script? HOT 1
- Building error with DynamoRIO on Windows 10 64bits HOT 11
- drltrace unable to track executable HOT 2
- Can it be attached to a running process?
- Crashes with calc.exe
- drltrace will not work on GUI Apps HOT 1
- Build Error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32 HOT 7
- Compilation script
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from drltrace.