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 ...
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 ...
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 ...
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. ...
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 ...
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:
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.
The /System/Library/Caches/com.apple.kernelcaches/kernelcache and the IPSW's kernelcache.release.iphone9 files have the same payload content but the former uses the IMG4 file format (containing a wrapper + payload) whereas the latter uses the IM4P file format (containing just the payload).
most of these structures can be queried with windbg
if you are running in usermode ntdll.pdb has these type information
if you are running in kernelmode ntos/ntkr/ aka nt*.pdb has these type information
you can use a tool like livekd from sysinternals along with windbg to do a
local kernel debugging session
following are output from livekd on a ...
What you have listed in your question isn't going to tell you what mode a process is executing in, and there's a couple things wrong with the thought process.
The help docs for !pte specify that the command takes a Virtual Address and displays PTE and PDE information about that address. The output of this command is kind of unintuitive because in actuality ...
Yes, it is possible. I do not want to go into details as there are a lot of comprehensive material available online:
Intels manuals which you will have to study in any case if you really want to understand how things work (from personal experience)
A VMM-based System Call Interposition Framework for Program Monitoring - one of the countless examples about ...
but every time I start the debugger,it seem to crash.
According to what I found searching around it is correct that the OS freezes as it is in debug mode.
Exactly. It's not crashing, it's only putting a breakpoint at system level: