ufrisk / pcileech-fpga

FPGA modules used together with the PCILeech Direct Memory Access (DMA) Attack Software
913 stars 206 forks source link

Screamer M.2 via Thunderbolt 3 #89

Closed VoxMi closed 2 years ago

VoxMi commented 3 years ago

First of all, I express my deep gratitude for your hard work! Below problem description.

Target Device: Intel Nuc Hades Canyon Target OS: Windows 10 (any build) Device: Screamer M.2 Device Firmware Version: 4.7 Connection Interface: Thunderbolt 3 Thunderbolt 3 Security Level: Legacy Mode VT-d State: Disabled TB3 <> PCIe x4 Controller: JHL6340 by Orico

Test results stage 1:

pcileech.exe -device fpga display -min 0x1000 img_1 pcileech.exe -device fpga display -min 0x2000 img_2 pcileech.exe -device fpga display -min 0xF000 img_3 pcileech.exe -device fpga display -min 0xFF000 img_4

After this error state the Screamer M.2 stops responding and hot reconnection sometimes leads to target system freeze.

Test results stage 2 after rebooting:

pcileech.exe -device fpga probe -max 0x2000 -vv img_6 pcileech.exe -device fpga probe -max 0xA0000 -vv img_7

Test results stage 3 after rebooting:

pcileech.exe dump -device fpga -min 0x1000 -max 0xF000 -out memdump.raw -v -force img_8

After this error the Screamer M.2 fails the tests stage 1/2 and hot reconnection sometimes leads to target system freeze:

img_9

Attempts to play with different parameters were unsuccessful. When connected directly to the PCIe bus (M.2 slot on the mother board inside Intel NUC), all tests pass successfully without any errors.

Respectfully!

ufrisk commented 3 years ago

Thunderbolt will stop working when reading from an invalid memory range; such as between 0xA0000-0xFFFFF. It's how it is and I haven't researched it closer.

The probe command is super aggressive and will disregard loaded memory maps. probe works really badly with Thunderbolt.

You can try to run pcileech with the -memmap option. You could either specify the memmap as a file or using auto.

i.e. pcileech.exe dump -memmap auto (if the target system is running Windows). Memmap auto starts the MemProcFS in the background to try to figure out the memory map. It may that a read happens outside an allowed range and TB3 will stop working. If that happens try the approach below:

or pcileech.exe dump -memmap your_memory_map_file.txt. Easiest way to get the memmap is to boot into Windows, run Dumpit and then MemProcFS towards the dump and copy the file: M:\sys\memory\physmemmap.txt

I have a Hades Canyon as well and you can try this memmap (it's 32GB in it tho; by the looks if it you have 16GB in yours) but you can try to adjust the max memory down 16GB; and I may have a different firmware version in mine (potentially different ranges).

physmemmap.txt:

   #         Base            Top
--------------------------------
0000         1000 -        57fff
0001        59000 -        9dfff
0002       100000 -       206fff
0003       20b000 -     35fbbfff
0004     35fbe000 -     3e707fff
0005     3f7fe000 -     3f7fefff
0006    100000000 -    8beffffff

But please try out the pcileech.exe -memmap auto first. I know it's not perfect; but the plan is to make it more stable in next MemProcFS version. Good thing is that my primary test system for this will be the Hades Canyon :)

Please let me know how it goes.

Paffo commented 3 years ago

Had the same problem and Ufrisk helped me fix, you indeed need the memmap, in my experience using Auto didn't work, but you can get it manually with RamMap (sysinternal) to obtain something like this unknown 1

Just write the memmap (or stay within those ranges for your reads).

ufrisk commented 2 years ago

I'm closing this due to old age. I hope the issue resolved itself. I've also, long over due, published a guide entry about this: https://github.com/ufrisk/LeechCore/wiki/Device_FPGA_AMD_Thunderbolt