I own a Logitech C920 Pro and a software called webcam settings allows me to easily turn off the lights. If this software can do this, so can a malware.
Also, a malware can be designed to click quick snaps when there is no keyword or mouse activity for a specific period. This can help the malware go unnoticed without controlling the light. Want to take it to the next level? You can use the mic anytime to estimate the user's distance from the system and then enable webcam accordingly. I know this would not be very accurate, but possible.
It is about the Macbook iSight. There is definitely no (official, known) software that allows you to turn off the privacy light. The Apple engineers intended it to be impossible to disable, and believed it was.
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.
Same here. Even nude photos would be embarrassing, but audio recordings could have effects far worse than some prude shame.
Especially since there is no LED to signal the microphone is active, it doesn't need to point anywhere. If it could be activated while the laptop is closed (force wake up a part of the OS for just a few minutes here and there for instance) it would be a really tough problem.
The beauty of your comment is that just a little over half a year ago you'd be considered a complete conspiracy nut and a paranoid tinfoil hatter but today there's no one even saying anything against you.
I use a cut-out piece of postit note for the camera, and a small piece of etape for the microphones -- seems stable, and both are pretty easy to take off without leaving too much spooge behind.
Does tape actually provide enough impedance to prevent surveillance through your microphones? Seems like all an attacker would have to do is amplify (and possibly filter) the audio a bit.
I turned up the mic all the way, did a skype test call. I could hear myself if I shouted (input level=0). If I talked at a normal volume level, it was audible (and the input level showed as 2/15. I might try a couple of layers of tape...
EDIT: Yeah, 2nd layer of tape = 0 input level even if I shout really, really loudly. You can't imagine how much my coworkers are enjoying this experimentation!
Skype has a noise gate - any play on the microphone below a certain level is cut off. Someone with direct access to your microphone can listen without the noise gate and might still hear.
Doesn't physically turn off the internal microphone. I've found out the hard way: I have a headset with a hardware mic switch. If this switch is in the "off" position when headphones are put into the jack, the mic built into my mac still operates.
Plus on MacBooks there is a second microphone to gather surrounding noise to improve sound quality. I don't think there is any non intrusive way to stop it from activating either.
You can, for example, set up an aggregate audio device in the audio input/output config panel to enable all inputs and outputs to work at the same time. So it's not unreasonable to think that the internal mic could be activated even with something plugged into the jack.
Well I was playing around a bit more, and I was able to disable the(or a, not sure how many are in 2010 MBPs) internal mic by taking an old audio input jack (cutting the wires), plugging it in (so it looks like a nub sticking out), going to the audio settings and setting the audio port from "Sound Output" to "Sound Input" and the internal mic picked up no readings. Still trying to figure out how to do that from the command line.
My current Thinkpad has a physical switch to disable radios. I'd like to have a physical 'privacy' switch that cut the power to internal microphones and cameras.
To be security aware, this has to be an auditable hardware power switch, and not just an interrupt/driver/bios combination that could be bypassed. It's also prefereable for security to have a an off-by-default switch, than an activity light you might not notice...
Great idea. Must be a physical switch that just cuts all physical links between the camera/microphone and the rest of the system, so that no reprogramming is possible. Unfortunately, little chance to see it in Apple products, as such switch would probably not look "slick" and would probably be considered "confusing for the user" and as such not suitable for implementing.
> Unfortunately, little chance to see it in Apple products, as such switch would probably not look "slick" and would probably be considered "confusing for the user" and as such not suitable for implementing.
That was my first thought, but then I realized the absolutely ridiculous extent to which Apple goes to build secure devices, and how "slick" the mute switch is on iPhones and iPads.
That's unfortunately the exception rather than the norm. I have seen laptops with switches for WiFi, and camera obturators, but manufacturers hardly think about these things. It's obviously not an Apple problem only, but it certainly hinders usability to have physical switches. Yet, I really wished they'd make that standard for all media peripheral (and not just on PC, but any device coming with these features). That would however be easily considered as an admission of failure to provide a secure software environment to their customers, and they might not like that aspect of it.
It's also cheaper to "just do it in software". Some laptops will seriously overheat if left turned on without an OS loaded, because the *s that designed them didn't even bother to hook up the temperature sensor to the fan controller and left the "hook up" to OS-level drivers.
My Dell has a wireless switch also, but it doesn't work under Linux, only Windows. In Linux, the radio remains on no matter what the position of the switch is. Meaning its's really a software switch, and hence worthless for security.
Sorry to burst your bubble but actually that "physical switch to disable radios" is, if I remember correctly, just another signal to the wireless card (which runs its own firmware as well). It's not a true power kill.
Some hardening guides suggest having the camera and microphone removed by an apple tech. I'm considering having this done on my next laptop - I just don't use them that often.
That's one big advantage of my old FireWire iSight camera – if the FireWire cable isn't plugged in, you _know_ it's not taking pictures.
(And now I half expect to read a new Snowden paper tomorrow detailing how the NSA coerced Apple into fitting batteries and flash storage into webcams so they could be instructed to covertly record video while not plugged in and upload it automatically later…)
Also note that a speaker can be used as microphones as well. (In physics terms they are the same device, which can convert sound to electricity or vice versa.) With modern sound cards having reprogrammable inputs and outputs, I wouldn't be surprised if even a laptop with no microphone installed could record audio.
(My friend once had to record herself for a foreign language homework, but her microphone broke. I instructed her to plug her headphones into the microphone jack and ust them instead. It worked, but she had to talk loudly to make them work.)
The RSA acoustic key recovery hack is particularly terrifying in this instance. Turning on the microphone on the computer can furnish an attacker with everything they need to recover encryption keys stored on the computer.
One of my friends always keeps her MacBook open, and had Skype set up to auto-answer video calls. (Until I fixed that for her.) She's a very educated professional woman who teaches at a university you've heard of.
In other words, HN readers might come up with defensive hacks, but 99% of the population is completely vulnerable to all kinds of spying, whether government or stalker, and the situation can only get worse as wireless electronics pervade every part of our lives. Books? Internet-enabled. Fridge? Internet-enabled. Car? Internet-enabled. Our own bodies? Carry wireless-connected smartphone 24x7.
One could argue that devising an effective privacy strategy to build into new device categories would be a waste of time until the devices are sufficiently popular enough to warrant the effort.
Now that we've reached that tipping point there should be sufficient interest from an adequate number of skilled and educated people to begin to work on solving this problem.
I wonder where the balance of good things vs bad things that've happened due to software-enableable laptop cameras currently sits?
I strongly suspect that the number of stolen laptops recovered thanks to the owner being able to use the camera to "invade the privacy and potentially take creep-shots" of the unauthorized current user, is way way smaller than the number of people who've had their privacy invaded and potentially had creepshots taken by their laptops unauthorized "p0wners".
Honestly, I don’t understand why it’s so difficult to create a camera chip not susceptible to any software hack. The camera sensor needs electrical current to work. Simply place the LED inline or in parallel to the camera and you are done. Any time current is sent to the camera sensor, the LED cant help it but light up. My knowledge of electronics is limited, but I know for a fact that this can be achieved without the use of any reprogrammable microchips, with the use of a simple electrical circuit.
IIRC, in my old Macbook (early 2008) the led is actually inlined. Some machines had a weird hardware bug that shorted this area and sometimes the led would go on... and the camera would be useless until next reboot (mine was one of these, didn't realise until ~after 6 months of owning it
Now all you have to do is warn users that the one LED is important and means something. Not like all the other LEDs that are on all the time and are mostly pointless.
> When the school district investigated the case, it found other incidents of webcam spying, and notified the students involved, including Levin. According to the lawsuit, filed in Eastern Pennsylvania District Court, Levin's younger brother commented on a light near the webcam that appeared to go on and off at odd times. His mother "dismissed the idea as absurd," but it appears he was right.
"Now all you have to do is warn users that the one LED is important and means something. Not like all the other LEDs that are on all the time and are mostly pointless."
No longer plastering devices with semi-pointless LEDs would help. Harddrive activity? Wifi? Bluetooth? I don't think all these lights are really necessary. Throw one on the power cable maybe, and a few to backlight the keyboard, but otherwise only use them as indicator lights for things that are actually important to the standard user.
Hey, I find the hard drive light very helpful in determining whether my system is thrashing for virtual memory, or likely stuck on some CPU-bound process.
The problem is that getting top to start can take a long time if it's actually thrashing heavily enough.
I'd agree that the LED is nonessential with HDDs -- you can just listen; and then you can even make out whether it's doing a lot of seeking or long continuous accesses, but you can't do that with SSDs.
>HDD light blinking? That means it's working correctly. Am I right?
In a lot of ways that is correct. Generally, when something is thrashing the hard drive it is making actual progress on its task, and its task is relativly short lived. This means that if your computer is going slowly, and the HDD LED is active, you can likely wait for the HDD LED to quiet down. In contrast, when your computer is going slowly (or not responding at all) and your HDD LED is off, it is much more likely that something is wrong and won't resolve itself.
That's the only LED that I actually miss on my MacBook. So much so that I have a virtual LED for this in the menubar. That and the batter indications LEDs older MacBooks used to have. The rMBP is missing those as well, not sure why they got rid of that.
I have a computer without a hdd indicator light and sometimes I miss it (like when I am fullscreened and a sudden lockup caused by unswapping lots of stuff occurs), but ultimately I haven't found it to be a big deal.
NO, that is the wrong way to go. HDD is important (especially if you have an SSD) because it shows when it's being accessed, Wifi is even more important because you're communicating over the network when that one activates, and if it's doing so without any reason to then you should suspect something going on (like malware infection). Ditto for BlueTooth. If they're implemented well, hardware indicators are impossible to fake.
One of my biggest gripes is how MS removed in Win7 the little connection icon in the system tray that shows when data is sent/received (it even split send/recv into two separate indicators, rather clever I think.) IMHO the trend of "simplification" is going too far. How about educating the users instead of making them more ignorant by hiding anything that they "wouldn't know about" (and making it harder for them to even start wondering about - and thus possibly learning)?
A Wi-Fi indicator is pretty useless for most users to detect malware infection because there's so much else that might be using the network at any given moment on a modern system. Likewise, I can't remember the last time I needed an HD access indicator. Don't need more things blinking at me conveying nothing useful/actionable.
Well, on MacBooks it’s the only LED. Ok, that’s slightly misleading, there is another one on the charging cable (indicating whether the device is connected to power and whether or not it is charging).
This to me seems more like an application of Occam’s razor. Hardware or Software malfunctioning seems much more likely than someone spying on you.
Malware that spontaneously lights the LED without activating the camera so the user becomes accustomed to a false indicator. Or have the LED turn anytime the machine is left idle (but still on) in order to burn out the LED.
Is it feasible to burn out the LED? Those things have lifespans of up to 100,000 hours, which means it's likelier the computer itself would be broken or obsoleted before the LED itself burns out.
Indicator LEDs usually just dim (unnoticeably) over time. Catastrophic failures do occur, but tend to be more likely with high-power torch/backlight LEDs that are driven hard to produce the most light rather than indicators which are operated at "visible but not too bright" levels. I have a keyboard from '86 and its numlock LED is still working perfectly fine after nearly 3 decades.
Now all you have to do is warn users that the one LED is important and means something.
There is already a common pop-culture shorthand for "now recording," the blinking red light. That's cheap and simple, and everyone already knows what it means, particularly when it's on a camera.
The real question, in my mind, is how the world-renowned user-experience and user-interface experts at Apple decided to use anything else.
Well, Apple and supporters (obligatory disclaimer: I own, and love, my rMBP, iPhone 5, and have two iPads in my house) have claimed that it was the case, and that it was physically impossible not to.
Then again, Apple’s marketing for the iPhone 5s made many claims of “subdermal fields”, “RF micro fields produced by the human body”, and how, as a result, it couldn’t be faked.
Except it could. Fairly easily. And without any remote pretense around the ‘emulate a live finger’. Just the fingerprint.
Much as I like Apple, these are pretty bold-faced deceptions.
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 demonstrably, implemented by every camera (ignoring hardware defects regarding the LED). The second is, as proven by the paper, not fulfilled by any.
{EDIT: added the malicious part to the 2nd requirement}
I thought the same as well. An LED in series with the circuit powering the CMOS sensor is all that would be needed. No amount of reprogramming is going to bypass a physical circuit.
This is disappointing, and I expect Apple will redesign the cameras because of it.
The LED is wired up directly to light up in the opposite state of the standby signal (i.e. off control) to the camera module.
However, the camera module has a programmable setting to ignore its standby pin, and the microcontroller can be programmed to do whatever it wants with the (now ignored) standby pin.
The fact the camera controller could be reprogrammed from user space and then used to emulate a keyboard or mouse and bypass security / a virtual machine particularly devious, and shows how hard it is to trust even known hardware.
It's not really the camera controller that can be reprogrammed, it's the USB controller - there is a setting that the USB controller changes in the camera chip, but there is a nontrivial amount of logic done on the USB controller.
Still, it's a very, very cool hack: they reprogram a microprocessor to send commands to another microprocessor and configure it in such a way that it enters a state where the pin that the LED is connected to is irrelevant.
> This is disappointing, and I expect Apple will redesign the cameras because of it.
The article mentions that authorities have tools to bypass the LED. I would guess that the complexity is on purpose and wasn't supposed to be used by the general public. I bet the same is true for sound.
One of the best ways is to have a dedicated "Chip Enable" pin on the camera module. You then connect an LED to the state of this pin and when the Chip Enable pin is "Hight" the LED is turned on. However, there needs to be additional circuitry (an extra pin) and some work to ensure proper voltage levels are met for both the pin and the LED (extra cost).
Another option is to enable the LED when power is turned onto the module.
It's increasingly common in modern ICs (SoCs and microcontrollers especially) to have only the minimum required connections be permanently assigned to physical pins. The rest of the pins are connected to some routing logic which in turn connects to the various chip internal signals. This is great in board design because you can often simplify PCB routing by reassigning pins as you need them for your layout, rather than other other way round.
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.
Having an inline LED is still a bit over-engineered in my opinion.
The earliest standalone webcams, for instance Logitech models and the IndyCam that came with the Silicon Graphics 'Indy' workstation, had a 'door' that you could slide over the lens when not in use. Lenovo had this on their all in one PC's a few years ago but I don't think they kept that feature.
What was wrong with the slide-across lens cover?
You would think it would be an essential feature for some.
> Having an inline LED is still a bit over-engineered in my opinion.
Overengineering usually refers to something that's not simple or elegant or a solution which represents more effort than the problem calls for. None of those factors seem to apply here.
I'm pretty sure you don't understand the significance of the "inline" in "inline LED." We're talking about an LED that will always light when the camera is powered up because it gets power when the camera itself does, from the same physical wire. It is on if the camera is getting power from the port. You could build a prototype with an LED spliced into a webcam's USB cable if you need to convince yourself that this is possible.
It's not a software hackable thing because of the physical orientation of the LED. This is where the current designs get it wrong by making things too complicated (though they have their reasons).
edit: I'd note that these features we're talking about aren't mutually exclusive
You're missing the "tamper evident" part. A laptop with the LED wired using a microntroller looks externally identical to a laptop with the LED wired inline. But you can always tell whether a cover is over the webcam or not just by looking at it.
A mechanical sliding piece of material without any electrical components at all must be considered simpler (and thus "less engineered") than an LED, mustn't it?
I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Also, USB is a bus, you can't splice an LED into the power line of the USB going to a camera and conclude that when the LED is lit, the camera is recording. There's a lot of other traffic that could be happening beween the host and the device, that doesn't mean the camera is performing any recording. The reverse would of course be true, though (no light = no recording).
> A mechanical sliding piece of material without any electrical components at all must be considered simpler (and thus "less engineered") than an LED, mustn't it?
Looking at my current macbook lid, I don't how how that would physically fit. The camera would need to be recessed further into the lid to accomodate for the door.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
I'm inclined to believe that a mechanical sliding door would have a higher failure rate than an LED.
> A mechanical sliding piece of material without any electrical components at all must be considered simpler (and thus "less engineered") than an LED, mustn't it?
Absolutely not. The moving parts vs. no moving parts divide is pretty huge, and an LED is not a complicated thing.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Having the LED in parallel on the power line is impossible to subvert without a soldering iron. I don't know why people are having trouble understanding this bit.
Perhaps to do this properly with a USB camera you'd need to give the camera its own USB controller. My god, who cares? The USB thing was just an example. The point is that you can wire in an LED such that when the camera has power, the LED has power.
> that doesn't mean the camera is performing any recording
The light today doesn't signify "recording," it just signifies that the camera is on.
Well, Ideally I wouldn't want to keep opening and closing the slide up and down. So this is simpler but not nearly that useful. Apple strives to be secure and easy to use. That's why the top dollar for apple products.
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.
No; I don't think any of the suggestions here can solve the 'someone might be spying on me whilst I'm already using my camera' problem - that's a very difficult one to cater for.
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.
A sliding lens cover is an exposed moving part, more prone to breakage and filling up with gunk, and also makes it more likely to smear the webcam with finger oils.
It's not difficult, but it makes the system unflexible, The vendors, not worried about the privacy implications, choose what makes the system more flexible.
I've heard that this was a serious flaw in Google's opinion, and they went through great efforts to ensure that the LED for the chromebook pixel was actually hard-wired into the camera's electronics. Which if true, shows that it's indeed possible.
It's not difficult, but it makes the system unflexible...
Um. That would be exactly the point of doing it, in this case. The camera indicator (and the microphone indicator that every laptop should but currently does not have) should be completely inflexible.
What "flexibility" is added by having an indicator that only sort-of indicates, anyway?
Seems like, at worst, any sort of manufacturing inflexibility is solved the same way they usually deal with this stuff: A ribbon cable. Then you just have to worry about the physical security of the machine which is its own independent issue regardless.
Personally, I assumed they did it this way since it seems obvious (that's what I do in my own electronics projects) and much simpler than using a microcontroller to do it. I forwarded this idea to concerned friends. Looks like I'm eating my own words.
"flexibility" is the same reason for why we have software designs that are many times more complex than necessary, an IMHO it's a line of reasoning that should be questioned more.
As a compromise, the indicator could be wired-OR: software can turn on the indicator if it wants to, and it gets turned on if the camera is on, but software cannot turn it OFF if the camera is on.
I am not an electrical engineer, I can't really judge the appropriateness or feasibility of various solutions.
But in the research paper cited by the Wash Post[1], there's a whole section where the authors discuss their recommendations, see under "VIII. SECURE CAMERA DESIGNS". Including some specific suggestions of how you would implement this design in hardware.
> Simply place the LED inline or in parallel to the camera and you are done. Any time current is sent to the camera sensor, the LED cant help it but light up.
So, upon (my incorrectly) presuming this was how it's already done in hardware and reading the headline of the article before I got to the text, I assumed they were turning it on and taking a single frame and turning it off fast enough that the LED was only on for a short enough time for the user not to be able to see it (or not notice).
Turns out the article claims they just reprogrammed the microcontroller to not turn it on in the first place. Of course that's a bad design, but you do need some more logic in there - the light needs to stay on for a minimum time when the camera is functioning so that the user can notice it.
This, too, is simple enough that it can be achieved without a microcontroller, but please don't presume that it's a simple fix. It's not just "put it in parallel".
Story time .... a while ago I had a similar discussion with someone because I said I have a thick black tape on my Macbook's webcam and I rest easy knowing I cannot be spied on using that camera unless the laws of physics change.
Of course many people made fun of it and mentioned "blah blah you are paranoid the LED cannot be manipulated and will always turn on ...".
Well ... here you go. Where are you now?
I wouldn't be surprised if someone-cough-you-know-who-cough had influenced the design for this to become a possibility. We know they are actively looking for opportunities like this. Go ahead, call me a paranoid again ... and next month when the story about how they did just that hits hacker news, I'll have an even better story to tell.
> The same technique that allows us to disable the LED, namely
reprogramming the firmware that runs on the iSight, enables
a virtual machine escape whereby malware running inside a
virtual machine reprograms the camera to act as a USB Human
Interface Device (HID) keyboard which executes code in the host operating system.
Seems that way. It wasn't too long ago there was a post about new breeds of malware that target various microcontrollers throughout a PC, able even to "hide out" in something like an optical drive to avoid detection or removal.
I really would hate to taint my MBP with ugly duct tap on the camera, but I may have to in the future.
Months ago I read about a company that rented laptops for people to make payments on and eventually own. They installed spy software so they could locate the laptops had the user not made a monthly payment. Employees were spying on users while they were having sex and other things. This wasnt on MBPs but they still managed to not notify the user.
Good point. That would also be an issue with the ice-pick method I guess.
It might be possible to drill out the webcam from the backside so long as you were very careful to not drill too far, but if that is how your computer is set up you should probably look for a safer method.
ifixit has some tutorials on how to remove the monitor glass that I've looked at before. You may need some special tools though and it isn't recommended for the retina displays.
>All these tape/paper/etc advices to cover the webcam
Jesus Christ, guys. Do you use Linux?
Just blacklist the webcam module to preventing it from loading whenever the system boots. Want to use the webcam? Load the module manually.
# modprobe uvcvideo
Want to unload the camera again? Easy.
# modprobe -r uvcvideo
Generally, it's the uvcvideo module, but it might change from system to system.
A malicious code would need root access to your system to load/unload the webcam module. If someone has root access to your computer/to execute code in your computer, you're in MUCH, much deeper shit than if you let someone film you. Seriously. Specially if you use your computer for money transactions or talk about important stuff to people.
The same thing is possible on OS X with kextload/unload and kextutil. Moving the extension to a "disabled" folder and so on, and you have a camera without a driver.
I would say that it's still notable even if it relies on root access, since it's been previously believed that this was not possible with software at all.
On early Macbook webcams it was electrically impossible to turn on the webcam without activating the light next to it. I'll see if I can find a source.
Edit: the story refers to precisely these early Macbooks. Yikes.
Any ideas why they changed it? Surely the circuit would be simpler like this rather than having the LED hooked up to the microchip and software controlling it.
If you have the LED hooked up in parallel with the chip, then you can't really do any fancy indication things like blink the LED, change colour (voltage level) etc. It's possible that the engineers wanted to maintain that flexibility.
Second, if the LED fails to a short your camera won't get any power. That means an expensive component appears to be broken when it's only a very cheap component, and you have no way to knowing that w/o opening up and inspecting or replacing parts. In contrast, if an isolated LED fails, one can still verify that the camera works via software, and choose not to send it in for repair.
Also, LEDs have a very small leakage current even in their off state. If somebody is hyperoptimizing power consumption they might choose to put the LED on a high impedence controller output rather than feeding off a power rail or similar.
Finally, the desired led might work off a configurable controller output, but that might not be the same as the output driving the chip enable pin. So you could require extra circuitry to convert to a compatible voltage/current level.
> Second, if the LED fails to a short your camera won't get any power.
One never puts an LED on the power line directly. That will certainly blow up most LEDs. Power rails are typically 5V or 3.3V. LED drop is about 1V (+/- 0.3, varies between part numbers). There is always a resistor in series with the LED, to drop the rest of the voltage, and limit the current. So, LED getting shorted is not a problem. This is the case even when we're driving LEDs from an o/p pin. Besides, Hobbyists often blow up LEDs because they're still learning. But how often have you seen these tiny LEDs fail in professionally designed products? I have never ever seen it happen. Degrade and lose brightness over the years? Sure. Fail? Never.
> LEDs have a very small leakage current even in their off state.
Are you talking about reverse bias? That makes no sense in this context. When you don't supply any power to it, there is nothing to leak.
> the desired led might work off a configurable controller output
That is what has led to this mess of surreptitious filming, in the first place. It's time they went back to the old ways.
> There is always a resistor in series with the LED
Sure, almost always. But there are many different voltage level, forward drop, forward current combinations for a given application. There's no guarantee, even with a ballast resistor, that the a shorted LED won't result in an effective short to the power rail (not a real short, but drawing close to the power supply's current sourcing limit). A resistor with a shorted LED results in a useless current sink, in any case.
> But how often have you seen these tiny LEDs fail...I have never ever seen it happen.
What you've seen or not seen has very little bearing on the reality that parts fail. Period. Things should be designed in a cost effective way that minimizes the possibility/effects of failures. FWIW, I had a laptop recently that had a dead LED on the front panel :-/
> There is always a resistor in series with the LED
I just meant that if your "power rail" is actually just a signal line (or whatever) for some other purpose, and the led is there to indicate activity, then even in "low" signal states where the LED isn't fully conducting yet there is a small leakage current.
And I thought I was clever for turning the light on for only a tiny split-second to take a picture... (I wasn't writing malware. I put the program on my own laptop before I sent it in to be serviced. http://ecritters.biz/applecarefacility/)
It actually is clever. I like this "go around instead of breaking" approach very much. Two similar cases:
A car magazine claimed they discovered a serious weakness in a particular brand of a steering wheel lock. The company made a series of improvements to the lock and challenged the magazine to demo their hack. The magazine guy approached the new lock, gave it a good hard yank and it came off the steering wheel.
Another one was the Flash fullscreen mode. Flash used to (probably still does) display a hard-coded warning after the app went full screen - obviously to prevent Flash apps from impersonating browsers, OSes and so on. I've seen a demo that took advantage of the fact that the text was an overlay over what the app displayed.
The demo app just went full screen and printed lots of messages in the same font as the Flash warning, all over the screen. The overlay was still visible (Flash made it impossible to hide or cover) but it was basically impossible to read. The demo then pretended it did a Windows restart - it was pretty scary :-)
Don't know, but I've seen The Club circumvented by cutting the steering wheel with what looked like gardening shears. Literally took less than two seconds to remove the device.
Split second as in actually significantly under a second? I've never been able to get mine to take a picture without lighting up for very nearly a full second.
Consider that the optical nerve is shut off when eyes move from one target to another. What human "sees" during that time is a retained image, so he is effectively blind. If you make something appear on screen away from his focal point it might distract user enough to be blinded while his focus moves across the screen, so the green dot won't be seen.
It really was significantly under a second. This was a much older model of MBP, though. A comment elsewhere in this thread suggests that maybe Apple switched from simply wiring the LED in with the camera to using a microcontroller for this very reason -- so the light would stay on for a minimum amount of time.
First: peer review. If your design documents are readily available, researchers don't have to reverse engineer them. Also, by open sourcing hardware design you lower the bar for critique: you might get feedback from an experienced electrical engineer who might not know how to write and upload a custom firmware for a USB controller.
Second: you can easily change it because it's not a black box.
NSA information assurance guidelines specify that one should cut the cables to all unnecessary IO devices before deploying hardware in a sensitive environment.
It's safe to assume they left a few things out, but part of NSA's mission is to protect the communications of US interests (government and enterprise) so it actually is part of their mandate to give advice like this.
The obvious solution is of course a bit of tape, but that's less convenient when you do actually want to use the camera.
I notice that the EFF have some nifty little 'ultra-removable adhesive' stickers[1] that might do better, but what would be better is some sort of low-profile adhesive backed sliding cover.
...
It appears I spoke too soon, there are already plenty out there, with mixed reviews. The 'iPatch'[2] looks interesting.
Notes from the article: they demonstrate it on a black macbook from 2008. They don't have a "modern" version of their disable-webcam-LED exploit.
The victim they talked to mentioned "she never saw the light on her laptop go on" — that doesn't mean it didn't, it just means she could have just not been looking for it.
Ideally, your webcam LED will be wired with your webcam itself. For your webcam sensor to be powered up, the LED will be powered up as a physical requirement of sending power to the webcam sensor. Many lesser-engineered webcams have software controlled LEDs (kinect bar, generic egg-shaped webcams) that don't even take "hacks" or "malware" to disable LEDs—you just run "turn led off."
Interesting to note: iPhone and iPad and a lot of Android devices don't have a camera indicator LED. While it is difficult to distribute iOS Apps outside the AppStore (where Apple would hopefully reject an App accessing camera information without informing the user) this totally could happen with Android Apps distributed outside of App Stores.
A while ago I wrote a component for the iPad that emulates the proximity sensor of the iPhone by measuring the brightness of images the the front camera captured. There was no way for the user to detect that I was actually capturing images.
I want hardware on/off switches for camera, microphone, wifi, bluetooth, and maybe even external speakers. These should be power switches, not switches that make a polite request to firmware for the firmware to act as if the devices are off.
Although I haven't looked into it in detail, yet, the T430 I have at the moment has a physical switch for WiFi and Bluetooth functionality.
I want the same for the built-in camera and mic. A little physical "red switch" that no amount of coding can defeat.
I agree with others, here. I'm worried at least as much about the microphone as I am about the camera. I can always physically block the camera -- and control what it is pointed at.
Further, I'm not comfortable with plugging in a microphone to "override" the built-in microphone. Physical design alone leaves me certain (although without proof) that this "override" is controlled by code. And a bit of experience with software that overrides such defaults to allow simultaneous input over multiple, "normally" orthogonal channels leaves me convinced that such can likely be done with the internal microphone of most devices.
Actually, it worked even better than I expected - it still chimes, but almost inaudibly, which means it won't wake anyone up but I can still tell I've hit the power switch - so $10 duly donated. Thanks v. much.
When turning on the macbook, hold the mute button. While this will last through reboots, I can't guarantee it since the setting seems to reset when I boot into windows or a liveCD.
I never get it - probably because my default volume is 0 (which is overridden nicely when I choose an alternate output source - like BT headphones or the headphone jack).
In fact, I'd like these switches to be above the F-keys and to have tiny LEDs that glowed when the switch (not the device, just the power switch) was allowing power to reach the device. I still want indicators showing when the devices themselves are operating, but for security purposes, I would treat the power switch LED as a warning that the devices have power and, therefore, could be on whether they claimed to be or not.
There was an article about this before - with a case where a hacker in California tried to blackmail students who he'd spied on having webcam-sex during a long term relationship.
Since I read that, I've been keeping a piece of post-it note on my Macbook Air camera, although it does fall off occasionally (and I need to remove it, very rarely, to actually use the camera.)
I've just upgraded it to a proper piece of card with real tape. ugly, but effective.
That the victim in this case didn't see the light, doesn't mean that it wasn't on. She might just not have noticed it. If the older models required so much effort to hack, i doubt it got easier with the newer models, especially since we are talking about Apple here.
Obv. its still a problem, even if the light turns on. Taking a quick picture doesnt requite the light to be on for long, so it could go by unnoticed.
There's quite a bit of alarm here and in the wording of the article. But no mention of HOW this exploit is applied. I mean surely they're not saying you send someone an e-mail and if they open it their webcam firmware is changed? Or visit a web page or have a flash banner ad run?
You'd have to get the user to download and run a package installer that prompts for an admin password RIGHT?
In other words; this isn't just something that can happen without end user interaction.
> You'd have to get the user to download and run a package installer that prompts for an admin password RIGHT?
In theory; but a motivated party with sufficient resources could simply ("simply") author a fake OS update and deliver it to you over a compromised ISP and you'd never know the difference.
You would just chain multiple exploits. For the right price you can buy a zero-day exploit for anything you want -- for the browser, OS & root access. If you have the money, installing the camera exploit in place is trivial.
To do this you need code execution privileges on the target machine, but there are many ways to do this (social engineering, browser exploit, etc). The research is specifically about disabling the camera light.
Nope. The paper explicitly states their assumptions. Asking for admin password (root) is not one of them. If you can get them to run a game (for example), you can pwn them.
I'm just playing devil's advocate here... Your argument for "open software/hardware" doesn't apply here. There was an exploit found in almost 6+ year old hardware/software. Has nothing to do with the fact if it is open or not. "Open" != "non-exploitable" || "flawless".
Also applies to crypto-accelerated CPU instructions.
With OSS and OSH, at least there's a chance of auditing what one has is what was released, and a chance to audit that there's no funny business going on.
... The voice came from an oblong metal plaque like a dulled mirror ... The instrument (the telescreen, it was called) could be dimmed, but there was no way of shutting it off completely. (1.1.3)
Oceanians live in a constant state of being monitored by the Party, through the use of advanced, invasive technology.
It was terribly dangerous to let your thoughts wander when you were in any public place or within range of a telescreen. The smallest thing could give you away. A nervous tic, an unconscious look of anxiety, a habit of muttering to yourself – anything that carried with it the suggestion of abnormality, of having something to hide. In any case, to wear an improper expression on your face (to look incredulous when a victory was announced, for example) was itself a punishable offense. There was even a word for it in Newspeak: facecrime, it was called. (1.5.65)
What's aggregated about you? Are you against this monitoring that protects us from fear and terrorism? Did you state that in some online devious hacker forum?
I'm not crazy, yes. When I first purchased a laptop with a camera (MBP 2008) I put tape on it. I did some research and found that the NSA had published a report that stated they could not confidently secure the iSight camera from external access. trying to find it now.
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.
There is a freely-available kernel extension[1] to make this firmware hack accessible to root only. The exploit depends on modding the camera firmware from userspace.
The kext is created by the same authors of the paper[2] this article is talking about. Search the paper for "iSightDefender".
240 comments
[ 19.7 ms ] story [ 4782 ms ] threadI own a Logitech C920 Pro and a software called webcam settings allows me to easily turn off the lights. If this software can do this, so can a malware.
Also, a malware can be designed to click quick snaps when there is no keyword or mouse activity for a specific period. This can help the malware go unnoticed without controlling the light. Want to take it to the next level? You can use the mic anytime to estimate the user's distance from the system and then enable webcam accordingly. I know this would not be very accurate, but possible.
It is about the Macbook iSight. There is definitely no (official, known) software that allows you to turn off the privacy light. The Apple engineers intended it to be impossible to disable, and believed it was.
Especially since there is no LED to signal the microphone is active, it doesn't need to point anywhere. If it could be activated while the laptop is closed (force wake up a part of the OS for just a few minutes here and there for instance) it would be a really tough problem.
One does not simply unload/delete kernel module on an iPad...
EDIT: Yeah, 2nd layer of tape = 0 input level even if I shout really, really loudly. You can't imagine how much my coworkers are enjoying this experimentation!
I'd want something more certain for a higher security situation, but this might do me for some "casual" use cases.
osascript -e 'set volume input volume 0' doesn't really produce the expected result…
This is with a mid-2012 macbook model.
That was my first thought, but then I realized the absolutely ridiculous extent to which Apple goes to build secure devices, and how "slick" the mute switch is on iPhones and iPads.
I wouldn't bet against it.
Agree entirely though.
I'd rather like a physical off switch as well like the original IBM PC (the big red lever)
(And now I half expect to read a new Snowden paper tomorrow detailing how the NSA coerced Apple into fitting batteries and flash storage into webcams so they could be instructed to covertly record video while not plugged in and upload it automatically later…)
(My friend once had to record herself for a foreign language homework, but her microphone broke. I instructed her to plug her headphones into the microphone jack and ust them instead. It worked, but she had to talk loudly to make them work.)
Embrace Big Brother, folks, 'cos he's here.
In other words, HN readers might come up with defensive hacks, but 99% of the population is completely vulnerable to all kinds of spying, whether government or stalker, and the situation can only get worse as wireless electronics pervade every part of our lives. Books? Internet-enabled. Fridge? Internet-enabled. Car? Internet-enabled. Our own bodies? Carry wireless-connected smartphone 24x7.
Now that we've reached that tipping point there should be sufficient interest from an adequate number of skilled and educated people to begin to work on solving this problem.
I strongly suspect that the number of stolen laptops recovered thanks to the owner being able to use the camera to "invade the privacy and potentially take creep-shots" of the unauthorized current user, is way way smaller than the number of people who've had their privacy invaded and potentially had creepshots taken by their laptops unauthorized "p0wners".
http://www.wired.com/threatlevel/2010/10/webcam-spy-settleme...
http://www.pcmag.com/article2/0,2817,2386599,00.asp
> When the school district investigated the case, it found other incidents of webcam spying, and notified the students involved, including Levin. According to the lawsuit, filed in Eastern Pennsylvania District Court, Levin's younger brother commented on a light near the webcam that appeared to go on and off at odd times. His mother "dismissed the idea as absurd," but it appears he was right.
No longer plastering devices with semi-pointless LEDs would help. Harddrive activity? Wifi? Bluetooth? I don't think all these lights are really necessary. Throw one on the power cable maybe, and a few to backlight the keyboard, but otherwise only use them as indicator lights for things that are actually important to the standard user.
HDD light blinking? That means it's working correctly. Am I right?
If people can perform remote admin on machines 1000s of miles away without the need of green LEDs, I'm sure consumer tech will do just fine.
I'd agree that the LED is nonessential with HDDs -- you can just listen; and then you can even make out whether it's doing a lot of seeking or long continuous accesses, but you can't do that with SSDs.
In a lot of ways that is correct. Generally, when something is thrashing the hard drive it is making actual progress on its task, and its task is relativly short lived. This means that if your computer is going slowly, and the HDD LED is active, you can likely wait for the HDD LED to quiet down. In contrast, when your computer is going slowly (or not responding at all) and your HDD LED is off, it is much more likely that something is wrong and won't resolve itself.
One of my biggest gripes is how MS removed in Win7 the little connection icon in the system tray that shows when data is sent/received (it even split send/recv into two separate indicators, rather clever I think.) IMHO the trend of "simplification" is going too far. How about educating the users instead of making them more ignorant by hiding anything that they "wouldn't know about" (and making it harder for them to even start wondering about - and thus possibly learning)?
This to me seems more like an application of Occam’s razor. Hardware or Software malfunctioning seems much more likely than someone spying on you.
http://www.grafik.com/blog/2011/11/apple-sleep-function/
But yes, it's nice that they don't have a bunch of LEDs for everything.
There is already a common pop-culture shorthand for "now recording," the blinking red light. That's cheap and simple, and everyone already knows what it means, particularly when it's on a camera.
The real question, in my mind, is how the world-renowned user-experience and user-interface experts at Apple decided to use anything else.
Then again, Apple’s marketing for the iPhone 5s made many claims of “subdermal fields”, “RF micro fields produced by the human body”, and how, as a result, it couldn’t be faked.
Except it could. Fairly easily. And without any remote pretense around the ‘emulate a live finger’. Just the fingerprint.
Much as I like Apple, these are pretty bold-faced deceptions.
Except, you know, they never actually said that.
The hack is to override the camera to ignore that signal. It is a rather unique idea and probably not something anyone even considered at Apple.
-- 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 demonstrably, implemented by every camera (ignoring hardware defects regarding the LED). The second is, as proven by the paper, not fulfilled by any.
{EDIT: added the malicious part to the 2nd requirement}
-- 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.
OS X allows non-privileged users to do that for some reason though...
This is disappointing, and I expect Apple will redesign the cameras because of it.
The fact the camera controller could be reprogrammed from user space and then used to emulate a keyboard or mouse and bypass security / a virtual machine particularly devious, and shows how hard it is to trust even known hardware.
Still, it's a very, very cool hack: they reprogram a microprocessor to send commands to another microprocessor and configure it in such a way that it enters a state where the pin that the LED is connected to is irrelevant.
The article mentions that authorities have tools to bypass the LED. I would guess that the complexity is on purpose and wasn't supposed to be used by the general public. I bet the same is true for sound.
Another option is to enable the LED when power is turned onto the module.
This interlock failed because the Micron sensor Apple used had software straps that could be reconfigured to have the sensor ignore its enable pin.
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.
The earliest standalone webcams, for instance Logitech models and the IndyCam that came with the Silicon Graphics 'Indy' workstation, had a 'door' that you could slide over the lens when not in use. Lenovo had this on their all in one PC's a few years ago but I don't think they kept that feature.
What was wrong with the slide-across lens cover?
You would think it would be an essential feature for some.
The fact that you can forget it open, duh!
Overengineering usually refers to something that's not simple or elegant or a solution which represents more effort than the problem calls for. None of those factors seem to apply here.
The sliding cover is simpler and more secure.
It's not a software hackable thing because of the physical orientation of the LED. This is where the current designs get it wrong by making things too complicated (though they have their reasons).
edit: I'd note that these features we're talking about aren't mutually exclusive
I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Also, USB is a bus, you can't splice an LED into the power line of the USB going to a camera and conclude that when the LED is lit, the camera is recording. There's a lot of other traffic that could be happening beween the host and the device, that doesn't mean the camera is performing any recording. The reverse would of course be true, though (no light = no recording).
Looking at my current macbook lid, I don't how how that would physically fit. The camera would need to be recessed further into the lid to accomodate for the door.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
I'm inclined to believe that a mechanical sliding door would have a higher failure rate than an LED.
Absolutely not. The moving parts vs. no moving parts divide is pretty huge, and an LED is not a complicated thing.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Having the LED in parallel on the power line is impossible to subvert without a soldering iron. I don't know why people are having trouble understanding this bit.
Perhaps to do this properly with a USB camera you'd need to give the camera its own USB controller. My god, who cares? The USB thing was just an example. The point is that you can wire in an LED such that when the camera has power, the LED has power.
> that doesn't mean the camera is performing any recording
The light today doesn't signify "recording," it just signifies that the camera is on.
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.
I've heard that this was a serious flaw in Google's opinion, and they went through great efforts to ensure that the LED for the chromebook pixel was actually hard-wired into the camera's electronics. Which if true, shows that it's indeed possible.
Um. That would be exactly the point of doing it, in this case. The camera indicator (and the microphone indicator that every laptop should but currently does not have) should be completely inflexible.
What "flexibility" is added by having an indicator that only sort-of indicates, anyway?
Seems like, at worst, any sort of manufacturing inflexibility is solved the same way they usually deal with this stuff: A ribbon cable. Then you just have to worry about the physical security of the machine which is its own independent issue regardless.
Personally, I assumed they did it this way since it seems obvious (that's what I do in my own electronics projects) and much simpler than using a microcontroller to do it. I forwarded this idea to concerned friends. Looks like I'm eating my own words.
As a compromise, the indicator could be wired-OR: software can turn on the indicator if it wants to, and it gets turned on if the camera is on, but software cannot turn it OFF if the camera is on.
But in the research paper cited by the Wash Post[1], there's a whole section where the authors discuss their recommendations, see under "VIII. SECURE CAMERA DESIGNS". Including some specific suggestions of how you would implement this design in hardware.
[1] https://jscholarship.library.jhu.edu/bitstream/handle/1774.2...
So, upon (my incorrectly) presuming this was how it's already done in hardware and reading the headline of the article before I got to the text, I assumed they were turning it on and taking a single frame and turning it off fast enough that the LED was only on for a short enough time for the user not to be able to see it (or not notice).
Turns out the article claims they just reprogrammed the microcontroller to not turn it on in the first place. Of course that's a bad design, but you do need some more logic in there - the light needs to stay on for a minimum time when the camera is functioning so that the user can notice it.
This, too, is simple enough that it can be achieved without a microcontroller, but please don't presume that it's a simple fix. It's not just "put it in parallel".
Of course many people made fun of it and mentioned "blah blah you are paranoid the LED cannot be manipulated and will always turn on ...".
Well ... here you go. Where are you now?
I wouldn't be surprised if someone-cough-you-know-who-cough had influenced the design for this to become a possibility. We know they are actively looking for opportunities like this. Go ahead, call me a paranoid again ... and next month when the story about how they did just that hits hacker news, I'll have an even better story to tell.
Here's the research paper linked to in the story, if anyone wants to see what the researchers have to say. I haven't taken a look yet myself: https://jscholarship.library.jhu.edu/handle/1774.2/36569
Ah, there it is right in the abstract, yep:
> The same technique that allows us to disable the LED, namely reprogramming the firmware that runs on the iSight, enables a virtual machine escape whereby malware running inside a virtual machine reprograms the camera to act as a USB Human Interface Device (HID) keyboard which executes code in the host operating system.
Ooh, neat.
Months ago I read about a company that rented laptops for people to make payments on and eventually own. They installed spy software so they could locate the laptops had the user not made a monthly payment. Employees were spying on users while they were having sex and other things. This wasnt on MBPs but they still managed to not notify the user.
http://www.wired.com/threatlevel/2012/09/laptop-rental-spywa...
A tiny piece of black electrical tape blends in nicely and won't leave gunk on your bezel.
It might be possible to drill out the webcam from the backside so long as you were very careful to not drill too far, but if that is how your computer is set up you should probably look for a safer method.
Jesus Christ, guys. Do you use Linux?
Just blacklist the webcam module to preventing it from loading whenever the system boots. Want to use the webcam? Load the module manually.
# modprobe uvcvideo
Want to unload the camera again? Easy.
# modprobe -r uvcvideo
Generally, it's the uvcvideo module, but it might change from system to system.
A malicious code would need root access to your system to load/unload the webcam module. If someone has root access to your computer/to execute code in your computer, you're in MUCH, much deeper shit than if you let someone film you. Seriously. Specially if you use your computer for money transactions or talk about important stuff to people.
I would say that it's still notable even if it relies on root access, since it's been previously believed that this was not possible with software at all.
Edit: the story refers to precisely these early Macbooks. Yikes.
Second, if the LED fails to a short your camera won't get any power. That means an expensive component appears to be broken when it's only a very cheap component, and you have no way to knowing that w/o opening up and inspecting or replacing parts. In contrast, if an isolated LED fails, one can still verify that the camera works via software, and choose not to send it in for repair.
Also, LEDs have a very small leakage current even in their off state. If somebody is hyperoptimizing power consumption they might choose to put the LED on a high impedence controller output rather than feeding off a power rail or similar.
Finally, the desired led might work off a configurable controller output, but that might not be the same as the output driving the chip enable pin. So you could require extra circuitry to convert to a compatible voltage/current level.
That's my guess.
One never puts an LED on the power line directly. That will certainly blow up most LEDs. Power rails are typically 5V or 3.3V. LED drop is about 1V (+/- 0.3, varies between part numbers). There is always a resistor in series with the LED, to drop the rest of the voltage, and limit the current. So, LED getting shorted is not a problem. This is the case even when we're driving LEDs from an o/p pin. Besides, Hobbyists often blow up LEDs because they're still learning. But how often have you seen these tiny LEDs fail in professionally designed products? I have never ever seen it happen. Degrade and lose brightness over the years? Sure. Fail? Never.
> LEDs have a very small leakage current even in their off state.
Are you talking about reverse bias? That makes no sense in this context. When you don't supply any power to it, there is nothing to leak.
> the desired led might work off a configurable controller output
That is what has led to this mess of surreptitious filming, in the first place. It's time they went back to the old ways.
> There is always a resistor in series with the LED
Sure, almost always. But there are many different voltage level, forward drop, forward current combinations for a given application. There's no guarantee, even with a ballast resistor, that the a shorted LED won't result in an effective short to the power rail (not a real short, but drawing close to the power supply's current sourcing limit). A resistor with a shorted LED results in a useless current sink, in any case.
> But how often have you seen these tiny LEDs fail...I have never ever seen it happen.
What you've seen or not seen has very little bearing on the reality that parts fail. Period. Things should be designed in a cost effective way that minimizes the possibility/effects of failures. FWIW, I had a laptop recently that had a dead LED on the front panel :-/
> There is always a resistor in series with the LED
I just meant that if your "power rail" is actually just a signal line (or whatever) for some other purpose, and the led is there to indicate activity, then even in "low" signal states where the LED isn't fully conducting yet there is a small leakage current.
A car magazine claimed they discovered a serious weakness in a particular brand of a steering wheel lock. The company made a series of improvements to the lock and challenged the magazine to demo their hack. The magazine guy approached the new lock, gave it a good hard yank and it came off the steering wheel.
Another one was the Flash fullscreen mode. Flash used to (probably still does) display a hard-coded warning after the app went full screen - obviously to prevent Flash apps from impersonating browsers, OSes and so on. I've seen a demo that took advantage of the fact that the text was an overlay over what the app displayed.
The demo app just went full screen and printed lots of messages in the same font as the Flash warning, all over the screen. The overlay was still visible (Flash made it impossible to hide or cover) but it was basically impossible to read. The demo then pretended it did a Windows restart - it was pretty scary :-)
Serious weakness indeed. Not what people (especially HN readers) usually mean by that phrase!
It's actually kind of amusing to see pictures of you and notice your hair growing over several weeks :)
First: peer review. If your design documents are readily available, researchers don't have to reverse engineer them. Also, by open sourcing hardware design you lower the bar for critique: you might get feedback from an experienced electrical engineer who might not know how to write and upload a custom firmware for a USB controller.
Second: you can easily change it because it's not a black box.
Not sure where that one is, but there is a wealth of data here: http://www.nsa.gov/ia/mitigation_guidance/index.shtml
It's safe to assume they left a few things out, but part of NSA's mission is to protect the communications of US interests (government and enterprise) so it actually is part of their mandate to give advice like this.
I notice that the EFF have some nifty little 'ultra-removable adhesive' stickers[1] that might do better, but what would be better is some sort of low-profile adhesive backed sliding cover.
...
It appears I spoke too soon, there are already plenty out there, with mixed reviews. The 'iPatch'[2] looks interesting.
[1] https://supporters.eff.org/shop/laptop-camera-cover-set
[2] http://www.virtualspaceindustries.com/theipatch/
The victim they talked to mentioned "she never saw the light on her laptop go on" — that doesn't mean it didn't, it just means she could have just not been looking for it.
Ideally, your webcam LED will be wired with your webcam itself. For your webcam sensor to be powered up, the LED will be powered up as a physical requirement of sending power to the webcam sensor. Many lesser-engineered webcams have software controlled LEDs (kinect bar, generic egg-shaped webcams) that don't even take "hacks" or "malware" to disable LEDs—you just run "turn led off."
A while ago I wrote a component for the iPad that emulates the proximity sensor of the iPhone by measuring the brightness of images the the front camera captured. There was no way for the user to detect that I was actually capturing images.
I want the same for the built-in camera and mic. A little physical "red switch" that no amount of coding can defeat.
I agree with others, here. I'm worried at least as much about the microphone as I am about the camera. I can always physically block the camera -- and control what it is pointed at.
Further, I'm not comfortable with plugging in a microphone to "override" the built-in microphone. Physical design alone leaves me certain (although without proof) that this "override" is controlled by code. And a bit of experience with software that overrides such defaults to allow simultaneous input over multiple, "normally" orthogonal channels leaves me convinced that such can likely be done with the internal microphone of most devices.
Since I read that, I've been keeping a piece of post-it note on my Macbook Air camera, although it does fall off occasionally (and I need to remove it, very rarely, to actually use the camera.)
I've just upgraded it to a proper piece of card with real tape. ugly, but effective.
Obv. its still a problem, even if the light turns on. Taking a quick picture doesnt requite the light to be on for long, so it could go by unnoticed.
You'd have to get the user to download and run a package installer that prompts for an admin password RIGHT?
In other words; this isn't just something that can happen without end user interaction.
In theory; but a motivated party with sufficient resources could simply ("simply") author a fake OS update and deliver it to you over a compromised ISP and you'd never know the difference.
https://jscholarship.library.jhu.edu/handle/1774.2/36569
> But researchers figured out how to reprogram the chip inside the camera, known as a micro-controller, to defeat this security feature.
Aren't Mac firmware updates always a big deal with special boot modes and audio tones?
There's really only 1 solid solution to this:
Open software and open hardware.
Edited for bad boolean.
Also applies to crypto-accelerated CPU instructions.
With OSS and OSH, at least there's a chance of auditing what one has is what was released, and a chance to audit that there's no funny business going on.
WEAKNESS IS STRENGTH
What's aggregated about you? Are you against this monitoring that protects us from fear and terrorism? Did you state that in some online devious hacker forum?
INFORM and VOTE
The kext is created by the same authors of the paper[2] this article is talking about. Search the paper for "iSightDefender".
[1] https://github.com/stevecheckoway/iSightDefender
[2] https://jscholarship.library.jhu.edu/bitstream/handle/1774.2...
I'd MUCH rather see an admin password prompt come up, instead of nothing all.