TB3 Unable to DMA about memprocfs HOT 25 CLOSED

Not really unfortunately. Microsoft has put a lot of work into thunderbolt security recently though.

The wifi slot (M.2 Key A+E) may be an option as well; even though it's not as convenient as thunderbolt would be. Something like this may work (together with the PCIe to M2 Key M adapter). https://www.aliexpress.com/item/4000203013065.html

from memprocfs.

Not really unfortunately. Microsoft has put a lot of work into thunderbolt security recently though.

The wifi slot (M.2 Key A+E) may be an option as well; even though it's not as convenient as thunderbolt would be. Something like this may work (together with the PCIe to M2 Key M adapter). https://www.aliexpress.com/item/4000203013065.html

To exclude it being a Windows issue i tried in Ubuntu and debian as well, same result.
Today i disassembled the laptop and connected the screamer directly where the SSD was, loaded into bios and i get successful reads in BIOS with Probe command.
However TB3 doesn't read in BIOS either, which makes me think its either a problem with Thunderbolt Adapter or with the Thunderbolt Controller my machine uses.
If i recall correctly you tested TB3 in past, do you remember which adapter you used? Im using one for eGPUs so it should have had worked, but it might be defective for all i know, i dont have other M2 devices to test it with.

from memprocfs.

I have used the Sonnet EchoExpress Pro TB2 to ExpressCard way in the past; together with an Apple TB3 to TB2 adapter.

Also some random "Alpine Ridge" (also quite old now) TB3 to PCIe adapter from AliExpress.

from memprocfs.

Hi, small update.
By literally changing random BIOS Settings out of despair, something changed, almost like a miracle, the screamer now can read memory, however it Always (tested multiple settings, tested both bios, EFI bootloader and in OS) stops at 323277 Pages Read, all the following just fail read, other than that, it only does it once, if i try to start a second read, it fails.
It makes me think that for some reason, after the 323277th page, the device disconnects, in fact no suceeding read is possible without unplugging it and replugging.

Do you have any suggestion on what might be the cause?

from memprocfs.

do you mean 323277 pages or 0x323277 pages?

if 323277 pages I don't have an explanation, if you mean 0x323277 pages it's probably since you're trying to read PCIe config space and memory mapped devices which are located in that range up to 4GB - and some systems stop responding when doing that.

Solution is that if you're running Windows on your target, start MemProcFS.exe -device fpga and copy the file: M:\sysinfo\memmap\physmemmap.txt

specify this physmemmap in subsequent calls to pcileech/memprocfs to avoid reading problematic memory regions; i.e.
MemProcFS.exe -device fpga -memmap c:\temp\physmemmap.txt
or
pcileech.exe -device fpga -memmap c:\temp\physmemmap.txt dump

from memprocfs.

I see I miscalculated the page numbers in the answer above, but I suspect it's the same issue and that the memmap will resolve the issue.

from memprocfs.

Thanks for the fast reply.
forgot to mention above that the 323277 is the number of pages read when running pcileech probe.
Pages Read stops at 323277 / 4849665, and from there all the rest are Pages Failed.
This happens not only when target is in windows, happens when target it's in BIOS as well.
Moreover, after this "interruption" the screamer will fail any read unless disconnected and reconnected from target, after which again it will only read that limited ammount.

from memprocfs.

yes, but try the memory map functionality if you're able to start MemProcFS, it's most probably just a physical memory range that you need to exclude.

Another way to retrieve the memory map if it's not working with pcileech at all would be to run dumpit.exe and then run the MemProcFS on the memory dump file.

from memprocfs.

Sadly i can't do that as i need live memory editing, hence the Screamer.
I will try on another machine, newer and see if the problem it's the same.
I still suspect that the issue is the adapter im using, but the reseller is refusing to refund without a video of me trying it with a GPU, which i do not have available at the moment...

from memprocfs.

Hello Ufrisk,
i have an update: a new adapter came which mounts a newer TB3 Controller.
It's faster to generally connect, but the issue was the same.
Excluded then that the issue was hardware, i spent restless nights trying various configurations in the BIOS (i have access to the debug bios for my computer) but nothing seemed to work.
In the end, being the idiot i am, i thought of what would have happened if i scanned the memory backwards, so i took the last range of physical memory and probed it, resulting in a flawless reading. I tried multiple times, and it worked consistently.
I was going back and back, and noticed (i have 16GB RAM total) that i can flawlessly read 15 of them, starting from the end.
I downloaded RamMap (sysinternal) and checked the Physical Ranges and noticed that they perfectly match the readable addresses:
Image

Reading the ranges specified there will work without issues, trying to read outside will crash the screamer, the thunderbolt driver (i guess) in my computer, and for some reason the Ethernet connection will stop working too, only rebooting will solve.

Do you perhaps have ANY idea of why this happens?
(Note that this happens only via TB3, using the Screamer internally via M2 will scan the whole memory without issues).
It's not Windows Protection features, as the exact same behavior it's in the BIOS.

Most importantly, without having access to the target Win OS (can't run any program on it) is there a way to still parse the virtual address space of a process despite this behavior?

Many thanks for your help and support.

EDIT:
Actually, sorry for the issue being here, i realized i use much more the VMMDLL API than MemProc itself.

from memprocfs.

Good that you got it to work. You may save this memory map to a file, please see the physmemmap.txt in the example here https://github.com/ufrisk/MemProcFS/wiki/FS_SysInfo_Memory for the format.

you may then supply this memory map file as a parameter to MemProcFS and it will avoid reading outside those ranges; i.e. MemProcFS.exe -device fpga -memmap physmemmap.txt

This is how things are on some computers unfortunately; it's not something I can do about it; it was one of the reasons why I introduced the memory map capability a while back as a workaround.

But if you specify the memmap things should work fine (hopefully) and you'll be able to read the virtual memory of your processes without any issues.

Good Luck :)

from memprocfs.

Hi,
sorry for the further bothering, i tried reproducing the syntax in the picture but PCILeech just has no output (unless very verbose) while MemProcFS just crashes the Screamer as if it's reading outside of the bounds.
Do you have an example of proper syntax for the memmap.txt file?
What i tried was:

0000 1000 - 9f000
0001 100000 - 4ec0e000
0002 .... and so on

I tried with both spaces or tabs as separators, i tried with and without 0x prefix, with and without preceeding zeroes.
I tried putting everything in C:/ instead of desktop to shorten the path.

Upon running PCILeech with -vv, the only lines after the initialization are:

LcMemMap_AddRange: 0000000000000000 - 000000000009ffff -> 0000000000000000
LcMemMap_AddRange: 0000000000100000 - 00000001f0000fff -> 0000000000100000 
LeechCore v2.1.5: Open Device: fpga

after which, no further output appears, after 2-3 seconds it closes.

from memprocfs.

sample memmap file:

0000         1000 -        8ffff
0001       100000 -     1fffffff
0002     20200000 -     40003fff
0003     40005000 -     ced22fff
0004     cef25000 -     d6a09fff
0005     dafff000 -     daffffff
0006    100000000 -    21e5fffff

syntax for use:

• pcileech.exe kmdload -kmd win10_x64_3 -v -vv -device fpga -memmap physmemmap.txt
• memprocfs.exe -device fpga -memmap physmemmap.txt

does it work at all?

from memprocfs.

With MemProcFS it still tells me it cannot identify OS and asks me for the DTB and crashes the screamer.
With PCILeech same as before, command give no output.

by dumping the "good" sectors i can see strings in clear, so it does read the memory correctly, its just ignoring the map (i guess?)

from memprocfs.

I saw this in your earlier debug outputs; Successfully loaded LeechCore v1.7.0 Device 3

that version is very old and does not support memmap and such.

can you please download the most recent binary distribution of PCILeech with all dependencies and try again?

https://github.com/ufrisk/pcileech/releases/tag/v4.7

from memprocfs.

i am using the 4.7, in fact in yesterday's log it said LeechCore v2.1.5,
As side note, i just tried running:
pcileech -device fpga patch -sig unlock_win10x64.sig -min 0x100000000 -max 0x4ae000000

and it did in fact successfully patched, unlocking the OS without the need of the password,
meaning that reads and writes are successful, but i can't get it to stay in the bounds specified with -memmap

from memprocfs.

Can you please try the most recent one; it's going to be LeechCore v2.2. It's not going to make any difference with the memmap unfortunately which I just don't understand why it's not working for you (but it does for me); but if really lucky it may fix your crash since I fixed a crash issue in it just the other day.

If that's not working this is a hard problem to solve like this. There will be some need for debugging and I'm unable to replicate the issue on one thunderbolt computer I have; but I'll check on another this weekend as well. But if that's not working this will need to be looked into either with visual studio or remote debugger :\

from memprocfs.

Found something:
by mistake i loaded your sample map instead of mine, and it DID this time stay in the bounds of the map (although wrong).
I checked the difference between your sample an my map, the only i could see is that in yours, all addresses ends with F, in mine with 0.
So i changed:

0000         1000 -     9f000
0001       100000 -     36d97000
0002     10000000 -     4ec0e000
0003     37697000 -     4d8ae000
0004     4ec0e000 -     4ec0f000
0005    100000000 -     4ae000000

into:

0000         1000 -     9ffff
0001       100000 -     36d97fff
0002     10000000 -     4ec0efff
0003     37697000 -     4d8aefff
0004     4ec0e000 -     4ec0ffff
0005    100000000 -     4aeffffff

And it correctly loaded the map, but doing so i go out of bound.
I tried changing it to:

0000         1000 -     8ffff
0001       100000 -     36d96fff
0002     10000000 -     4ec0dfff
0003     37697000 -     4d8adfff
0005    100000000 -     4adffffff

But it will start again the original problem:

LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000
LcMemMap_AddRange: 0000000000100000-00000004a0000fff -> 0000000000100000
LeechCore v2.2.1: Open Device: fpga
LcMemMap_AddRange: 0000000000001000-000000000009efff -> 0000000000001000
LcMemMap_AddRange: 0000000000100000-0000000036d96fff -> 0000000000100000
LcMemMap_AddRange: 0000000037697000-000000004d8adfff -> 0000000037697000
LcMemMap_AddRange: 0000000100000000-00000004adffffff -> 0000000100000000
 Memory Map:
 START              END               #PAGES
 0000000000013000 - 000000000009ffff  0000008d
 00000000000c0000 - 000000004eefffff  0004ee40
 00000000000c0000 - 000000004eefffff  0004ee40

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       12064 / 19168 (62%)
 Speed:          377 MB/s
 Address:        0x00000002F2000000
 Pages read:     323277 / 4907008 (6%)
 Pages failed:   2765107 (56%) // And so on.

and upon reaching Page 323277 the screamer disconnects, my Ethernet connection dies and the thunderbolt port is unresponsive until reboot.

I really appreciated you wanting to help me and im willing to try anything.
It was such a smooth ride via PCIe, i can't understand why Thunderbolt is being so much of a pain.

from memprocfs.

probe does not use the memory map. could you please try dump instead?

from memprocfs.

pcileech -device fpga -memmap map.txt dump -vv

LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000
LcMemMap_AddRange: 0000000000100000-00000004a0000fff -> 0000000000100000
LeechCore v2.2.1: Open Device: fpga
LcMemMap_AddRange: 0000000000001000-000000000009efff -> 0000000000001000
LcMemMap_AddRange: 0000000000100000-0000000036d96fff -> 0000000000100000
LcMemMap_AddRange: 0000000037697000-000000004d8adfff -> 0000000037697000
LcMemMap_AddRange: 0000000100000000-00000004adffffff -> 0000000100000000
Memory Dump: Initializing ... Done.
 Current Action: Dumping Memory
 Access Mode:    Normal
 Progress:       208 / 19168 (1%)
 Speed:          2 MB/s
 Address:        0x000000010D000000
 Pages read:     0 / 4907008 (0%)
 Pages failed:   53248 (1%)

It does add the Ranges, but won't dump.
Also tried using the "corrected" map with MemProcFS, it will still give the DTB error and crash the screamer.

from memprocfs.

I located an issue with the memory auto-detect algorithm running even tho a memory map is specified; that causes some out of range reads at the very top of memory. when doing that thunderbolt stops working on my NUC test system; even tho the computer isn't crashing.

I'll fix this tomorrow; I'm hopeful it will resolve your issues as well. Will let you know when I published the update.

from memprocfs.

updated the binary packages right now; is it working better if you run it with the memmap over thunderbolt now?

from memprocfs.

Hi,
i still haven't tested it extensively, but it does indeed mount now, and by editing the memory of a process, the changes actually write correctly.

I will try to run some simulations and come back to you, in the mean time, Many thanks for your help!

from memprocfs.

Thanks for the update; it's good to see that the initial results are promising; looking forward to the more detailed result :)

from memprocfs.

I'm closing the issue since it seems it's been resolved. Best wishes for your DMA project.

from memprocfs.