201–210 of 241 posts
I would be more concerned about the microphone. I can easily cover the camera with tape. Also, random pictures of me programming or reading HN are probably less damaging audio recordings of conversations I might be having.
Earlier quoted context omitted.
Macbooks already have this: it's called the keyboard and it "slides over the lens" when you close the laptop when it's not in use. Much easier to do automatically than remember to slide a 'door' across. Or do people really leave their laptops open when not in use?
That doesn't prevent spying when you are using your computer, which could be really embarrassing if you are for instance looking at porn. Also, sometimes you want to leave it one when you aren't using it, like when you're downloading something.
On the whole, I think this discussion focuses on the wrong 'problem'. If someone can gain access to your computer, taking control of the camera is just one of a whole host of nasty activities they could get up to - the real problem is securing against remote access in the first place.
[1] http://arstechnica.com/security/2013/12/perv-utopia-light-on...
While this is theoretically possible with some firmware hack on 2008 machines you are far more likely to be compromised on any Android device that has side loaded apps.
No one has mentioned cellphone camera/microphone. I assume it's feasible to do the same remote operation with those?
Earlier quoted context omitted.
I don't think anyone at Apple considered this LED to be designed "tamper proof". They just lazily implemented a requirement possibly written as: -- A LED shall light up when the camera is activated. But what they should have implemented is: -- It shall not be possible to activate the camera without the LED being lit, taking malicious third-party software into account. The first requirement is obviously, and demonstra…
I'd be much happier with a requirement to the industrial design department: -- There shall be a way for the user to physically obstruct the camera lens. Apple used to have this in their standalone camera back in the day.
Earlier quoted context omitted.
I'd be much happier with a requirement to the industrial design department: -- There shall be a way for the user to physically obstruct the camera lens. Apple used to have this in their standalone camera back in the day.
Yeah, HP had that in some of there old machines too, remember I had one with a physical slidethingy
Earlier quoted context omitted.
configuration.
Not really what I'm looking for.
This is usually done at runtime, typically a bit of code that happens after the reset vector that puts the various config values into the appropriate registers that set up this routing and other customisable options.
In the case here, it's those other options that are the issue.
From the paper, Part IV(A):
> The Micron image sensor has a 16 bit configuration register, RESET (which is distinct from the #RESET power on reset signal). RESET is addressable from the I2C interface at address 0x0D in register page 0
And the hack involves setting that configuration register to unexpected values to enable functionality that bypasses the LED display circuit:
> Bit 7. Prevent STANDBY from affecting entry to or exit from the low-power state if set.
> Bit 6. Prevent STANDBY from contributing to output enable control if set.
(where STANDBY is the signal/pin to which the LED is connected)
So the controller assumes that the physical STANDBY pin will always accurately reflect/control the state of the sensor, which is not necessarily the case if it's been disabled by re-configuration.
In other words, would this work while the machine is off or running Linux?