If you're looking to find the base address of a segment based on its selector, you can use dg<selector>; in this context you would use dg fs:
0:000> dg fs
P Si Gr Pr Lo
Sel Base Limit Type l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
003B 7ffdf000 00000fff Data RW Ac 3 ...
This is doable in WinDbg, but the syntax isn't the greatest. The other answers are probably better if you're just looking to get a result quickly. That said, here's how you'd do it.
RegOpenKeyExW is an stdcall function, and it looks like you're on a 32-bit version of Windows, so when you enter the function the first argument will be at ESP+4, the second at ...
Given your requirements, you'd be much better off sticking with WinDbg.
OllyDbg doesn't do .NET, nor is it capable of directly analyzing minidumps. It does have the ability to log its run traces, but this is likely not the type of logging that you need.
OdbgScript is nice, but it sounds like that's not enough of a reason for you to make the change.
It is effectively true that there is no additional impact. Non-invasive debugging is simply suspending the process, and then reading the register context and memory. Since there are no alterations to the memory, there isn't any physical thing to detect. The timing discrepancies that it introduces are detectable, but the same effects can be produced by a ...
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 ...
Make sure if you have the correct breakpoint address
issue lm an exe without symbol will be shown as
start end module name
00400000 0040f000 image00400000 (no symbols)
compare the NtHeader->AddresssOfEntrypoint with @$exentry
0:000> r $t0 = image00400000
0:000> ?? ((ntdll!_IMAGE_NT_HEADERS *) @@( poi( @$t0 + 0x3c ...
So how exactly do i figure out what is the remote process it is going
to communicate with, or what pipe it is using to communicate?
The first step is to find the RPC client interface. This can be found via the first argument to NdrClientCall2(), named pStubDescriptor. In your question, pStubDescriptor points to SspiCli!sspirpc_StubDesc:
And here is how ...
This is more of a SW dev problem than RE, but you can try using !htrace to find out where the mutex was originally allocated (creation stack trace).
Alternatively, try to figure why the thread #3 exits without releasing the lock.
This may be a bit tricky, but if you can repro the two scenartios (with and without releasing the lock), differential debugging ...
I am not sure if plugins exist but you can write simple scripts like below to hide WinDbg on case to case basis.
r?$t0 = (ntdll!_peb *) @$peb;?? @$t0->BeingDebugged;eb (@$t0+2) 0;?? @$t0->BeingDebugged
ZwSetInformationThread (XP SP3 syscalls with sysenter)
bp ntdll!ZwSetInformationThread "r eip = $ip+0n12 ; r eax = 0; gc"
Yes, you can do kernel debugging using two VMs. You will need to connect their serial ports.
The above is for Windows. OS X setup needs to be done manually: http://www.dcl.hpi.uni-potsdam.de/research/WRK/2011/01/running-wrk-on-mac-os-with-vmware-fusion/index.html
In the connection string ...
You can use ScyllaHide. There are plugins for many debuggers, but it is also possible to use InjectorCLI.exe to inject ScyllaHide into any process. Here are the steps (for a 32 bit process, if you want a 64 bit process, replace every x86 with x64):
Extract ScyllaHide (download) anywhere;
Run NtApiTool\x86\PDBReaderx86.exe and when it's finished, copy ...
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\\";
It has been a while since I've used Virtual PC, but I remember the instructions in this guide worked well: http://silverstr.ufies.org/lotr0/windbg-vmware.html
However, Virtual PC is extremely outdated (7 years old) and it's much easier nowadays to do VM kernel debugging with VirtualKD along with VMware or VirtualBox.
Even the free version of IDA Pro is worth having. Finding the general structure of an unknown binary is much easier with it than with anything else. If you have an unknown DLL, it will show you which exports it has, and looking at the assembly code helps you guess the parameters.
In most cases, to debug a .dll, you'll want to write a small program to call ...
0072 (0100) :
0072 - this is the number of passes remaining before the breakpoint is hit.
(0100) - this is the original limit passed in.
Note that these are hexidecimal values, so the crash was hit on the 142nd iteration (0x100-0x72).
0x80 is smaller than 142 (0x8E), so it expected that you would hit the breakpoint before the crash with that setting.
no there is no shortcut loader knows only about the $exentry because it is an embedded pointer in the PeHeader
from there to main is mostly traversed by either single stepping or observing and recognizing known functions by practice and experience
the crt code is fairly common and the source for crt is available in crt folder of any visual studio ...
I have had hands down the best experiences with PaiMei, or in particular PyDbg for these purposes. The book "Grayhat Python" brought it to my attention and I decided to give it a try.
Here's a somewhat generic skeleton I've been using in my dynamic analysis (dynamic-analysis) efforts. I have adjusted it so it'll hook the Unicode version of the ...
Extended Base Pointer, as the name suggests, is usually used as a frame pointer. That, among other things, means that it's used to access function parameters and local variables. If you think about how stack works, you can conclude the following:
local variables will be on the negative offset from the base pointer
address in the frame pointer will be the ...
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.
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 ...
The Windbg debugger plugin is an IDA Pro debugger plugin that uses Microsoft's debugging engine (dbgeng) that is used by Windbg, Cdb or Kd.
The Windbg plugin is very similar to IDA Pro's Win32 debugger plugin, nonetheless by using The Windbg plugin, one can benefit from the command line facilities and the extensions that ship with the debugging tools.
they are supported if you add the special escape sequence @!" symbol "
make sure you set a resolved breakpoints not an unresolved one
and be aware a single address may point to several instantiations of these classes
Microsoft (R) Windows Debugger Version 10.0.17744.1001 X86
lets look for some functions with angle brackets in them
It seems the correct term is Critical System Service. There are API from userland but I can't find anything for the kernel. So I took a quick look into the RstrtMgr.dll and it seems the list is actually hardcoded...
For the processes: