Kernelcache plugin fails to parse prelinked kext segments in iOS 16.4

[Siguza]

Environment

% date
Thu Mar  9 03:13:13 CET 2023
% r2 -v
radare2 5.8.3 30065 @ darwin-arm-64 git.5.8.2-242-gc5afa57768
commit: c5afa577686af9706dfb656360afb25add7cdac1 build: 2023-03-08__20:29:00
% uname -ms
Darwin arm64

Description

Running r2 against an iOS 16.4 beta kernelcache with prelinked kexts (A11), I am no longer seeing the SORTING KEXTs... message at startup, and running iS only gives me the segments of the main kernel binary:

[0xfffffff0071c4570]> iS
[Sections]

nth paddr            size vaddr                   vsize perm type name
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
0   0x0098501c     0x6c24 0x0098501c             0x6c24 -r-- ---- com.apple.kpi.bsd.
1   0x0000165c    0x34ec0 0xfffffff007005640    0x34ec0 -r-- ---- 0.__TEXT.__const
2   0x0003651c       0xf0 0xfffffff00703a500       0xf0 -r-- ---- 1.__TEXT.__copyio_vectors
3   0x0003660c    0x626b9 0xfffffff00703a5f0    0x626b9 -r-- ---- 2.__TEXT.__cstring
4   0x00098cc5    0x1efb4 0xfffffff00709cca9    0x1efb4 -r-- ---- 3.__TEXT.__os_log
5   0x000b7c79        0x0 0xfffffff0070bbc5d        0x0 -r-- ---- 4.__TEXT.__thread_starts
6   0x000b7c7c      0x398 0xfffffff0070bbc60      0x398 -r-- ---- 5.__TEXT.__eh_frame
7   0x000b801c      0x2b8 0xfffffff0070bc000      0x2b8 -r-- ---- 6.__DATA_CONST.__mod_init_func
8   0x000bc01c    0xd9778 0xfffffff0070c0000    0xd9778 -r-- ---- 7.__DATA_CONST.__const
9   0x0019579c      0x160 0xfffffff007199780      0x160 -r-- ---- 8.__DATA_CONST.__hib_const
10  0x001958fc    0x11200 0xfffffff0071998e0    0x11200 -r-- ---- 9.__DATA_CONST.__kalloc_type
11  0x001a6afc     0x7030 0xfffffff0071aaae0     0x7030 -r-- ---- 10.__DATA_CONST.__kalloc_var
12  0x001b001c      0xba4 0xfffffff0071b4000      0xba4 -r-x ---- 11.__TEXT_EXEC.__hib_text
13  0x001b401c   0x683c70 0xfffffff0071b8000   0x683c70 -r-x ---- 12.__TEXT_EXEC.__text
14  0x0083801c      0xee0 0xfffffff00783c000      0xee0 -r-x ---- 13.__KLD.__text
15  0x0083c01c        0x8 0xfffffff007840000        0x8 -r-- ---- 14.__LASTDATA_CONS.__mod_init_func
16  0x0084001c       0x40 0xfffffff007844000       0x40 -r-x ---- 15.__LAST.__pinst
17  0x0000001c        0x0 0xfffffff007844040        0x0 -r-x ---- 16.__LAST.__last
18  0x0084401c      0x6e1 0xfffffff007848000      0x6e1 -rw- ---- 17.__KLDDATA.__cstring
19  0x00844704       0x78 0xfffffff0078486e8       0x78 -rw- ---- 18.__KLDDATA.__const
20  0x0084477c        0x8 0xfffffff007848760        0x8 -rw- ---- 19.__KLDDATA.__mod_init_func
21  0x00844784        0x8 0xfffffff007848768        0x8 -rw- ---- 20.__KLDDATA.__mod_term_func
22  0x0000001c        0x0 0xfffffff007848770        0x1 -rw- ---- 21.__KLDDATA.__bss
23  0x0084801c    0x18240 0xfffffff00784c000    0x18240 -rw- ---- 22.__DATA.__data
24  0x0086025c     0x5490 0xfffffff007864240     0x5490 -rw- ---- 23.__DATA.__lock_grp
25  0x0086801c     0x2f30 0xfffffff00786c000     0x2f30 -rw- ---- 24.__DATA.__percpu
26  0x0000001c        0x0 0xfffffff00786f000    0x529f4 -rw- ---- 25.__DATA.__common
27  0x0000001c        0x0 0xfffffff0078c2000    0x34d98 -rw- ---- 26.__DATA.__bss
28  0x0086c01c    0x18000 0xfffffff0078f8000    0x18000 -rw- ---- 27.__BOOTDATA.__data
29  0x0088401c    0x178a0 0xfffffff007910000    0x178a0 -rw- ---- 28.__BOOTDATA.__init
30  0x0089b8bc     0xf5e8 0xfffffff0079278a0     0xf5e8 -rw- ---- 29.__BOOTDATA.__init_entry_set
31  0x0098401c   0x7e0000 0xfffffff004d38000   0x7e0000 -r-- ---- 30.__PRELINK_TEXT.__text
32  0x02e0401c   0x32c000 0xfffffff007bc4000   0x32c000 -rw- ---- 31.__PRELINK_INFO.__info
33  0x0116401c  0x1744000 0xfffffff005518000  0x1744000 -r-x ---- 32.__PLK_TEXT_EXEC.__text
34  0x02c5001c   0x1b4000 0xfffffff007a10000   0x1b4000 -rw- ---- 33.__PRELINK_DATA.__data
35  0x028a801c   0x3a8000 0xfffffff006c5c000   0x3a8000 -r-- ---- 34.__PLK_DATA_CONS.__data
36  0x02e0401c        0x0 0xfffffff007bc4000        0x0 -rw- ---- 35.__PLK_LLVM_COV.__llvm_covmap
37  0x02e0401c        0x0 0xfffffff007bc4000        0x0 -rw- ---- 36.__PLK_LINKEDIT.__data
38  0x008ac01c    0x422cf 0xfffffff007938000    0x422cf -r-- ---- 37.__LINKINFO.__symbolsets

[0xfffffff0071c4570]> 

This applies to all three 16.4 betas that have been released so far.

Doing the same on iOS 16.3.1 kernels or earlier yields somewhere between 2000 and 3000 sections from kexts such as com.apple.security.sandbox, com.apple.filesystems.apfs, etc.

I had a look at the __PRELINK_INFO.__info section, but didn't find any obvious change that would break kext parsing.

Test

iOS 16.3.1 and 16.4 beta 1 kernels are attached.

iOS-16.3.1-20D67-d201ap,d20ap,d211ap,d21ap.gz
iOS-16.4-20E5212f-d201ap,d20ap,d211ap,d21ap.gz

[mrmacete]

the change is that prelink info is now using references to xml elements instead of repeating stuff, needs work in the dict parser which is currently ignoring attributes altogether

[mrmacete]

this is a workaround you can apply in the meantime:

diff --git a/libr/bin/p/bin_xnu_kernelcache.c b/libr/bin/p/bin_xnu_kernelcache.c
index 4a2e4dab5b..8a770bc256 100644
--- a/libr/bin/p/bin_xnu_kernelcache.c
+++ b/libr/bin/p/bin_xnu_kernelcache.c
@@ -401,6 +401,9 @@ static RList *filter_kexts(RKernelCacheObj *obj, RBinFile *bf) {
                RListIter *internal_iter;
                r_list_foreach (kext_item->pairs, internal_iter, item) {
                        if (!strcmp (item->key, "CFBundlePackageType")) {
+                               if (item->value->type == R_CF_NULL) {
+                                       goto yeah_ok;
+                               }
                                if (item->value->type != R_CF_STRING) {
                                        break;
                                }
@@ -408,6 +411,7 @@ static RList *filter_kexts(RKernelCacheObj *obj, RBinFile *bf) {
                                if (strcmp (type->value, "KEXT")) {
                                        break;
                                }
+yeah_ok:
                                kext_incomplete--;
                        }

[Siguza]

Wait, it never handled ID and IDREF?! How did any of this ever work then? :O

But I guess I can look into that.