ufrisk / MemProcFS

MemProcFS
GNU Affero General Public License v3.0
3.04k stars 372 forks source link

U #173

Closed fortnitebott closed 1 year ago

fortnitebott commented 1 year ago

U

ufrisk commented 1 year ago

That module is available as a file system module for the MemProcFS virtual file system. It's not directly accessible via an API function.

1) You can either mount the memory using MemProcFS.exe and then observe the module behavior (it takes a short while to render) and then open the file system file in C++. It's located at: M:\misc\procinfo\

2) You may use the VMMDLL file system API. This way you don't have to install the file system driver and mount it as a drive. First you'd need to initialize plugins (only once) with VMMDLL_InitializePlugins() then list files (and their sizes) with VMMDLL_VfsListU() and read files with VMMDLL_VfsReadU() The file will to read in this case would be named \misc\procinfo\dtb.txt.

ufrisk commented 1 year ago

what does progress_percent.txt say? it takes a short time to complete processing before results show up.

ufrisk commented 1 year ago

Did you resolve this? i.e. wait until the progress_percent.txt got to 100%?

ufrisk commented 1 year ago

@unemknip it will start processing on the first access of one of these files.

After that you'd need to Sleep some substantial amount of time, like at least 100ms and try reading again. Processing should take like 10-30 seconds if things go well. And you should be able to monitor the progress by reading progress_percent.txt. The Sleep is very important.

Also reading may also return VMMDLL_STATUS_END_OF_FILE sometimes on success so you'd need to check for that as well.

I should probably add an example to this for this particular file in the vmm examples.

ufrisk commented 1 year ago

@unemknip I'm glad to see the issue is resolved, and thanks for the update :) Hopefully the DTB module will be of use. I'll publish an example about how to do this in the example project in the next release as well.

ufrisk commented 1 year ago

And I've updated the example file at: https://github.com/ufrisk/MemProcFS/blob/0d535cc28dc132ecda475d328216319c6fae4029/vmm_example/vmmdll_example.c#L1428

The key when using this from the API seems to be doing some Sleep after the first read, otherwise the separate processing thread doesn't seem to start. Dunno why this is, but it's not an issue if you know about it I guess.

I'm closing this issue since it's now (hopefully) resolved.

Please let me know if there should be any lingering issues around this.

FocuzJS commented 1 year ago

@ufrisk In case you were wondering this code helps them locate the DTB on EasyAntiCheat after it's been relocated due to the new physical page being marked as a System PTE still. 🤣 Was crazy to see you committed this code the exact day I wrote something similar.

ufrisk commented 1 year ago

oh, that was it was about, it would explain quite a few things. thought it was some kind of new malware (in a sense I guess you can call it that, and it's probably just a matter of time before it's used for that as well)... but why the sudden interest in this? This was something I added way back.

FocuzJS commented 1 year ago

I imagine they just searched your repositories for "DTB" and stumbled on this working solution to their problems. Not sure how much you know about the actual thing they are trying to defeat but you can read some technical details about it here: https://www.unknowncheats.me/forum/anti-cheat-bypass/561736-analyzing-easyanticheats-cr3-protection.html essentially they are using some infinity hook esque technique to hook exceptions in the kernel globally, then they proceed to overwrite the DirectoryTableBase of the KPROCESS they are protecting to something that will trigger exceptions whenever the system tries to load it into CR3 and from their hook they set the correct one. Initially you fixed this by adding a validation to the DTB so that if memprocfs was started before the anticheat applied their protection, the invalid DTB would no longer break memprocfs's cache. To address this (and for other reasons too) they somehow furthered the solution by reserving a new home for the PML4 entry at a new physical address. However as you can imagine this is wildly unsupported by Microsoft and I assume to try and stay compatible and not have to catch more exceptions (just my assumption), the new physical address is marked as a System PTE in the PfnDatabase. That's why your code is able to locate the correct DTB and also why you've recently also been asked to add support for the VMMDLL_OPT_PROCESS_DTB ConfigSet option. Hope this transparency helps you in some way. Thanks again for all the work you've put into these repositories; there's really some amazing code in here.

FocuzJS commented 1 year ago

I imagined correctly as he is now trying to make it harder for people to discover this issue that he needed help with to begin with🤣