ChanServ 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
nafod has quit [Quit: Ping timeout (120 seconds)]
nafod has joined #asahi-re
DragoonAethis has joined #asahi-re
DarkShadow44 has joined #asahi-re
Emantor has joined #asahi-re
PhilippvK has joined #asahi-re
the_lanetly_052 has joined #asahi-re
Astra[m] has joined #asahi-re
MajorBiscuit has joined #asahi-re
MajorBiscuit has quit [Quit: WeeChat 3.5]
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-re
chadmed has quit []
the_lanetly_052__ has joined #asahi-re
the_lanetly_052 has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi-re
MajorBiscuit has quit []
MajorBiscuit has joined #asahi-re
<sven>
i've started to look into bluetooth with R's notes a bit. looks like apple calls the transport used for communication with the actual chip "apple converged IPC" and maybe also "apple converged PCI"
<marcan>
(no idea where those came from, but public decryption keys for public firmware blobs are fair game FWIW)
<nicolas17>
oh so he just tweeted them out lol
<marcan>
so I guess we can finally decrypt iBoot/SMC and answer some mysteries that way (RE policy still applies as usual, don't do that if you're writing drivers and I don't know you know what you're doing)
<sven>
huh, cute
<sven>
the one iboot i briefly looked at contained almost no strings and wasn't much fun to reverse engineer fwiw
<marcan>
I'm more interested in things like like SMC, I looked at an iPhone one and that helped answer some questions but there was enough that was different to leave plenty of mysteries
<marcan>
also since SMC is always on, this is good for proving absence of backdoors and such
<sven>
yeah, i looked for the ANS shutdown sequence I think
<sven>
and even finding that was annoying
<sven>
and I missed the PMGR reset anyway
<marcan>
the DCP client side would be nice to find too
<marcan>
and also exactly what algorithm apple used to use for mode selection before they nixed it
<sven>
true
<marcan>
also, IIRC iBoot talks to some EPIC endpoints besides the iBoot/disp0 one
<marcan>
and I'd love to know what it does with those
<marcan>
I already reversed some of it, it's in proxyclient stuff
<marcan>
but I didn't find anything useful to solve the hotplug problem
<marcan>
though I bet it could be done with i2c shenanigans poking the dp2hdmi chip, but that's *another* layer of blind undocumented registers
<marcan>
(since the HPD pin goes through it)
<marcan>
we do have firmare for that one
<marcan>
... it's x86. 80186.
<marcan>
so yeah, nice rabbit hole for someone to go down if they're bored
<nicolas17>
as if knowing there's an x86 iPhone baseband wasn't cursed enough already
<marcan>
tbh though, the current "shut down DCP" solution is quite pretty, and better than prodding magic registers and having to have linux prod them back
<marcan>
I think I'm going to stick with that for now
<marcan>
need to fix up Linux RTKit so it uses an always-safe sequence to bring up RTKit that works regardless of what shutdown mode a copro is in
<marcan>
then it doesn't have to care
<nicolas17>
these keys were probably extracted via JTAG on a CPFM00 (prototype) M1 chip that "fell off a truck", but if you hypothetically exploited a bootrom bug or something on a production M1, you could get the same keys
<nicolas17>
(I know marcan knows this, just stating it for everyone reading :p)
<marcan>
Right. I don't endorse all that "fell of a truck" stuff, but if the end result is data that is in everyone's M1 anyway being published, I'm not going to say no to using it.
<marcan>
Ultimately those keys being public help a lot of causes, including verifiability of the boot chain.
<marcan>
(I wish Apple just stopped encrypting this stuff)
<sven>
that still seems to be common broadcom stuff, there are some vague references to this in the wlan driver as well
<sven>
*mystery
<sven>
firmware selection also seems to be rather simple: get the chip name from the PCI dev id and then get the antenna or whatever island code name from the DT just like wifi. there's only a third component I don't understand yet (USI vs. MUR)
<nicolas17>
does anyone know if AWDL is implemented in the macOS driver or in the Wi-Fi firmware?