ufrisk
commented
3 years ago It's good to see that PCILeech seems to be working.
When you try to read the notepad memory you're messing up virtual memory with physical memory.
Virtual memory is what processes on the CPU executes in. Your notepad address: 0x7ff7e3d70000 is a virtual address specific to notepad.
Virtual addresses are translated into physical addresses by the Memory Management Unit (MMU) on the CPU using Page Tables. The max physical address is: 0x86effffff according to the probe.
Please check out my MemProcFS, it should do what you want; i.e. translate physical memory into virtual memory in a virtual file system. It's Windows only though. Download MemProcFS; Install the Dokany virtual file system driver; Download the FTDI driver and run it with: MemProcFS.exe -device fpga https://github.com/ufrisk/MemProcFS
About the speed; even tho Linux have slightly lower read performance than Windows due to driver support what you're experiencing is just extremely slow. I suspect that you have a USB2 connection - i.e. a USB2 port on your computer; or the cable (or extension) being USB2 only.
But please test with the MemProcFS on Windows for this. Please let me know how it goes.
sec-hack-research
Hi,
first of all, thank you for your intensive work. It finally motivated me to invest some more time in DMA based attacks.
Here is the issue I am facing since a few days, and I am not sure if it is a bug or a (stupid) mistake that I've made. I hope one can help me with this.
Pre-work that I've done
Used Hardware
Screamer M.2 USB-C (R04) + JTAGSerial pack from Lambdaconcept.
Hardware setup
Software setup
Since I (so far) failed to compile pcileech on my own (still the missing FTDI driver I guess, simply did not have enough time for this so far), I am using the pre-compilled binary from your webste: PCILeech_files_and_binaries_v4.8-20210202.zip
Overall-Goal
To find out if everything is working as expected, I wanted to create an "easy" example and try to read out runtime memory of a specific process. I did choose "notepad.exe", where I've opened notepad and did enter "1112223334567890AAABBBCCCDEFGHIJK" as data. This "string" I would like to be able to read out via PCILeech.
Performed steps
(...some of them are for sure not following the most intelligent way - I'm still learning and open for any advices...)
Find out process ID of notepad
-> 6652
Use pmap (python-version of it) to find out memoryregions of notepad
(on Windows machine, obviously) D:\Python\PySysInternals>python pmap.py 6652 Address RSS Mode Mapping 0000x1e45e270000 804.0K r C:\Windows\System32\locale.nls 0000x1e45fb10000 24.0K r C:\Program Files\WindowsApps\Microsoft.LanguageExperiencePackde-DE19038.0.1.0 0000x1e45fc20000 104.0K r C:\Windows\SystemResources\notepad.exe.mun 0000x1e45fc70000 3.2M r C:\Windows\Globalization\Sorting\SortDefault.nls 0000x1e461d50000 18.4M r C:\Windows\Fonts\StaticCache.dat 0000x1e462fc0000 24.0K r C:\Windows\Registration\R000000000015.clb 0000x1e4630e0000 8.0K r C:\Windows\System32\oleaccrc.dll 0000x1e4639f0000 16.0K r C:\ProgramData\Microsoft\Windows\Caches\cversions.2.db 0000x1e463a00000 292.0K r C:\ProgramData\Microsoft\Windows\Caches{6AF...}. 0000x1e463a50000 16.0K r C:\ProgramData\Microsoft\Windows\Caches\cversions.2.db 0000x1e463a60000 624.0K r C:\ProgramData\Microsoft\Windows\Caches{DDF...}. 0000x1e463b00000 84.0K r C:\Program Files\WindowsApps\Microsoft.LanguageExperiencePackde-DE19038.0.1.0 0000x1e463b30000 92.0K r C:\Users\Dennis\AppData\Local\Microsoft\Windows\Caches{AFB...}. 000x7ff7e3d70000 4.0K r C:\Windows\System32\notepad.exe 000x7ff7e3d71000 148.0K xr C:\Windows\System32\notepad.exe 000x7ff7e3d96000 40.0K r C:\Windows\System32\notepad.exe 000x7ff7e3da0000 12.0K rw C:\Windows\System32\notepad.exe 000x7ff7e3da3000 20.0K r C:\Windows\System32\notepad.exe ...
So I've thought:
000x7ff7e3d70000 4.0K r C:\Windows\System32\notepad.exemight be of interest.Check if PCILeech actually works
On the attacker machine:
./pcileech probewith the result: [+] using FTDI device: 0403:601f (bus 1, device 92) [+] FTDIFTDI SuperSpeed-FIFO Bridge000000000001 Memory Map: START END #PAGES 0000000000000000 - 000000000009ffff 000000a0 00000000000c0000 - 000000008f7fffff 0008f740 0000000100000000 - 000000086effffff 0076f000
Current Action: Probing Memory Access Mode: Normal Progress: 34544 / 34544 (100%) Speed: 171 MB/s Address: 0x000000086F000000 Pages read: 8382432 / 8843264 (94%) Pages failed: 460832 (5%) Memory Probe: Completed.
Read memory content of notepad
Now begins my issue, where I've now read multiple documents on how Windows organizes his memory and how pmap actually shows the content. Sorry in advance, since for an expert, many things might be obvious - but I still need to learn a lot. Obviously, I can't read from
0x7ff7e3d70000, and I guessed PCILeech reads complete pages. Page-size seemed to be 4k (?).0x7ff7e3d70000 devided by 4000 -> 0x1FFDF8F5C
Display memory content:
./pcileech display -min 0x1FFDF8F5Cresulted in (and I hope the following text is not the memory content of my opened keepass..):
[+] using FTDI device: 0403:601f (bus 1, device 92) [+] FTDIFTDI SuperSpeed-FIFO Bridge000000000001 Memory Display: Contents for address: 0x00000001FFDF8000 0f50 c6 01 74 0b 48 8d 4c 24 40 ff 15 11 57 12 00 c7 ..t.H.L$@...W... 0f60 44 24 20 00 00 00 00 4c 8d 0d d2 f7 1d 00 4c 8d D$ ....L......L. 0f70 05 53 e0 1d 00 33 d2 48 8b cf e8 4c 77 0f 00 48 .S...3.H...Lw..H 0f80 85 c0 75 0e 48 8b d3 48 8b cf ff 15 40 56 12 00 ..u.H..H....@V.. 0f90 eb 0b 48 8b d0 48 8b cb e8 23 00 00 00 48 8b 4c ..H..H...#...H.L 0fa0 24 78 48 33 cc e8 b6 49 0f 00 4c 8d 9c 24 80 00 $xH3...I..L..$.. 0fb0 00 00 49 8b 5b 20 49 8b 73 28 49 8b e3 5f c3 cc ..I.[ I.s(I.... 0fc0 4c 8b dc 57 48 83 ec 70 49 c7 43 b0 fe ff ff ff L..WH..pI.C..... 0fd0 49 89 5b 18 49 89 73 20 48 8b 05 31 94 1d 00 48 I.[.I.s H..1...H 0fe0 33 c4 48 89 44 24 68 48 8b fa 48 8b d9 33 f6 89 3.H.D$hH..H..3.. 0ff0 74 24 24 48 3b d1 75 43 41 b9 68 14 00 00 4c 8d t$$H;.uCA.h...L. 1000 ef f5 fa 36 39 89 58 66 ba 0e 95 e9 7c 15 99 ae ...69.Xf....|... 1010 d3 59 e8 5c 98 02 db 5f f5 3c 8d 8e 73 01 2b dd .Y.....<..s.+. 1020 e8 df a1 6a 83 41 7a d1 0e 34 8a 7b b0 5c 0c 71 ...j.Az..4.{..q 1030 6d 17 3a c4 6e dc 22 f6 60 9d 18 ae c8 71 bd 1e m.:.n.".`....q.. 1040 c0 5e 37 c7 d5 d1 2d 9c 1c 17 c4 77 bc ea 78 ad .^7...-....w..x.
So I though, great, he seems to read memory content. To verify, I've also read
0x1FFDF9000, which resulted in different content.Dump memory to file
My logical next step was to try to dump the potentially interesting content to a file.
./pcileech dump -min 0x1FFDF8F5C -max 0x1FFDF8F68[+] using FTDI device: 0403:601f (bus 1, device 92) [+] FTDIFTDI SuperSpeed-FIFO Bridge000000000001 Memory Dump: Successful.
However, the resulting file is empty!
-rw-rw-r-- 1 user user 0 Feb 5 13:48 pcileech-1ffdf8f5c-1ffdf8f68-1210135-134857.raw-> Is this now a bug, or am I doing something wrong? <-
If I can "display" memory content, why can't I dump this to a file? Since with "display" I did see something, I also thought I do not have to inject any kernel-module to the target-system. A "full dump" seems to work, but it is quite slow and with my 32GB of RAM - produces quite big analysis files.
./pcileech dump[+] using FTDI device: 0403:601f (bus 1, device 92) [+] FTDIFTDI SuperSpeed-FIFO Bridge000000000001 Memory Dump: Initializing ... Done. Current Action: Dumping Memory Access Mode: Normal Progress: 34544 / 34544 (100%) Speed: 22 MB/s Address: 0x0000000100000000 Pages read: 8382368 / 8843264 (94%) Pages failed: 460896 (5%) Memory Dump: Successful.
-rw-rw-r-- 1 user user 34G Feb 5 15:51 pcileech-0-86f000000-1210135-152600.rawWhat am I doing wrong? Thanks for your time in advance!
Cheers, Dennis