 Good morning camera nerds. Yeah, a few of us in here. Um, I'm pretty excited about this talk. Um, I was also pretty excited to make sure that I had Bluetooth turned off of my camera when I showed up. Um, so I guess, uh, if everybody wants to go ahead and turn on the Wi-Fi, on their cameras now? Yeah, no? No? Okay. Okay. That's fine. Um, how many uh, so we got a lot of camera, how many camera people do we have here? Awesome. How many people find that the software on their camera is uh, something other than complete ass? By the way, that's a surprise. You can get you up on stage, or maybe you work for Nikon. Who knows? So I think we've all struggled with this and probably thought, boy this probably isn't terribly well thought out. Um, and then of course then you go buy a Canon printer these days and you get a CD with all the software on it and like, really? What year is this? Anyhow, I could, I could, I could complain about that for days. Um, right now we are going to learn about uh, how, how kind of broken the software on our cameras is and how vulnerable that can be when we are out and shooting and wanting to take advantage of some of these fancy features that uh, these camera manufacturers think we'd all need to pay extra for in the first place. Let's give Ayal, a big round of applause. Have a great time, man. Thanks. Hi everybody. Hi everyone. Thank you for coming. Uh, I'm Ayal and I'm going to talk today about my recent research called Say Cheese or how I ran some of your DSLR camera. Before I start, let's have a brief interview. Um, I'm Ayal Itkin. I'm a vulnerability researcher at Checkpoint uh, research group. In my research projects, I usually tend to focus on embedded devices or network protocols and you can usually read about my recent publications on my Twitter. Now that we've finished with the introduction, let's start. Being a vulnerability researcher usually means you study uh, a program, an embedded device, you find vulnerabilities in it, you responsibility discloses to the vendor, uh, you wait for a conference, hopefully you get accepted and that's it right? But after you finish up with the research, starts the most complicated part in uh, the routine of a vulnerability researcher and this is finding the idea for the next uh, research. And looking for new research ideas is always tough. Uh, we don't simply fall off a truck and that's it. Um, for this uh, part of my uh, daily work I have uh, practices for finding new leads for research projects. Um, the first of which is check up new technologies uh, Vajas got published. Um, if it's new and fresh, less eyes uh, looked upon it and maybe we'll find something interesting in that product. The second is attend conferences like DEF CON and hope for a good idea to pop up and that's uh, usually helpful. And the last and um, the last part in which help for this specific research is ask friends, family, what software and hardware they usually use on a daily basis. If many people use this product, it's probably interesting. Um, and if you'll find vulnerabilities in it uh, it will be a good publication and an interesting research. For this specific research, as you probably already understood, we're going to focus on hardware and more specifically my dad's camera because my dad has a camera, it takes it around to uh, family events, important life events, trips and no one is allowed to actually touch the camera or do anything with it. So I was interesting to find out if I can hijack the camera and exploit it. So we're going to talk, to talk today about cameras. And if we look on cameras from uh, security perspective as a black hat, we can see we have a good fear in cameras. We have a photography which is a very common hobby. Being a common hobby, it also means that many potential victims. We have many people that use cameras, take them with them to important places. If you could do something to cameras, you'll have many potential victims you could infect. In addition, people buy expensive cameras and actually found out that the lens is the most expensive part. But yeah, people buy expensive cameras and equipment and they treat them with care. Because you have special backpacks for your camera, you don't let anyone touch it. Um, and this also means that if the target is expensive, you'll probably have money. And if you have money, you have a good potential to take your money and uh, get it to our own. And the last part is, cameras still, uh, memories from special life events. You go to a trip to Japan, you travel to DEF CON, you saw all of your pictures on your camera, and if someone will take your camera or hijack your images, you'll get emotionally involved. You'll get dramatic, you won't think clearly, and that's a good fear. You have many people with money that don't think clearly when something happens to their camera. And we are thinking like, assuming I can take over your camera, your target DSLR camera, mirrorless camera, anything like it, what can I do with it? Well, uh, I can break it, but I really don't know why people still do IoT breaking this year, but it's a thing. Um, it's a good espionage tool. It already takes pictures with high quality. But we're going to focus today on the third part, which is ransomware. If I can lock up your camera and encrypt all of your images, I can ask for cash back. And as most of you have cameras and you're attached to them, the important question to be asked is that if I encrypt your camera, all your images in the camera and lock the camera itself, would you pay to get your camera back? And we really think that the answer is yes. People will pay. This is an interesting attack vector. So let's try to install ransomware on your cameras. Let's get started. So, meet our target for this specific research. We decided to focus on Canon EOS ATD. We chose this specific model because it supports both USB and Wi-Fi. So we could test both, uh, interfaces for this specific camera. In addition, we chose to focus on Canon because Canon controls are more than half of the market share. So it was quite easy to decide. I think that all of the people I know of which has digital cameras have Canon cameras. So that was quite obvious. After we chose Canon, we saw that Canon has an extensive modding community called Magic Lantern. And actually, there are a few modding communities for Canon cameras and other cameras as well. We have Magic Lantern and we have CHDK, which stands for Canon Hack Development Kit. Essentially, we can think about it as a jail-broken camera. Uh, both communities extend the original functionality. They solve bugs. They add new features. Uh, it really is a jail broken camera with an open source community behind it. So we have, uh, researchers, which reverse engineer the hardware and the firmware of the camera. And essentially, they want to build up an emulation environment, so developers will be able to develop open source features for their cameras. Reading through the forums, I actually saw that several developers don't have enough money to buy the camera. So they only have a emulated camera on their computer because they don't have enough money to actually buy a physical camera of their own. So being an open source community have all of the benefits. We have extensive wiki pages that document how the camera works. They actually document even important structs inside the firmware and symbols, meaning addresses in the firmware itself. As we can see here, we have the documentation for the method called task create, which creates a new task on the camera. We have the documentation for all of the, or most of the parameters of the function, and we can see the documentation itself, but the arguments are not really known yet or not all of them know. And that's because it's community based. Some info is still missing from the documentation, but nevertheless it's still a gold mine when we start our own research. I don't need to understand in full all of the internal data structures of the camera and what's the operating system and find out a few important functions because Magic Lantern already did it for us, documented on the wiki pages. That's a really good start for an embedded research. Just as an important note before we continue, at the time of our research, and I think that even today, fix me if I'm wrong, there's no Magic Lantern port yet for this specific camera, which means that if you install Magic Lantern on your Canon camera, it comes with basic debugging functionality. You have the capabilities to read memory from the camera, write memory to the camera, and even execute lower scripts for some reason. We don't have it. We don't have a port for our camera. We only have the documentation in the internet. It's really useful. It's better than nothing, but we don't have a debugger for our own camera. The attack vector we are going to focus on is called PTP. And when you Google up PTP, you can see that the PTP protocol stands for IEEE 1588, which is precision time protocol. And I did my thesis on this protocol so I can talk here for hours about how the master clock is going to send a precise timestamps to the slave clock. But what does it have to do with cameras? Well, it don't. It turns out that PTP also stands for the picture transfer protocol, which makes more sense, right? That's actually going to be the second time it breaks the PTP protocol. And PTP stands for picture transfer protocol. Initially, we had only USB to connect our camera to the computer. And nowadays, our cameras also support Bluetooth and Wi-Fi. So the protocol was extended. And now it also supports PTP over IP. But we have to remember that it's the same old protocol from the USB. And we're going to see it in the next slides. In addition, although the protocol is called picture transfer protocol, it supports a surprisingly high amount of commands. You can query the camera for the battery level, for the firmware version. And actually, there are a lot of the different commands in it. We'll see in the next slide. So it looks like a promising attack vector. There was some prior work about this protocol. And this was six years ago in Hack in the Box, Daniel Mende presented his talk called paparazzi over IP. In this talk, he also talked about PTP. And he showed that it's a really naive network protocol. Since it was developed from the USB protocol to IP, no one thought about adding some authentication or encryption to it. Which means that if you're on the same Wi-Fi network with the camera, you can send messages to it. And that's good for our attack vector. We are going to focus on implementation vulnerabilities in this protocol and not in the original functionality it offers. So we hope to find vulnerability in the implementation and take over the camera. Thanks. Time to analyze the firmware itself. This was a classic case in our research. You simply download the firmware update file from the vendor's website. It's called a .FIR file. Proposedly, it's firmware. When we open it in our hex editor, we initially saw a problem. In the byte histogram you can see, we have an even distribution of all of the bytes. Which usually means that the firmware is probably encrypted or compressed. So we looked back on Magic Lantern. And what do they have to say about it? And it's actually AES encrypted. Which is bad news. Uh, I consulted with a friend which told me, yeah, even if it's encrypted, you probably could find a key in Google and that's it. And this didn't work. Magic Lantern do have the key but they don't share it because they want to use it for their product. So the key is not available online and we can decrypt the firmware. Uh, at this point it looks like, it looks like a dead end. Uh, we have a camera. Uh, can we somehow maybe dump the firmware from the camera itself? Uh, it's a nice camera. We don't want to break it. We actually bought a new camera. Uh, it works. Um, how did Magic Lantern research their own cameras? And it turns out that they developed something called a ROM dumper. And a ROM dumper is a firmware update file that they created and signed. Um, which you load into your camera and it dumps the firmware to your SD card. So I used ROM dumper and as you can see it actually, uh, worked quite nicely. And now we have the firmware on our SD card without breaking the camera which is quite good. Now we load it into our disassembler. Uh, Magic Lantern even, uh, give instructions on how to load the dump, uh, fixed on to IDA. And we then verified all the basic functions we found. Again, Magic Lantern's documentation. So, so everything aligns correctly. The firmware itself, uh, um, is an ARM firmware. And that's because the camera uses an ARM CPU. A 32 bit little NDN ARM CPU. Which usually means that once you load it into IDA, you now have to manually improve IDA's ARM analysis because it doesn't distinguish, distinguish quite clearly between ARM code sections and thumb code sections. So we have to manually improve it. Luckily for you, um, you don't have to do it yourself. We developed an IDA plugin just for this case which called Thumbs Up. Thumbs Up is a really, uh, basic IDA plugin that uses really, really basic machine learning, only basic random force classifiers and that's it. And it improves the analysis. Uh, you can read all about it in a research blog post and it's already on Github. Um, Thumbs Up was designed to improve the analysis, uh, focused on ARM assembly, uh, to distinguish correctly between thumb and ARM code sections. And it was used as part of a prepossess phase for an additional IDA plugin called CARTA, which matches open source with a statically inserted into the firmware. In our case, we couldn't find any, uh, such open sources because it seems that Canon implemented everything on their own, which is a good sense because we are going to find vulnerabilities if they re-implemented everything in our camera. Just to get the sense of, uh, why did we need to improve the analysis? Before we started, uh, and we just loaded it to IDA, we saw this, uh, navigation bar and all of the brown rectangles stands for code sections without functions. It means that IDA analyzed it as code, but couldn't distinguish any functions inside it. And we have a lot of, uh, these brown rectangles. After you execute thumbs up, it looks like this. We no longer have any brown rectangle and we actually found a few more function pointers and strings in the data sections as well as we can see in the white swipes in the green part. So, use thumbs up, uh, it runs quite fast. It's already on our github. Don't do manually what the script can do for, uh, uh, on. Now that we finished analyzing it and loaded it into IDA, uh, the operating system itself is called Dry OS. Dry OS is a proprietary real-time operating system. Um, Canon actually developed it especially for their own cameras. And I'll repeat that. Canon especially implemented their own real-time operating system just for their cameras, which is quite insane. I haven't saw it, uh, in other products. However, from our perspective, it's just a real-time operating system. It's a flat memory outer space. Everything is fixed. You'll find a vulnerability in a single task. You can hijack the entire camera and that's it. And the bonus of this operating system is that the camera reboots in three seconds, which you probably, uh, saw it on your own. You have your own cameras, but this also means that when I developed the exploit and I debug it because the exploit usually doesn't work on the first attempt, rebooting the camera only takes three seconds. Not a minute, not seven minutes, not 20 minutes, like any other embedded device, it only takes three seconds. And that saves us a lot of time during our research. Time to break up the PDP protocol. The first part is locate the code. And the PDP protocol is the command-based protocol. We send requests to the camera and we get response back. Every command has a unique identifier called an opcode. And thanks to an anonymous .NET programmer, here we can see the PDP commands from the SDK, which was found on Magic Hunter's development group and you have the link to almost the full list. Here we can see a partial list. We have commands to open a session to the camera, close a session, create an object or what they have in their documentation. And we can see that each command has a unique identifier and we can find them in the firmware. So the next part is gonna be to locate the code, simply search for these constants in the firmware. We actually did the search and we found a massive function with a unique code pattern as we can see here. We have the constants to close a session, to open a session to get the devices info. And the opcode is always the first argument to the function in R0. In R1, we have a function pointer, which is gonna be the function handler for this command. And the third argument is always 0. Probably flags that no one uses. This means that the function we actually located is a function that is responsible to registering the PDP handler. This means we now have the full mapping between each opcode and the respective function pointer. So now it's gonna be quite easy to scan all of the functions and check for vulnerabilities in them. We verified our findings with trace strings. There are a lot of trace strings inside the firmware itself. So we have the handler for open session. It includes strings such as open session. So we know we're on the right track. Just as a basic recap for now, we have almost 150 unique handlers. I really wasn't kidding when I told you that protocol supports dozens of dozens of commands. It actually supports additional commands, but some of them are duplicate. So we have 148 unique handlers. Usually the rule of thumb is that if you find 10 handlers, you'll find one vulnerability. So we're going to find vulnerabilities somewhere in the different handlers. The second stage is to understand the API. Since we have a fixed function that registers all of the different handlers, they all implement the same API. Each handler can receive up to five different arguments which are integer types, 32 bits. And some of the requests can also be included with an input data buffer. Every handler will use a fixed context called ptp context, but uses function pointers to analyze a process and send back data to us. Without knowing about these function pointers, the code itself looks like gibberish, but Magic Lantern happily documented the struct for us, so we just could use it and that's it. Although we started with almost 150 unique command handlers, a quick scan showed us only 38 different commands that actually receive an input buffer. Which makes sense because the protocol is used to query information from the camera and not to sending information to the camera. So most of the time you only get back information and we don't send data. Although it's a massive reduction to the source space, it's still better than nothing. And if we apply to the same rule of thumb, we're going to probably find three or four vulnerabilities in the firmware. At this point, you could probably think of okay, simply fuzz all of the different commands, you'll find vulnerabilities, the camera will crash and that's it. But you have cameras, you know it doesn't work that way. Even when I connected the camera to the USB and tried to send messages in Python to it, I crashed. So the camera always crashes. Fuzzing is not going to work and I don't have any external mechanism to physically reboot the camera each time. In addition to the fact that sometimes when the camera gets stuck, you actually need to plug off the battery and reinsert it. So fuzzing is going to be quite slow. Instead, it's also manually finding vulnerabilities in the firmware, good old code added and that's it. Hoping to find some shallow vulnerabilities but one good vulnerability will be enough for us. And it actually worked quite well. We found three remote code execution vulnerabilities right on the first scan. And here you can see the CVEs for these vulnerabilities. One important thing to note is that two of the vulnerabilities are in Bluetooth related commands and if you have this specific camera model you might know that the Canon EOS ATD doesn't even support Bluetooth. But hey, I'm not complaining. Maybe it's a leftover from a different model, maybe it's for future support, I don't know. But we have vulnerabilities in an interface we don't even have in the camera. The three vulnerabilities we found are buffer overflow on the globals, buffer overflow on the stack and buffer overflow over the heap. So we have all of the vulnerabilities we need and we chose to focus on our vulnerability over the stack because it's easiest to exploit. Time to build the exploit for our camera. Here we can see the code snippet for the vulnerable part and the first line will query the packet for its size and store it in a variable. Without using this size we're going to prepare a local stack buffer of fixed size. We fill up the response packet in advance and then we read the data from the network according to the attacker's size into a fixed size buffer. And this usually means it's a classic buffer overflow. We use the attacker's size without checking if it's smaller than the size of the buffer on the stack. We can simply overflow the data and change the return address. However, we don't stop here. Before we actually return to the function we can see some mystery callback that is used to process the incoming packet. We don't have a debugger. We don't know what does this mystery callback do. We simply hope we can bypass it freely and return back from the function so we can execute our own code. Please remember this mystery callback will see it in advance on the next slide. When building the exploit we need to remember we don't have a debugger. We only have a camera and that's it. It's a nice little back box. We can see it but we don't have a debugger for it. In such cases I usually prefer to use what I call sleep based debugging. You simply find a function for sleep somewhere in firmware and you add a code to sleep one, two or five somewhere inside your exploit. If your exploit took five seconds and when it crashed you know you reached your break point. If the code crashed immediately you didn't reach your break point. This way you can debug your exploit without having a debugger. It does mean that you actually use a watch and time up your exploit every time but it's better than nothing and this way you can distinguish where did we reach thus far in the exploit. You can move the break point around to check where the exploit failed. Usually it fails right from the start but you can move it around. And usually embedded devices and your computer crash they can show you a notification waiting crash. When you have a vulnerability in the windows kernel for example you'll see a nice little boot scan of death which looks like this. And in embedded devices you see something similar. Up until now I had a fax results for last year and we have a screen for the printer and now we have a screen for the camera itself. So it really does look the same. On an obviously printer you have a blue screen on the screen of the printer and on the camera you have error 70. Sometimes you get error 80 which I don't know what does it mean but error 70 is what you usually get. And after you get the error you need to reboot the camera sometimes it means you have to plug off the battery and reinsert it. But that's quite straightforward. However we didn't have enough luck in our research. For some reason the camera usually hangs instead of crashing. And this means that if I sleep for five seconds and then hang indefinitely or hang indefinitely it looks exactly the same. So we can't see our break point. It's not really useful. And we want an alternative trace point that triggers an event we actually can see. At this point it's too complicated to print something to the screen and sleeping doesn't work. The camera doesn't do any noise that I know of. So we don't have a lot of options. I decided to change tactics and use a different approach. Instead of sleeping call an address that always crashes. But how do we find an address that always crashes? We don't have a debugger. It turns out when you jump to address zero the camera hangs. When you jump to address one the camera hangs. Address minus one the camera hangs. After a few hours and a lot of guess work we found this address. If you call this address the camera crashes. I don't know what's important in this specific address but it works. So now we're going to use this address as our own break point. If we saw nothing we hang before our break point and if you crashed it means we reach our break point and that's it. And essentially we're going to do this experiment. Coyote wants to get to the end of the tunnel. If he crashed into the mountain we got to our break point. If it stopped before the mountain we stopped before break point. So that's the experiment we're going to do time and time again until we fix all of the bugs in our exploit and execute code over the camera. And it worked. This blind crash based debugging actually worked. We have a remote code execution. Time to use our debugger, boot it into the camera and study the camera more intensively. Usually I allowed my own debugger called Scout to start a dynamic reverse engineering. And up until now if you remember we use PTP over USB. While Scout uses TCP it's a network based debugger and the TCP fails. It looks like we either have USB without network or we have Wi-Fi without USB. So we can't have both USB and both Wi-Fi on. So even if we exploit vulnerability over the USB Scout gets stuck inside. So it can't phone home back to us and we can debugger camera. We'll have to do something else. The camera already supports Wi-Fi. Let's migrate our exploit to Wi-Fi and hope it works this time. Initially we used a project called PTPi. You can find it on a GitHub link. It's a Python implementation for the PTP protocol. Like any other open source it didn't work out of the box but it was better than nothing. When we reached the part of the PTP over IP for Wi-Fi we turned out that we haven't actually implemented this feature. We haven't open issue about it for three years or two years or something but we don't have it implemented. So we read for the specs, we implemented the part needed for the Wi-Fi and now we were able to send messages to our own camera over Wi-Fi. Which wasn't quite stable because the Wi-Fi for camera isn't shaky to say the least. But if you recall we have a vulnerability in the application layer in the PTP protocol. It's the same protocol over USB and over Wi-Fi. So the same express script this time over Wi-Fi should work, right? No. Earlier we expected a vulnerability in a Bluetooth related command. Something about notifying the camera about the Bluetooth connection. And now it hangs instead of executing code. We can't debug it because we don't have a debugger. But essentially it looks like the same history callback we saw earlier and now hangs instead of simply working. And this is because we assume that the Wi-Fi system on cheap hangs when we remind it it doesn't support Bluetooth. When we used USB Bluetooth was fine. But when we're using Wi-Fi it actually says no, we don't have Bluetooth. I already have Wi-Fi. That's it. Simply hang and that's all. So we don't have a vulnerability. We don't have an exploit. Time to think again, find something new to actually exploit the camera. We need more vulnerabilities. Time to scan for additional vulnerabilities in the PTP handlers. On the first scan we only identified shallow bugs. Maybe we missed something. And it turns out we did. We actually missed two vulnerabilities that are quite similar. And this is a snippet for these vulnerabilities. Initially we get the size of the packet just as we did before. And this time we check it against the fixed known size of the packet. For this case it's 100. If we send a packet which is longer or shorter there will be an error log debug print off. And then nothing. Because we have an error log and then no return. So if I send a large packet of 200 bytes it's not 100. We'll see an error log and then we'll use 200 to read bytes from my packet to the local stack buffer. And that's it. So they know we're attacking them but they don't do anything with it. So I checked it up and it is indeed only a debug print. Not an error that crashes the camera. So we once again have two stack based buffer overflows that they actually know of but they haven't fixed. Okay. So I'm not complaining. It works. I adjusted all of the constants in the X-ray script. And now we have successfully exploited a remote code execution this time over Wi-Fi. So we have five vulnerable PTP handlers. All of our POCs worked over USB. But only three of them worked over Wi-Fi. So the next time someone says to you this vulnerability is exploitable it's not. You need to check it because some history callback will interfere with your POC and only three of our vulnerabilities actually worked over Wi-Fi. So always test everything before you say it's a remote code execution. Now that we've demonstrated the code execution over USB and Wi-Fi and the question arises have you finished? And no. Our goal was run somewhere. And us attackers are profit maximizers which is a good term for I'm being lazy. We want to implement that somewhere but we don't want to develop our own crypto for it. And you should really don't, shouldn't implement your own crypto. And why should you? You can simply steal the crypto from someone else. Canon already implemented crypto for their own firmware update. Something about a yes. So this time we can use our own debugger, search for these functions and hopefully we can use the cannons on crypto functions for our run somewhere. Time to look for these functions. So let's scheme for the design of the firmware update. And the firmware has two symmetric AES keys. Being symmetric meaning that it's probably not the best firmware update but it works in a way that you have one key to verify the firmware update but it could also be used to sign a new one. And the additional key to decrypt the firmware update but you could also use it to encrypt your own file. And we use an HMAC based signature which is again symmetric. When we search to further crypto functions we actually found the keys in the firmware itself. And that's a huge jackpot. We can actually use the keys we found to encrypt our own firmware update and simply send it to the camera. So let's see how it works. When we looked upon the crypto functions we saw that Canon uses a proprietary key derivation but AIDA can't even decompile. We have multiple different crypto functions which doesn't make a lot of sense. We can even see in this mem copy that they actually lose some of the bytes of the hash they calculated because the buffer isn't big enough. So they copy only 12 bytes out of 20 and they simply lose 8 bytes for some reason. Don't implement your own crypto. The encryption is OFB tug mode of operation and that's mainly because it looks like output feedback block. It matches the Wikipedia page of output feedback block but when tested against Python's crypto library it doesn't work. The first AES block matches my calculation but the second block doesn't. Maybe it's some problem with the endianity I don't know but at this phase it really looked wrong to simply implement it in Python. Too many proprietary calculations AIDA can't even decompile it. It simply felt wrong to try to implement it on my computer. So instead we chose a different approach. For our attack I simply implemented a scout instruction that calculates the crypto. This means that instead of understanding how the proprietary key derivation works I simply told my debugger to call their function and that's it. So I found the address in memory of the key derivation function and told my debugger to execute this function and now I don't need to implement it on my own. So now the camera can my camera after I compromised it can calculate for me the correct signature. So we can think about something like a signature or a call on our own camera. And after which I also implemented an additional command to encrypt or decrypt the firmware update. So this was quite useful when we had to test Canon's patch because we could decrypt and newly updated firmware and test the fixes. Which brings us to our attack at home using the already compromised camera. I can send a usual firmware update to the camera. The camera will decrypt it and now we have the plain firmware on our computer. Now we can add any back door vulnerability feature we want to this firmware to have our own malicious firmware and send it back to the camera. The camera will encrypt it, sign it and now we have our own legit malicious firmware update. Which brings us to the vulnerability itself. It turns out that the PTP protocol has a command for firmware update. So we can take the malicious firmware update, send it over Wi-Fi to the target camera and without any user interaction we just took over the camera without any vulnerability. And it turns out we have no user interaction for firmware update for some reason. So we did a test with Magic Lantern's ROM Damper and we can see now we now have checkpoint results ROM Damper instead of Magic Lantern. So we have our own firmware update file, we can simply send it to the camera, no need for any vulnerability. Please don't use symmetric crypto for your firmware update. Time to connect the dots. Once we finish with the firmware update we return back to the ransomware. We implemented the logic to encrypt all of the picture using Canon's crypto functions. So now we read pictures from the SD card and encrypt them and store them back. Time for a demo. So here you can see my laptop and the camera without any cables. And just to show you the camera works. So we used the camera, we took some pictures and we now have free images on our own camera. Now exploit the vulnerabilities we've seen using my XORI script. We need to wait a bit for some events and then we send our malicious payload to the camera. We've just infected the camera and you can see the blinks on the SD card meaning that we're now encrypting the images and storing them to the SD card. And after we finish we actually show the ransom message to the user. So we've just installed our own ransomware. And as you can now see all of the images were encrypted and the camera can't show them and playback. So, responsible disclosure. We reported all of the vulnerabilities to Canon and worked quite closely with them to patch all of the vulnerabilities. Canon confirmed all of them rated as high or critical and issued a patch. They have a security advisory already on their website. You should really test if you have a firmware update for your specific camera and download it. You can find all of the details in our blog post in this link. Links also to Canon's advisory in English and in Japanese, any language you want. Just to the side note after we received the patch we also tested that Magic Lantern's ROM damper also works and it still works. So please don't ask me for the crypto keys. I deleted them for my computer. If Canon will exchange the keys with new pair, Magic Lantern won't be able to sign their version or the ROM damper. And I really don't want Magic Lantern to work hard on extracting new keys. So I don't have my keys. Please don't send me any email about it. Conclusions. We found many vulnerabilities in the PDP implementation and one design issue in the extension that Canon implemented for the firmware update. Um, they might also apply for other vendors. They surely will apply for other DSLR models, off Canon, maybe mirrorless cameras as well. If your camera uses PDP to connect to something, to your computer, to your mobile phone, the vendor will need to check if it has similar vulnerabilities and maybe issue an additional patch. The PDP protocol itself has no network level protection, so that's not a good idea. Uh, anyone can simply send messages and attack your camera. If you're not using Wi-Fi, turn it off. Uh, if you're not using Bluetooth, turn it off. You don't want anyone, especially in DefCon, to connect and to, for the Wi-Fi to your camera and ransomware it. So if you're not using something, turn it off. And just last note, Canon implemented a proprietary key derivation for their crypto for some unknown reason. Uh, it didn't get any additional security and it didn't actually stop me implementing anything. So bypassing it was easy. We used our debugger to invoke their function and that's it. So I don't know how the crypto works, but I bypassed it. So there's no actual reason to re-implement or invent your own crypto. It doesn't work. Last slide. Uh, through this research, I used a few tools which I developed and were already accessible on our GitHub account. We had Carta and I had a plugin to match open sources in binaries and this time Canon didn't use any open source. Uh, we had Thumbs Up to improve Ida's analysis which works quite well even in my ongoing research. And the embedded debugger that I actually used, Scout, you load it as your exploit shell code into the camera, load your own debugger and that's it. You can compile your own C code, execute it on your camera and decrypt the image from Canon. So all of you are accessible on a GitHub account. Use them. If you have any question, send me an email. Uh, please use these tools. Don't do anything manually and don't re-implement the wheel. That's it. Thank you for coming.