Drwrap and app2app instrumentation

[carlo cannarsa]

Hi, I'm using DynamoRIO to hook a Sleep function and do various things (like accelerate time, saving the delay etc.).

I hook the Sleep in two ways: one from the instrumentation event, the other from drwrap.

From drwrap I change the delay parameter to 10ms in order to "accelerate" them. By the way, I need to still instrument the Sleep call at assembly level because I need to detect if it is in a cycle. My goal is to accelerate time, and even though I set a negligible delay, a Sleep cycle with a huge upper bound can surely evade from that.

To accomplish this task, from the app2app event I search if the IAT address jumps to the Sleep address in kernel32 modulein order to detect the call and I save the current instruction pointer. If the current instruction pointer is equal to the previous saved instruction pointer I'm in a cycle and I need to replace the Sleep with NOPs.

First: I notice that If I replace the call to the Sleep (that is the last instruction) with a NOP I get an error, telling me that DynamoRIO needs to terminate the basic block with a control flow instruction. I read the docs and this is true, each bb must be terminated with a control flow instruction. So How i can solve this? How can I insert a cti to the next block just to satisfy this requirement?

Second: If the Sleep is hooked with drwrap, then it seems that it doesn't return to the client code. I need drwrap to return to the event app2app instruction because, according to the casistic, I have to replace the Sleep with NOP or wrap it and lower the delay. I noticed that the app2app event is executed only in the first iteration, and after that, is never executed because of drwrap handler. I thought that this could be for cache-related mechanisms of dynamorio. And I partially solved this problem by placing a clean call before the Sleep and flush the cache. In this case I remain in the client code also after the 2nd iteration. But I don't want to flush the cache with a clean call because it's too much overhead. 
Is there an easier solution that can solve these problems?

I'm very sorry for the length of the message, the contextualization of the problem was difficult to explain and very specific, I hope it's clear enough.

Carlo