From 3420f16feaa9d9920f39c8109caf688d2ab4ea14 Mon Sep 17 00:00:00 2001 From: _xeroxz Date: Tue, 20 Oct 2020 08:08:44 +0000 Subject: [PATCH] Update README.md --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index f6215fc..7acf49f 100644 --- a/README.md +++ b/README.md @@ -21,6 +21,9 @@ have execution in CPL0. If there are any issues with the code make an issue (pos ### What? nasa-mapper is like every other driver mapper except the driver is not mapped into the kernel, only specific contexts/processes you decide to map the driver into. +There are limitations to this driver mapper. Firstly your driver is not going to be globally mapped. Its only going to be accessable from inside of your context. +You can still call kernel functions, but you cannot switch contexts. In other words do not call `KeStackAttachProcess` directly. You can call MmCopyVirtualMemory though +since the context switch will happen inside of `ntoskrnl` which is globally mapped. ### How? @@ -33,6 +36,8 @@ processes pointing at the allocated driver in the runtimebroker, thus mapping th Keeping your driver out of the kernels paging tables. Most driver mappers map a driver into a kernel pool (ExAllocatePool). Physmeme, Kdmapper, Drvmapper, all do this, its easily detected and easy to dump. This keeps your driver inside of your context :) +I guess you can call this physmeme v2? You can use any driver that exposes physical memory read/write with this driver mapper, simply replace the vulnerable driver inside of raw_driver.hpp. + # Spectre Please disable spectre/meltdown when using nasa-tables/nasa-patch/nasa-mapper. You can download a program to disable spectre/meltdown [here](https://www.grc.com/inspectre.htm). \ No newline at end of file