You cannot step into kernel mode from Ollydbg. You need a kernel debugger like windbg, as ollydbg is a user mode debugger.
Since you posed the question, I assume you neither have a kernel debugging connection,
nor the driver where that control code is sent for analyzing it, as answered by Jonathon.
Usage of proper security measures to deal with malware ...
More specifically, it sounds like your executable is loading a Device Driver. Userspace executables often communicates with drivers via IOCTLs (or I/O Controls).
DeviceIoControl does just that: sends an IOCTL to the driver. Note the second parameter to this function: DWORD dwIoControlCode. This is the code that identifies which IOCTL the program is ...
Here is a perfect explanation how sysenter works: http://www.osronline.com/article.cfm?id=257
All native API calls from User Mode have a body that simply loads an index into EAX, executes SystemCallStub, and returns
SystemCallStub saves a pointer to the top of the User Mode stack into EDX and executes a SYSENTER instruction
SYSENTER disables ...
Would this driver exist in user space, or in kernel space?
Is it even possible for a non kernel mode driver to exist?
You can write a user-mode driver using the User-Mode Driver Framework, but that type of driver is effectively a user-mode service with access to some extra I/O functionality.
What we typically think of as a "driver" is a ...
I still think this will create a BSOD, what's more I think that this is deliberate. It makes perfect sense to assume that this is deliberate once piecing all the puzzle pieces together. The source incompatibility will inevitably force that the developer notices the change of type for KeNumberProcessors from PCCHAR to CCHAR. The likeliest error is: error ...
So assuming like you said, you have the linear address of your device object, use the windbg extension !object 0xlinearaddress. Based on your windows build, it will display the linear address of the object header. Which in memory exists right below the object.
Use windbg to parse the OBJECT_HEADER structure for you. Starting with Windows 7 you are going to ...
ntdll.dll is not privileged in any sense and can't do anything that your user mode library can't. So no, it doesn't have "permission" do directly call kernel-mode code and it doesn't do that.
What it does is pass through one special interface the kernel provides in order to receive user mode calls. Depending on the version and on the CPU, the ntdll ...
7FFE0308h is a pointer inside the KUSER_SHARED_DATA struct.
The pre-set address for access from kernel mode is defined symbolically in WDM.H as KI_USER_SHARED_DATA. It helps when debugging to remember that this is 0xFFDF0000 or 0xFFFFF780`00000000, respectively, in 32-bit and 64-bit Windows. Also defined is a convenient symbol, SharedUserData, which casts ...
I had the same problem at first when trying to connect IDAPro to windbg. What I did was the following:
Manually edit the ida.cfg file located inside .\IDA 6.4\cfg\ directory.
Change the DBGTOOLS path with WinDbg tools directory. For example, to:
DBGTOOLS = "C:\\Program Files (x86)\\Windows Kits\\8.0\\Debuggers\\x86\\";
For some reason I have yet to determine, every effort to set a breakpoint on this module by name (fdisk.sys) is failing. The driver isn't loaded at bootup (at least, not at the point that I'm investigating right now). It's loaded by a module and then unloaded again fairly soon thereafter.
I finally used a debugger (indside my VM) to step through the ...
I'll post my own answer here so I can find this again in the future.
Using CFF Explorer open the service binary.
Find the AddressOfEntryPoint in the Optional Header.
Find the .text entry in Section Headers.
Calculate raw_offset = raw_address - virtual_address + AddressOfEntryPoint.
Within the built-in hex editor, navigate to raw_address.
Change the two ...
It may be late but:
If you use WinDBG(kd) to debug the kernel use
sxe -c ".echo fdisk loaded;" ld:fdisk.sys
this is usable in user and kernel mode and cause the debugger break-in after module loaded and before entry-point.
VirtualQueryEx() is the way to go if you want a memory map of a target process.
However, if you want information about modules only, you can extract it from the PEB of the target process.
Get the PEB address using NtQueryInformationProcess, using ProcessBasicInformation for the ProcessInformationClass, so it writes a PROCESS_BASIC_INFORMATION. This ...
you can try breaking on driver load instead on just the entry:
sxe ld drv.sys
This will stop windbg when the image gets loaded, so you'll be able to set breakpoints using raw addresses if all else fails.
By definition, 32 bit systems cannot have more than 64 CPU cores (either virtual or physical). This is a hard limit on Microsoft's side for reasons unknown. One can assume those limitations are related to implementation details of the kernel such as the number of CPU core structures, etc.
Since this is a 32bit driver it'll only be allowed to run in a 32 bit ...
Following cites, answering your first question come from Windows Internals Sixth Edition Part 1, page 225:
Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution
of 32-bit x86 applications on 64-bit Windows. It is implemented as a set of user-mode DLLs, with
some support from the kernel for creating 32-bit versions ...
For conventional inline hooks (that just replace the first few bytes of the function), you can simply read the first few bytes of each function to check if it is hooked. Deeper inline hooks will be difficult to detect.
Apart from inline hooks, someone may also hook the SSDT. The SSDT is a table that sits between syscalls from WINAPI's and the kernelmode ...
For windbg take a look at my answer here
How can you reliably unpack a Windows driver manually?
if you are using virtual kd and vmware just run the script when virtual kd breaks for the first time after the connection
it will simply print out all the driver details as and when they are loaded right from bootphase
for other vms you need to set sxe -ibp; ...
I would suggest you to put a breakpoint on NtCreateSection function which is responsible on validating and mapping the PE image when called with SEC_IMAGE flag. Hopefully you can track down where it fails by stepping through it.
GynvaelColdwind had invited honorary_bot who had 4 streams about Kernel Debugging.
The videos can be found here: Stream 1, Stream 2, Stream 3, Stream 4.
Around 34 min in the stream 1 he mentions the slowness of COM connection and around 38 he mentions usage of VirtualKd and why it works much faster. There's also a short installation/setup process.
As I think, someone else might have this problem, I have to answer my own question...
First. please read the question carefully ( it is long but worst it ).
As Virtual Box only accepts signed DLLs so you have to sign the
VBoxKD64.dll and/or VBoxKD.dll. it is not easy to find a trust sign so avast guys make a pre-signed virtual-kd available for ...
The SYSENTER instruction affects many registers, but most importantly it sets EIP to the value of the SYSENTER_EIP_MSR register (in IA-32 terminology). At boot-time, Windows sets SYSENTER_EIP_MSR to the address of ntoskrnl!KiFastCallEntry().
So at a high-level, SYSENTER "jumps" to ntoskrnl!KiFastCallEntry().
For more details, see http://www.codeguru.com/...