zlacker

Since some sort of firmware is required, this seems like a "turing tarpit" security exploit from my laymans perspective.

There's no standard that I know, that, like "Secure EFI / Boot" (or whatever exact name it is), locks the API of periphery firmware and that would be able to statically verify that said API doesn't allow for unintended exploits.

That being said: imagination vs reality: the Turing tarpit has to be higher in the chain than the webcam firmware when flashing new firmware via internal USB was the exploit method.

>>moritz+(OP)
No firmware is required. Macbooks manufactured since 2014 turn on the LED whenever any power is supplied to the camera sensor, and force the LED to remain on for at least 3 seconds.

(Source: I architected the feature)

>>axoltl+c5
Thanks for your reply — yourself as the Source can only make me feel flattered then for you responding to me.

> Macbooks manufactured since 2014 turn on the LED whenever any power is supplied to the camera sensor, and force the LED to remain on for at least 3 seconds.

That convinced me originally I think, good old days! I'd almost forgotten about it. The way you phrased it, it sounded like 50% OS concern to me.

But if cam & LED rly share a power supply, and the LED is always on without any external switch, Good then!

>>moritz+W6
I was not very popular with the camera firmware folks for a while. They had to re-architect a bunch of things as they used to occasionally power on the camera logic without powering the sensor array to get information out of the built-in OTP. Because the LED now came on whenever the camera was powered they had to defer all that logic.

>>axoltl+h9
What does OTP stand for in this case? The camera PROM??

>>Profes+Ia
Apologies. OTP is One-Time-Programmable. The physical implementation of this varies, in this specific case it was efuses (anti-fuse, actually). It's used for things like calibration data. For a camera it contains information about the sensor (dead pixels, color correction curves, etc.).