I was trying to do a dynamic loading of dhcpcsvc6.dll to support ipv6 on win7 and ipv4 on xp. But GetProcAddress of Dhcpv6CApiInitialize always fails. So I used exescope to examine the exports of the dll, this is what I got.
Version: 6.1.7600.16385.
00000001 404632EA Dhcpv6AcquireParameters
00000002 40463E4F Dhcpv6CancelOperation
00000003 40463EB9 Dhcpv6EnableTracing
00000004 40461D3B Dhcpv6FreeLeaseInfo
00000005 404644D3 Dhcpv6GetTraceArray
00000006 404645D9 Dhcpv6GetUserClasses
00000007 404642D1 Dhcpv6IsEnabled
00000008 40461730 Dhcpv6QueryLeaseInfo
00000009 40463419 Dhcpv6ReleaseParameters
0000000A 40463E31 Dhcpv6ReleasePrefix
0000000B 40463BF5 Dhcpv6ReleasePrefixEx
0000000C 40463BD1 Dhcpv6RenewPrefix
0000000D 40463892 Dhcpv6RenewPrefixEx
0000000E 40463F51 Dhcpv6RequestParams
0000000F 40463871 Dhcpv6RequestPrefix
00000010 40463549 Dhcpv6RequestPrefixEx
00000011 404647D1 Dhcpv6SetUserClass
Dhcpv6CApiInitialize is not in it. I also tried dhcpcore6.dll, dhcpsvc.dll and 64bit versions of these.. no findings.
I wonder where this function really is? Do I really have to call it before any other dhcp v6 apis?
MSDN reference: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363306(v=vs.85).aspx
TL;DR
Functions are not present until Win8. The Win8 version (I examined version 6.2.9200.16433) does nothing useful. It seems safe to ignore these functions if they're not present in dhcpcsvc6.DLL.
Explanation:
Statically linking requires Win8 SDK (already built into VS2012).
VS2010 with Win7 SDK won't compile.
When compiled with Win8 SDK, the compiled exe won't run on Win7, saying The procedure entry point Dhcpv6CApiInitialize could not be located in the dynamic link library dhcpcsvc6.DLL. That means that the functions are indeed exported from dhcpcsvc6.DLL.
Win8 version of the DLL does contain these functions.
_Dhcpv6CApiInitialize#4 essentially just puts 2 to output parameter:
10004199: mov edi,edi // Standard Hotpatch spot
1000419B: push ebp // Standard Prologue
1000419C: mov ebp,esp // Standard Prologue
1000419E: mov eax,dword ptr [ebp+8] // eax <- param0
100041A1: test eax,eax // if (param0 == 0)
100041A3: je 100041AB // return;
100041A5: mov dword ptr [eax],2 // *param0 = 2;
100041AB: pop ebp // Standard epilogue
100041AC: ret 4 // end of function
_Dhcpv6CApiCleanup#0 does nothing at all:
100041B6: ret
Related
So I'm working on some binary to assembly to c++ code. It's for a project.
When I disassemble the binary I'm getting a lot of repeating assembly code and I'm not sure what it's doing. It's almost like it's just pointing it's way down.
0x0000000000000000 <+0>: push %rbp
0x0000000000000001 <+1>: mov %rsp,%rbp
0x0000000000000004 <+4>: lea 0x0(%rip),%rsi # 0xb <main+11>
0x000000000000000b <+11>: lea 0x0(%rip),%rdi # 0x12 <main+18>
0x0000000000000012 <+18>: callq 0x17 <main+23>
0x0000000000000017 <+23>: callq 0x1c <main+28>
0x000000000000001c <+28>: mov %eax,0x0(%rip) # 0x22 <main+34>
0x0000000000000022 <+34>: mov 0x0(%rip),%eax # 0x28 <main+40>
0x0000000000000028 <+40>: cmp $0x1,%eax
0x000000000000002b <+43>: je 0x40 <main+64>
0x000000000000002d <+45>: lea 0x0(%rip),%rsi # 0x34 <main+52>
0x0000000000000034 <+52>: lea 0x0(%rip),%rdi # 0x3b <main+59>
0x000000000000003b <+59>: callq 0x40 <main+64>
0x0000000000000040 <+64>: mov 0x0(%rip),%eax # 0x46 <main+70>
0x0000000000000046 <+70>: cmp $0x1,%eax
So the repeating code is the "lea" and "callq". Based on the way I'm reading it, it's just pointing to the next line down. For example, the first lea ends with #0xb <main+11> which is the line right below it, and that one points to the line below it, and so on. Can anyone help with what I'm looking at?
There's at least a hundred extra lines in the project, so I'm not looking for a free A, I just need help understanding.
Edit: I am working with a .o file without access to the original .cpp file and the task is to use GDB and Bless to help me read the Assembly output and reassemble it into a .cpp file that works the same as the original code.
So the repeating code is the "lea" and "callq".
The addresses suggest that you are disassembling .o file, not an executable (you should always show the command you used when asking about its output).
Try objdump -dr foo.o instead -- the picture should become much clearer.
P.S. GDB isn't really the right tool for looking at .o files anyway.
Update:
I tried the objdump -dr Project1.o and got pretty much the same output
Look closer: it's not the same output. objdump will display relocations, which show where he CALL will actually go to.
You should also be able to link Project1.o into an executable (something like gcc Project1.o -o Project1), and run gdb Project1 and then disas main. You will see that that disassembly makes more sense, and also matches the output of objdump.
I'm new to C++ programming and have always wanted to write a system information program for MS-DOS. I'm currently using the latest DigiMars C++ compiler and MASM 6.13 for my project. The project settings are for large memory model with a target CPU of an Intel 8088 processor for the widest compatibility with MS-DOS.
I'm attempting to write a routine that checks if the CPU supports the CPUID instruction found on late model 486 and early Pentium CPUs. I found a couple bits of code through Google searches and have been able to add them to the project and successfully compile, but none of them work. The problem is that when I attempt to execute the program I get a message about an invalid instruction (under my Windows NT 3.51 test system) and it completely hangs on my test MS-DOS systems.
The code I'm using is as follows:
public _is_cpuid_supported
cpuid macro
db 0fh, 0a2h
endm
_is_cpuid_supported proc near
.486
push bp
mov bp, sp
sub sp, 40
push eax
push ebx
pushfd ; get extended flags
pop eax
mov ebx, eax ; save current flags
xor eax, 200000h ; toggle bit 21
push eax ; put new flags on stack
popfd ; flags updated now in flags
pushfd ; get extended flags
pop eax
xor eax, ebx ; if bit 21 r/w then eax <> 0
pop ebx
pop eax
je no_cpuid ; can't toggle id bit 21, no cpuid here
mov ax, 1 ; cpuid supported
jmp done_cpuid_sup
no_cpuid:
mov ax, 0 ; cpuid not supported
done_cpuid_sup:
mov sp, bp
pop bp
ret
_is_cpuid_supported endp
I've also tried the sample from OSDev.org here: https://wiki.osdev.org/CPUID?msclkid=3c6e16f9c23611ec98be59859d0dd887 but it doesn't work either. Any tips? Let me know if further clarification is needed.
In large memory model DOS programs, the default for assembly procedures is far. Removing the near keyword from the line _is_cpuid_supported proc near solved the problem. Thanks to #MichaelPetch for the tip.
I disassemble my C code (just printf("hello world") ) in gdb and I got
0x0000000000001135 <+0>: push rbp
0x0000000000001136 <+1>: mov rbp,rsp
0x0000000000001139 <+4>: lea rdi [rip+0xec4] # 0x2004
0x0000000000001140 <+11>: mov eax,0x0
0x0000000000001145 <+16>: call 0x1030 <printf#plt>
0x000000000000114a <+21>: mov eax,0x0
0x000000000000114f <+26>: pop rbp
0x0000000000001150 <+27>: ret
I set break point to main and exam rip register.
rip 0x555555555139 0x555555555139 <main+4>
What are those numbers in font of < > in gdb?
I can only access the memory that rip point to.
if those numbers aren't memories can I change format that make gdb display memory?
Sorry for my bad English.
What are those numbers in font of < > in gdb? I can only access the memory that rip point to.
You are dealing with a position independent executable, which is linked to load at address 0, but is relocated at runtime to a different address (in your case, 0x555555554000).
You likely performed disas before running the application (i.e. before the relocation happened). If instead you do this:
(gdb) start
(gdb) disas main
then GDB will show you relocated instructions.
In an effort to track down some hard to reproduce crashes I've configured the UnhandledExceptionFilter to create mini-dump files as described here: Debugging Custom Filters For Unhandled Exceptions and Effective Minidumps
The dumps are being successfully captured but I'm not having much luck interpreting the stack information. In the hope that someone else will have experienced something similar I'll provide as many details as I can below. Sorry if this question ends up being a little verbose as a result.
Visual Studio provides the following dump summary:
Dump Summary
------------
Dump File: MiniDump.dmp
Last Write Time: 15/08/2012 22:07:22
Process Name: Server.exe : C:\Project\Server.exe
Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information: Not Present
System Information
------------------
OS Version: 6.1.7601
CLR Version(s):
Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Server.exe C:\Project\Server.exe 1.0.0.1
ntdll.dll C:\Windows\SysWOW64\ntdll.dll 6.1.7601.17725
kernel32.dll C:\Windows\SysWOW64\kernel32.dll 6.1.7601.17651
KERNELBASE.dll C:\Windows\SysWOW64\KERNELBASE.dll 6.1.7601.17651
mysqlpp_d.dll C:\Projects\Ken11\bin\debug\mysqlpp_d.dll 0.0.0.0
wsock32.dll C:\Windows\System32\wsock32.dll 6.1.7600.16385
ws2_32.dll C:\Windows\SysWOW64\ws2_32.dll 6.1.7601.17514
msvcrt.dll C:\Windows\SysWOW64\msvcrt.dll 7.0.7601.17744
libmySQL.dll C:\Projects\Ken11\bin\debug\libmySQL.dll 0.0.0.0
user32.dll C:\Windows\SysWOW64\user32.dll 6.1.7601.17514
advapi32.dll C:\Windows\SysWOW64\advapi32.dll 6.1.7601.17514
msvcp90d.dll C:\Projects\Ken11\bin\debug\Microsoft.VC90.DebugCRT\msvcp90d.dll 9.0.21022.8
msvcr90d.dll C:\Projects\Ken11\bin\debug\Microsoft.VC90.DebugCRT\msvcr90d.dll 9.0.21022.8
mfc90d.dll C:\Projects\Ken11\bin\debug\Microsoft.VC90.DebugMFC\mfc90d.dll 9.0.21022.8
dbghelp.dll C:\Windows\System32\dbghelp.dll 6.1.7601.17514
mswsock.dll C:\Windows\System32\mswsock.dll 6.1.7601.17514
wininet.dll C:\Windows\SysWOW64\wininet.dll 8.0.7601.17785
rasman.dll C:\Windows\System32\rasman.dll 6.1.7600.16385
devobj.dll C:\Windows\SysWOW64\devobj.dll 6.1.7601.17621
Looking at the stack of the thread where the exception occurred we get the following extremely short call stack:
msvcr90d.dll!6d69f824()
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr90d.dll]
--> Server.exe!CServer::LoadPageList() Line 269 + 0x28 bytes C++
cccccccc()
All the correct threads in the application have nice clean stacks showing calls all the way back to __RtlUserThreadStart E.g:
mswsock.dll!_WSPRecv#36() + 0x34ff bytes
ws2_32.dll!_WSARecv#28() + 0x71 bytes
wsock32.dll!_recv#16() + 0x33 bytes
>libmySQL.dll!008aaa2f()
[Frames below may be incorrect and/or missing, no symbols loaded for libmySQL.dll]
libmySQL.dll!008aac0d()
libmySQL.dll!008a34d7()
libmySQL.dll!008a30d2()
libmySQL.dll!0084be35()
libmySQL.dll!00851572()
libmySQL.dll!00851c2b()
Server.exe!CServer::logStatusToDB(AsynchStatus_T * pStatus=0x04f18170) Line 1717 C++
Server.exe!CServer::checkStatus(AsynchStatus_T * pStatus=0x04f18170) Line 2145 C++
Server.exe!CThread::ControllingFunction(void * lpParameter=0x03fffe08) Line 1280 + 0xf bytes C++
kernel32.dll!#BaseThreadInitThunk#12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart#8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart#8() + 0x1b bytes
How could the lower portion of the crashed thread's stack get replaced by 0xCCCCCCCC?
For completeness here is the disassembly of the frame Server.exe!CServer::LoadPageList() Line 269 + 0x28 bytes
00453217 mov byte ptr [ebp-4],0
0045321B mov esi,esp
0045321D lea ecx,[ebp-104h]
00453223 call dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > (6DA994h)]
00453229 cmp esi,esp
0045322B call _RTC_CheckEsp (690D20h)
00453230 mov dword ptr [ebp-4],0FFFFFFFFh
00453237 mov esi,esp
00453239 lea ecx,[ebp-20h]
0045323C call dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > (6DA994h)]
00453242 cmp esi,esp
00453244 call _RTC_CheckEsp (690D20h)
00453249 push edx
0045324A mov ecx,ebp
0045324C push eax
0045324D lea edx,[ (45327Ch)]
00453253 call _RTC_CheckStackVars (690D50h)
00453258 pop eax <<<=== exception refers to this line
00453259 pop edx
0045325A mov ecx,dword ptr [ebp-0Ch]
0045325D mov dword ptr fs:[0],ecx
00453264 pop ecx
00453265 pop edi
Update
Completely forgot to include the function source (thanks Joachim):
void CServer::LoadPageList()
{
CString header;
header.Format("Accept: text/plain, */*; q=0.01\r\n");
_pSession->setHttpHeader (header);
_pSession->ReadPage (_T("/Pages"), true);
SaveTimeStampedFile ("Pages.txt");
}
The strange thing is that all of the operations in the function LoadPageList complete successfully, the crash seems to happen after the string's destructor is called just before returning from this stack frame.
I'm currently working on hooking ntdll.dll calls via dll injection.
At first, I create thread in existing process via CreateRemoteThread() then I load my dll via LoadLibrary and finally hook calls on PROCESS_ATTACH.
Injection works fine, but then I want to log all registry and file system queries. And the problem is that it doesn't work properly.
I decided to publish code via PasteBin, because piece is pretty big. Here is the link:
http://pastebin.com/39r4Me6B
I'm trying to hook ZwOpenKey, then log key content and then launch "true" function by pointer. Function NOpenKey gets executed, but process stops without any errors.
Does anyone see any issues?
If you use OllyDbg, ZwOpenKey starts with 5 bytes MOV EAX, 77.
You can overwrite these bytes like so JMP _myZwOpenKey then from there you can do whatever with the values on the stack, restore all registers then do a JMP 7C90D5B5 which is address of ZwOpenKey + 5 bytes.
CPU Disasm
Address Hex dump Command Comments
7C90D5AF 90 NOP
7C90D5B0 /$ B8 77000000 MOV EAX,77 ; ntdll.ZwOpenKey(guessed rg1,Arg2,Arg3)
7C90D5B5 |. BA 0003FE7F MOV EDX,7FFE0300
7C90D5BA |. FF12 CALL DWORD PTR DS:[EDX]
7C90D5BC \. C2 0C00 RETN 0C
I usually do these in Assembly that way I don't have to mess around a lot with type casting and all that. Hope this helps.