Re:Malware can turn off webcam LED and record video, demonst...
by axoltl on Wednesday November 27, 2024 @05:32PM
(#42260474)
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)
Re:Malware can turn off webcam LED and record video, demonst...
by moritzwarhier on Wednesday November 27, 2024 @05:48PM
(#42260582)
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!
Re:Malware can turn off webcam LED and record video, demonst...
by axoltl on Wednesday November 27, 2024 @06:10PM
(#42260727)
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.
Re:Malware can turn off webcam LED and record video, demonst...
by ProfessorLayton on Wednesday November 27, 2024 @06:23PM
(#42260816)
What does OTP stand for in this case? The camera PROM??
Re:Malware can turn off webcam LED and record video, demonst...
by axoltl on Wednesday November 27, 2024 @06:50PM
(#42261012)
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.).
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.