Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improving execution performance and possibly stability #2

Open
m0rethan3 opened this issue Aug 15, 2021 · 7 comments
Open

improving execution performance and possibly stability #2

m0rethan3 opened this issue Aug 15, 2021 · 7 comments

Comments

@m0rethan3
Copy link

thx for taking attention on my previous issue
also you can just look at NtUserCreateWindowStation function kernel implementation for example (or any other that match rule i described next) and you probably notice that actually to hook it you need to swap just one pointer
i think that this hook should be PatchGuard free as well cuz pointer resides in .data RW section
and to not make multiple syscall calls in usermode e.g. to disable smep or KeSetSystemAffinityThread call you can craft shellcode one time and patch it to function addresses or data that you need to make capcom-like execution faster and physmem loaded driver free

and also last advice: easy virtual to physical address translation example using physmem vulnerable driver - https://github.com/zx0CF1/physmem_drivers/blob/master/huawei_PoC/phymem.cpp#L66

@m0rethan3
Copy link
Author

oh and you can just patch vulnerable driver itself to not mess with windows kernel images and probably PatchGuard cases

@m0rethan3
Copy link
Author

m0rethan3 commented Aug 15, 2021

and forgot to say, according to this blog post https://blog.can.ac/2018/04/28/escape-smep-exploiting-capcom-safely/ actually you don’t need to disable interrupts because some NT kernel routines may not work at all

@kkent030315
Copy link
Owner

We do not need such a nanosecond-level performance.

@m0rethan3
Copy link
Author

ye i know but you anyway can patch that vulnerable driver (just need to find some ioctl that you don’t use) instead of ntoskrnl syscall and replace all physmem scanning with virtual to physical address translation of that ioctl handler address to patch it one time

@kkent030315
Copy link
Owner

That's the good point. Also bruteforcing system's CR3 is the good one than scanning entire physical memory. I will bring the implementation when I get time to do so! :)

@serby2000
Copy link

serby2000 commented Nov 22, 2021

Also bruteforcing system's CR3 is the good one than scanning entire physical memory.

What would you achieve by bruteforcing CR3 when Kernel Structs including Page Tables are protected from mapping with ZwMapViewOfSection?

@estimated1337
Copy link

Also bruteforcing system's CR3 is the good one than scanning entire physical memory.

What would you achieve by bruteforcing CR3 when Kernel Structs including Page Tables are protected from mapping with ZwMapViewOfSection?

protected from MmMapIoSpace mapping but not from ZwMapViewOfSection, with last you can map actually entire physical memory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants