Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

self modify application would CRASH when run under DynamoRIO #1199

Closed
derekbruening opened this issue Nov 28, 2014 · 16 comments
Closed

self modify application would CRASH when run under DynamoRIO #1199

derekbruening opened this issue Nov 28, 2014 · 16 comments

Comments

@derekbruening
Copy link
Contributor

From [email protected] on June 26, 2013 07:44:48

APP CRASH
The application's behavior under DynamoRIO is different from its native behavior. What version of DynamoRIO are you using? 4.0.1 What operating system version are you running on? windows xp sp3 What application are you running? selfmodify.exe, it would self-modify its code, the exe is in the attach,and the source code is at end of this issue. Is your application 32-bit or 64-bit? 32-bit How are you running the application under DynamoRIO? with drconfig syswide_on, use bbcount.dll and selfmodify.exe.config32 What happens when you run without any client? it will execute a command "calc" , and start a new process c:\windows\system32\calc.exe
What happens when you run with debug build ("-debug" flag to drrun/drconfig/drinject)? not test What steps will reproduce the problem? 1.just run it, it will reproduce. 2. 3. What is the expected output? What do you see instead? Is this an application crash, a DynamoRIO crash, a DynamoRIO assert, or a hang (see https://code.google.com/p/dynamorio/wiki/BugReporting and set the title appropriately)? application crash

0:000> r
eax=00009e8e ebx=00000000 ecx=000002e2 edx=7c92e4f4 esi=1f12de69 edi=1f12de4c
eip=1f12de4b esp=0012ff68 ebp=0012ff7c iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010287
1f12de4b 8ead662d6161 mov gs,word ptr [ebp+61612D66h] ss:0023:61742ce2=????

0:000> u eip-4
1f12de47 68a51e8e8e push 8E8E1EA5h
1f12de4c ad lods dword ptr [esi]
1f12de4d 662d6161 sub ax,6161h
1f12de51 c0e004 shl al,4
1f12de54 02c4 add al,ah
1f12de56 aa stos byte ptr es:[edi]
1f12de57 e202 loop 1f12de5b
1f12de59 eb05 jmp 1f12de60
0:000> u
1f12de5b e9ebffffff jmp 1f12de4b
1f12de60 e9ea7679ff jmp 1e8c554f
1f12de65 0000 add byte ptr [eax],al
1f12de67 0000 add byte ptr [eax],al
1f12de69 0000 add byte ptr [eax],al
1f12de6b 0000 add byte ptr [eax],al
1f12de6d 0000 add byte ptr [eax],al
1f12de6f 0000 add byte ptr [eax],al

the last 2 basic block code:
TAG 0x004020f8
+0 L3 90 nop
+1 L3 90 nop
+2 L3 90 nop
+3 L3 90 nop
+4 L3 d9 ee fldz
+6 L3 d9 74 24 f4 fnstenv [esp-0x0c]
+10 L3 5e pop esi <--- here get self location 0x004020f8 + 4
+11 L3 83 c6 20 add esi, 0x20
+14 L3 56 push esi
+15 L3 5f pop edi <--- loop self modify from 0x004020f8 + 4 + 0x20
+16 L3 33 c9 xor ecx, ecx
+18 L3 66 b9 ff 02 mov cx, 0x02ff
+22 L3 66 ad lodsw
+24 L3 66 2d 61 61 sub ax, 0x6161
+28 L3 c0 e0 04 shl al, 0x04
+31 L3 02 c4 add al, ah
+33 L3 aa stosb
+34 L3 e2 f2 loop 0x0040210e
END 0x004020f8

TAG 0x0040210e
+0 L3 66 ad lodsw <------- here may be the crush block
+2 L3 66 2d 61 61 sub ax, 0x6161
+6 L3 c0 e0 04 shl al, 0x04
+9 L3 02 c4 add al, ah
+11 L3 aa stosb
+12 L3 e2 f2 loop 0x0040210e
END 0x0040210e

and the source code of the exe:

#include "stdafx.h"
#include <windows.h>

int _tmain(int argc, _TCHAR * argv[])
{
char *sc = "\x90\x90\x90\x90\xd9\xee\xd9\x74\x24\xf4\x5e\x83\xc6\x20\x56\x5f\x33\xc9\x66\xb9\xff\x02\x66\xad\x66\x2d\x61\x61\xc0\xe0\x04\x02\xc4\xaa\xe2\xf2\x70\x6d\x6f\x69\x69\x6a\x61\x61\x61\x61\x61\x61\x67\x61\x69\x6a\x6f\x66\x64\x62\x6e\x63\x67\x65\x69\x6c\x66\x63\x64\x61\x69\x6c\x66\x63\x61\x6d\x69\x6c\x66\x63\x62\x65\x69\x6c\x68\x63\x63\x69\x61\x70\x6c\x68\x65\x6b\x63\x67\x64\x62\x70\x70\x64\x62\x6d\x61\x6b\x6d\x64\x6d\x67\x62\x68\x6d\x61\x63\x63\x6d\x63\x61\x6d\x62\x6d\x70\x61\x6e\x61\x62\x6d\x68\x6f\x63\x70\x61\x66\x63\x66\x68\x69\x6c\x66\x63\x62\x61\x69\x6c\x65\x63\x64\x6d\x61\x62\x6e\x61\x69\x6c\x65\x61\x68\x69\x69\x66\x6d\x61\x68\x65\x65\x6b\x61\x62\x6e\x61\x66\x61\x69\x6c\x65\x69\x62\x69\x69\x6c\x66\x69\x63\x61\x61\x62\x6e\x64\x6f\x64\x64\x6d\x65\x6a\x69\x6c\x64\x65\x69\x6c\x61\x62\x6e\x67\x64\x62\x70\x70\x64\x62\x6d\x61\x6b\x6d\x6d\x62\x6d\x70\x61 \x6e\x61\x62\x6d\x68\x64\x69\x6f\x61\x68\x66\x70\x65\x61\x64\x68\x6e\x70\x69\x64\x6c\x68\x6e\x63\x65\x68\x66\x6f\x63\x66\x69\x69\x6c\x66\x69\x63\x65\x61\x62\x6e\x64\x67\x67\x69\x6c\x61\x6d\x65\x6c\x69\x6c\x66\x69\x62\x6d\x61\x62\x6e\x64\x69\x6c\x61\x65\x69\x6c\x61\x62\x6e\x61\x69\x6a\x65\x65\x63\x65\x63\x65\x66\x6c\x66\x6c\x67\x62\x66\x6a\x66\x6b\x66\x62\x70\x70\x6f\x61\x66\x69\x66\x70\x66\x6b\x69\x6c\x62\x63\x6f\x6c\x69\x67\x66\x6e\x67\x6b\x61\x62\x69\x6e\x69\x66\x6c\x6a\x61\x61\x61\x61\x61\x61\x66\x61\x67\x69\x64\x62\x69\x6c\x67\x70\x69\x68\x70\x70\x6e\x66\x6c\x6c\x70\x61\x6c\x66\x6b\x63\x66\x67\x67\x69\x6b\x67\x6a\x66\x6c\x6e\x6a\x6e\x70\x70\x6e\x66\x64\x6d\x61\x67\x68\x6d\x61\x6b\x69\x61\x70\x6c\x6f\x61\x68\x66\x61\x66\x6c\x6c\x65\x68\x62\x64\x68\x63\x67\x70\x67\x6b\x61\x61\x66\x64\x70\x70\x6e\x66\x67\x64\x67\x62\x67\x6d\x67\x64\x63\x6f\x67\x66\x68\x69\x67\x66\x61\x61\x00" ;
DWORD old = 0;
VirtualProtect (sc, strlen (sc), PAGE_EXECUTE_READWRITE , & old);
__asm {
jmp sc
}
MessageBoxA (0, "done", "done" , 0);
return 0;
}

Attachment: selfmodify.rar

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1199

@derekbruening
Copy link
Contributor Author

From [email protected] on June 26, 2013 09:35:06

there does seem to be a problem with DR handling modifying OP_loop's target at the end of the same bb

Status: Accepted
Owner: [email protected]
Labels: Bug-AppFail

@derekbruening
Copy link
Contributor Author

From [email protected] on June 26, 2013 13:54:50

This test app seems to crash before it modifies a loop target.

However, making my own tests I found two bugs in selfmod handling: one with stos used to perform the write, and another with the write using eax as the address register.

But, I cannot reproduce any problem with xor used to perform the write, as was indicated in your original email. Can you run that xor code sequence (minimized as much as possible) under debug -loglevel 4 and attach the log?

Status: NeedInfo

@derekbruening
Copy link
Contributor Author

From [email protected] on June 26, 2013 15:59:05

More detail on the two bugs: the address acquiring selfmod code is very old and has some problems. It saves the flags before executing lea, meaning it gets the wrong address if the address register is eax. Plus, it acquires the address post-write, meaning it gets the wrong address for string instructions that modify their address registers.

@derekbruening
Copy link
Contributor Author

From [email protected] on June 26, 2013 17:20:19

hi:
I have much more self modify applications run under DR crash, because in
the original email ,the exe will download a malware and run it if run
success, I can't send that sample to infect your PC, so I changed another
one that just execute a command "calc", if you need more sample that run
crash under DR , I can send to you.

@derekbruening
Copy link
Contributor Author

From [email protected] on June 27, 2013 08:32:27

Can you try r2147 from http://build.chromium.org/p/client.dynamorio/builds/ which fixes the two aforementioned bugs? Are there any selfmod cases that do not run correctly with r2147 ? For any that don't, can you isolate the instruction that does the modification that is not detected?

@derekbruening
Copy link
Contributor Author

From [email protected] on June 27, 2013 08:58:45

A third bug is handling a push (or pop to a stack slot) that modifies code. It will rarely miss the selfmod detection due to erring on the minus side which typically keeps it inside the block but it's possible. This is a regression from issue #164 which changed the stack operand offsets.

@derekbruening
Copy link
Contributor Author

From [email protected] on June 27, 2013 09:16:02

I have used r2147 test the two aforementioned .exe applications, it still
crash, but at this time, the crush point is changed.
Do you havetested r2147 would run right in your environment?

thanks for response quickly!

@derekbruening
Copy link
Contributor Author

From [email protected] on June 27, 2013 09:22:03

If selfmodify.exe run success, it will start calc.exe, you can see it.

2013/6/28 lovesuae [email protected]

@derekbruening
Copy link
Contributor Author

From [email protected] on July 02, 2013 09:58:16

We tried the sources pasted in the initial entry above, which simply crash. We created tests of detecting modification based on the analysis you provided and you can see those tests in the commit diffs. Those are the bugs that were fixed here.

Looking at the attached source code, which is different from what was pasted, it does work as you say. It looks like it uses the FPU last instruction pointer to get the address of the code to modify. That's currently not handled: it's issue #698 . Note that as of a year ago at least neither Pin nor Valgrind handled this either (see https://code.google.com/p/dynamorio/issues/detail?id=698#c2 ).

We may take a stab at issue #698 even if it's not on by default, to make sure there are no other bugs here.

Status: Accepted

@derekbruening
Copy link
Contributor Author

From [email protected] on July 02, 2013 10:20:27

I copy the code I pasted in the issue #1199 , it must be google-code
rich-text-editor add a white space ' ' between "\x61 \x6e" for start a new
line, sorry for this.

@derekbruening
Copy link
Contributor Author

From [email protected] on July 11, 2013 07:28:18

This issue was closed by revision r2165 .

Status: Fixed

@derekbruening
Copy link
Contributor Author

From [email protected] on July 11, 2013 07:32:56

The app here now runs successfully. Can you try your other apps with r2165 and let us know whether they all work? If there are any further problems, please file new issues.

@derekbruening
Copy link
Contributor Author

From [email protected] on July 15, 2013 02:41:45

I have tested 2 applications that contain "fnstenv" instruction, they all work correct,seems this problem has been solved ^_^

@derekbruening
Copy link
Contributor Author

From [email protected] on July 16, 2013 17:28:43

We hit some performance issues with the solution in r2165 . We have disabled part of it (under a new off-by-default runtime option "-translate_fpu_pc") in r2185 . The sample app in this issue still works, though, as it does not need the slower path we removed. Do these other applications still work under r2185 ? This will be what we plan to use for the imminent DR release.

@derekbruening
Copy link
Contributor Author

From [email protected] on July 16, 2013 21:49:45

Hi Derek Bruening:

I have tested 3 apps that use fnstenv to get self location and self
modify its code, the 3 apps are all work correct under r2185 !

@derekbruening
Copy link
Contributor Author

From [email protected] on July 17, 2013 06:48:11

Excellent, marking Verified.

Status: Verified

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant