 Well, I'll start again, so my name is Alfredo Teja, he's already in Isaxon, we're going to talk about exploiting digital cameras, there you go. So, we're going to talk about how to script digital cameras basically, how we reverse this script, this will not be an exploitation at low level, this will be a high level exploitation, we actually are writing interpreter language, present in almost all PowerShot digital cameras, we're going to talk about what we can do with this and what are the security consequences of it. Okay, let's start with the basics. Modern digital cameras, I'm sure you are aware, are in fact powerful computers, they almost all have an ARM processor and a lot of memory and they are really fast computers. We have a digital camera, sorry, the digital cameras that we are studying doesn't have a complete memory management unit, they have a memory protection unit, so it really can run a secure operative system, but it runs an operative system, nevertheless, Canon digital cameras use dryos, it is an operative system built by Canon, and that's about it. We have complete computers, of course we are not the first that research into exploiting digital cameras, in fact there is a huge project called CHDKey that it has a few years already, and they are very, very, very incredible guys, they build a custom firmware for Canon digital cameras, they enhance functionality, but this really can be used to attack a camera, because we can see here, this is the main problem that this approach, for this modification to work, you must download a firmware modification inside the memory card, but the memory card must be locked before the firmware can be executed, so this is not really a good way to exploit, to take over a digital camera, because you have to physically access the memory card and switch the login, and also there are other requirements like a special file system, a needFAT 16, only working FAT 16, so this is a great modification, but really can be used to attack a camera, that is why this project is in fact very secure, we want to see if there is another way. So we first try to run our code exploiting the image parsers inside the camera, this way if we could find a bug in the image parsers and write an exploit for it, we could take control of the camera as the user is trying to see an invalid image in the camera's playback mode, the ARM processor jumps to an exception handler when it tries to read or write an invalid memory address, so what we did is write an exception handler to try to find the bugs, find bugs when passing the parsers, we did find some bugs, but before writing an exploit for them or trying to write an exploit, we found another way that is better, the best thing about writing an exploit for the image parsers are that this is binary, and function offsets change from camera model to model, so it would probably be very difficult to write an exploit that works in a lot of models. We found this other method that is the interpreter and the script, when we analyzed, when we analyzed the film one of one camera, we used the Ida Pro, and we can see a lot of interesting strings, this string shows that there is a plain text parser inside the camera, this parser is composed of two parts, one is the Yag, that is yet another compiler compiler, and the other is Flex, that is a lexical scanner. Well, we let our phone, I was saying we find this parser, and this parser is commonly found in interpreters and compilers, we assume it was an interpreter as it makes more sense inside the camera. We let our phone, we were not the first one to find this interpreter, but there is no public information on how to write a script for the cameras, or any information on the syntax or semantics of this language, and it is very difficult to just guess how to write an script for this language, because any error causes the camera to simply shut down, and there are no error messages that say why the script is invalid. So we found that a whole language activated inside every camera, and so we have to reverse a complete language, that is a little difficult, what we have, we have how to execute the language, we have what are the requirements that memory card has to execute a script, and I have a little file when the script is placed, and some tags inside the boot sector, but most importantly, it doesn't require anything more than that, it doesn't require the memory card to be locked, it doesn't require a special file system, so if you have a malware running in your computer and you insert a memory card, this malware card inject code in your camera, because you don't only have to remove the memory card, insert a new camera without doing anything else, and it will execute, so I say why that is very useful, but we need to reverse an interpreter, it's not an introduction and an algorithm, but a complete language, so let's start from the beginning, what are the structures of this interpreter, where it's a very standard interpreter, we have a grammatical parser here, a lexical parser, is lex and jak, by the way lex was built in the idea of tonic-nude, and I'm sorry, lex was built by Eric Schmidt, say of Google, and jak was built by tonic-nude, it's the software, open source software that have more than 30 years old, but they are like the standards of real interpreters, basically you have the script here, and the tokenizer, the lex parser will start to read character by character, and produce tokens, these tokens can be wild print, variable names, they are basically tokens for any language, they are a field to the grammatical parser, and the grammatical parser can either produce code, so you have a compiler, or execute functions, you have an interpreter, that's all, in this case of course the camera inside has an interpreter, not a compiler, it will be very crazy, you have a compiler and a camera, but you have an interpreter, so this is the function that those parsing, this is a very complex function, we have the string here is syntax error, the string that we found, we see that this is an interpreter in fact, here we have a code of the lexical analyzer, and here's this little basic block here, so we're going to start with trying to do what tokens made our language, so we don't know even what language it is, or any of the rules, so this is the tokenizer, it's very complex, you can see, in fact it's a huge case, this is a case statement, the one for each token, and the tokenizer in fact is a table basal regular expression, basically it's a regular expression parser, that's why we really can't find the individual tokens in memory, the tokens are coded inside a huge table, this table is feed to a state machine and the state machine recognize tokens, so we couldn't find any tokens in looking at the firmware or looking at the memory, we have to reverse the regular expression parser, here is a portion of the parser, the parser is open source, so we know that we have to solve code, but we don't have the tables, one idea that we have is to emulate this in a computer, just pick up the table from memory and emulate, there is not a single table, there is a lot of tables in a lex parser, in this diagram we look in the memory here, this is a table in fact, we implemented the table back to C code and just recompile a standard lex code parser and then brute force it, there is, so we're going to do a demonstration, we're going to run a demonstration of this brute forcing process here, this of course is ruining in my laptop because only we stole the, sorry, we pick up the tables, here is, yeah we are reinforcing every character, when you say success here is that a token was successfully parsed or accepted for the token I said, so every number is a valid token, because numbers are tokens too, now we're going to start parsing the operators, so we accept, this is our valid operator for this language, letters are also valid tokens because we can do variables and we have here, we have a token that is a function, it's a valid token too, so we have a function, we have if, it's a better case, if, upper case, lower case, we have here sub, sub is another token, we are accepting every token of this language, so we run this for a while and we have this, we have a lot of tokens belong to this language, so maybe it's familiar to you, these are basic tokens, so this language is basic, now we know that every camera has a basic interpreter inside, but we don't have the grammatical structure, it can be millions of variations of basics, so for that, we should build an emulator, how are we in time? Well, as Alfredo was saying, having the tokens was not enough, as we, even if we tried some basic scripts, very simple basic scripts, they appeared invalid, so we had to emulate the original firmware on an emulator, we use QMU that has the capability to emulate another processor, but can't emulate the whole camera, so we couldn't use it to both the original firmware and try to parse a script with it, instead what we did is captured the state of the machine, of the camera, as it was parsing a script, that is capture all the registers and all the memory and dump it to the memory card, and then take that information and resume the execution inside our emulator, to do this, to do this, we couldn't just set a break point inside the interpreter and take control, because we are not sure that that's even possible, we had to use the section handlers, what we did is force the script interpreter to rise an exception as it was beginning to parse a script, we can see from the source code of the flex scanner that it tries to access an array, an array with a value that is inside the static variable, and we change that value and then the processor tries to access that value, it crashed and then we could dump all the state. To know which memory regions we need to dump, we just use the memory protection unit. Inside this unit, there are registers that define the valid memory regions, and we only need to ration the memory and the ROM. To control the execution of the emulator, we use the integrate CDB server and also the integration of CDB with Python, this way we could write a Python script and control the execution from it, this Python script can set break points, modify the registers and control aspects of the emulator. We need to make some changes to the original firmware, because we couldn't allow it to call the operating system, because it wouldn't work, it would try to access some hardware registers that weren't emulated. So we changed the read function so we could feed the emulator or script, and we did it in a way that it read one character at a time, and this way when the interpreter found an error as it was parsing the script, we could find exactly at which point the error was found. Well, this is the general way that we found out about the syntax. We tried a script and find out the location of the error, and then we changed it until no error was found. These are three scripts, the last one is valid, syntactically valid, but it doesn't do anything. The second slide shows that if you try to call a script a function outside the body of another function, that's an error. You can only call function from the body of other function. So this way we realized that there must be one function, that's the entry point. I'm going to show you now the emulator as it's running. The emulator is already running, I'm just going to run the Python script. You can see here in blue the script that is about to be fed. The emulator read all the script one character at a time and found out exactly where the error is found. In this case, bar is in the find. In this second demo, I'm going to show a valid script that hasn't the entry point. So we arrived to a break point that doesn't lead to code execution. This way we later found about the entry point. This is the third demo that with the initialize function, that's the entry point. This script is totally valid and we arrived to a break point that shows that code is about to be executed. This is a complete valid script that prints hello world to the camera screen. You can see that there are a lot of pre-fined functions inside the camera. Alfredo is going to talk about it. Okay, at this time we have the grammatical structure of the language, we have the tokens, but the language also has a lot of functions that we can call. In fact, this is wrong. There are 5,000 functions, sorry, 100. Inside a common camera, governing everything from the sensors, little motors, accelerometers, CCD, absolutely everything you can access from this language. In fact, you can access the main memory of the kernel using poke and peak instructions because it's basic, like Commodore 64 basic. We started to build a document and a user guide of this language is here we are going to put it online after this. We are documenting all the functions. We don't have all, of course, because that's 500, but we have some of them. They are very interesting things about this language. For example, there are functions you read about the kernel process memory here. You can see, this is the square valent of the top Unix common inside a camera. So how many process do you think a camera can have? It can have hundreds of, sorry, about 70, 70 processes inside a Canon camera. All these processes governing from the buttons, so the display for keeping the CCD warm, it's a very complete operative system inside this camera. I'm going to publish this document in short so everybody can start building scripts. So, okay, what we can do with this language? Well, because it's difficult to do something with a camera, but you can do some stuff like we're going to show now. For example, you can, the old school that we show at the beginning. Okay, here it is. This is the little school that we show at the beginning. This is not new, but this is, we're going to show this script in a lot of cameras and it should work, because it's basic. It's not accessing any low level system. Okay, you have, this is a cheaper camera. This is a 470 Canon. The first one was a G10, one of the high-end cameras, but the script worked perfectly. Do you want to test in your camera, Oren? Well, it will work in every power shot camera. Let's see if it works. Show it. Okay, well, it worked perfectly. We don't have any special code to choose between cameras. It's the same code. It works in every camera. Okay, so what else you can do with this script? Well, of course, we can make pictures appear. We can put fake picture in the camera, for example. Just a minute, please. I'm going to show a demonstration about, well, you can't put any kind of image inside the camera, for example. We're going to erase every picture inside this memory card. Okay, it's ready. So, we're going to show that there is no picture in there. It's like a magic trick. There's no picture there, so we're going to launch the exploit. Okay, launch it. There it is. Explodeploy. And then we will turn on the camera again. We know there is a picture of General Perón there. Of course, this picture didn't exist before. We put it there, or Esprit just made a picture appear. So this is not so dangerous until you start putting pictures of illegal things in the cameras, and then you have to explain to police that your camera has a virus. But we have a more serious exploit here. It's about, maybe you have her. This exploit is very new. It's the link exploit that was made public just a week ago. I have a SD without the files that exploit this bug. But there is a script for the camera that will launch this exploit. Okay, let's try. We don't have space for the USBs here. First, we are going to show the memory card. Nothing happened here. But this is the script. You can see it here. This is the script that launched the link exploit. It creates a lot of links inside the memory card. It doesn't have eject, so we're going to eject it anyway. We are going to run the exploit in any camera, in fact, can be anyone. We're going to launch this one. This one is the cheapest. Let's see if this works, because if it doesn't work, we have a video, so you can believe it. It's already, and then you just remotely the memory card. Let's see if this works, because we never tested this, really. And whoops. Ah, what? Consecution. Well, this is the form of the link exploit that you when you execute, when you see a memory card, it's used for a, I'm sorry. Sorry, this wasn't supposed to be this way, because we forgot to reset the explorer process. The problem with this is that once we showed the empty memory card, the shortcuts were still there, so I'm going to show it after resetting the explorer process. Well, okay. We got a video that we're going to blow out that it works. When in fact, kind of work it, but not like we wanted to do. This is a real exploit that we, basically we are just copying a file in the memory card, and when you just saw the file, it will execute code like this one, like this showing there here. Of course, it can execute any kind of code. And, well, that's counter measures. It's about counter measures. We had, you have to be ready to be sure that there are no files with these extensions, as these are necessary to launch CHDK or the script. So if there are not a third of these files in your memory card, you are safe from this. Can you, cameras, use picture transfer protocol. And that means when the computer is connected to the camera through the USB cable, the computer can't read the root directory of the memory card. So the good news is that you can get infected through the USB cable, but the one thing is that no antivirus can scan the whole memory card when it's connected by the USB cable to the camera. Well, so that's all. We have a language that we found inside every power shot camera. We documented it. We're going to put it online. So if you have a digital camera, now you have a general purpose computer that you can use to program in basic. It will run in every power, no, I don't know. It's everyone, but every power shot camera that we test. So that's it. Thank you very much.