Looking lower level, I think it might actually be possible to talk to the Thread NCP coprocessor ("Fillmore") without private entitlements, presuming you're unsandboxed...

Maybe I can just port the open-source version of the daemon?

I created a (very rough) tool to play around with the #Thread radio built-in to M3+ #AppleSilicon #Mac devices!

Unfortunately, it requires private entitlements, so you'll need SIP disabled and AMFI bypassed.

https://github.com/JJTech0130/threadctl

You can configure the #Thread interface using the private CoreThreadRadio.framework...

Unfortunately it requires the entitlement com.apple.private.ctr.thread

I used Wireshark on threadradiod's utun interface on my Mac, and when I toggle a Matter-over-Thread lamp using Home app I see #Matter packets sent on port 5540!

It seems like after a minute or two the Home app figures out there is a Thread Border Router and shuts down utun9 in favor of just using the router.

I opened the Home app and threadradiod started right up, and created the following new interface!

(weird side effect of this: if you have a jailbroken iPhone 12, you could theoretically use that for authenticating as a CarPlay headunit... just need to talk via I2C to the display flex)

(this isn't actually useful, on all modern iOS/Mac devices you can get a BAA certificate, which CarPlay will happily accept instead of an MFi certificate because that's how CarPlay Simulator works)

You'll see it under AppleAuthCPRelay in ioreg, it's just connected to I2C.

The same AppleAuthCPUserClient appears to also be used to talk to a connected #Lightning authentication chip (over the IDBus protocol)... see AppleAuthCPMGAID

On the iPhone 12, the battery also contains a similar authentication mechanism, though it doesn't exactly seem to be the same MFi coproc.