Thread: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista
Status: Beta
Brought to you by:
bdpayne
From: Matthew D. <ma...@at...> - 2008-01-17 19:24:07
|
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 -----Original Message----- From: Bryan D. Payne [mailto:br...@th...] Sent: Thursday, January 17, 2008 10:11 AM To: Matthew Donovan Cc: xen...@li... Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista Matthew, Welcome to the list. I have a few thoughts for you to explore... (1) My best guess is that you are using the wrong windows "sysmap" file. Of course, it is not really a sysmap file for windows but it does have critical offset information. And, while the snippet that you showed appears to be close to the right format (the extra "= xxx" and the end of each line looks weird to me), I would question if it is the correct information. Specifically, these data will be different for PAE and non-PAE kernels. Here's how to get the file: (non-PAE) dumpbin /exports c:\windows\system32\ntoskrnl.exe (PAE) dumpbin /exports c:\windows\system32\ntkrnlpa.exe Just save the output of these commands to a file and use that for the "sysmap". As an example, the files for my version of Windows XP SP2 are provided under the notes directory in subversion. (2) I noticed in the debug output that your version of windows is using PSE. My setup at this end does not use that, so it is likely that there are bugs in the PSE support mechanism. If (1) doesn't fix your problem, I would look into this next. (3) Finally, you are using Xen 3.1.2. This *should* work with HVM domains, but I haven't had time to work out all the kinks in supported Xen 3.1.x. So it's possible that there is some weird bug that you are triggering. Although I think that (1) and (2) are more likely. Also, it's worth noting that I haven't played with Vista yet. I imagine that it will "just work" if you get the right offsets and exports file. But, you'll be charting new territory there. Let me know how that goes as I'd be very interested in knowing if it works! Cheers, bryan On Jan 17, 2008 9:36 AM, Matthew Donovan <ma...@at...> wrote: > Hi, > > I'm trying to get the Xenaccess examples working with Windows. I > ultimately want to use it with Vista but for a first step I'd be happy > to get it working with XP SP2. When I try to run the process-list and > module-list examples on Vista or XP, it fails during initialization > with "failed to init XenAccess library: Bad address". (The full > output is below.) > > For Vista, I changed the constants in process-list.c to be appropriate > (determined using windbg). > For XP I just used the constants that were already there and verified > they were correct. > > I talked with Jim (I've just started on the project) and he showed me > a Windows sysmap(?) file. I included part of that just so you can > tell me if I got the format right. I assume it's OK since there isn't > an error looking up PsInitialSystemProcess. > > I'm using Xen 3.1.2 and XenAccess 0.4 on Fedora Core 8. > > I'm not really sure what to try next. > > Thanks for the help. > -matthew > > > XENACCESS.CONF: > winvista { > sysmap ="/root/libxa/winvista-exports.txt"; > ostype = "Windows"; > win_tasks = 0xa0; > win_pdbase = 0x18; > win_pid = 0x9c; > win_peb = 0x188; > win_iba = 0x8; > win_ph = 0x18; > } > > winxp0 { > sysmap ="/root/libxa/winxp-exports.txt"; > ostype = "Windows"; > win_tasks = 0x88; > win_pdbase = 0x18; > win_pid = 0x84; > win_peb = 0x1b0; > win_iba = 0x8; > win_ph = 0x18; > } > > SYSMAP (?) SNIPPET: > 94 0 000CA3D3 AlpcGetHeaderSize = _AlpcGetHeaderSize@4 > 95 1 000CA451 AlpcGetMessageAttribute = > _AlpcGetMessageAttribute@8 > 96 2 000CA414 AlpcInitializeMessageAttribute = > _AlpcInitializeMessageAttribute@16 > 97 3 0003273E CcCanIWrite = _CcCanIWrite@16 > 98 4 001D7530 CcCopyRead = _CcCopyRead@24 > > > > PROCESS-LIST OUTPUT FOR XP VM: > > XenAccess Version 0.4 > --got domain info. > **set instance->xen_version = 3.1.0 > --got domain name from id (4 ==> winxp0). > 1 |winvista { > 2 | sysmap ="/root/libxa/winvista-exports.txt"; > 3 | ostype = "Windows"; > 4 | win_tasks = 0xa0; > 5 | win_pdbase = 0x18; > 6 | win_pid = 0x9c; > 7 | win_peb = 0x188; > 8 | win_iba = 0x8; > 9 | win_ph = 0x18; > 10 |} > 11 | > 12 |winxp0 { > 13 | sysmap ="/root/libxa/winxp-exports.txt"; > 14 | ostype = "Windows"; > 15 | win_tasks = 0x88; > 16 | win_pdbase = 0x18; > 17 | win_pid = 0x84; > 18 | win_peb = 0x1b0; > 19 | win_iba = 0x8; > 20 | win_ph = 0x18; > 21 |} > 22 | > --got sysmap from config (/root/libxa/winxp-exports.txt). > --reading in windows offsets from config file. > --got ostype from config (Windows). > **set instance->os_type to Windows. > **set instance->pae = 1 > **set instance->pse = 1 > --got memory layout. > **set instance->hvm to true (HVM). > --MapPFN: Mapping mfn = 1. > --MapPFN: Mapping mfn = 2. > --MapPFN: Mapping mfn = 3. > --MapPFN: Mapping mfn = 4. > --MapPFN: Mapping mfn = 5. > --MapPFN: Mapping mfn = 6. > --MapPFN: Mapping mfn = 7. > --MapPFN: Mapping mfn = 8. > <snip> > --MapPFN: Mapping mfn = 4093. > --MapPFN: Mapping mfn = 4094. > --MapPFN: Mapping mfn = 4095. > failed to init XenAccess library: Bad address > > > > ---------------------------------------------------------------------- > --- 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 > -- Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
From: Matthew D. <ma...@at...> - 2008-01-21 18:48:56
|
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 > |
From: Matthew D. <ma...@at...> - 2008-01-21 18:57:38
|
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 > |
From: Matthew D. <ma...@at...> - 2008-01-22 14:45:32
|
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 |
From: Bryan D. P. <br...@th...> - 2008-01-22 15:05:52
|
> WOOT! > > Ok, I know what is happening. Cool... I'm glad that it's working. I was just starting to to dig into this deeper :-) > 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? Interesting. I'm not sure about this value. Does everything else seem to be working properly using that as the page offset? If it is, in fact, the right value. Then I'll need to figure out how to determine the correct value when bootstrapping xenaccess... > 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.) Good point. I'll see about updating it so the search cutoff is based on the physical memory size. > 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.) It doesn't surprise me that this number is different for Vista. However, it does surprise me that you're seeing the number that you mentioned. The '1b' is a size / length field, so I would think that this would not be set to '00'. But, stranger things have happened. I'll see if I can get Vista installed on my system one of these days to see if my system looks the same as yours. If so, then it's probably safe to assume that we have found the proper magic number. Thanks for keeping me updated, this is all very helpful... -bryan -- Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
From: Matthew D. <ma...@at...> - 2008-01-22 15:35:59
|
The process-list and module-list examples work. The process-data example fails with "failed to get process addresses from peb: Bad address" (full output below). I haven't looked closely at this one yet. Regarding the 'magic' EPROCESS number in Vista, I was a little off. The _DISPATCHER_HEADER struct definition has changed (from wdm.h): typedef struct _DISPATCHER_HEADER { union { struct { UCHAR Type; union { UCHAR Abandoned; UCHAR Absolute; UCHAR NpxIrql; BOOLEAN Signalling; }; union { UCHAR Size; UCHAR Hand; }; union { UCHAR Inserted; BOOLEAN DebugActive; BOOLEAN DpcActive; }; }; volatile LONG Lock; }; In the Windbg output, I didn't notice that some of the offsets were the same (i.e. the struct used unions.) However, the size has changed to 0x20 so I believe the 'magic' number for Vista is 0x00200003. -matthew process-data output: XenAccess Devel Version --got domain info. **set instance->xen_version = 3.1.0 --got domain name from id (2 ==> winxp0). 1 |winvista { 2 | sysmap ="/root/examin/libxa/winvista-exports.txt"; 3 | ostype = "Windows"; 4 | win_tasks = 0xa0; 5 | win_pdbase = 0x18; 6 | win_pid = 0x9c; 7 | win_peb = 0x188; 8 | win_iba = 0x8; 9 | win_ph = 0x18; 10 |} 11 | 12 |winxp0 { 13 | sysmap ="/root/examin/libxa/winxp-vm-pae-exports.txt"; 14 | ostype = "Windows"; 15 | win_tasks = 0x88; 16 | win_pdbase = 0x18; 17 | win_pid = 0x84; 18 | win_peb = 0x1b0; 19 | win_iba = 0x8; 20 | win_ph = 0x18; 21 |} 22 | --got sysmap from config (/root/examin/libxa/winxp-vm-pae-exports.txt). --reading in windows offsets from config file. --got ostype from config (Windows). **set instance->os_type to Windows. **set instance->pae = 1 **set instance->pse = 1 --got memory layout. **set instance->hvm to true (HVM). --got ntoskrnl (0x004d7000). --PTLookup: lookup vaddr = 0x80159554 --PTLookup: cr3 = 0x00000001 --PTLookup: pdpi_entry = 0x00000010 --PTLookup: pdpe = 0x00000000bfcfd8a8 ++Cache set (PsInitialSystemProcess --> 0x00000000) --got PA to PsInititalSystemProcess (0x025c8a00). **set instance->kpgd (0x806ee000). **set instance->init_task (0x81fd8250). --PTLookup: lookup vaddr = 0x81fd8250 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023d8250 ++Cache set (0x81fd8000 --> 0x023d8000) --MapMFN: Mapping mfn = 0x000023d8. --PTLookup: lookup vaddr = 0x820aad30 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1080 --PTLookup: pgd = 0x00000000024001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x024aad30 ++Cache set (0x820aa000 --> 0x024aa000) --MapMFN: Mapping mfn = 0x000024aa. --PTLookup: lookup vaddr = 0x81fe70a8 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023e70a8 ++Cache set (0x81fe7000 --> 0x023e7000) --MapMFN: Mapping mfn = 0x000023e7. --PTLookup: lookup vaddr = 0x820bf3c0 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1080 --PTLookup: pgd = 0x00000000024001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x024bf3c0 ++Cache set (0x820bf000 --> 0x024bf000) --MapMFN: Mapping mfn = 0x000024bf. --PTLookup: lookup vaddr = 0x81fbf0a8 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023bf0a8 ++Cache set (0x81fbf000 --> 0x023bf000) --MapMFN: Mapping mfn = 0x000023bf. --PTLookup: lookup vaddr = 0x81fd9a08 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023d9a08 ++Cache set (0x81fd9000 --> 0x023d9000) --MapMFN: Mapping mfn = 0x000023d9. --PTLookup: lookup vaddr = 0x81fba5d8 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023ba5d8 ++Cache set (0x81fba000 --> 0x023ba000) --MapMFN: Mapping mfn = 0x000023ba. --PTLookup: lookup vaddr = 0x81fe46f0 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023e46f0 ++Cache set (0x81fe4000 --> 0x023e4000) --MapMFN: Mapping mfn = 0x000023e4. --PTLookup: lookup vaddr = 0x820ca3d0 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1080 --PTLookup: pgd = 0x00000000024001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x024ca3d0 ++Cache set (0x820ca000 --> 0x024ca000) --MapMFN: Mapping mfn = 0x000024ca. ++Cache hit (0x81fe7e28 --> 0x023e7e28, 0x023e7000) --MapMFN: Mapping mfn = 0x000023e7. --PTLookup: lookup vaddr = 0x81fc6a10 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x023c6a10 ++Cache set (0x81fc6000 --> 0x023c6000) --MapMFN: Mapping mfn = 0x000023c6. --PTLookup: lookup vaddr = 0x81f1c3d8 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1078 --PTLookup: pgd = 0x00000000022001e3 --PTLookup: 2MB page --PTLookup: paddr = 0x0231c3d8 ++Cache set (0x81f1c000 --> 0x0231c000) --MapMFN: Mapping mfn = 0x0000231c. ++Cache hit (0x81fd8250 --> 0x023d8250, 0x023d8000) --MapMFN: Mapping mfn = 0x000023d8. ++Cache hit (0x820aad30 --> 0x024aad30, 0x024aa000) --MapMFN: Mapping mfn = 0x000024aa. ++Cache hit (0x81fe70a8 --> 0x023e70a8, 0x023e7000) --MapMFN: Mapping mfn = 0x000023e7. ++Cache hit (0x820bf3c0 --> 0x024bf3c0, 0x024bf000) --MapMFN: Mapping mfn = 0x000024bf. ++Cache hit (0x81fbf0a8 --> 0x023bf0a8, 0x023bf000) --MapMFN: Mapping mfn = 0x000023bf. ++Cache hit (0x81fd9a08 --> 0x023d9a08, 0x023d9000) --MapMFN: Mapping mfn = 0x000023d9. ++Cache hit (0x81fba5d8 --> 0x023ba5d8, 0x023ba000) --MapMFN: Mapping mfn = 0x000023ba. ++Cache hit (0x81fe46f0 --> 0x023e46f0, 0x023e4000) --MapMFN: Mapping mfn = 0x000023e4. ++Cache hit (0x820ca3d0 --> 0x024ca3d0, 0x024ca000) --MapMFN: Mapping mfn = 0x000024ca. ++Cache hit (0x81fe7e28 --> 0x023e7e28, 0x023e7000) --MapMFN: Mapping mfn = 0x000023e7. ++Cache hit (0x81fc6a10 --> 0x023c6a10, 0x023c6000) --MapMFN: Mapping mfn = 0x000023c6. ++Cache hit (0x81f1c3d8 --> 0x0231c3d8, 0x0231c000) --MapMFN: Mapping mfn = 0x0000231c. --UserVirt: pgd for pid=1732 is 0x860401c0. --PTLookup: lookup vaddr = 0x7ffd9000 --PTLookup: cr3 = 0x860401c0 --PTLookup: pdpi_entry = 0x860401c8 --PTLookup: lookup vaddr = 0x860401c8 --PTLookup: cr3 = 0x806ee000 --PTLookup: pdpi_entry = 0x806ee010 --PTLookup: pdpe = 0x0000000000af1001 --PTLookup: pgd_entry = 0x00af1180 --PTLookup: pgd = 0x000000000262a163 --PTLookup: pte_entry = 0x0262a200 --MapMFN: Mapping mfn = 0x0000262a. --PTLookup: pte = 0x0000000000000000 --PTLookup: paddr = 0x00000000 ERROR: address not in page table (0x860401c8) --PTLookup: pdpe = 0x00000000b7fec000 ERROR: address not in page table (0x7ffd9000) ERROR: could not find PEB struct for pid = 1732 failed to get process addresses from peb: Bad address -----Original Message----- From: Bryan D. Payne [mailto:br...@th...] Sent: Tuesday, January 22, 2008 10:06 AM To: Matthew Donovan Cc: xen...@li... Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista > WOOT! > > Ok, I know what is happening. Cool... I'm glad that it's working. I was just starting to to dig into this deeper :-) > 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? Interesting. I'm not sure about this value. Does everything else seem to be working properly using that as the page offset? If it is, in fact, the right value. Then I'll need to figure out how to determine the correct value when bootstrapping xenaccess... > 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.) Good point. I'll see about updating it so the search cutoff is based on the physical memory size. > 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.) It doesn't surprise me that this number is different for Vista. However, it does surprise me that you're seeing the number that you mentioned. The '1b' is a size / length field, so I would think that this would not be set to '00'. But, stranger things have happened. I'll see if I can get Vista installed on my system one of these days to see if my system looks the same as yours. If so, then it's probably safe to assume that we have found the proper magic number. Thanks for keeping me updated, this is all very helpful... -bryan -- Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
From: Bryan D. P. <br...@th...> - 2008-01-17 20:42:30
|
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 > |