ghidra: A lot of Bad instructions
Describe the bug A lot of normal instructions are recognized as Bad instructions
The follow is one of them
Bad instructions From 1c002cff2 to 1c002cffd
1c002cfcf 48 8b 0d MOV hWnd ,qword ptr [ghsemDynamicModeChange ] = ??
92 49 1b 00
1c002cfd6 45 8b e8 MOV R13D ,flags
1c002cfd9 48 89 74 MOV qword ptr [RSP + local_1a0 ],RSI
24 68
1c002cfde 4c 8b e2 MOV R12 ,hrgnClip
1c002cfe1 48 89 75 90 MOV qword ptr [RBP + local_178 ],RSI
1c002cfe5 89 74 24 58 MOV dword ptr [RSP + local_1b0 ],ESI
1c002cfe9 89 74 24 60 MOV dword ptr [RSP + local_1a8 ],ESI
1c002cfed 48 85 c9 TEST hWnd ,hWnd
1c002cff0 74 0c JZ LAB_1c002cffe
1c002cff2 48 ?? 48h H
1c002cff3 ff ?? FFh
1c002cff4 15 ?? 15h
1c002cff5 8f ?? 8Fh
1c002cff6 63 ?? 63h c
1c002cff7 1d ?? 1Dh
1c002cff8 00 ?? 00h
1c002cff9 0f ?? 0Fh
1c002cffa 1f ?? 1Fh
1c002cffb 44 ?? 44h D
1c002cffc 00 ?? 00h
1c002cffd 00 ?? 00h
the pesudo-code is:
if (_ghsemDynamicModeChange != 0) {
/* WARNING: Bad instruction - Truncating control flow here */
halt_baddata();
}
To Reproduce Steps to reproduce the behavior:
- Analyze the win32kbase.sys file at the last version windows 10(rs5)
- Go to function _GetDCEx you will see it
Expected behavior Like ida’s resoult:
.text:00000001C002CFCF 48 8B 0D 92 49 1B 00 mov rcx, cs:ghsemDynamicModeChange
.text:00000001C002CFD6 45 8B E8 mov r13d, r8d
.text:00000001C002CFD9 48 89 74 24 68 mov [rsp+200h+var_198], rsi
.text:00000001C002CFDE 4C 8B E2 mov r12, rdx
.text:00000001C002CFE1 48 89 75 90 mov [rbp+100h+var_170], rsi
.text:00000001C002CFE5 89 74 24 58 mov [rsp+200h+var_1A8], esi
.text:00000001C002CFE9 89 74 24 60 mov [rsp+200h+var_1A0], esi
.text:00000001C002CFED 48 85 C9 test rcx, rcx
.text:00000001C002CFF0 74 0C jz short loc_1C002CFFE
.text:00000001C002CFF2 48 FF 15 8F 63 1D 00 call cs:__imp_ExEnterPriorityRegionAndAcquireResourceShared
.text:00000001C002CFF9 0F 1F 44 00 00 nop dword ptr [rax+rax+00h]
presudo code:
if ( ghsemDynamicModeChange != 0 )
ExEnterPriorityRegionAndAcquireResourceShared();
Screenshots None
Environment (please complete the following information):
- OS: windows 10 RS5 64bits version
- Version: ghidra_9.0_PUBLIC_20190228
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 19 (6 by maintainers)
Commits related to this issue
- Update instructions for x86 See https://github.com/NationalSecurityAgency/ghidra/issues/22 — committed to kant2002/Ghidra by kant2002 5 years ago
- Update instructions for x86 See https://github.com/NationalSecurityAgency/ghidra/issues/22 — committed to kant2002/Ghidra by kant2002 5 years ago
- Update instructions for x86 See https://github.com/NationalSecurityAgency/ghidra/issues/22 — committed to kant2002/Ghidra by kant2002 5 years ago
I believe it happens due to the disassembler determining that the code will not be executed. You can select the bytes which are “??”, right click and click Disassemble or just press D.
OK. So a lot is collecting on this ticket. Good finds! I’ve worked out a solution for the 48 FF 15 … Try adding the following to
ia.sincat line 2712. I can’t guarantee it’s totally correct, but here it is:I’ve updated the FAQ with some information about fixing missing or bad instructions in our Sleigh files. Have a look for documentation and a Sleigh debugging script.
The above instruction is vfmadd213sd xmm3,xmm1,QWORD PTR [rip+0x474fd9] (thanks zbe on Discord)
I’m pretty sure there are some significant unhandled SSE instructions as well. E.g. this instruction: 14107663e c4 ?? C4h 14107663f e2 ?? E2h 141076640 f1 ?? F1h 141076641 a9 ?? A9h 141076642 1d ?? 1Dh 141076643 d9 ?? D9h 141076644 4f ?? 4Fh O 141076645 47 ?? 47h G 141076646 00 ?? 00h I try to stay away from low level SSE & AVX instructions though for my sanity, so I can’t tell you what the opcode is.
If you’re referring to the bits of padding code between functions, Ghidra doesn’t bother to parse them since they can’t be executed. On Wed, Mar 13, 2019 at 11:32 AM Sebastian C notifications@github.com wrote:
Looks like REX is broken for call atleast
It’s work!!! Thanks bro.