drrun.exe access violation when accessing fs:[0C0h]

[Alessandro D.]

Hello,

I've been running drrun.exe with the bbcount.dll and winafl.dll instrumentation and they crash with all the target client I tried so far.

I created an harness which loads a DLL and calls its entry point. My harness is compiled as 64bit binary, the target DLL is 64bit and drrun.exe is 64 bit too.

The crash happens when my harness calls LoadLibraryW, and it crashes at the following instruction:

00000000`710a3083 64ff1425c0000000 call qword ptr fs:[0C0h] fs:00000000`000000c0=????????????????

I tried to load also other 64bit dlls and it crashes with all of them at the same instruction.

The bt does not give any useful hint I guess, I see just an entry with an offset and no symbols at all, so I don't know which code it's executing during the crash.

Can anyone help with this?

Thank you

[Derek Bruening]

The "harness" is the application, or the client?  The crash is application code or client code?  If client, did you load symbols for the client?  Or just snoop around on the stack to manually construct the callstack.  if it's the application: use DR's logs.

fs:[0C0h] is the WOW64 gateway for 32-bit apps, also used by 32-bit WOW64 DR as an atomic system call instruction: but in 64-bit you would not expect to see it.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/7e642ca5-0713-4455-af16-38d4c1865384n%40googlegroups.com.

[Alessandro D.]

Thank you for answering.

So, the harness is the application. Is an EXE that loads a DLL and calls its entrypoint. I want to fuzz the DLL.

I tried drrun.exe with bbcount.exe and winafl.dll client libraries.

Your observation about WOW64 haven's gate makes sense. Looking at the assembly, it looks like a lot like RtlSetContext or RtlUserThreadStart.

The crash occurs in the application code. More specifically, when my harness calls LoadLibraryW to load the target DLL I want to fuzz. The DR's log files you told me to check are these ones: https://dynamorio.org/page_logging.html ? I will check them tomorrow morning then...

Anyway, I noticed that I get the crash on fs:[0c0h] only if I put a breakpoint to LoadLibraryW and go through it with the debugger. If I attach the debugger and just let it run, I get a crash here:

00000000`c030e58f 488b14d0 mov rdx,qword ptr [rax+rdx*8] ds:00000000`00000000=????????????????

I know it's a too generic instruction, but the callstack tells me it's still very near to the other "call fs:[0C0h]".

May I have done something wrong during building? I built DynamoRIO and winafl from sources but I also tried the release - already compiled - 64bit version of DynamoRIO and I get the same behavior.

[Derek Bruening]

How is the crash reported: propagated to the application I assume, and not reported as a DR crash?

What happens with the debug DR build?

What happens with this same app with no client (just "drrun -- app")?

To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/baef6a41-071d-4df0-972c-fac2a8a01f21n%40googlegroups.com.

[Alessandro D.]

I would say the crash is propagated to the application. DR does not complain about anything.

I just built a Debug build for DR and made the following tests:

1. Executed without client, it just works. It works with both the Debug build from sources and the downloaded release.

2. I executed the Debug build with bbcount.dll as client, it doesn't work. After my application crashes (mov rdx,qword ptr [rax+rdx*8] ds:00000000`00000000=????????????????), drrun.exe correctly displays the instructions count.

3. I generated a level 2 logfile and looked a bit into it. As I imagined, the last fragment of the call stack is RtlUserThreadStart, so I guess it's crashing around there. Do you want me to attach the logfile?

Thank you for your support.

[Derek Bruening]

That is surprising that bbcount would cause problems as it does next to nothing; likely the issue is around DR changes when a client is present or when one with basic block events is present.

One approach would be to binary search between the working no-client case and non-working bbcount case.  Remove events from bbcount to see if they matter; add options to the no-client run that are set in options_enable_code_api_dependences().

To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/c417c3f9-f6b4-449a-bdc2-db5d8d68d4f1n%40googlegroups.com.

[Alessandro D.]

I'm back with some additional information:

I'm trying to run another application now, and it crashes at the same point as the old one:

mov rdx,qword ptr [rax+rdx*8] ds:00000000`00000000=????????????????

rax is a pointer to the thread local storage:

mov     rax, qword ptr gs:[58h]

and the it is zero. Below is the output of the !teb command:

TEB at 000000e7b2ea6000

ExceptionList: 0000000000000000

StackBase: 000000e7b2dc0000

StackLimit: 000000e7b2dba000

SubSystemTib: 0000000000000000

FiberData: 0000000000001e00

ArbitraryUserPointer: 0000000000000000

Self: 000000e7b2ea6000

EnvironmentPointer: 0000000000000000

ClientId: 0000000000005f10 . 0000000000005fa8

RpcHandle: 0000000000000000

Tls Storage: 0000000000000000

PEB Address: 000000e7b2ea5000

LastErrorValue: 0

LastStatusValue: c00700bb

Count Owned Locks: 0

HardErrorMode: 0

If I run the application standlone, it has the TLS initialized.

Any suggestion why this would happens?

thank you

[Alessandro D.]

I guess I realized what's the problem:

it doesn't work on Windows 11 PRO Version 10.0.22000 but it correctly works on Windows 10 PRO 10.0.19043

Does DynamoRIO support Windows 11 at all?

[Derek Bruening]

On Fri, Jul 1, 2022 at 10:56 AM Alessandro D. <alessandr...@gmail.com> wrote:

I guess I realized what's the problem:

it doesn't work on Windows 11 PRO Version 10.0.22000 but it correctly works on Windows 10 PRO 10.0.19043

Does DynamoRIO support Windows 11 at all?

Our current automated Github Actions testing is all "windows-2019" == 10.0.17763.

Looks like Github Actions most recent is "windows-2022" == 10.0.20348 (https://github.com/actions/virtual-environments/blob/main/images/win/Windows2022-Readme.md) so that's not 11 either (It's Server 2022 I think).

So it looks like we have no simple way to add automated testing for 11 yet?

Could you file an issue on this Windows 11 problem?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/733b15d2-084f-4c76-be5c-7cbf54dddd48n%40googlegroups.com.

[Alessandro D.]

Yes I can, I will do it as soon as possible.