liboffsetfinder64
liboffsetfinder64 copied to clipboard
liboffsetfinder64: failed with exception: overflow reached end of vmem
Whenever I try to run the findjboffsets.sh in example folder I got this error:
./findjboffsets.sh
offsetexporter: liboffsetfinder64 version: 0.143-ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7-RELEASE
Init KPF('/Users/ethernal/kernel.dec')
Warning: compiled without img4tool, extracting from IMG4/IM4P disabled!
got fat macho with first slice at 50896896
[WARNING] We encountered __TEXT_EXEC section, marking normal __TEXT section as non-executable!
Detected non-slid kernel.
Inited machopatchfinder64 143 ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7
Kernel version: 8796.122.4~1
Detected iOS 16 kernel
[Error] liboffsetfinder64: failed with exception:
[exception]:
what=overflow reached end of vmem
code=29032456
line=443
file=vmem.cpp
commit count=42
commit sha =f4037f7763f724fdb389d18d625bad9495509206
kernel.dec : iPhone X - iOS 16.5
I also get the same error on my iPhone X on 16.6b1
Maybe it's because the iPhone X processor architecture is not arm64e
Probably
Maybe it's because the iPhone X processor architecture is not arm64e
yes, but kfd also works with arm64 so I think there is a problem in the library.
By modifying the findjboffsets.sh script like this:
offsetexporter -i /Users/ethernal/kernel.dec \
-t template_dynamic_info.h \
-o gen.h \
--get_kernel_version_string %kern_version% \
--find_struct_thread_offset_thread_id %thread__thread_id% \
--find_sizeof_struct_thread %thread__object_size% \
--find_sizeof_struct_uthread %uthread__object_size% \
--static %vm_map_entry__links__prev% 0x00 \
--static %vm_map_entry__links__next% 0x08 \
--static %vm_map_entry__links__start% 0x10 \
--static %vm_map_entry__links__end% 0x18 \
--static %vm_map_entry__store__entry__rbe_left% 0x20 \
--static %vm_map_entry__store__entry__rbe_right% 0x28 \
--static %vm_map_entry__store__entry__rbe_parent% 0x30 \
--static %_vm_map__hdr__nentries% 0x30 \
--static %_vm_map__hdr__rb_head_store__rbh_root% 0x38 \
--find_struct__vm_map_offset_vmu1_lowest_unnestable_start %_vm_map__vmu1_lowest_unnestable_start% \
--find_sizeof_struct__vm_map %_vm_map__object_size% \
--find_base %kernelcache__kernel_base% \
--find_cdevsw %kernelcache__cdevsw% \
--find_gPhysBase %kernelcache__gPhysBase% \
--find_gVirtBase %kernelcache__gVirtBase% \
--find_perfmon_devices %kernelcache__perfmon_devices% \
--find_bof_with_sting_ref %kernelcache__perfmon_dev_open% "perfmon: attempt to open unsupported source" 0 \
--find_ptov_table %kernelcache__ptov_table% \
--find_vm_first_phys_ppnum %kernelcache__vm_first_phys_ppnum% \
--find_vm_page_array_beginning_addr %kernelcache__vm_page_array_beginning_addr% \
--find_vm_page_array_ending_addr %kernelcache__vm_page_array_ending_addr% \
I was able to get all offsets except vm_pages and vn_kqfilter which return two different errors:
If you keep the --find_vm_pages %kernelcache__vm_pages% \
:
./findjboffsets.sh
offsetexporter: liboffsetfinder64 version: 0.143-ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7-RELEASE
Init KPF('/Users/ethernal/kernel.dec')
Warning: compiled without img4tool, extracting from IMG4/IM4P disabled!
got fat macho with first slice at 50896896
[WARNING] We encountered __TEXT_EXEC section, marking normal __TEXT section as non-executable!
Detected non-slid kernel.
Inited machopatchfinder64 143 ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7
Kernel version: 8796.122.4~1
Detected iOS 16 kernel
[Error] liboffsetfinder64: failed with exception:
[exception]:
what=loc not within vmem
code=39780360
line=607
file=vmem.cpp
commit count=42
commit sha =f4037f7763f724fdb389d18d625bad9495509206
If you keep the --find_function_vn_kqfilter %kernelcache__vn_kqfilter% \
:
./findjboffsets.sh
offsetexporter: liboffsetfinder64 version: 0.143-ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7-RELEASE
Init KPF('/Users/ethernal/kernel.dec')
Warning: compiled without img4tool, extracting from IMG4/IM4P disabled!
got fat macho with first slice at 50896896
[WARNING] We encountered __TEXT_EXEC section, marking normal __TEXT section as non-executable!
Detected non-slid kernel.
Inited machopatchfinder64 143 ab2d635e1cd0c51ae6e7ff1d2bfa2b6af9bdeee7
Kernel version: 8796.122.4~1
Detected iOS 16 kernel
[Error] liboffsetfinder64: failed with exception:
[exception]:
what=overflow reached end of vmem
code=29032456
line=443
file=vmem.cpp
commit count=42
commit sha =f4037f7763f724fdb389d18d625bad9495509206
Removing both I get "Done writing to file 'gen.h'" and in the gen.h file I get this:
const struct dynamic_info kern_versions[] = {
{
.kern_version = "Darwin Kernel Version 22.5.0: Mon Apr 24 21:10:12 PDT 2023; root:xnu-8796.122.4~1/RELEASE_ARM64_T8015",
.fileglob__fg_ops = %fileglob__fg_ops%,
.fileglob__fg_data = %fileglob__fg_vn_data% - 8,
.fileops__fo_kqfilter = %fileops__fo_kqfilter%,
// .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 = %fileproc_guard__fpg_guard%,
.kqworkloop__kqwl_state = %kqworkloop__kqwl_state%,
.kqworkloop__kqwl_p = %kqworkloop__kqwl_p%,
.kqworkloop__kqwl_owner = %kqworkloop__kqwl_owner%,
.kqworkloop__kqwl_dynamicid = %kqworkloop__kqwl_owner% + 0x18,
.kqworkloop__object_size = %kqworkloop__object_size%,
.pmap__tte = %pmap__tte%,
.pmap__ttep = %pmap__ttep%,
.proc__p_list__le_next = %proc__p_list__le_next%,
.proc__p_list__le_prev = %proc__p_list__le_prev%,
.proc__p_pid = %proc__p_pid%,
.proc__p_fd__fd_ofiles = %proc__p_fd__fd_ofiles%,
.proc__object_size = %proc__object_size%,
.pseminfo__psem_usecount = %pseminfo__psem_usecount%,
.pseminfo__psem_uid = %pseminfo__psem_uid%,
.pseminfo__psem_gid = %pseminfo__psem_gid%,
.pseminfo__psem_name = %pseminfo__psem_name%,
.pseminfo__psem_semobject = %pseminfo__psem_semobject%,
// .psemnode__pinfo = 0x0000,
// .psemnode__padding = 0x0008,
// .psemnode__object_size = 0x0010,
.semaphore__owner = %semaphore__owner%,
.specinfo__si_rdev = %specinfo__si_rdev%,
.task__map = %task__map%,
.task__threads__next = %task__thread_count% - 0x28,
.task__threads__prev = %task__thread_count% - 0x28 + 8,
.task__itk_space = %task__itk_space%,
.task__object_size = %task__object_size%,
.thread__task_threads__next = %thread__map% - 0x18,
.thread__task_threads__prev = %thread__map% - 0x18 + 8,
.thread__map = %thread__map%,
.thread__thread_id = 0x3f0,
.thread__object_size = 0x498,
.uthread__object_size = 0xfffffff004dd053d,
.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 = %vnode__v_un__vu_specinfo%,
._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 = %_vm_map__pmap%,
._vm_map__hint = 0x90 + 0x08,
._vm_map__hole_hint = 0x90 + 0x10,
._vm_map__holes_list = 0x90 + 0x18,
._vm_map__object_size = 0xfffffff004dd09d5,
.kernelcache__kernel_base = 0xfffffff007004000,
.kernelcache__cdevsw = 0xfffffff007855200,
.kernelcache__gPhysBase = 0xfffffff007157eb8,
.kernelcache__gPhysSize = 0xfffffff007157eb8 + 8,
.kernelcache__gVirtBase = 0xfffffff0071560d0,
.kernelcache__perfmon_devices = 0xfffffff0078935d0,
.kernelcache__perfmon_dev_open = 0xfffffff007323130,
.kernelcache__ptov_table = 0xfffffff00710a968,
.kernelcache__vm_first_phys_ppnum = 0xfffffff007892b30,
.kernelcache__vm_pages = %kernelcache__vm_pages%,
.kernelcache__vm_page_array_beginning_addr = 0xfffffff0071098f8,
.kernelcache__vm_page_array_ending_addr = 0xfffffff007892b28,
.kernelcache__vn_kqfilter = %kernelcache__vn_kqfilter%,
},
};
vm_pages and vn_kqfilter not many exploits are necessary.
felix-pb put it this way:
Note that none of the exploits require the better KRKW primitive in order to succeed. However, if you plan on doing research based on this project, then it is probably worthwhile to add support for the better KRKW primitive for your own device!