<davidrysk[m]>
question I have: will iBoot load a mach-o that has an LC_MAIN pointing to the entry point?
<marcan>
unlikely, if that's not how XNU loads
<davidrysk[m]>
without the configure-boot option in kmutil we can't test :)
<Shiz>
davidrysk[m]: kmutil also uses kernelcache at other points iirc
<davidrysk[m]>
Shiz: yes, but does it use kernelcache for configure-boot --custom-boot-object? the documentation for that specifically states that you use that to load a mach-o
mogeryy has joined #asahi-re
<Shiz>
idk, but bputil's policy stuff seems to refer to it as kcOS :p
<Shiz>
kc being... kernelcache
<Shiz>
(presumably)
mogery has quit [Ping timeout: 260 seconds]
<Shiz>
marcan: fwiw, libkern/kxld/kxld_object.c in xnu sources may be relevant
<marcan>
davidrysk[m]: a kernelcache *is* a mach-o (wrapped in an img4)
<Shiz>
gobjdump: kc: unknown load command 0x34
<Shiz>
ooh :)
<Shiz>
ah, LC_DYLD_CHAINED_FIXUPS
<modwizcode>
Why is it wrapped in an img4?
<davidrysk[m]>
mach-o support in objdump is incomplete, otool (from apple's cctools) is more complete
<Shiz>
davidrysk[m] otool doesn't even recognize it as an object file :)
<davidrysk[m]>
Shiz: the img4?
<davidrysk[m]>
(which file?)
<Shiz>
might be my local macOS version which is outdated
<Shiz>
the kernelcache extracted from the img4, trying on m1 now
<jix>
davidrysk[m]: LC_UNIXTHREAD is older than LC_MAIN and was also used for userspace stuff before
<jix>
I haven't touched osx stuff in over 10 years, but I back then I did some sizecoding and that involved sticking some code into the LC_UNIXTHREAD command so that all those bytes aren't wasted
<Shiz>
sounds familiar
<davidrysk[m]>
well, will iBoot boot a simpler Mach-O that doesn't have all this crap?
HeN has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 256 seconds]
tiagom has joined #asahi-re
<Shiz>
marcan: did you extract the kernel from the fileset? :p
<marcan>
Shiz: fileset?
<Shiz>
yeah, the kernelcache is a fileset
<Shiz>
it's just a container with a bunch of inner mach-Os
<Shiz>
special type of mach-O file
<marcan>
not quite
<marcan>
it used to be that
<marcan>
these days it's all prelinked anyway
<Shiz>
well
<Shiz>
i just extracted the kernelcache
<marcan>
there's one big massive text section outside the fileset
<Shiz>
and it has a com.apple.kernel, which is a mach-o executable
<Shiz>
hum
<marcan>
anyway none of this matters as far as the bootloader is concerned
<Shiz>
-rw-r--r-- 1 partynorge staff 85M 11 Jan 19:24 com.apple.kernel
<Shiz>
the sizes all add up to me, i think it's inside the fileset
<Shiz>
sure
<Shiz>
yeah, this is not prelinked
<marcan>
what file are you looking at?
<Shiz>
the kernelcache extracted from the preboot partition at $vuid/boot/$policy/System/Caches/com.apple.kernelcache/kernelcache
<Shiz>
(from the top of my head)
<marcan>
__TEXT_EXEC is like 50MB
<marcan>
outside the filesets
<Shiz>
yeah, i do see that
<Shiz>
i guess it is, then? but all the files inside are individual seemingly-proper mach-O files
<Shiz>
with adding-ups izes
<Shiz>
the duality of mach-o
<marcan>
then __TEXT_EXEC is just the text of the kernel itself?
<Shiz>
oh, yeah I think it makes sense now
<Shiz>
com.apple.kernel *is* the big blob, and the .kexts are 'inside' but also individually referencable
<marcan>
are they really?
<marcan>
all the iOS research says they were prelinked and not quite complete
<Shiz>
is my guess, but maybe not
<marcan>
but maybe this is different from iOS
<Shiz>
otool does complain that the stuff I extract is truncated, so there might be something there
<Shiz>
bleh
<Shiz>
got too excited because my own parser could parse the etracted stuff again :p
<marcan>
lol
<Shiz>
starting to think it may just be the headers
<marcan>
remember the code *has* to be linked together
<marcan>
because CTRR
<Shiz>
right
<Shiz>
so yeah, the 'kexts' are first, then the big kernel file, each with at least proper mach-O headers
<Shiz>
and I guess those kexts are just the headers, checking now
<Shiz>
(in the fileset entry list, I mean)
<roxfan>
IIRC in some iOS version they reshuffled segments so that all __TEXT are separate from all __DATA; not sure if that's the case with macOS
<Shiz>
okay, so each fileset entry seems to be a mach-O header and the string section
<Shiz>
curious
tiagom has quit [Quit: tiagom]
tiagom has joined #asahi-re
<roxfan>
i think com.apple.kernel is mostly standalone but kexts are prelinked to refer to addresses inside it
<roxfan>
also they're all not contiguous in the cache so you can't just dd
<roxfan>
maybe jtool can extract them, not sure
<Shiz>
yeah my conclusion was stupid, my apologies
<Shiz>
tbf, i didn't expect them to throw in all the individual headers :P
<roxfan>
some code still relies on valid header being there
mogeryy has quit [Quit: Leaving]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wolf511[m] has joined #asahi-re
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 240 seconds]
parallax has joined #asahi-re
tiagom has quit [Quit: tiagom]
ransom has joined #asahi-re
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]