@ -77,6 +77,7 @@ This repo should serve as a reference rather then working code, after all it is
# Project Info
### Patch Guard
This is an old project that tested many of my theoretical page table manipulation concepts. This project was created in part to find bugs/problems with my theories
and to be used as a reference for future projects. It was not ment to be used for anything else. From this project I have learned that PSKP (Process-Context Specific Kernel Patches)
is not page guard friendly. Patch guard does indeed check the kernel PML4E's to ensure they are pointing at valid PDPT's. Although triggering patchguard has never been
@ -84,29 +85,15 @@ done before personally. This leads me to my second patchguard related conclusion
all address spaces. Reguardless I have never been able to trip patchguard on these detections, I've ran this is code in a VM for over 48 hours doing a simple patch to
ntoskrnl.exe.
### Access Violations
Another note about PSKP is that when memory is allocated in the new PDPT, PD, and PT it is not being mapped into other processes kernel mappings. This means its possible
to crash the system by allocating memory, KeStackAttaching and then accessing that memory (since its not mapped into the process you KeStackAttached too). Any function
that uses KeStackAttachProcess can cause an access violation and thus a crash. MmCopyVirtualMemory allocates a pool and then calls KeStackAttachProcess. This was the
reason i manually walk the paging tables and map the physical memory into virtual memory.
### TLB And Pre-PTM Page Table Library
Since this project uses a very very old version of PTM, before PTM was every made, it uses a different technique to map physical memory into virtual memory.
The code in this project changes a PTE of a VirtualAlloc'ed page to point at another VirtualAlloc'ed pages PT. This allows the library to change the second
VirtualAlloc'ed pages PFN from usermode. If the original PFN is not restored before the program closes (and all virtual memory is unmapped), a crash will happen (PFN Corruption).
Also dealing with the TLB was a pain in the ass, the TLB was such an issue I created a new technique to get around it which is used in PTM. I generate new
virtual addresses on the fly now and ensure they are accessable.
### luna-1 (AMD)
Driver gets allocated inside of the kernel using a normal pool. The Nt headers of the driver are zero'ed. Communication with this driver happens via a process specific
syscall hook (meaning the hook cannot be seen in any other context). Detected on EAC, should be fine for BattlEye.
Since with PSKP MmCopyVirtualMemory can cause issues with memory not being present in one address space and is present in another, the page tables are manually walked
and the physical page is directly written too. This works well, all memory is writeable since page protections are bypassed.
### luna-1 (INTEL)
Driver gets allocated inside of the current process (not the kernel itself) and makes a process specific syscall hook to communicate (just like the AMD one). The AMD luna-1
also works for intel. This project is using a super old version of PSKDM which is not stable, its also using an old version of PTM and its using physmeme instead of VDM. Not sure if EAC is enumorating all processes PML4's yet, when they do this will be detected. Should be fine for BattlEye.
Since with PSKP MmCopyVirtualMemory can cause issues with memory not being present in one address space and is present in another, the page tables are manually walked
and the physical page is directly written too. This works well, all memory is writeable since page protections are bypassed.
_xeroxz
3 years ago