5.1Read the data bug

[DIXIN20]

5.0 Everything is normal. After replacing h, lib and dll of 5.1, it is normal to read a small amount of data. The data can't be read more than once, and then it can be read again a few minutes later. When it can't be read, the device can't be connected after closing the program

[ufrisk]

I made an optimization of the reads in leechcore.dll around that time. It may be what is causing your issues. I heard others had minor issues with it (nothing major like this though).

I could add a initialization/start-up option to it to make it perform the old way and maybe it will help. i.e. you'll have to add some extra info to the device fpga startup parameter (-device fpga://algo=4) would this be ok?

Note that the above is just a suggestion, it's not implemented yet.

[DIXIN20]

Sure, No problem

[ufrisk]

Can you please try this again to see if this is fixed in the update I published earlier on today.

1) Test it with default settings. Are you still experiencing this issue? 2) Test it with startup option -device fpga://algo=4 (this will revert it back to how it was done prior to v5.1).

[DIXIN20]

您能否再试一次，看看我今天早些时候发布的更新是否解决了这个问题。

1. 使用默认设置对其进行测试。您是否仍然遇到这个问题？
2. 使用启动选项对其进行测试-device fpga://algo=4（这会将其恢复到 v5.1 之前的状态）。

The problem still exists, using -device fpga://algo=4 can read normally

[ufrisk]

Thank you for confirming this. I'd need additional input from more users before I'm reverting this change though. The performance increase is quite substantial.

For now I believe your acute issue is resolved since you're able to use the new option.

I'll leave this issue open for a while to see if anyone else have issues.

[DIXIN20]

感谢您确认这一点。不过，在恢复此更改之前，我需要更多用户的额外输入。性能提升相当可观。

现在我相信您的尖锐问题已经解决，因为您可以使用新选项。

我会暂时搁置这个问题，看看是否还有其他人有问题。

It may involve VMMDLL_Scatter. When only one VMMDLL_Scatter_Initialize series command is used, the data can be read. After adding a VMMDLL_Scatter_Initialize, only the first group can read the data, and the data in the second group is messed up.

[ufrisk]

Thanks, I'll take a look 👍

[ufrisk]

I think I found the bug and hopefully it's now fixed. Can you please test that it is now working in the new version I just released?

Huge thanks for reporting this :)

[DIXIN20]

我想我发现了这个错误，希望它现在已经修复了。你能测试它现在在我刚刚发布的新版本中工作吗？

非常感谢您报告此事 :)

FPGA: TINY PCIe TLP algrithm auto-selected! LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000 LcMemMap_AddRange: 0000000000100000-00000004bfffffff -> 0000000000100000 LeechCore v2.14.1: Open Device: fpga [CORE] DTB located at: 00000000001ae000. MemoryModel: X64 [CORE] NTOS located at: fffff80130a00000 [INFODB] INIT: SUCCESS: va=0xfffff80130a00000 [SYMBOL] Initialization of debug symbol .pdb functionality completed [SYMBOL] [ srvC:\Users\Cain\Desktop\MemProcFS-master\files\Symbolshttps://msdl.microsoft.com/download/symbols ] [CORE] EPROCESS located at ffff888fe84bd080 [PROCESS] OK: FALSE [PROCESS] PID: 000 PPID: 000 STAT: 000 DTB: 000 DTBU: 000 NAME: 000 PEB: 000 [PROCESS] FLnk: 000 BLnk: 000 oMax: 000 SeAu: 000 VadR: 000 ObjT: 000 WoW: 000 [PROCESS] Unable to fuzz EPROCESS offsets - trying debug symbols [PROCESS] OK: TRUE [PROCESS] PID: 440 PPID: 540 STAT: 004 DTB: 028 DTBU: 388 NAME: 5a8 PEB: 550 [PROCESS] FLnk: 448 BLnk: 004 oMax: a40 SeAu: 5c0 VadR: 7d8 ObjT: 570 WoW: 580 [PROCESS] SYSTEM DTB: 00000000001ae000 EPROCESS: ffff888fe84bd080 [PROCESS] # STATE PID DTB EPROCESS PEB NAME [PROCESS] WARNING: PID '620' already exists or bad DTB [PROCESS] 0000 (skip) 0000026c 00048dcbe000 ffff888ff0b1a140 00b5684d9000 csrss.exe [PROCESS] WARNING: PID '612' already exists or bad DTB [PROCESS] 0001 (skip) 00000264 000482d1f000 ffff888ff0b15080 00ef0e843000 wininit.exe [PROCESS] 0002 (list) 000002d0 00048424a000 ffff888fefe26140 00d03ebcf000 csrss.exe [PROCESS] 0003 (list) 00000238 000482d6a000 ffff888feef770c0 00360c321000 smss.exe [PROCESS] 0004 (list) 000000ac 000000679000 ffff888fe854f080 000000000000 Registry [PROCESS] 0005 (list) 00000004 0000001ae000 ffff888fe84bd080 000000000000 System [CORE] Initialization Failed. Unable to walk EPROCESS. #5 VmmProc: Unable to auto-identify operating system for PROC file system mount. Specify PageDirectoryBase (DTB/CR3) in -cr3 option if value if known. [CORE] Failed to initialize.

PGA: TINY PCIe TLP algrithm auto-selected! LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000 LcMemMap_AddRange: 0000000000100000-00000004bfffffff -> 0000000000100000 LeechCore v2.14.1: Open Device: fpga [CORE] DTB located at: 00000000001ae000. MemoryModel: X64 [CORE] Initialization Failed. Unable to locate ntoskrnl.exe. #3 VmmProc: Unable to auto-identify operating system for PROC file system mount. Specify PageDirectoryBase (DTB/CR3) in -cr3 option if value if known. [CORE] Failed to initialize.

There is still a problem, without fpga://algo=4, can't use

[ufrisk]

are you using the leechcore.dll file from this release?

https://github.com/ufrisk/LeechCore/releases/download/v2.14/LeechCore_files_and_binaries_v2.14.1-win_x64-20221127.zip

[DIXIN20]

您正在使用leechcore.dll此版本中的文件吗？

https://github.com/ufrisk/LeechCore/releases/download/v2.14/LeechCore_files_and_binaries_v2.14.1-win_x64-20221127.zip

I am this version of the file

[ufrisk]

I'm closing this issue since it's a bit old. Also the issue seems to be "resolved" if you specify an algorithm (algo) so PCILeech/MemProcFS should be working for you.

I quite don't understand why some target systems have this behavior whilst others do not. I can't really backtrack on my changes and change the defaults though since they come with large performance gains for the absolute majority of the users.

Sometimes also this may be related to custom firmwares of the device. Anyway I wish you the best with your DMA attacks (even if you may have to resolve to use the algo=4).