Crash Debugging Win32 Application - debugging

I'm spending lot of time doing crash debugging of Win32 apps. One thing i'm very curious to know about is, How to find whether any address belongs to stack / heap or program code section. Is there any windbg/ollydbg plugin available for this purpose? Or I've to to it manually from memory map?
Ex:
0:000> r
eax=00930264 ebx=008e0000 ecx=41414592 edx=00930000 esi=41414141 edi=008e0441
eip=00407289 esp=0012fae0 ebp=0012faf4 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010206
MyApp+0x7289:
00407289 8b1437 mov edx,dword ptr [edi+esi] ds:0023:41cf4582=????????
0:000> u eip
MyApp+0x7289:
00407289 8b1437 mov edx,dword ptr [edi+esi]
0040728c 8b4c3704 mov ecx,dword ptr [edi+esi+4]
00407290 57 push edi
00407291 e89ae8ffff call MyApp+0x5b30 (00405b30)
00407296 897d14 mov dword ptr [ebp+14h],edi
00407299 5f pop edi
0040729a 85c0 test eax,eax
0040729c 741e je MyApp+0x72bc (004072bc)
In this case i wanna know which register pointing to which section (code/stack/heap )so that i can proceed further to the root cause.
Thanks in Advance.

0:000> ?#esi+#edi
Evaluate expression: 36278408 = 02299088
0:000> !address 02299088
ProcessParametrs 00311020 in range 00310000 00410000
Environment 02294848 in range 02290000 02390000
02290000 : 02290000 - 00100000
Type 00020000 MEM_PRIVATE
Protect 00000004 PAGE_READWRITE
State 00001000 MEM_COMMIT
Usage RegionUsageHeap
Handle 00310000

Related

Seemingly wrong instruction pointer reported by VS2017

Edit:
I've investigated more, and the problem reported below seems to happen only when I use Visual Studio 2017 to pause the process. It also seems that when rip is pointing to an invalid location, it's always a +1 byte offset from the correct instruction start.
Also, for context, this is a large C++ project with lots of dlls, some compiled with MSVC 2015, the rest with icc (intel compiler 2017). This is run in a python process using boost C++/python bindings.
Original post:
I am pausing my program randomly to see what are my threads doing during some heavy computation.
Note that I am not debugging a crash, resuming the program works fine.
Howver the VS debugger is sometimes unable to dissassemble the machine code.
For instance, on one thread where rip=000007FE8B048EE2, it shows this:
000007FE8B048EDE ?? ??
000007FE8B048EDF ?? ??
000007FE8B048EE0 ?? ??
000007FE8B048EE1 ?? ??
}
if (params.derandomize) {
000007FE8B048EE2 adc ebp,eax
GetRNG().Seed(id);
000007FE8B048EE4 pop rax
000007FE8B048EE5 wait
000007FE8B048EE6 adc byte ptr [rax],al
000007FE8B048EE8 mov rcx,rax
The decoded x86 instructions also seem wrong (adc, pop, wait, adc ??), so I tried to attach WinDBG as well (non invasive mode):
0:019> u rip
somedll!<lambda239>::operator()+0x132:
000007fe`8b048ee2 13e8 adc ebp,eax
000007fe`8b048ee4 58 pop rax
000007fe`8b048ee5 9b wait
000007fe`8b048ee6 1000 adc byte ptr [rax],al
000007fe`8b048ee8 4889c1 mov rcx,rax
000007fe`8b048eeb 8b9570080000 mov edx,dword ptr [rbp+870h]
000007fe`8b048ef1 e8fa911000 call somedll!bla::bla::blabla::blabla::Seed (000007fe`8b1520f0)
000007fe`8b048ef6 4c8ba5b0080000 mov r12,qword ptr [rbp+8B0h]
Ok, it's the same garbage...
But then I tried to dissassemble from an address slightly above rip:
0:019> u rip-30
somedll!<lambda239>::operator()+0x102:
000007fe`8b048eb2 00488b add byte ptr [rax-75h],cl
000007fe`8b048eb5 084863 or byte ptr [rax+63h],cl
000007fe`8b048eb8 81d003000048 adc eax,48000003h
000007fe`8b048ebe 83f8ff cmp eax,0FFFFFFFFh
000007fe`8b048ec1 740a je somedll!<lambda239>::operator()+0x11d (000007fe`8b048ecd)
000007fe`8b048ec3 4889c2 mov rdx,rax
000007fe`8b048ec6 48899570080000 mov qword ptr [rbp+870h],rdx
000007fe`8b048ecd 486381e0030000 movsxd rax,dword ptr [rcx+3E0h]
0:019> u
somedll!<lambda239>::operator()+0x124:
000007fe`8b048ed4 483bd0 cmp rdx,rax
000007fe`8b048ed7 7501 jne somedll!<lambda239>::operator()+0x12a (000007fe`8b048eda)
000007fe`8b048ed9 cc int 3
000007fe`8b048eda 80b96303000000 cmp byte ptr [rcx+363h],0
000007fe`8b048ee1 7413 je somedll!<lambda239>::operator()+0x146 (000007fe`8b048ef6)
000007fe`8b048ee3 e8589b1000 call somedll!bla::bla::blabla::GetRNG (000007fe`8b152a40)
000007fe`8b048ee8 4889c1 mov rcx,rax
000007fe`8b048eeb 8b9570080000 mov edx,dword ptr [rbp+870h]
0:019> u
somedll!<lambda239>::operator()+0x141:
000007fe`8b048ef1 e8fa911000 call somedll!bla::bla::blabla::blabla::Seed (000007fe`8b1520f0)
000007fe`8b048ef6 4c8ba5b0080000 mov r12,qword ptr [rbp+8B0h]
000007fe`8b048efd 488d95f0070000 lea rdx,[rbp+7F0h]
000007fe`8b048f04 488d8dc0070000 lea rcx,[rbp+7C0h]
000007fe`8b048f0b 498b0424 mov rax,qword ptr [r12]
000007fe`8b048f0f 4c8da570080000 lea r12,[rbp+870h]
000007fe`8b048f16 488942d0 mov qword ptr [rdx-30h],rax
000007fe`8b048f1a 4c8962d8 mov qword ptr [rdx-28h],r12
the first instructions "add byte ptr" and "or byte ptr" at 000007fe`8b048eb2 don't make sense because rip-30 likely falls in the middle of an instruction, but after it seems to resync because it corresponds to the source code:
if (id == params.dbgbreak_id) {
__debugbreak();
}
if (params.derandomize) {
GetRNG().Seed(id);
}
000007fe`8b048ecd 486381e0030000 movsxd rax,dword ptr [rcx+3E0h]
000007fe`8b048ed4 483bd0 cmp rdx,rax // if (id == params.dbgbreak_id) {
000007fe`8b048ed7 7501 jne somedll!<lambda239>::operator()+0x12a (000007fe`8b048eda)
000007fe`8b048ed9 cc int 3 // __debugbreak(); }
000007fe`8b048eda 80b96303000000 cmp byte ptr [rcx+363h],0 // if (params.derandomize)
000007fe`8b048ee1 7413 je somedll!<lambda239>::operator()+0x146 (000007fe`8b048ef6)
000007fe`8b048ee3 e8589b1000 call somedll!bla::bla::blabla::GetRNG (000007fe`8b152a40)
000007fe`8b048ee8 4889c1 mov rcx,rax
000007fe`8b048eeb 8b9570080000 mov edx,dword ptr [rbp+870h]
000007fe`8b048ef1 e8fa911000 call somedll!bla::bla::blabla::blabla::Seed (000007fe`8b1520f0)
clearly there is no instruction begining at 000007fe8b048ee2 !
There is je at 000007fe8b048ee1, and call at 000007fe8b048ee3
So... I thought, hmmm there's a bug in the debugger... let's check the registers:
0:019> r
rax=ffffffffffffffff rbx=000000000021d420 rcx=000000000021d5d0
rdx=0000000002696568 rsi=0000000000005d38 rdi=0000000056eefc40
rip=000007fe8b048ee2 rsp=0000000056eef5b0 rbp=0000000056eef5e0
r8=0000000000000006 r9=000000000021d0b8 r10=0000000006456570
r11=0000000000000006 r12=0000000056eefe50 r13=00000000069a8820
r14=000000000021d1a8 r15=0000000056eefe60
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
What?? rip=000007fe8b048ee2 ?? How is that possible?
It explains why the debugger is showing garbage: it is trying to dissassemble starting from rip, but rip points to the middle of an instruction.
But why is the reported rip wrong? Is the OS culprit?
Am I missing something?

CreateFileA in Windows API in NASM 64: incorrect parameter, but which one?

I am creating a file using CreateFileA from the Windows API in NASM 64-bit (see https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilea). With the following parameters, no file is created and it returns an error 87 ("the parameter is incorrect") from GetLastError (see https://learn.microsoft.com/en-us/windows/desktop/debug/system-error-codes--0-499-)
Here are the parameters:
rcx - lpFileName
;dwDesiredAccess
mov rdx,2
I chose FILE_WRITE_DATA from https://learn.microsoft.com/en-us/windows/desktop/FileIO/file-access-rights-constants
; dwShareMode
mov r8,0
According to https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilea: If this parameter is zero and CreateFile succeeds, the file or device cannot be shared. According to https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilea, the value should be zero for no sharing.
; lpSecurityAttributes
mov r9,const_inf ; (Pointer to null value dq 0xFFFFFFFF)
OR mov r9,const_0
According to https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilea: "If this parameter is NULL, the handle returned by CreateFile cannot be inherited by any child processes the application may create and the file or device associated with the returned handle gets a default security descriptor."
sub rsp,24 ; stack space
; dwCreationDisposition
mov rax,2 (CREATE_ALWAYS)
mov [rsp+16],rax
; dwFlagsAndAttribute
mov rax,128
mov [rsp+8],rax
The value 128 is from https://learn.microsoft.com/en-us/windows/desktop/FileIO/file-attribute-constants
; hTemplateFile
mov rax,[const_inf]
mov [rsp+0],rax
Here is the full file creation code:
CreateAuditFile:
push r10
mov r10,rax ; Core #
mov rdi,FileHandles
mov rbx,[rdi+r10]
cmp rbx,0 ; has file been created
jne file_next
mov rcx,FileName_1
mov rdx,2 ;dwDesiredAccess ;0x40000000
push r8
push r9
mov r8,0 ; dwShareMode
mov r9,const_0 ; lpSecurityAttributes
;OR: mov r9,const_inf ; lpSecurityAttributes
; CREATE STACK SPACE FOR REMAINING PARAMETERS:
sub rsp,24
mov rax,2 ; dwCreationDisposition (CREATE_ALWAYS)
mov [rsp+16],rax
mov rax,128
mov [rsp+8],rax ; dwFlagsAndAttributes
mov rax,[const_inf]
mov [rsp+0],rax ; hTemplateFile
push r10
call CreateFileA
pop r10
mov rdi,FileHandles
call GetLastError
mov [rdi],rax
add rsp,24
pop r9
pop r8
pop r10
file_next:
ret
I have looked carefully at the parameter options, but the error message only says "invalid parameter." It doesn't say which parameter.
My question is: which parameter or parameters above is incorrect? Are the parameters on the stack passed correctly?
Thanks for any help.
I solved this problem, and here is the solution. The stack handling on my original question was incorrect. The right way to handle the stack is shown below.
The values for each of the parameters (such as DesiredAccess, ShareMode and Security Attributes) may be different depending on the specific needs of the project, but the parameters are passed as in the code below:
CreateAuditFile:
mov rcx,FileName_1
sub rsp,56 ; 38h
xor eax,eax
mov qword [rsp+48],rax ; 30h
mov eax,80
mov dword [rsp+40],eax ; 28h
mov eax,2
mov dword [rsp+32],eax ; 20h
xor r9,r9
xor r8d,r8d
mov edx,40000000
call CreateFileA
mov rdi,OutputFileHandle
mov [rdi+r15],rax
xor eax,eax
add rsp,56 ;38h
ret
Thanks very much to everyone who responded.

Where is relocation data stored in a PE file if not in the .reloc section?

I have the following program:
BITS 32
section .data
_num1: dd 5
section .text
global _start
_start:
push ebp
mov ebp, esp
mov eax, 9
add eax, [_num2]
sub eax, [_num1]
leave
ret
_num2: dd 7
Which assembles into the x86 instructions below:
0x00401000 <+0>: push ebp
0x00401001 <+1>: mov ebp,esp
0x00401003 <+3>: mov eax,0x9
0x00401008 <+8>: add eax,DWORD PTR ds:0x401016
0x0040100e <+14>: sub eax,DWORD PTR ds:0x402000
0x00401014 <+20>: leave
0x00401015 <+21>: ret
Now, the addresses of the sub and add instructions seems pretty fixed (absolute). Indeed, the VirtualAddress of the .data section is 0x2000, but what if the program doesn't load at its preferred address and relocation must be applied?
In this case, since the VirtualAddress's are RVA's, the sections remain relative to each other, but the addresses above are fixed.
How does the loader know that it must change these addresses to point to the proper data items?

How could it happen? (in debugging minidump file)

I'm tracing dmp file which seems like crashed calling virtual function of broken object instance.
it seems that vft of the broken object pointer pointed wrong address(0x3822a497) and program crashed immediately after call edx to 0x3822a497 (LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497), and instruction pointer (EIP) couldn't even go one step further. then, shouldn't it be edx=0x3822a497? but both Visual Studio and Windbg indicates edx=0x1e4dcc0.
Can somebody explain how could it happen?
EDIT: I trusted LAST_CONTROL_TRANSFER too much, but still mystery exists. please first see updated suppositions 1,2,3 below and give me a possible scenario.
Result of windbg !analyze -v
Failed calling InternetOpenUrl, GLE=12029
FAULTING_IP:
+8cde67
3822a497 006e00 add byte ptr [esi],ch
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 3822a497
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 0138d2cc
Attempt to write to address 0138d2cc
PROCESS_NAME: DDD.exe
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
FAULTING_MODULE: 76df0000 kernel32
DEBUG_FLR_IMAGE_TIMESTAMP: 518275c9
MODULE_NAME: DDD
ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_PARAMETER1: 00000001
EXCEPTION_PARAMETER2: 0138d2cc
WRITE_ADDRESS: 0138d2cc
FOLLOWUP_IP:
DDD+8cde67
00ccde67 ?? ???
FAILED_INSTRUCTION_ADDRESS:
+591b2faf0239d8f4
3822a497 006e00 add byte ptr [esi],ch
MOD_LIST: <ANALYSIS/>
FAULTING_THREAD: 00000650
BUGCHECK_STR: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_WRITE_WRONG_SYMBOLS
PRIMARY_PROBLEM_CLASS: BAD_INSTRUCTION_PTR
DEFAULT_BUCKET_ID: BAD_INSTRUCTION_PTR
LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
0018cfe0 00ccde67 1a75cb52 00000000 28e86c00 0x3822a497
0018cfe4 1a75cb52 00000000 28e86c00 00000011 DDD+0x8cde67
0018cfe8 00000000 28e86c00 00000011 29b52260 0x1a75cb52
STACK_COMMAND: ~0s; .ecxr ; kb
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: DDD+8cde67
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: DDD.exe
BUCKET_ID: WRONG_SYMBOLS
FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_DDD.exe!Unknown
WATSON_STAGEONE_URL: http://watson.microsoft.com/...
Followup: MachineOwner
---------
0:000>
Result of windbg .excr
0:000> .ecxr
eax=0018d0c8 ebx=78b3b6a8 ecx=00cddb00 edx=01e4dcc0 esi=0138d2cc edi=0018cfc8
eip=3822a497 esp=0018cfe4 ebp=00000002 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210282
3822a497 006e00          add     byte ptr [esi],ch          ds:002b:0138d2cc=??
Result of windbg r
Last set context:
eax=0018d0c8 ebx=78b3b6a8 ecx=00cddb00 edx=01e4dcc0 esi=0138d2cc edi=0018cfc8
eip=3822a497 esp=0018cfe4 ebp=00000002 iopl=0 nv up ei ng nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210282
3822a497 006e00 add byte ptr [esi],ch ds:002b:0138d2cc=??
Disassembly before LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497
current_time = timeGetTime();
00CCDE34 call dword ptr [__imp__timeGetTime#0 (17EE5FCh)]
(*it)->proc();
00CCDE3A mov eax,dword ptr [ebx]
00CCDE3C test eax,eax
00CCDE3E je 00CCDFFE
00CCDE44 test edi,edi
00CCDE46 je 00CCDFFE
00CCDE4C cmp dword ptr [eax+4],edi
00CCDE4F ja 00CCDFFE
00CCDE55 cmp edi,dword ptr [eax+8]
00CCDE58 jae 00CCDFFE
00CCDE5E mov ecx,dword ptr [edi]
00CCDE60 mov eax,dword ptr [ecx]
00CCDE62 mov edx,dword ptr [eax+0Ch]
00CCDE65 call edx
00CCDE67 push 0
EDIT
Oh I forgot to put stack state.
stack (esp=0x18cfe4)
0x0018CFA4 00000000 00000000 00000000 00000000 ................
0x0018CFB4 00000000 00000000 00000000 00000000 ................
0x0018CFC4 00000000 fffffd34 000002e4 fffffd34 ....4?..?...4?..
0x0018CFD4 000002cc 00000019 00000000 0018d0c8 ?...........??..
0x0018CFE4 >00ccde67 1a75cb52 00000000 28e86c00 g??.R?u......l?(
0x0018CFF4 00000011 29b52260 00000000 78b3c718 ....`"?).....??x
0x0018D004 29b522a0 00000000 78b3b6ac 29b522a0 ?"?)....???x?"?)
0x0018D014 00000000 78b3b6a8 1a75cb52 00000140 ....???xR?u.#...
0x0018D024 01e4f688 1a75cb52 0018d050 0170d884 ???.R?u.P?..??p.
0x0018D034 ffffffff 0018d05c 0098ec41 1a75cb36 ....\?..A??.6?u.
Disassembly around eip (0x3822A497)
3822A490 54 push esp
3822A491 00 db 00h
3822A492 65 db 65h
3822A493 00 72 00 add byte ptr [edx],dh
3822A496 61 popad
3822A497 00 6E 00 add byte ptr [esi],ch
3822A49A 69 00 74 00 65 00 imul eax,dword ptr [eax],650074h
Memory dump around eip (0x3822A497)
0x3822A480 55da14f5 80000000 00001e08 00000024 ?.?U........$...
0x3822A490 00650054 00610072 0069006e 00650074 T.e.r.a.n.i.t.e.
0x3822A4A0 004e0020 00630065 006c006b 00630061 .N.e.c.k.l.a.c.
0x3822A4B0 00000065 4d747cba 55da14f2 80000000 e...?|tM?.?U....
Obviously this is not valid instructions but wide characters text.
I think it is very likely that callee broke edx information as xwlan said.
( And I thought LAST_CONTROL_TRANSFER is some kind of trustful information. It was just displaying last callstack entry to eip )
But my suppositions still don't make a sense. Can somebody make a scenario that makes sense?
Suppose 1: instruction jumped before 0x3822A497 and executed popad
I think this makes most sense. (e.g. could jumped by some indirection jump/call to pointer to text buffer 0x3822A490)
If so, popad would executed, which pops EDI, ESI, EBP, EBX, EDX, ECX, and EAX from stack.
Then why can't I find these register's values from stack?
For example, if so, shouldn't I see 0x00000002 (ebp), 0x01e4dcc0 (edx) from stack near 0x0018CFE4 (esp)?
Suppose 2: callee was not 0x3822A497 , instruction jumped exactly to 0x3822A497
I think it is very rare case.
If jump was by indirect call/jmp, nothing would pointed to 0x3822A497 which is odd number,
If jump was by relative call/jmp, the call instruction would be near 0x3822A497,
but I can't find such a relative calls when I disassembly from every point near 0x3822A497
and because it has ##, 00, ##, 00, ## pattern of wide character text,
most possible jump instruction jumps to next instruction pointer, for example:
3822A494 72 00 > jb 3822A496
3822A496 61 popad
3822A497 00 6E 00 add byte ptr [esi],ch
Suppose 3: Callee was 0x3822A497
then why edx is not 0x3822A497. (First question)
You're putting too much faith in the call stack, you're likely missing a frame here (probably some sort of FPO related artifact). I suspect that EDX wasn't the bad EIP, it held the address of a valid function that eventually set up the invalid EIP.
If I were you, I would reconstruct EDX at the time of the crash and see what function it is. Then you can try to figure out what that function might have done to trash EIP (probably a stack overflow). If you're feeling lucky/lazy, you could hope that EDX has stayed unmolested and see what, "uf #edx" gets you.
look like stack corruption, "esp=0018cfe4 ebp=00000002", ebp is apparently a bad value.
i'd suggest check the code "00CCDE65 call edx", the edx looks like point to a virtual function, this function and its callee corrupt the stack. dds esp in windbg can help to dump current stack memory to check whether there's any suspicious values, e.g. any string?

Windbg _imp__xxx symbol's address seems to be dereferenced using the data segment register

I am learning Windbg. And for practice, I am debugging a 64bit fre app that create a process.
I added a breakpoint on CreateProcess (bp KERNEL32!CreateProcessWStub)
When the breakpoint is hit, I disassemble the code (u) and it looks like this:
Breakpoint 0 hit
KERNEL32!CreateProcessWStub:
000007f9`f8024ab4 4c8bdc mov r11,rsp
0:000> u #rip L20
KERNEL32!CreateProcessWStub:
000007f9`f8024ab4 4c8bdc mov r11,rsp
000007f9`f8024ab7 4883ec58 sub rsp,58h
000007f9`f8024abb 488b8424a8000000 mov rax,qword ptr [rsp+0A8h]
000007f9`f8024ac3 498943f0 mov qword ptr [r11-10h],rax
000007f9`f8024ac7 488b8424a0000000 mov rax,qword ptr [rsp+0A0h]
000007f9`f8024acf 498943e8 mov qword ptr [r11-18h],rax
000007f9`f8024ad3 488b842498000000 mov rax,qword ptr [rsp+98h]
000007f9`f8024adb 498943e0 mov qword ptr [r11-20h],rax
000007f9`f8024adf 488b842490000000 mov rax,qword ptr [rsp+90h]
000007f9`f8024ae7 498943d8 mov qword ptr [r11-28h],rax
000007f9`f8024aeb 8b842488000000 mov eax,dword ptr [rsp+88h]
000007f9`f8024af2 89442428 mov dword ptr [rsp+28h],eax
000007f9`f8024af6 8b842480000000 mov eax,dword ptr [rsp+80h]
000007f9`f8024afd 89442420 mov dword ptr [rsp+20h],eax
000007f9`f8024b01 ff1591951100 call qword ptr [KERNEL32!_imp_CreateProcessW (000007f9`f813e098)]
000007f9`f8024b07 4883c458 add rsp,58h
That call to _imp_CreateProcessW is misleading because when I trace (t) to the point where I am right at that call, that's is what I see
KERNEL32!CreateProcessWStub+0x4d:
000007f9`f8024b01 ff1591951100 call qword ptr [KERNEL32!_imp_CreateProcessW (000007f9`f813e098)] ds:000007f9`f813e098={KERNELBASE!CreateProcessW (000007f9`f7578960)}
So it looks like _imp_CreateProcessW address is a relative address (left by the linker?).
And that the data segment register (ds) is used somehow to resolve the final address (in this case, KERNELBASE!CreateProcessW (000007f9`f7578960))
This doesn't make sense though because I read that segments are not used in modern architecture (except for the fs and gs register that hold TCB's address)
My questions are:
what's going on there?
why is CreateProcessW not present in kernel32.dll (only the stub is). MSDN say that CreateProcess is in kernel32.dll
what's the story behind symbols that start with imp. Are they linker artifacts?
Thanks!!!
Note: I run .symfix and .reload at the beginning.
The value of the registers at that moment (right before the call):
0:000> r
rax=0000000000000000 rbx=0000000000000048 rcx=0000000000000000
rdx=0000000000535138 rsi=0000000000000000 rdi=0000000000000000
rip=000007f9f8024b01 rsp=00000000004df550 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=00000000004df5a8 r12=0000000000000000 r13=000007f7abfb1258
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206
IIRC __imp_ and stubs were introduced to take care of SxS. You will notice that most if not all kernel32 & kernelbase calls end up calling __imp_.
If regards to stubs, a quick example is
IsDebuggerPresent()
Doing a GetProcAddress on this will return the address of IsDebuggerPresentStub which will jump to IsDebuggerPresent, which in turn will jump to:
_imp__IsDebuggerPresent
In essence, you're correct. The _imp__XXX works a bit like a VFT.

Resources