Can the correct QR Code shut down a digital security camera system?
Only if you paste it to a brick and then use the brick to smash the camera.
I suppose that a video system for, say, factory process monitoring could be set up to respond in different ways when it scans certain bar codes (End of Row, Stop) but there’s no general secret code that will make systems shut down or do anything else.
Only if the security camera has software/firmware that interprets QR codes - they’re just barcodes - not magical basilisks.
It is, however, possible for a camera to have some sort of design flaw that could cause it to shut down in certain conditions and those conditions could be very specific (complexity of a specific image could crash the compression algorithm, for example), but such cases would be unique and probably pretty obscure - certainly not general enough to be used as some sort of universal shutdown weapon.
I’ve experienced one real-world case that I suspect was something like that, on a smartphone camera.
The only QR codes I’ve used with security cameras is the sticker on the DVR to make installing the phone app easier.
Maybe in the next Mission Impossible movie but not real life.
Like other plot devices for “back doors” they aren’t put into a secure system.
Someone could deliberately sabotage security recording systems so that the firmware for the camera
-
Contains QR code reading routines. As a side note, this is computationally expensive - if you’re pinching pennies making cameras, I think there are dedicated ASIC video compression chips you can use that will not have the flexibility to even run such software.
-
Responds to a specific QR code
Oh, but this won’t delete the recordings going up to the point that the person waved the code in front of the camera. So you’d actually need to make the DVR that records security feeds actually process each stream, and when it reads the magic code, causes retroactive deletion of the records.
This is all technically possible, but it’s not small flaw. It’s a huge and computationally intensive feature to add to a security system - not something a rogue programmer could easily sneak in. It very well might require changes to the hardware for the security system to add an additional, or beefier, processor to run the decoding routines.
And, amusingly, features like this in software projects that are poorly tested tend to fail. A more realistic movie scene would be an attempt to use this, but the coder they bribed to insert this feature fails to reliably read the code, and so they have to keep trying, tensely, while a guard is about to catch them.
Realistically, it’s so much easier to hack any security DVR via the Internet, assuming it’s connected. And they usually are so people can monitor them remotely. And, as SamuelA pointed out, they are made as cheaply as possible, which means either security from the lowest bidder or open source software - which can be secure if you keep it up to date, but in practice means they use an old version and never update it. Heck, you’re lucky if the person setting it up ever changed it from the default admin password!
That’s exactly what I thought when I saw the OP.
Note that it may not work for roughly a thousand years.
Oh, and as Howard Tayler mentioned in a commentary box in the book where those strips appeared, even in a thousand years it will only be possible if those security cameras were never properly secured and had a terrible default administrator password.
The QR code in the strip says: “UID=ADMIN PASS=DEFAULT CMD=SLEEP[600sec noprompt fnord]”
Actually, the security cameras in that strip had multiple vulnerabilities, since even after they found out about the first attack and changed the password, Kathryn was still able to hack them again, using a different command but the same method.
Of course, by the time of those strips, computer technology has advanced greatly, and it probably is cheaper to use general-purpose hardware and firmware capable of reading and interpreting QR codes than it is to custom-make something that’s deliberately weakened enough that it can’t. For a security application, they really should have paid extra for the custom build anyway, but apparently they didn’t. Keep in mind, of course, that this was just a shopping mall security system, so they probably spared every expense (which would perhaps even have been justifiable, given the sorts of threats mall security is typically expected to face).
Thanks for the intro–I’ve discovered I like the strip.
The OPost came from a Thread on QR, & the news about a guy that jumped the White House fence.
The two issues percolated a bit, & spawned this Thread.
Agree with your overall points. But as to the tidbit above here’s another way to more easily skin that cat.
Have the camera always buffer a few seconds of video, so what gets sent out to the DVR is a few seconds ago, not real time. When the perp waves the hack QR code in front of the camera, those last few seconds are deleted from camera memory and the stationary scene from before then is sent. Or the camera just goes dark, whichever is the goal.
This buffering could be built up slowly, where a short term test of the camera would show no delay. e.g. For the first 6 hours of operation the camera relays video with no delay. But over the next 48 hours operation the camera slowly builds up a bow-wave of, say, 30 seconds of buffered video. Thereafter it sends the 30-second delayed video one-for-one while buffering fresh video. And patiently awaits the triggering QR code.
Agree this is all Hollywood stuff. But not impossible for all that.
Word of warning: you will want to consume it all. That’s almost 17 years of daily strips, several of which require research to get the punchline. 
Door number 2 is to move to a security model where devices have more clearly defined, limited functionality.
Let’s give an example. Remember how the old VHS tape/analog systems worked? The cameras had a sensor and hardware that scans the sensor into a serial analog waveform. That analog waveform gets written to magnetic tape inside the VCR. The quality was not great (it could be pretty good but rarely was in most places) but not there’s nothing to hack in to. There’s no password or network link. Either you have physical access to the VCR doing the recording or you do not.
That’s totally doable in the digital world. You use very similar sensors. You digitize the sensors right at the sensor itself, and you send the digital signals, via a parallel bus, to a chip. That chip is single purpose. There’s a lot of steps, but parallel digital signals come in, and compressed ethernet frames come out. It can’t be updated - internally it may in fact be a powerful microprocessor, but the software is burned into it permanently.
Then on the other side, a corresponding chip receives the ethernet frames in RAM and formats them into writes for the HDD or SSD media the video is actually stored on. Writes get sent to disk (really important to have redundancy at this step) and crystal clear video is kept.
So far no route in for hackers. But wouldn’t it be nice to view the feed remotely, say, for an alarm monitoring service to be able to check what’s going on? How about you develop a GUI that lets you do it all, and make the GUI the same whether you are viewing the feed remotely or not? So someone viewing remotely could potentially delete DVR data, etc. There might be software isolation but it’s probably not very good because companies making camera software and DVR are not multinational giants. (not that the big boys do much better)
Myself, I was hooked by the storyline where they needed to take Coriolis into account to shoot straight in a rotating space habitat.
I was hooked by the storyline where they had to use antimatter charges to demolish a reality TV building.
Good point. Howard didn’t say what he encoded into that last QR code, but I scanned it at high-res from my book and decoded it. That command was:
I’m going to spoiler box this next part for anyone who hasn’t read beyond that part of the strip. Kathryn and her friends used to work for an intelligence service, so they probably have far greater skills and inside information than most people when it comes to hacking security cameras and databases.
I like the “fnord” parts. Heh.
So, comic strip aside… 
You know, most of the home-grade security cameras these days are internet-connected and often running some ancient version of embedded Linux and probably with a default password set and multiple zero-day attack vectors. And QR codes are extremely flexible encoding schemes (read: vulnerable) They’re not “just barcodes” the way a UPN is . They can store almost 3kB of arbitrary data and I’ve managed to crash the sample Barcode Reader app on Android multiple times with homebrewed QR codes (not even on purpose). Buffer overflows and injections are probably entirely possible as long as the camera in question is actually set up to try to discover and read QR codes. I don’t think any of the current-gen ones do that by default, but could probably be attacked over the internet to do so. And I’m sure future cameras would start including machine vision capabilities to recognize faces, UPNs, book covers, grocery lists, business cards, blah blah and yes, QR codes – like Alexa meets Google Goggles. It’s only a matter of time before it becomes a viable attack vector.
Here’s a paper on how they could be attacked, for what it’s worth: