Ransomware-ing a DSLR Camera | Hacker News Reader

Ransomware-ing a DSLR Camera

research.checkpoint.com

165 pointsKye32 comments

First off, Magic Lantern is amazing, it has been a huge value-add for my camera (which I kind of hate because it disincentivizes Canon from improving its practices).

Secondly, does anyone know how ML got the encryption key and why they aren't releasing it?

As with many community ran projects based around a commercial vendor, fear of being DMCA'd out of existence is real. We can safely assume they want to be left alone by Canon and not posting the encryption key not only shows they mean no harm to Canon, it also could be argued in court that they are not violating the DMCA (despite the fact they had to obtain the key somehow, at least they can claim ignorance as to how their firmware was magically encrypted/signed - yes it's weak but its something).

What's to stop people from forking the entire magic lantern code base and putting it on a self hosted gitlab server physically hosted at a Russian or Chinese domestic ISP that ignores 100% of US copyright/DMCA threats?

The fact that the developers themselves aren’t Russian.

I really appreciate researchers like this who take the time to explain in detail the way in which they find vulnerabilities, especially when they document even the dead ends. For a relative lay person like myself, it really helps me gain an understanding and appreciation for the work that goes into keeping applications secure.

> ...even the dead ends.

I agree. I find it harder to follow a highly technical blog post that goes on and on from one productive thing to the next like a machine. I want to follow the process, not just duplicate the results. If I can just copy/paste your code to reproduce I'm never going to learn how you arrived at your results!

Yes, that is often times missing from these write-ups, and can lead me to feel more frustrated during my own projects when things don't go perfectly well on the first go!

Ironically, I thought the email from Canon was a hoax and didn’t open it yet. I’ve got some patching to do today.

I hope this doesn't make it more difficult for Magic Lantern devs.

First thing I thought of as well. It's a fantastic project and I would hate for Canon's response to this to negatively affect them, whether it becomes hardening the device's firmware upgrade process to the point that the project does not become feasible or unnecessary legal woes.

It could get even worse if the perpetrator instead of bricking the device decides to install a backdoor that silently uploads photos to a server whenever a wifi connection is established.

Cameras tend to insist on being a HostAP, not a client.

Canon DSLRs and mirrorless cameras can act as Stations.

Meanwhile in Sony Alpha land: the entire firmware is Linux based and you can pwn it and install Android payloads... but the reverse-engineering community seems to have died down :(

As expected, all CVEs are related to memory corruption issues.

Serious question and asking as not a current Rust user - is this something Rust would have prevented?

(Let's assume the any technical limitations of compiling firmware for the camera in Rust are overcome - just focusing on the memory corruption part)

I believe so. Any memory safe language (not just Rust) would've prevented memory corruption. One of Rust's aims is to target embedded development, so one might hope for software such as these to be written in Rust at some point in future.

Rust's safety mechanisms aren't about buffer overflows. But if you can get away with always using a specific vector type throughout the code (instead of using the simpler and more modular rawpointer+length/rawpointer+offset+length scheme), and you enable bounds checking when compiling, then yes, you probably can get there most of the way or even all the way. But it will be more painful in my experience, and there might be a noticeable performance overhead (I've actually never used Rust but many other languages with objects).

Isn’t Rust Vec a pointer and a length by itself?

A pointer, a length, and a capacity. Slices are pointer and length.

Yeah, you are right - I missed out the capacity part. Why is the parent pointing out Vec as being “opposed to a raw pointer, a length and a capacity”?

I believe that they mean you can’t mess it up; a slice is much nicer than two separate things. There’s no way to get them out of sync, etc.

I was pointing out vector objects (as opposed to rawpointers) mainly because I'm not aware of any other practical way to enable automated bounds checking.

Apart from that I actually find it more appealing and "correct" to have a separate length value. As soon as there are multiple parallel arrays the vector approach will have redundant length information, so from an aesthetical point from of view I prefer not to glue the length to the vector/array.

But yeah, with a separate length there is more manual work for simple tasks, so it's easier to mess up.

By being part of the same data structure and managed by the compiler there is no way to get out of sync, due to copy-paste or mismatch when several arrays are being used together.

Rust or any other language that has bounds checking enabled by default.

> is this something Rust would have prevented?

No.

(Betteridge's Law)

This type of security is often overlooked in embedded devices, especially those ones that are connected to wifi/cellular for the first time.

A good bit of advice I received was "imagine someone is trying their hardest to break into your device at every interface. What can they do?". With that mindset you can then see where to firewall every connection to the outside world to the main controls of your system.

The camera software of all modern DSLRs, mirrorless cameras and even camera lenses is total junk. I have successfully crashed D7200, D7500 by throwing random packets at them over the network ( which probably explains why the cameras only work in the HostAP mode and never as clients -- weirdly it explains Nikon's position of "it" being a security choice )

I'm now wondering if there's even a Snow Crash exploit from throwing random data in through the lens.

It's probably tricky, as thermal noise/shot-noise fluctuations are not on the side of the exploiter.

Interesting idea, though :).

I'm going to use this the next time my wife suggests unloading my old Hasselblad.

Is there a direct link to patches anywhere? Canon's press-release and the Canon USA website don't appear to have direct links.

Reply on news.ycombinator.com