marcan changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | RE policy: https://alx.sh/re | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 265 seconds]
dibas has quit [Ping timeout: 260 seconds]
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dibas has joined #asahi-re
dibas has joined #asahi-re
ransom has joined #asahi-re
Tokamak has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 264 seconds]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has quit [Remote host closed the connection]
Tokamak has joined #asahi-re
ransom has joined #asahi-re
justMaku has quit [Remote host closed the connection]
q3k|m has quit [Remote host closed the connection]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
klaus_ has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 264 seconds]
marcan changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | WARNING: this channel (only) may contain binary reverse engineering discussion | RE policy: https://alx.sh/re (MANDATORY READ) | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
bylaws has joined #asahi-re
lewurm has joined #asahi-re
rootspring[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: 265 seconds]
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd has joined #asahi-re
mogery has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 272 seconds]
justMaku has joined #asahi-re
robher has joined #asahi-re
q3k|m has joined #asahi-re
justMaku has quit [Quit: Client limit exceeded: 150]
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd has joined #asahi-re
sumoon[m] has joined #asahi-re
klaus_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
HeN has quit [Quit: Connection closed for inactivity]
Tokamak has joined #asahi-re
klaus_ has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 264 seconds]
ransom has joined #asahi-re
ransom_ has joined #asahi-re
ransom has quit [Ping timeout: 272 seconds]
<davidrysk[m]> marcan: https://twitter.com/marcan42/status/1348668349404782592 -- are you looking at the built t8101 kernel?
<marcan> davidrysk[m]: just the mach-o structures, to see what I should be feeding iBoot
<marcan> (not the code)
<marcan> I'm probably do a trick I've used in the past, of building the mach-o structures inside the memory image in a linker script
<marcan> then I can just build with a normal ELF tolchain and objcopy -O binary to get a mach-o
<marcan> *I'll
<davidrysk[m]> wonders if PongoOS has done some of this work already
<davidrysk[m]> oop, PongoOS directly includes APSL-licensed Apple headers :(
<Shiz> yikes
<Shiz> mach-O ain't fun
<davidrysk[m]> https://crna.cc/b/4? -- kinda interesting
<marcan> there's a reason I'm staying away from PongoOS
<marcan> different standards
<davidrysk[m]> yeah
<marcan> (and why I added that warning to our RE policy)
<davidrysk[m]> that's not how a typical (userspace) mach-o encodes its entry point
<marcan> really?
<JTL> davidrysk[m]: I've never studied Mach-O, tell me more :p
<davidrysk[m]> no, it uses LC_MAIN
ransom has joined #asahi-re
<marcan> ah
<davidrysk[m]> uh I know corkami made a poster for mach-o
<marcan> oh that would've been helpful about 3 hours ago
<davidrysk[m]> too basic :)
<marcan> https://mrcn.st/p/5SrEyT0o some subset of mach-o parsed with Construct
<davidrysk[m]> marcan: are you looking at the kernel or the kernelcollection?
<marcan> /usr/bin/header lol, where did that come from
<marcan> I must be tired already
<marcan> davidrysk[m]: kernelcache is what it is called
<davidrysk[m]> :(
<marcan> :(?
<davidrysk[m]> (about you being tired lol)
<marcan> ah :)
modwizcode has joined #asahi-re
ransom_ has quit [Ping timeout: 256 seconds]
<davidrysk[m]> the manpage for kmutil uses the term "boot kext collection"
<marcan> yeah, I guess that's a better name for it
<marcan> anyway, it's just a mach-o
<davidrysk[m]> but isn't clear whether that's just for kexts
<marcan> they prelink all the boot kexts into a single kernel
<davidrysk[m]> my point though: kmutil is probably what wraps it into an asn.1
<davidrysk[m]> the mach-of file for the kernel is at /System/Library/Kernels and doesn't look wrapped in an asn.1 to me
<marcan> yes, kmutil does the asn.1 bit
<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
<Shiz> anyway
<Shiz> apparently this can dump kernelcaches
<davidrysk[m]> that looks handy (just note that his tools are proprietary licensed)
<Shiz> yep
<davidrysk[m]> (usually are **)
<Shiz> no source sadly
<Shiz> doesn't matter anyway, because it segfaults on the kernel :)
<Shiz> it doesn't like LC_FILESET_ENTRY (0x35)
<davidrysk[m]> my otool is fine with that
<davidrysk[m]> probably is that your local macOS (or your Xcode) is outdated
<Shiz> probably yea
<davidrysk[m]> (latest Xcode works with macOS 10.15.x fwiw)
<Shiz> oh yay, mach-o filesets
<davidrysk[m]> hm
<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…]