Physical and virtual adresses #30
Comments
|
The phys2virt command line option is operating system independent as long as the target runs on the x64 CPU architecture. I currently do not have a command line option for the reverse, even though you're not the first to ask. It would be a rather generic page table walk, you would have the CR3/PML4 address and the Virtual Address as input and the Physical Address at the output. I'll look into possibly adding it, but for now you'll have to do a manual page table walk for it (please consult intel manuals for this). |
|
For function Action_PT_Phys2Virt you need to input cr3 and if i understand correctly each process have its own cr3/pml4 address right ? How do i get this cr3 address for specific process? |
|
This is not supported at the moment. You should probably be able to use volatility for this if you have the memory dump though. I might implement some functionality helping with this in the not too distant future. |
|
I'll add this in the next release of PCILeech. I have other features to complete before release as well so it may take some time. |
|
Ok I will be waiting. Thank you ufrisk. |
|
Thank you so much for the update. Now there is pt_virt2phys. Witch function i need to use to get cr3 for specific process? Another question is spartan cards latency better then usb3380? How many read/write calls would i be able to do in 1 sec? |
|
The easiest way, if using the USB3380, is probably to dump all memory with the USB3380 via a kernel module to a dump file. Then run Two reasons why the USB3380 is not supported. But it should work with the file approach. You just won't be able to edit live memory via the process file system, but otherwise it should work in read-only mode. |
|
I got some problem with kernel module. You know what could be the problem ? |
|
you need to dump the memory to the file before you can use it, running the dump command., in your case also when using the mount command against a file only specify the file in the device option, no need to specify kmd address too. also you specify the wrong kmd address, please read the output about the address where it's loaded. |
|
Run into same problem here http://prntscr.com/iuytu5 saying no kernel module. |
|
can you please run the identify command as it says in the printscreen you posted?
|
|
Sorry i though identify option don't work on usb3380. Still have kernel module problem http://prntscr.com/iv0omh && pid folder is empty. Sorry for bothering you. |
|
Can you please try to re-run your last command and also add the I believe you might possibly have tripped over a bug I fixed in the not yet released next version (I just want to confirm if that is the case). If thats the case I could send you a pre-release binary. |
|
D:\Users\Zibux\Desktop\pcileech-master\pcileech_files>pcileech.exe mount -device dumpmem1.raw -cr3 0x1ab000 -vv MOUNT: INFO: FILES folder not mounted. (No kernel module loaded). VmmProc: Unable to locate EPROCESS offsets.
|
|
yeah, it's the bug, can you please try the more recent dev version at: |
|
Tried dev version getting same stuff. On one dump file kernel error dispersed but folders still empty. D:\Users\Zibux\Desktop\newdevversion>pcileech.exe mount -device dumpmem1.raw -cr3 0x1ab000 -vv MOUNT: INFO: FILES folder not mounted. (No kernel module loaded). VmmProc: Unable to locate EPROCESS offsets. ===============================================================================
|
|
this is hard for me to look into here as-is, are you able to provide the memory dump somehow so that I may look into it and try to identify the problem? |
|
Where can i dm you google drive link ? Thanks for helping me out. |
|
@UlfFrisk at twitter or Telegram if you prefer it, alternatively drop and email to pcileech@frizk.net |
|
I sent dump to email. |
|
Thanks, I found some issues which I hope should now be resolved. If you can test You should be able to click into each process, and read the PML4/CR3 in the PML4 file. Or eaven easier if you wish to convert virtual memory to physical memory just write the virtual memory address into the file K:\proc\name<your_process>\virt2phys\virt Please let me know if this works or not, and if you have any additional questions or improvements suggestions. |
|
Works perfect! Thank you very much for help :) . |
|
hi @ufrisk how could i access/find pml4/cr3 for specific process? how can i scan for this? i know it is in the code someplace because you do it in dokan/mount system inside the file, but i need to do this without relying on mount. thx. |
|
Unfortunately that is not implemented outside the memory process file system (mount command) at the moment. It's quite complex to do this, but it may be possible for you to modify the code to do so without relying on the mount command. |
|
i've done this overnight :) nice simple c code, very readable over time. comments when needed, without many knowledge of sys internals i can make nice changes. in fact i recommend to keep it like it is, i think such feature would cause bloat, you would be adding them everywhere. people who need it can implement it when reading your code for only some hours. |
|
@ufrisk noticed bug. not difference between x64 and x86 peb scan so x86 process = bad/short module list. im fix and maybe push. |
|
not really a bug, but a lack of feature. the 32-bit PEB and modules parsing is missing for WoW64-processes (commonly known as 32-bit processes). Only the 64-bit part of those processes are parsed in the PEB and modules list. I haven't gotten around to add it, a pull req would be awesome :) if you decide to go ahead looking into it can you please parse the 32-bit PEB into the file win-peb32 (or something like that) and keep the 64-bit PEB around as-is? |
|
i did try to implement it in rush but now im gone for some days so couldn't make it, will work on it when back. had trouble finding the wow64 peb, should be 0x1000 behind/on front but wasn't. can i ask is wow64 peb using x64 structure still? surprise not much info about wow64 pebs |
|
64-bit peb is used for 64-bit ntdll, wowcpu and other 64-bit dlls, so I'd rather keep it as-is. The 64-bit stuff is used, when syscall is to be made the thread moves into 64-bit long mode and 64-bit ntdll before calling into kernel. I read somewhere that 32-bit peb is now randomized on latest win10, but I haven't done much research on it. |
|
so i think easy way is to create form of signature for 32-bit peb (since randomize like u say) but im not find it via typical method (both ntqueryinformationprocess and teb->peb). i thought that ntqueryinformationprocess->peb is x64 and teb->peb are the x86 but its not from test. any idea how to get 32-bit/x86/wow64 peb so i can create signature or investigate. |
|
teb->peb should get you the 32-bit one (in a test application) or did they change that one as well in recent builds? once you have the address of the 32-bit peb I suspect there should be a ptr somewhere pointing to it... I haven't really looked into this, it's been (and still is) on my todo list, I just have other things to look into first ... |
|
seem like it here. i think they change it again. any recommend for what pattern to search to fine 32-bit peb? if not no worry i will keep trying. |
|
@kdezz I'll probably push support for this to github some time next week or the week after that together with a few other new capabilities. It seems like the 32-bit PEB is located +/- 0x1000 from the 64-bit PEB depending on OS version. |
|
@kdezz I hope 32-bit process support (not operating system support) is working as it should now. Please let me know otherwise. |
|
It doesnt unfortunately :( |
|
This should be working and be resolved now. Closing issue. |
Is there any function in pcileech that could convert virtual address to physical? What did you do when you run into pointers and you need to read them ?
Saw you have funciton m_phys_to_virt but it is for linux right ?
Basically, im trying to read pointers that point to virtual address.
The text was updated successfully, but these errors were encountered: