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 ...
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 ...
There is no need for emulation because x64 processors can execute x86 (32-bit) code natively using so-called compatibility mode. You only need to set up proper descriptors in the GDT (L=0 for 32-bit code, L=1 for 64-bit code) and it "just works". This is what Windows does. E.g. from this OSR post, the windows 7 x64 GDT has these entries:
GDT[0x04] = 32 bit ...
There is an open source project: openpst, which reimplements most functionality of the qpst tool.
Some of the protocols used are:
diag - used to read nv memory, and switch to dload mode using kDiagDload.
sahara - used by the primary bootloader in newer qualcomm chipsets
dload, used by bootroms, and older chipsets.
streaming dload - used by the flash loader....
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 ...
You don't disable that kind of integrity check, you simply set the checksum. The one that's relevant in this particular case is the respective field in the IMAGE_OPTIONAL_HEADER, that is IMAGE_OPTIONAL_HEADER::CheckSum.
That said, you will likely run into additional issues once you resolved this one. I am not sure if the kernel itself is subject to Early ...
It works As Expected and Documented
Running a plain .thread resets context to CurrentThread as documented
Quote From Documentation
The address of the thread. If this is omitted or zero,
the thread context is reset to the current thread.
You Cannot Set @rip to Arbitrary Values
Use the sniffer for the communication channel it uses (most likely USB) to see which data is sent to your device. Try to search for the constants you see in the sniffer to find which binary may be responsible for generating the data sent to the device. Disassemble the binary, find the exact code piece responsible for protocol processing, decompile it ...
1) you should be aware local kernel debugging is not actual kernel debugging
2) i hope you have enabled /debug on switch in bcdecdit prior to using local kernel debugging feature
3) i hope you are aware a third party app is available which does not require setting /debug on switch
i hope you have properly set the symbol path for ...
It sounds like you aren't sure what you want to do exactly. Is there any part of the firmware you want to reverse engineer in particular? I suggest you first start by reading some blog posts on devttys0.com, as he seems like an excellent source for information about reverse-engineering router firmwares.
If a binary contains symbols, IDA Pro should ...
There is a really good book which does exactly that:
"Windows Internals: The Implementation of the Windows Operating Environment" by Matt Pietrek.
It's full of disassembly listings from the Windows 3.x kernel and other parts.
You should try VirtualKD which uses a fast VM-specific mechanism to communicate with the debugger instead of slow serial port emulation. Another option could be Ethernet or USB-based debugging but I'm not sure how to set it up with VMs...
To start with, the offsets are more likely to match the current OS at the time of the book's writing (probably Win7) than Windows 10. That said, a good reference to internal kernel structures over different Windows versions is Geoff Chapell's website: https://www.geoffchappell.com/studies/windows/km/index.htm
For example, looking at KPCR, we can see that at ...
On the pte command you use an address from where did you get that address FFFFF6FB7EA00068 <<<<<
If it is a virtual address does it truly belong to the active process context ?
are you in the process context of iexplore.exe ??
(did you do .process /p /r EPROC_ADDR )
just doing .process /p /r changes only the display in windbg and the ...
Fixed the issue this was a two part problem.
Avast anti virus was slowing down the VM to a crawl
solution uninstall avast or in some cases DISABLE the option: Settings > Troubleshooting > "Enable hardware assisted visualization"
There is a bug in newer versions of WinDBG when debugging older versions of windows
solution use an older version of WinDBG, or ...
The overall format of an AArch64 Linux kernel can be found in https://www.kernel.org/doc/Documentation/arm64/booting.txt
Of particular note (emphasis mine):
The AArch64 kernel does not currently provide a decompressor and
therefore requires decompression (gzip etc.) to be performed by the
boot loader if a compressed Image target (e.g. Image.gz) is used. ...
In long mode, segmentation is not really used and all segment registers have base of 0. fs and gs are exceptions that were added to address thread-specific data. Their real base addresses are stored in MSRs (model specific registers) instead of the descriptor table. The MSRs are only accessible in kernel mode, but you can get the value of GS indirectly via ...
gs is kernel mode only
you can see the data in windbg if you are in a kd session
0: kd> ? @@c++(@$pcr->GdtBase)
Evaluate expression: -8781100130384 = fffff803`7da55fb0
0: kd> dq gs: l1
__readgsword() is an intrinsic it must have some magic :)
1: kd> rdmsr c0000101
msr[c0000101] = ffffe601`555ea000
when you are in kd session lm displays both kernelmode modules and user mode modules
use lm u to display only usermode modules
this will be consistent with the !vad display
kernel mode modules aren't associated with a single process and as such they are not a part of processes virtual address descriptor table
obviously you can get the pte for any ...
It is possible. Take a minute to read the output from analyze. There's a few fields that will tell you what driver faulted like "FAULTING_MODULE", "IMAGE_NAME", and "MODULE_NAME".
It will give you the state of the registers as well and specifically what instruction that caused the crash so you'll see something like
driver + offset:
So there is an answer in the original post, but what i was missing is the interface where i'll be attaching the debugger at in the boot-args
so I have to add kdp_match_name=en24, where en24 is the physical interface the machines are communicating at
Just adding here the answer as well, as it might help someone in the future
Linux kernel can boot mostly on its own by probing the hardware and using the linked-in drivers. The NT kernel requires an environment such as UEFI or legacy BIOS and relies on it, for example, to load additional drivers. It also expects to be loaded in a certain manner by the pre-loader (winload.efi) while Linux has less strict requirements.
This is why ...
Include the targets of the pointers into the snapshot (can be done by enabling the target segment’s loader flag in segment properties, or via “Analyze module” from the Modules context menu)
Rename the import table pointers using the pointed-to names (e.g. using renimp.idc or similar script)
these should be comments but it grew up
what is the windbg version ?
what is the os version ?
what is the output of lm m "your specific Module"
are the symbols loaded for your Module ?
have you tried disassembling with u <address> in command window as it appears you are looking at Disassembly Window
did you try ln <address> to list the ...
Assuming You Wrote this code
This opens a file in the current Directory
Reads its contents and counts the content length and
Prints to console contents and count
This is a crt function it transistions from
crt to kernel32.dll , kernelbase.dll and ntdll.dll in user mode. and
from ntdll it transitions into kernel mode via a syscall to NtCreateFile in ntoskrnl/...
AFAIK often on laptops the special keys are handled not by the OS but the embedded controller (EC), either completely without the OS involvement or via the ACPI interface.
So you might have to look at the ACPI tables and see if there are methods you can hook (not sure how it works in Linux).
The syscall instruction is always invoked in long mode, by the 64-bit ntdll (there are two ntdll in a wow64 process), so the return to user mode should be there. The jmp fword ptr [r14] instruction jumps back to x86 code from x64.
When dealing with mixed mode stacks in WinDbg, the wow64ext extension is useful, e.g.:
I would add information to the first answer.
The switch of the mode from Wow64 to 64bit, aka "Heaven's Gate", is in wow64cpu.dll. offset j_Wow64Transition is a part of wow64cpu.dll.
These slides helps you to understand the procedure of executing 64bit syscall from Wow64 process with assembly codes as a example.
Eventually, I have used kdsrv(x86) in the host machine :
Kdsrv -t tcp:port=5006
And in IDA the following connection string:
and it worked.