Fastest way to read process memory

[behzad62]

While testing, I noticed reading a process memory using Kernel-Bridge is slower than a small driver I wrote.
I checked and it seems KB is mapping MDLs and then copies the memory. While all I need is using a Method_Out_Direct to get a kernel-address space buffer and attach to target process stack, Copy memory and detach.
I wonder if such a thing or something close is possible in KB?

[HoShiMin]

Sure, in the kb2 that still is in development I already improved read and write performance

[behzad62]

Sure, in the kb2 that still is in development I already improved read and write performance

Good to know, looking forward to it.
Meanwhile I tried to map my driver using KB and while it succeeds, I didn't have any luck communicating with it. CreateFile simply fails to open a handle to driver.

[behzad62]

Well I fixed the above issue. Now I wonder if calling NtUnloadDriver is enough to free the allocated kernel memory and un map the driver, else it would be nice if you implement this feature in kb2.

[HoShiMin]

But you should deallocate the allocated memory manually if your driver was manualmapped.
Nobody knows how to deallocate the memory properly.
And it is unsafe at all to unload a manualmapped driver.

[behzad62]

It seems, recent updates to windows prevents your signed driver to load. Well that makes mapping drivers using KB impossible anyway.

[romanholidaypancakes]

Sure, in the kb2 that still is in development I already improved read and write performance

hi, when will kb2 be released and will it support vthook?

[HoShiMin]

Sure, it will be open-source. But it is the very loooong project that I have been making for about ~2 years.
I didn't abandon it: it had two complete refactorings and now I divided it into two parts: the framework Ktl and the Kb itself that built on top of the Ktl.
So, I don't think it will be complete soon, but when it's ready - it will be open-source.

[HoShiMin]

Sure, it will be, I answered here: Fastest way to read process memory · Issue #37 · HoShiMin/Kernel-Bridge (github.com)09.04.2022, 04:04, "liwei1024" ***@***.***>: Sure, in the kb2 that still is in development I already improved read and write performance Will KB2 still open source —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[liwei1024]

当然，在仍在开发中的 kb2 中，我已经提高了读写性能

Can KB1 be updated first

[romanholidaypancakes]

Sure, it will be open-source. But it is the very loooong project that I have been making for about ~2 years. I didn't abandon it: it had two complete refactorings and now I divided it into two parts: the framework Ktl and the Kb itself that built on top of the Ktl. So, I don't think it will be complete soon, but when it's ready - it will be open-source.

hi, can we know something about the progress of kb2? thanks😀

[eaglesharkmayonnaise]

Sure, in the kb2 that still is in development I already improved read and write performance

Hi, how is the progress of kb2? Maybe we need a more compatible svm/vtx hook. Thanks

[HoShiMin]

@eaglesharkmayonnaise, @romanholidaypancakes

Hi here, guys! In fact, it's not abandoned as it looks like :D
For these years I tried several times: I began with Kb2, then it was transformed into the Ktl framework as a basis for the following Kb implementation.
But then I realized that it becomes more and more complicated - and... I dropped it and started with Rust instead.
Well, it was a useful experience to realize that Rust is completely - not! - totally inapplicable for kernel development as it have awfully incomplete and even broken and wrong bindings for WDK (in wdkmetadata and in windows-driver-rs as well).
And now (for ~3 weeks ago) I started the third incarnation of this framework.

So, yes, it's in development now - not totally from scratch as I copy some parts from early implementations, but with significant design reimplementation to be as simple as possible. And sooo... For know I can't say nothing other than it will be released... when it's done ;D

[eaglesharkmayonnaise]

I have tried Rust and attempted to make it interact with C/C++. This means that I would need to write a lot of unsafe code. Additionally, if I need to access the original C/C++ structures, I would have to create corresponding struct copies in Rust. If working in the kernel, it would likely require even more of the same repetitive work. Of course, it might be that I don't know enough about Rust.

[HoShiMin]

@eaglesharkmayonnaise, exactly!
In Rust, all we have is either Microsoft's metadata or bindgen. And both have critical issues like absent alignment for certain structures, absent defines (as bindgen doesn't support them), invalid constants due to ignoring of the target platform (in the metadata like IRQL values).
So that, you have to re-check every your step. Ah, that's bullshit.

So, I just dropped it too and started with C++ again.