[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-discuss
Subject:    Re: [Qemu-discuss] Regarding QEMU Monitor "x /fmt addr" command
From:       Jakob Bohm <jb-gnumlists () wisemo ! com>
Date:       2019-01-17 20:02:15
Message-ID: 46fcd9ee-e63a-1a87-8818-12369f090342 () wisemo ! com
[Download RAW message or body]

On 17/01/2019 19:57, Peter Maydell wrote:
> On Thu, 17 Jan 2019 at 18:54, Phil Jones <phil.jones.2019@outlook.com> wrote:
> > Sorry, I meant address of an integer variable inside of a process. Thank you for \
> > the answers, that confirms my suspicions. If I were to translate guest process \
> > virtual address to Windows physical address, could I use that to read value?
> Only if you do the virtual-to-physical translation
> exactly at the point when the relevant process is
> in memory and when the memory is swapped in and not
> out on disk, and you don't let the guest run between
> the point when you do the translation and when you use
> it. (Otherwise windows could swap something out or
> change to a different process.) But if it worked to
> do that then the 'x' command would work too.
> 
> thanks
> -- PMM
> 

Note that on Windows, there are low level ways to get (and optionally
lock) a range of  process-address-space virtual memory addresses to
the (qemu virtualized) physical addresses.

These ways include:

1. Having a cooperating kernel module ("driver") make the appropriate
   calls, as if it was planning to pass this memory to a piece of non-
   standard DMA/bus-master hardware (not the higher level calls that
   refer to specific busses like PCI or devices like virtio disk 2).
    In the future, someone might add this to one of the qemu helper
   client drivers, as something accessible from the gdb stub.  Note
   that a few undocumented calls may be needed to get a pointer to a
   chosen process.  Also note kernel mode driver signing problems.

2. Using the builtin WinDbg stub in the Windows kernel.  This was
   always meant to be accessed from a different (Windows) machine,
   and as such can usually be mapped to a qemu device that can then
   be forwarded to another virtual machine running just WinDbg and
   associated data.  WinDbg has command line versions too (kd.exe
   for talking to the stub in the Windows kernel).

3. Using Windows-build specific symbol information (available via
   a special "debug use only" "public symbol server" service) to
   locate the memory mapping structures for processes and mapping
   it to "physical" addresses, this latter method is the one that
   has the fewest side effects on the virtual machine, but doing
   this reliably requires some deep experience, or helper scripts
   developed by someone else.

The above applies to all versions of NT-based Windows (not 100%
certain about the ARM ports though, but i386, AMD64, MIPS, PPC and
Alpha should be fine).  For the VxD based Windows (Windows 3.x in
"enhanced mode", Windows 95,98 and Me) each of the 3 methods are
somewhat different, and I don't think there is a command line
version of the kernel mode debugger clients (WDEB386.exe).

Windows 3.x in "standard mode" or "real mode" generally keeps a
mostly 1:1 virtual to physical mapping.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


[prev in list] [next in list] [prev in thread] [next in thread]