I want having a deep dive into ntdll!NtQueueApcThread seeing what happen after syscall instruction is executed. According to the document(Intel® 64 and IA-32 Architectures Software Developer’s Manual), the syscall instruction using the msr's LSTAR (0xC0000082) as the rip, so I set breakpoint in the nt!KiSystemCall64, which is the address I got by "rdmsr c0000082". But it's not working, my debugger doesn't break. It seems that the syscall inst does not jump to the address stored in the msr.
This is what I have done:
0: kd>
ntdll!NtQueueApcThread+0x10:
0033:00007ffb`3c32c640 7503 jne ntdll!NtQueueApcThread+0x15 (00007ffb`3c32c645)
0: kd>
ntdll!NtQueueApcThread+0x12:
0033:00007ffb`3c32c642 0f05 syscall
0: kd> rdmsr c0000082
msr[c0000082] = fffff802`3681e6c0
0: kd> u fffff802`3681e6c0
nt!KiSystemCall64:
fffff802`3681e6c0 0f01f8 swapgs
fffff802`3681e6c3 654889242510000000 mov qword ptr gs:[10h],rsp
fffff802`3681e6cc 65488b2425a8010000 mov rsp,qword ptr gs:[1A8h]
fffff802`3681e6d5 6a2b push 2Bh
fffff802`3681e6d7 65ff342510000000 push qword ptr gs:[10h]
fffff802`3681e6df 4153 push r11
fffff802`3681e6e1 6a33 push 33h
fffff802`3681e6e3 51 push rcx
0: kd> bp ffff802`3681e6c0
0: kd> t
ntdll!NtQueueApcThread+0x14:
0033:00007ffb`3c32c644 c3 ret
the target system version is Windows10 build 19042
After a few day study, I got to know what the problem is. In normal situation, setting a breakpoint in nt!KiSystemCall64 will cause a BSOD, this is because the first three instruction in nt!KiSystemCall64 is setting the kernel stack, which is required by windows kernel debugging mechanism. So the solution is setting the breakoint after the kernel stack is setup
bp nt!KiSystemCall64+0x15
In my situation, setting breakpoint does nothing happend, seems like the breakpoint is not working, I guess it is due to the anti-virus software I installed, which may have hooked some thing. After I uninstalled it, breakpoint is worked.
Related
When I try to run an app that installs and uses AlamoFire, I get the following crash after the build succeeds.
dyld`__abort_with_payload:
0x1006e7eb4 <+0>: movl $0x2000209, %eax ; imm = 0x2000209
0x1006e7eb9 <+5>: movq %rcx, %r10
0x1006e7ebc <+8>: syscall
-> 0x1006e7ebe <+10>: jae 0x1006e7ec8 ; <+20>
0x1006e7ec0 <+12>: movq %rax, %rdi
0x1006e7ec3 <+15>: jmp 0x1006e63e8 ; cerror_nocancel
0x1006e7ec8 <+20>: retq
0x1006e7ec9 <+21>: nop
0x1006e7eca <+22>: nop
0x1006e7ecb <+23>: nop
dyld: Library not loaded: #rpath/Alamofire.framework/Versions/A/Alamofire
Referenced from: /Users/scottlydon/Library/Developer/Xcode/DerivedData/TimeFountain-ezxosxusmvqbwafcjpntqcqqdpkl/Build/Products/Debug/TimeFountain.app/Contents/MacOS/TimeFountain
Reason: no suitable image found. Did find:
/Users/scottlydon/Library/Developer/Xcode/DerivedData/TimeFountain-ezxosxusmvqbwafcjpntqcqqdpkl/Build/Products/Debug/TimeFountain.app/Contents/MacOS/../Frameworks/Alamofire.framework/Versions/A/Alamofire: code signature in (/Users/scottlydon/Library/Developer/Xcode/DerivedData/TimeFountain-ezxosxusmvqbwafcjpntqcqqdpkl/Build/Products/Debug/TimeFountain.app/Contents/MacOS/../Frameworks/Alamofire.framework/Versions/A/Alamofire) not valid for use in process using Library Validation: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)
/Users/scottlydon/Library/Developer/Xcode/DerivedData/TimeFountain-ezxosxusmvqbwafcjpntqcqqdpkl/Build/Products/Debug/TimeFountain.app/Contents/MacOS/../Frameworks/Alamofire.framework/Versions/A/Alamofire: code signature in (/Users/scottlydon/Library/Developer/Xcode/DerivedData/TimeFountain-ezxosxusmvqbwafcjpntqcqqdpkl/Build/Products/Debug/TimeFountain.app/Contents/MacOS/../Frameworks/Alamofire.framework/Versions/A/Alamofire) not valid for use in process using Library Validation: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)
I don't know why not having an anonymous "image" would crash my app. My app has my code signing set
Changing the signing certificate to Development from Sign to Run Locally solved it for me.
Does the time required to execute an rdmsr depend significantly on the register read?
Yes, the time can depend significantly on the register. Here are a few examples (as measured on an Intel Core i7-8700K):
Reading register E8H (IA32_APERF) requires about 91 core cycles.
Reading register 1A0 (IA32_MISC_ENABLE) typically requires between ~500 and ~550 core cycles.
Reading register 19CH (IA32_THERM_STATUS) typically requires between ~900 and ~1050 core cycles.
Reading register 198H (IA32_PERF_STATUS) typically requires between ~5300 and ~5700 core cycles.
Here are the nanoBench commands I used for the measurements:
sudo ./kernel-nanoBench.sh -asm "rdmsr" -asm_init "mov RCX, 0xE8"
sudo ./kernel-nanoBench.sh -asm "rdmsr" -asm_init "mov RCX, 0x1A0"
sudo ./kernel-nanoBench.sh -asm "rdmsr" -asm_init "mov RCX, 0x19C"
sudo ./kernel-nanoBench.sh -asm "rdmsr" -asm_init "mov RCX, 0x198"
Writing a solution in Windows using Visual Studio 2013 C++ and trying to get the _penter and _pexit hooks working.
Getting error LNK2001: unresolved external symbol _pexit and error LNK2001: unresolved external symbol _penter for all my project files when I compile it with /Gh and /GH. I have a solution with two projects - one my main project compiled with /GH and /Gh and another DLL project which defines _penter and _pexit in an assembly file(wrote a seperate assembly file for it since my application is x64).
If I have another symbol(a different function in the DLL), that is being seen and I am able to call it from the other project and it works properly as expected, but when I compile with /GH and /Gh options its not finding the definitions for _penter and _pexit. Not able to find why this happens.
Also, if I try to write the _penter and _pexit in the cpp file itself, it gets exposed and the other project is able to see it. But I cant write inline assembly in x64, so I've written it in a seperate asm file but that doesnt get exposed.
Also, I tried writing a def file as follows,
LIBRARY EXTLIB
EXPORTS _penter
EXPORTS _pexit
and point my main project to it, it gives me these two errors,
1>------ Build started: Project: MyProj, Configuration: Release x64 ------
1>Definitions.def : error LNK2001: unresolved external symbol _penter
1>Definitions.def : error LNK2001: unresolved external symbol _pexit
1>..\..\build\MyProj.lib : fatal error LNK1120: 2 unresolved externals
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
when I dont give the def file, the errors are like,
1>Reality.obj : error LNK2001: unresolved external symbol _pexit
1>Reality.obj : error LNK2001: unresolved external symbol _pexit
...
for all my files in the project.
What am I doing wrong? How do I make my project see the definition for _penter and _pexit?
EDIT:
extern entry:Proc
extern exit:Proc
PUBLIC _penter
PUBLIC _pexit
EXPORTS _penter
EXPORTS _penter
.code
PUSHREGS macro
push rax
push rcx
push rdx
push r8
push r9
push r10
push r11
endm
POPREGS macro
pop r11
pop r10
pop r9
pop r8
pop rdx
pop rcx
pop rax
endm
_penter proc
push rax
lahf
PUSHREGS
sub rsp, 8+16
movdqu xmmword ptr[rsp], xmm0
sub rsp ,8
sub rsp,28h
mov rcx,rsp
mov rcx,qword ptr[rcx+136]
call entry
add rsp,28h
add rsp, 8
movdqu xmm0, xmmword ptr[rsp]
add rsp, 8+ 16
POPREGS
sahf
pop rax
ret
_penter endp
_pexit proc
push rax
lahf
PUSHREGS
sub rsp, 8+16
movdqu xmmword ptr[rsp], xmm0
sub rsp ,8
sub rsp,28h
mov rcx,rsp
mov rcx,qword ptr[rcx+136]
call exit
add rsp,28h
add rsp, 8
movdqu xmm0, xmmword ptr[rsp]
add rsp, 8+ 16
POPREGS
sahf
pop rax
ret
_pexit endp
end
So I have a block of assembly code that initializes a program, resolves kernel32, finds GetProcAddress, then finds LoadLibarayA to load User32.dll. It works up to the point of LoadLibraryA. It crashes in the function call but I can see User32.dll loaded in the debugger. If I try to use LoadLibraryA on a different module such as Kernel32.dll it returns and succeeds.
Here is the full source if you want to look it over
https://gist.github.com/mojobojo/921a5af897e86bb940a2
Exception thrown at 0x00007FFAFAE8E91C (ntdll.dll) in Small.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
Here is the snippet that trys to load user32.
mov rcx, ActualAddress + User32DllStr ; ActualAddress is the program address in memory
call rax ; LoadLibararyA
cmp rax, 0
je EndFunction ; Failed to open user32.dll
LoadLibraryAStr:
db "LoadLibraryA", 0
Here is a look at the call stack.
ntdll.dll!RtlDosPathNameToRelativeNtPathName() Unknown
ntdll.dll!LdrpResolveDllName() Unknown
ntdll.dll!LdrpFindLoadedDll() Unknown
ntdll.dll!LdrGetDllHandleEx() Unknown
ntdll.dll!LdrGetDllHandle() Unknown
KernelBase.dll!00007ffaf82d2984() Unknown
KernelBase.dll!00007ffaf82d29ef() Unknown
user32.dll!00007ffaf934e7e8() Unknown
user32.dll!00007ffaf934dc92() Unknown
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpPrepareModuleForExecution() Unknown
ntdll.dll!LdrpLoadDll() Unknown
ntdll.dll!LdrLoadDll() Unknown
KernelBase.dll!00007ffaf82d8e4a() Unknown
KernelBase.dll!00007ffaf82d97e5() Unknown
kernel32.dll!00007ffaf8b5499a() Unknown
Small.exe!0000000140010253() Unknown
I figured it out. My stack wasn't 16 byte aligned.
I'm working on porting Mumble over to Windows RT (using the jailbreak), and I've hit an issue where this one function is getting corrupted when Mumble loads.
Mumble (Corrupt function):
0:000> dq user32.dll+0x023918
77a63918 47c3004244696841 4770df010c16f241
77a63928 4770df010c17f241 4770df010c18f241
77a63938 4770df010c19f241 4770df010c1af241
77a63948 4770df010c1bf241 4770df010c1cf241
77a63958 4770df010c1df241 4770df010c1ef241
77a63968 4770df010c1ff241 4770df015c81f44f
77a63978 4770df010c21f241 4770df010c22f241
77a63988 4770df010c23f241 4770df010c24f241
0:000> u user32.dll+0x023918
* ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\windows\system32\user32.dll -
user32!WindowFromPoint:
77a63918 6841 ldr r1,[r0,#4]
77a6391a 4469 add r1,r1,sp
77a6391c 0042 lsls r2,r0,#1
77a6391e 47c3 ?blx r8
77a63920 f2410c16 mov r12,#0x1016
77a63924 df01 svc #1
TeXworks (Expected output):
0:000> dq user32.dll+0x23918
77a63918 4770df010c15f241 4770df010c16f241
77a63928 4770df010c17f241 4770df010c18f241
77a63938 4770df010c19f241 4770df010c1af241
77a63948 4770df010c1bf241 4770df010c1cf241
77a63958 4770df010c1df241 4770df010c1ef241
77a63968 4770df010c1ff241 4770df015c81f44f
77a63978 4770df010c21f241 4770df010c22f241
77a63988 4770df010c23f241 4770df010c24f241
0:000> u user32.dll+0x23918
* ERROR: Symbol file could not be found. Defaulted to export symbols for C:\windows\system32\USER32.dll -
USER32!WindowFromPoint:
77a63918 f2410c15 mov r12,#0x1015
77a6391c df01 svc #1
77a6391e 4770 bx lr
77a63920 f2410c16 mov r12,#0x1016
77a63924 df01 svc #1
77a63926 4770 bx lr
77a63928 f2410c17 mov r12,#0x1017
77a6392c df01 svc #1
(Apologies for the less than stellar formatting of the code, a screenshot of the windows can be found here: http://i.imgur.com/M6mLHN1.png )
Mumble uses Qt (customized by the Mumble team, to my understanding), Protobuf, Boost, and OpenSSL
TeXworks uses Qt
What I've tried so far:
Disabling the application compatibility engine
Unloading user32.dll at load, then reloading it (calling FreeLibrary 100 times, then calling LoadLibrary)
Removing anything that might look even remotely suspect from the manifests (from Qt and Mumble)
Removing the entire manifests (from Qt and Mumble)
If I patch this one function using cdb after Mumble launches it all works awesomely, but if I don't patch it the first action performed that calls that function ends in a crash. Opening/closing windows and dragging all call that function, so it's rather critical to the program that it's there.
Any help or pointers on this would be more than appreciated.
Edit: I've verified that it's something inside mainCRTStartup that's mucking around with it, trying to figure out what exactly it is now.
Edit 2: Found a platform-specific hook hidden in the Mumble code that was causing my troubles. Solved.
Since I can finally answer this now, Mumble had some hooks hidden away that I didn't know about. I defined a custom entrypoint that called mainCRTStartup so I could step through that and find exactly where that memory was getting changed, it led me straight to the hook.
Here's the code I used for that:
EXTERN_C int WINAPI mainCRTStartup();
void __stdcall EntryPoint()
{
MessageBox(HWND_DESKTOP,L"Pause(Before mainCRTStartup)",L"Pause(Before mainCRTStartup",MB_OK);
mainCRTStartup();
ExitProcess(0);
}
That allowed me to attach a debugger at the messagebox and step through mainCRTStartup until I found the static initializer that was getting called to load the hook.