Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista
Status: Beta
Brought to you by:
bdpayne
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 |