Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I wish I had the expertise to do such in-depth reverse engineering of firmware blobs.
The DCP is actually the thing that's stopping me from providing native brightness control on the HDMI port of the newer Macs inside Lunar (https://lunar.fyi). Users have to either switch to a Thunderbolt port to get native brightness control for their monitor, or use a software dimming solution like Gamma Table alteration.
It's not clear what's going on, but it seems that the HDMI port of the 2018+ Macs uses an MCDP29xx chip inside, which converts the HDMI signal to DisplayPort internally, so that Apple doesn't have to decode both HDMI and DP video signals. (that is also the reason why even the newest MacBook and Mac Studio have only HDMI 2.0, that's the most the converter chip supports [0])
When sending DDC commands through the IOAVServiceWriteI2C call, monitors connected to the HDMI port lose video signal, or flicker or completely crash and need a power cycle to get them back.
The Thunderbolt ports however send the DDC command as expected when IOAVServiceWriteI2C is called
After @marcan42 from Asahi Linux pointed out [1] the DCPAVFamilyProxy kexts, I've looked into it and I found some different writei2c methods and some MCDP29xx specific code, but no clue on how to call them from userspace.
I guess I'll have to look into how the analysed exploit is using the RPC, and also check the methods assembly from inside the firmware blob itself. I was not aware that most userspace methods are now shims for remotely calling the embedded code.
[0] https://www.kinet-ic.com/mcdp2900/
[1] https://twitter.com/marcan42/status/1483283365407371265