Initializing virtual file system takes ages via API

[Dopepigeon]

Hey, I encountered some weird behavior using the c API to access the virtual file system. I first call VMMDLL_InitializePlugins and then read \misc\procinfo\progress_percent.txt until it's 100%. The Problem is that it takes almost 5 Minutest to finish, while using MemProcFs.exe and mounting the File System including going up to 100% takes around 30 Seconds. Any clue why that can happen?

Thanks in advance!

[Akandesh]

I've compiled a program which does the following:

1. Calls VMMDLL_Initialize with "-device fpga -waitinitialize -vv"
2. Runs VMMDLL_InitializePlugins
3. Queries "\misc\procinfo\progress_percent.txt" in a while loop

Then I sent it to Dope and it was as slow as he described but when I run it on my system it's fairly quick. Takes less than 20 seconds.

[ufrisk]

can you test: pcileech.exe dump -out none -device fpga -v -min 0x100000000 -max 0x200000000 and report back what speed you're getting. Your issue seems to be most consistent with degraded USB2 speeeds, which is why I'd like for you to run the above test.

[Dopepigeon]

can you test: pcileech.exe dump -out none -device fpga -v -min 0x100000000 -max 0x200000000 and report back what speed you're getting. Your issue seems to be most consistent with degraded USB2 speeeds, which is why I'd like for you to run the above test.

I get 170-200mb/s

[ufrisk]

Then I don't have a clear explanation about your issue.

I know the current generation of the file is very slow, but it should be in the tune of 20-60 seconds as described above. It should not take 5 minutes.

I could probably vastly improve generation times of that file, but there haven't really been any need for it and there is quite a bit of work involved.

How much memory do you have in your system?

[Dopepigeon]

Then I don't have a clear explanation about your issue.

I know the current generation of the file is very slow, but it should be in the tune of 20-60 seconds as described above. It should not take 5 minutes.

I could probably vastly improve generation times of that file, but there haven't really been any need for it and there is quite a bit of work involved.

How much memory do you have in your system?

The target system has 64gb. Attacker has 16. The weird thing is that using the MemProcFS.exe to mount the file system and fully load procinfo takes 30 seconds, and not 5 minutes as well. That's what I don't understand, how can that be faster compared to a direct API call that does not even mount the file system.

[Dopepigeon]

Just tried it again after a while. API call initialization gets stuck at 0%. MemProcFS.exe is still working, tho it did throw some plugin message that was not there before.

Even after restarting both systems multiple times, it continues to be stuck at 0%. 

C:\Users\Research\Desktop\Dma\MemProc\plugins\pyp_reg_root_reg$usbusb$storage.py:28: SyntaxWarning: invalid escape sequence '\V' vidpid = vidpid.replace('USB\VID', 'VID=').replace('&PID_', ', PID=').replace('\', ', SN=')

[Dopepigeon]

Update: Removing one ram stick, so downgrading to 32gb, made it work again. Tho it is still very slow. I also tried different hardware on the attacker side, same slow speed. It must have something to do with the Target System. But that wont explain why MemProcFs.exe itself is so fast and never failing.

[ufrisk]

Removing one RAM stick to half the memory would cut the time in half.

Still, there is an error in your programming somehow if the MemProcFS file system works fine-ish but your program is not. I know there must be a Sleep in the loop that checks the progress for it to work properly for some reason.

The other error you posted in the post above is not related.

[Dopepigeon]

I did add a sleep, no change. Here is my code. Even with half the memory it tages 5 minutes

if (!VMMDLL_InitializePlugins(DmaHelper::hVMM)) {
    std::cout << ("[-] Failed VMMDLL_InitializePlugins call\n") << std::endl;
    return false;
}

ConsoleProgressBar progressBar(100, 70);

while (true) {
    BYTE bytes[4] = { 0 };
    DWORD i = 0;
    auto nt = VMMDLL_VfsReadW(DmaHelper::hVMM, (LPWSTR)L"\\misc\\procinfo\\progress_percent.txt", bytes, 3, &i, 0);

    progressBar.setProgress(atoi((LPSTR)bytes));

    if (nt == VMMDLL_STATUS_SUCCESS && atoi((LPSTR)bytes) == 100)
        break;

    Sleep(2000);
}

[ufrisk]

it looks alright to me, have you tried the example at: https://github.com/ufrisk/MemProcFS/blob/e1893e895c18dfc1c67a5b5487805cd5d46d6c93/vmm_example/vmmdll_example.c#L1548

[Dopepigeon]

it looks alright to me, have you tried the example at:

https://github.com/ufrisk/MemProcFS/blob/e1893e895c18dfc1c67a5b5487805cd5d46d6c93/vmm_example/vmmdll_example.c#L1548

Yes same problem.

[Dopepigeon]

Very weird, so it was stuck again at 0%. And I was thinking, it's around the same time as yesterday 00:00-00:30, so I changed the timezone on the target. And magically it worked again, slow, but it worked. Very weird behavior, switching time zone back to normal did not hinder it to keep working.

I will check tomorrow if I can reproduce it.

[Dopepigeon]

Very weird, so it was stuck again at 0%. And I was thinking, it's around the same time as yesterday 00:00-00:30, so I changed the timezone on the target. And magically it worked again, slow, but it worked. Very weird behavior, switching time zone back to normal did not hinder it to keep working.

I will check tomorrow if I can reproduce it.

I was not able to reproduce it sadly.

Seems like I can get it fixed by adding the info sqlite database file to the working directory. Still painfully slow tho

[ufrisk]

it's good to add all the files from the latest binary release to your current directory, including files like symsrv.dll and dbghelp.dll and info.db.

[ufrisk]

I'm closing this issue since I assume its resolved (since I haven't heard anything here).

Also, I'd probably be able to pull off a 30-50% speed increase on this function some time in a future release.

It's probably going to be a good bit into next year since this isn't really a prioritized feature right now.

Anyway, if it's still not working let me know.