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

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

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
>