Hacker News Reader

Comment by revelation | Hacker News Reader

Or, you know, spare one of the trillion transistors to switch power to 1) camera and 2) LED.

There, solved. No full-powered ARM needed to control an indicator light.

I'm guessing it's not that simple because there may be situations when the camera has power and is capturing an image (think hot-standby) but is not transmitting image data to the world outside the sensor package.

I don't want my camera to capture pictures without the LED being on, ever.

And what if I turn on the camera for a tenth of a second, take a picture, and turn it off. You won't notice the LED being on for a tenth of a second. Software makes it easier to prevent such things.

You definitely don't need software to add a little delay for turning off the LED, but sure, it would be slightly more complicated than just a dang wire.

Just wrote a test app on macOS that initializes the camera, gets the first video frame, and turns it off. You definitely notice the bright green LED being on for a split second.

You only notice it immediately if you're looking for it. I've gone minutes with the camera on before noticing the LED while I was distracted by other stuff on the screen.

Source code?

Why not both? It is trivial to make a circuit such that the LED is on if either there is power to the camera, or the software tells you to.

I would guess you could do the same with a circuit, even if that means you lose on flexibility (but given the concerns of many users, I'd say it's worthy).

A small piece of black tape or a physical shutter is likely a better choice. Who cares if the camera is on if it can't pick up anything?

The microphone, on the other hand, is kind of a bigger deal and still has that issue.

Yeah, exactly since the camera in the previous generation MBP actually had 4GB SD storage on it.

The ARM was not bought to power the LED, it was bought in for TouchID. The camera LED is the icing, not the cake.

They have a point though. Why would there be any software that controls the LED? Is it not more secure to have it hooked up directly to the camera power line and turn them both on and off inseparably?

Turning off the camera power would mean it wouldn't show up on the bus, so the computer wouldn't know it existed.

It would make sense for the camera itself to drive the LED, instead of the computer/drivers doing it. I don't know if the camera ICs support this or not, though -- if not, it's not really something Apple can add if they're integrating a standard camera component. On the other hand, they control the T1 entirely, so they can easily do this with the new architecture.

From what I recall when it was in the news, the camera does control the LED, but it's just a USB camera on the USB bus, so the demo attack worked by reflashing the software on the camera.

I write a piece of malware that pops the camera on long enough to snap a single frame and then turn back off. The LED blinks, quite possibly too fast for you to notice.

OTOH, you can delay the LED and have it very noticeably on for a second or two when it's software-controlled.

How 'bout some pulse shaping. Rising edge of the camera power triggers a latch, whose output is pulse-shaped so that you get a little attention-catching "LED flash" when the camera turns on (brightness tapers off quickly) and is just dimly / visibly lit beyond that. This could be done with 1970s hardware with maybe two chips and some passives. Maybe one chip if you're getting ingenious.

An attacker could piggyback on user initiated sessions of video camera use. After the user closes the connection, it could immediately trigger an extra 0.1s session that would go unnoticed because of the proximity with the user intended session.

Good point, but then why not implement the delay in immutable (and trivial and cheap) hardware? Is this not both simpler and more secure?

I guess, yeah, you could do it in hardware. But I don't think, then, it ends up being directly connected to the power feed for the camera itself, yeah? You start creating false-status cases. (This is speculation; I am not an electronics wizard.)

One word: capacitor. Seriously, solved case for many many decades

Power->delay off circuit->LED. Seems pretty direct to me. The delay off circuit would probably have its own connection to power as well.

Post 2013? that's exactly how it was hooked up.

Why not just have a hard switch to cut the power to the camera. It is pretty low tech. Would be hard to hack without flipping the switch. No way camera could operate without power.

A physical power switch would take more volume in the computer than the camera itself and would have a failure rate at least an order of magnitude higher than the camera. Things which people physically operate need to be physically more robust than electronic components on a circuit board.

Yo dawg. I heard you like ARMs, so we put an ARM on your ARM.

https://github.com/patjak/bcwc_pcie/wiki/Specification---Fea...

^^ did everyone already miss that the webcam was an entire SoC and not just a sensor hooked up to UVC?

Hence why you power-cycle the thing.

What? How is that supposed to help anything. It's not like you can physically disconnect the webcam without disassembling the panel.

The crazy part is you don't even know if it's still recording with the entire laptop off. Could it not, in theory, draw power off the main battery independent of the system being on? It certainly should be able to while in sleep mode.

Before we shrinked transistors to a mere atoms wide their main purpose was in switching power.

And no, it's not connected to the main battery, because presumably it runs on 3.3V and maybe even some more exotic voltages for the image sensor. That needs to be regulated.

Reply on news.ycombinator.com