Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

 WOOT!

Ok, I know what is happening.

For debugging purposes, I changed get_ntoskrnl_base() to go search physical
memory for the string "System", then go back 0x174 bytes and look for
0x001b0003.  When I found that I knew the phyiscal address of the EPROCESS
block we're looking for: 0x25c8a00.  Using a kernel debugger, I found that
the virtual address of the EPROCESS block is 0x821c8a00.  Subtract the
numbers and the distance is 0x7fc00000, not 0x80000000.  I changed
init_page_offset() to reflect this and recompiled.  That worked and I got
the process list for my XP VM!

I'm not sure what the 0x7fc00000 is though it looks familiar.  I think I've
come across it in my readings but I haven't found it yet.  Any ideas?

A couple things to note:

1)  In get_ntoskrnl_base(), the while() loop only goes to 0x01000000 bytes
of memory.  My VM has 512 MB and so I had to change the break condition up
to 0x20000000.  Is there a way to know how much memory a VM has via an xc_
function?  (The xa_ code could always read the Xen config file used to boot
the VM.)

2)  The "magic" number 0x001b0003 won't work for Vista.  I haven't done any
rigorous checking, but on one process I have looked at, the number would be
0x00000003.  (Again, I don't know yet if this is consistent for all EPROCESS
blocks.)

-matthew

-----Original Message-----
From: Matthew Donovan [mailto:ma...@at...] 
Sent: Monday, January 21, 2008 2:03 PM
To: Bryan D. Payne
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

Oops.  Hit send before I was done writing.

In test_ntoskrnl_base(), this chunk returns the correct virtual address of
the _EPROCESS block.

    sysproc += base;	

    xa_read_long_phys(instance, sysproc, &sysproc);
    if (sysproc <= instance->page_offset){
        return XA_FAILURE;
    }

 
The virtual-to-physical address translation isn't right (I guess) because
the returned header value is zero:

    sysproc -= instance->page_offset;

    /* sysproc should now be the PA of a an EPROCESS location */
    xa_read_long_phys(instance, sysproc, &header);
    
    /* Test for EPROCESS using technique from 'Searching for Processes
       and Threads in Microsoft Windows memory dumps' in DFRWS 2006 */
    if (header != 0x001b0003){ /* this number is different on Vista */
        return XA_FAILURE;
    }


We tried turning off PAE in hopes that it would also turn off PSE.  No such
luck.  However, I wrote a program that checks if PSE is enabled (using the
CPUID instruction) in the guest and it reports that it isn't. 

I see in your code that you use xc_vcpu_getcontext() and then check if a bit
is set in CR4.  I'm still having some problems knowing where the line
between VM and host is.  Should the CR4 register report the same as the
CPUID instruction?  From what I've read from the Xen mailing lists, I'm
assuming that if the guest doesn't see PSE enabled, then the page size is
always 4KB.  Is that a correct assumption?  Do you know how I could just
turn PSE off completely?

I'm not really sure what else to try here and any further suggestions would
be great.

Thanks
-matthew


-----Original Message-----
From: Matthew Donovan
Sent: Monday, January 21, 2008 1:50 PM
To: 'Bryan D. Payne'
Cc: xen...@li...
Subject: RE: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

Hi Bryan,

I think I have the problem pretty well narrowed down.  Perhaps you can shed
some light on what I'm seeing.

The code is breaking in test_ntoskrnl_base().  Using WinDbg in the Windows
VM, I verified that we are getting the correct virtual address of the
_EPROCESS block for the System process.


-----Original Message-----
From: Bryan D. Payne [mailto:br...@th...]
Sent: Thursday, January 17, 2008 3:43 PM
To: Matthew Donovan
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

One more thought.  I just had another look at your debug output.  It looks
like it is failing in the get_ntoskrnl_base function (located in
windows_memory.c), because there is no evidence that it found the kernel
image.  Normally you would see something like:

--got ntoskrnl (0x004d7000)

This function would fail if it had the wrong offset for
PsInitialSystemProcess (but it sounds like you have tried all kinds of
options for that, since this is read from the exports file), if the kernel
image did not start at the top of the mapped page (which is conceivable for
PSE), or if we were just having trouble reading memory from the VM.  You
might try adding additional debugging code within this function (and its
helper, test_ntoskrnl_base) to see exactly where it's failing.

-bryan


On Jan 17, 2008 2:27 PM, Matthew Donovan <ma...@at...> wrote:
> Thanks for the pointers.
>
> I think I've exhausted all combinations of option 1 with no success.  
> The extra output (= _Symbol@X) shows some linking information (calling 
> convention and total size of arguments in bytes) and was caused by 
> dumpbin.exe.  I used the version that came with Visual Studio 2008; an 
> older version of dumpbin doesn't produce it.  I generated export files 
> for both kernels (pae and non-paw) and stipped out the extra stuff.  
> Still
no go.
>
> I guess I'll move on to option 2.
>
> -matthew
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
XenAccess-devel mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenaccess-devel