Once again, this is why firmware needs a hardware write-enable switch, not a software one.
Cue the arguments that remote updating is needed to fix bugs that allow remote updating. :-/
1. firmware updating
2. write-enable for disk contents
3. turning the microphone on
4. turning the camera on
In a surprise development, the webcam I just bought comes with a flip-up lens cap. Yay! It's Nexigo, they deserve a shout-out for this. But in the Dept of Half-Assed Features, the lens cap does not disable the microphone, so I still have to unplug it when not in use.
Hardware switches are easier for microphones and cameras, because you literally cut the power for a device.
Most flash chips have a write-enable line that you can put a switch on. Usually have to cut a trace but often can avoid soldering right to the legs by following traces.
Was a common thing to do to receivers (“Integrated Receiver Decoders”) back in the paytv days. Thankfully they had firmware on a parallel eeprom and config stuff on a smaller serial eeprom (that could handle 1m writes instead of 1k writes). Receivers could have a lot of wires especially after they implemented some lock-detection that had to be countered with some 74ac logic that could disrupt the 2nd step of starting a write job.
Should be doable for something like a router or cable modem, but maybe not on something like these WD drives. Like a mod chip without having to worry about the vendor trying to counter you.
Of course you’re still screwed if something is only non-persistent but at least any issues are resolved with a simple reboot.
No, it’s not. The actual low-level chip on the flash has a separate pin that must be connected to ground to enable writes.
You make an embedded Linux device with a read only partition based on a hardware switch. You figure out all the bugs that are caused by software not being able to write temporary files to disk. You figure out how to do configuration management on a separate system with something more complicated than a ten line YAML file.
Want to change your password? That's /etc/shadow -- did you some how rig that up to be writeable, while the rest of /etc was not? Also, since I presume your management decided to not let the users have root, because of course they did... You'll need to resort to software tricks to make sure the user can't change the root password.
Oh, and remember. No software read only tricks. Hardware switch.
Please let me know when you finish, I'll help audit your system.
Last edit: To all the reply guys, yes. I know it's possible. My statement is it isn't easy, and there are many challenges. (Especially compared with the simplicity of a power cut switch to a webcam.)
I can make you a microcontroller with a firmware update switch that blinks a light. By the time you scale that up to a full fledged embedded Linux system with a board designed in house, with weird hardware that is keeping you back on Linux 3.16 because nobody knows how to port your drivers, with cryptographically signed updates, fault tolerant firmware slots, and a nasty stack of software developed by web devs that can't fathom why they can't write to disk, that has to interoperate with legacy hardware and systems, that has a management bureaucracy that can't understand why it's taking so long to implement the new media server plugin, and devices in the field aren't getting automatic updates...
No. No it's not easy. Part way through, management will kill the project, you'll end up with a switch that's read in software, and eventually wind up on the front of HN as someone who did security wrong.
But by all means, take your "easy" idea to WD and tell them you'll have it working on their devices by Q1 2022.
(Aside: As for my idea of a configuration system, I’ve developed entire [incremental!] build systems that take a kernel source tree and configuration files and generate fully boot-ready images with drivers, packages, and even GUI support down to specifying the themes and customizing panel layouts, and more via a fully declarative syntax. The images have been booted on commodity hardware not under our control spanning some twenty-plus years of technology on more than a 100k machines. This is HN: not everyone is merely an armchair expert in whatever the topic of discussion is for today. It can be beneficial to assume expertise is out there and seek it rather than deny things are possible.)
In both cases you can write to the filesystem just fine. The writes just stay in RAM and don't get committed to disk.
There are cons to this approach, but you've listed none that apply in the real world
People seem to be thinking I'm saying this is impossible. I'm not, I never did. I'm sorry I'm frustrated, but it's difficult to respond to things you didn't say.
I'm saying, compared to a power cut switch for a webcam (which, I seem to remember even Apple screwed up accidently), a write protect switch is more challenging.
A power cut switch is mostly challenging mechanically. How do I get the dang thing on the case? But otherwise, that's the only consideration.
For a truly hardware based write protect switch that disables write capabilities at the silicon level, you have to adapt your image, your software, your hardware, and many of your procedures for the bring up process.
Is that challenging? For some people in this thread, I suppose not. But compared with a power cut? Orders of magnitude more challenging. Especially when you are bringing this to a massive codebase that hasn't had this as a design consideration.
I’ve also had to do it on a desktop Gigabyte motherboard circa 2009 after a successful BIOS update left the flash rom unstable.
Then there's NVRAM (non-volatile random access memory), which is usually smaller than EEPROM but has infinite write cycles, requires very little preparation to write (since it's just RAM), and is often used to store configuration data, not code.
> Then there's NVRAM
I was under the impression that NVRAM is less of a specific technology and more of a desideratum. As for implementations of it aside from ages-old battery-backed RAM, there’s FRAM used in some TI microcontrollers and (Wikipedia tells me) some other stuff, but it’s all patented to hell and back so we’re unlikely to see any of it in general use (although TI microcontrollers are admittedly lovely).
First, some internal boot ROM, likely with fuses burned in for the particular IO configuration, reads a bootloader (likely Das U-boot) from external flash memory. That first-stage bootloader initializes the parallel/SPI NAND/NOR flash interface and DRAM controllers, and then launches the second-stage bootloader. The second-stage bootloader uses those memory controllers to read the firmware image out of memory into RAM, then executes it.
If you want to update the firmware - more precisely, to change the location or signature of the image that should be loaded by the second-stage bootloader - it would be trivial to add a check for a GPIO switch to allow or deny changes.
turns out it was leeching power from another still-active device through its data pins!
there was not enough power flowing through this way to actually do something, but there was enough to keep the brownout detector from kicking in and resetting the chip
Some 10-15 years ago someone built dirt simple radio tags this way. Just a microcontroller, with a capacitor and an antenna trace connected to some io pin. I loved that hack.
It's really, really helpful to figure out which wall wart goes with which device.
Another tip I learned from another. You know those green plastic tabs that keep a bread bag closed? They clip onto a cable nicely, and write on them with a sharpie which device the other end is attached to. That really helps with the rat's nest of wires under my desk. One of them says "cam" on it :-)
Also, with respect to cables, this is really why we need tri-colored braided cables from a reputable dealer (ANKER!?): white, black, gray, blue — that gives 64 possible combinations!
I'd consider that an honor.
In related news, I used an old Android phone and DroidCam over USB as a webcam. The picture quality is stellar, much better than any webcam you might find, and it's very simple to stop it by unloading the driver (I know, I know...).
It's funny how such basic things from the past were thrown away. Every floppy disk ever had this.
However, i also believe that if such a thing existed for modern gear, it would only be used by 1% of people, and even then, mostly accidentally, resulting in millions of trouble tickets. So I'm not sure what the compromise is.
BTW, I would read TV repair manuals as a kid (yes, weird). There was always the "check to see if it is plugged in". Plugging TVs in made a lot of money for service people.
I see similar things in car manuals for car won't start. "Put gas in it."
Edit: This was back in the days when you could repair a TV with a soldering iron and a screwdriver. Every hardware store had a tube testing machine. I'd have fun by randomly swapping the tubes that fit in the same socket and seeing what effect that would have on the TV's operation.
https://devblogs.microsoft.com/oldnewthing/20040303-00/?p=40...
I was also the family "TV tube test person" as a kid. I must have been around 6 or 7.
For the young'uns, TV sets used to have tubes and hand-soldered point-to-point circuitry. Just like an ENIAC, a tube TV would always "go on the fritz" as the tubes burned out.
My dad showed me how to pull out all the tubes, and we would put them in a cigar box and go to the little corner grocery, which had a tube tester in front. I would dial up all the settings for each tube and test it, and we would buy replacements for the bad ones. Take them back home and I would plug them in, and the TV worked again! Dad was always generous and made sure I got credit for it.
BTW did you ever get to discharge the high voltage connection to the picture tube with a screwdriver and wire with alligator clips? One clip to chassis ground, the other to the screwdriver, then slip the screwdriver under the rubber insulated connector, and BANG!
> I don't buy the argument that if not everyone uses it, nobody should get it.
Here you go: https://puri.sm/security/.
Most people are surprised that speakers can be used as microphones by "running them in reverse", and so you also need a hardware switch for your speakers to maintain privacy.
Pretty much the only way this might be possible is if you had an audio port that was capable of functioning as both a TRS output and a TRS input (not a TRRS "headset" port), and had a set of headphones plugged into said port, and had a piece of malicious software that was able to reconfigure the port to act as an input.
A simple intercom is just two speakers, one on each end, wired together in a loop.
In my childhood I took apart a broken WalkMan and discovered if I connected a random ~8" loudspeaker driver in the tape head's place, I could eavesdrop on my siblings and parents from across the house by placing the speaker against the walls or floor, complete with volume control and everything.
It was incredibly sensitive, and infuriating to learn how much everyone was constantly lying and talking behind eachother's backs at that age.
That's actually a feature of many realtek sound drivers. https://www.reaper-x.com/2012/02/13/how-to-remap-retasking-r...
Most embedded PC sound cards made in the last few years have this.
(also, you'll need headphones without an amplifier as well!)
I think it was realtek built-in on a hp SFF PC.
If there's non-secret hardware inputs on the speakers... it's probably easier to just remove that.
The threat is if the speaker jack has recording hardware. That's why I said "attached to the speakers".
If you're thinking about adding a switch to disable recording via the speaker jack, for safety purposes, you should probably just remove that capability entirely.
Although at that point I think I'm more worried about the microphonic properties of ceramic capacitors in the signal path.
instead we have undocumented microphones for 'future purposes'. Thanks Google
Because paying customers don't understand or care about privacy.
Facebook is still a thing. Let that sink in.
I highly recommend them for remote working software engineers; the macros are amazing (eg start camera, lights, open meeting software in one go - then another to shut it all down).
You will still need to double check that all the mappings haven't changed for whatever reason, from time to time. (I'm on Win20/WSL2).
The answer to "Did you check the wifi switch?" is almost always "What wifi switch?".
Because then the firmware can never auto-update, but needs to be manually and explicitly done -- flick the switch, apply the update, flick again.
And clearly a significant proportion of people (probably a very large majority if we're being honest) will simply never update firmware.
So which is the bigger threat: unpatched firmware, or firmware auto-update vulnerabilities?
The answer doesn't seem intuitively obvious at all to me. But there must be stats available -- frequencies and severities of vulnerability categories, and how often people update firmware on non-auto-updating devices. So it doesn't seem terribly hard to compute an answer?
Actually, preferentially they should be taken offline and the consumer should have to opt-in to leaving them connected to the Internet, but that's a whole separate issue.
Before EOL auto-update is a vulnerability, and after EOL security patches might still be made available for the absolute worst vulnerabilities, but now wouldn't get to practically anyone.
Not arguing against the idea, just saying that the economics will never work in favor of this.