memflow-pcileech vmware / remote implementation

[cr7pt0pl4gu3]

I have the following code from example:

My Win10 VM is open, MemProcFS can read from it:

However, the example does not work:

Is there anything I can do to fix this and achieve fast live memory reads/writes or is it currently a technical issue?
I'm very new to this and it would be great if you could tell if I'm doing something wrong or is it actually not working right now? :D

[ko1N]

Hey there, better place for this issue would be memflow-pcileech project. Anyways, does leechcore require to set the device argument to "vmware://" or is "vmware" sufficient? I personally haven't tried anything besides FPGA yet.

[cr7pt0pl4gu3]

Both are fine I think (vmware:// and vmware), this for example works fine:

[ko1N]

Device is straight put into LC_CONFIG:
https://github.com/memflow/memflow-pcileech/blob/main/memflow-pcileech/src/lib.rs#L38

Does it need anything else being setup apart from running as admin?

[cr7pt0pl4gu3]

Don't think so

[ko1N]

I couldnt see any additional steps that memprocfs is doing to initialize leechcore, but there probably is something i overlooked. Otherwise im kinda out of ideas right now, will have to test this on my setup at one point.

[cr7pt0pl4gu3]

Also wanted to ask, is it currently possible to dump memory remotely, e.g. using pcileech -remote? (LC_CONFIG.szRemote)

[cr7pt0pl4gu3]

Oh I see, is support for it planned anytime soon?

https://github.com/memflow/memflow-pcileech/blob/3febc1b6a76f0f17fcdc70836c1d48051565b3e9/memflow-pcileech/src/lib.rs

[ko1N]

No one used them before but it should be quite straight forward to add those parameters, do you have an example on how they would be set? I Assume remote and remoteDisableCompress are bools and szRemote is just a string that we should pass through?

[cr7pt0pl4gu3]

Not sure how they're set in the code specifically, this is what I was using:
.\MemProcFS.exe -device PMEM://C:\winpmem_64.sys -remote rpc://insecure:computername.local

[cr7pt0pl4gu3]

https://github.com/ufrisk/MemProcFS/blob/ba8dd59afe2edcce64801ec976c92b2e2973d94f/includes/leechcore.h

[ko1N]

It seems to only require szRemote to be set:
https://github.com/ufrisk/MemProcFS/blob/f1abe87dc2411fc6c097e4a97a8dd94edb6a8e52/vmm/vmmdll_core.c#L604

I gave it a shot and added a remote parameter that you should be able to set now. Do you mind giving it a shot? You can find it on the latest commit on the main branch.

[cr7pt0pl4gu3]

Sure, I'll give it a shot tomorrow (actually, today since it's 2:34 AM for me). Thank you so much! 😄

[cr7pt0pl4gu3]

Can't seem to make it work :(
Pretty new to Rust as well, and with no documentation (that I could find) on how to pass args there I'm stuck 😞.


Probably just passing them wrong

[ko1N]

I noticed yesterday that more complex argument formatting will confuse our argument parser. For the time being you can parse it manually like so:

let args = ConnectorArgs::new(None, "device=pmem,remote=\"rpc://insecuret:hp\"".parse().unwrap(), None);

I also added new test cases here:
9291305#diff-47b7e5a3ad9ec55ac75b25991ae1fe1d633f4769f02c40200d91cba3d46c1d27R396

So i can fix them up. Ideally the : syntax should probably go away but i havent decided upon that yet. Hope this helps for now, sorry for the inconvenience.

[cr7pt0pl4gu3]

Had some issues with ConnectorArgs struct, debugged it a bit, if anyone comes by, the solution is to use this memflow version (because those structs are different between stable and beta as of now):

Thank you so much again, I can confirm it is working, or at least it's using the library to connect to the remote PC successfully:

[cr7pt0pl4gu3]

You can close this issue if you want to, or use it to track vmware integration in the future if you'd want to add it 😄
Renaming to vmware/remote issues would be helpful since this thread ended on a different topic xD!

[ko1N]

I updated the title but would like to keep this open until the original issues are resolved (and arg parsing works fine).

[cr7pt0pl4gu3]

Could you please advise if that's a bug or am I doing something wrong? Looks like the integration with memflow-win32
is broken?

[cr7pt0pl4gu3]

Again, had to use the "0.2.0-beta9" version for memflow-win32 crate, this fixed my issue, although API is different, maybe there's a documentation to it already?

[cr7pt0pl4gu3]

I also can't seem to find a way to find process info by process name, only for ntoskrnl, meaning the following example doesn't work:

[cr7pt0pl4gu3]

Can't find process_info_list() as well

[emesare]

Can't find process_info_list() as well

I also can't seem to find a way to find process info by process name

With version 0.2 of memflow all os implementations are generic over the base traits found in the memflow repository (Os, Process).

You should be able to find the methods, it could be that you are not including those traits in your source file and intellij-rust cannot find the traits, could you share code?

It would be advised to use the memflow applied videos as a loose reference as they have not been updated/corrected for 0.2, however they still provide good general information that carries over.

@h33p might update the videos for 0.2 (once the release has been stabilized), I don't know.

[cr7pt0pl4gu3]

Thank you so much @dankope, I didn't include the trait, fixed my issue

[ko1N]

I noticed yesterday that more complex argument formatting will confuse our argument parser. For the time being you can parse it manually like so:

let args = ConnectorArgs::new(None, "device=pmem,remote=\"rpc://insecuret:hp\"".parse().unwrap(), None);

I also added new test cases here: 9291305#diff-47b7e5a3ad9ec55ac75b25991ae1fe1d633f4769f02c40200d91cba3d46c1d27R396

So i can fix them up. Ideally the : syntax should probably go away but i havent decided upon that yet. Hope this helps for now, sorry for the inconvenience.

So this parser confusion is now fixed on the next branch and will be released in 0.2.0-beta10 somewhat soon. You should be able to put in the arguments in the format you "expect" with this update :)