 Everyone can hear me in the back. It's fine. OK. Hello, everyone. Welcome to HackingMFPs, PostScript Moving Hacks talk. A few words about myself. Somebody of you might know me as MFAC author or previous HackingMFPs presentations. And I would like to, just as a warm-up, ask the audience which vendor do you think will be covering? So I'll ask to raise hands for Xerox. OK. Who is for HP? Oh, much bigger. It's like 70% and Canon. Like 10% and 5% Xerox. OK. And one more question is, how many of you have written by hand any PostScript file? Not generated, but written by hand. OK, it's around 25%, cool. And some PostScript file which interacts with hardware or any weird things like, OK, two hands, three, OK. So this will be very interesting for you. OK, so a quick refresher. Why again I talk about MFPs and so on and so on? Well, MFPs, as you might know, printers and so on, are basically essential part of any modern network. And as part of any modern network, it's like a trustworthy resource because it's inside the network. Usually it carries confidential data, confidential documents being printed once in a while or less confidential data. It's part of the private network of where it is being deployed. It's not very well patch managed, usually. Well, it's because it's seen as an embedded device. And patch management is not very well standardized on those devices. And usually it is, or sometimes it is connected to the public internet, which is very bad. OK, so the history of hacking MFPs goes back to the 60s. Those slightly over 50 years old will be more comfortable. This story is like a story from 60s where we spied on the Soviet Union embassy. Also, we had a camera, but it's more mechanical camera and so on, some circuitry. And basically, hacking MFPs goes back to the 60s. So however, modern hacking covers the last 10 years, like the last decade, and it started around 2002, public modern printer hacking research. And then it kept iterating every few years. And basically, we are now in 2011, 2012, with very revived printer hacking interest. And this particular talk, compared to other talks I've made or other talks available, will mainly focus already on remote code execution on the MFP side. And basically, in 2010, we've demonstrated and we've mapped publicly exposed MFPs and printers. And as you can see with little scripting, there was like, we've governed tens of thousands of these. We've mapped them on the Earth. So you can see a big density in Europe of various vendors. Also, we've found ways and demonstrated how it is possible to deliver generic payload to the MFPs using Word documents, as well as deliver payload to the MFPs in a generic way using Java. And some other searches demonstrated with JavaScript. So web is also an avenue for this, not only open and pre-attachments. But this talk is not only about basically hacking MFPs in a generic way, but it has like a post-script orientation. And what about post-script? It's basically a general-purpose language invented by Adobe in 85. And basically, it was one of the first typesetting languages available on the market. And the picture is very representative, because it's a picture from Adobe's presentation of a post-script. And it turns out that the road of post-script is as long and it's bumpy and has unexpected turns at the end. So it was somehow profiting. Again, post-script, if you have listened to the previous talk, it's a Turing-complete language. And as you could understand from, I'm not a very big expert in formal languages and so on. But as you could understand, Turing-complete languages are not very secure, so to speak. But basically, Adobe's implementation of post-script has the widest share on the market. And it's implemented in most post-script interpreters and printers and on various org stations doing the formatting. So it's about roughly 90%, according to some supplemental note, it's roughly 90% of Adobe's interpreters versus 10% of other vendors for post-script interpreters. And the interesting side is basically post-script being a general-purpose language and being Turing-complete was built with very generic ideas in mind. And it is built with very powerful capabilities. And basically, it has file system or some kind of virtual file system operators and input-output subsystems like Affronet or SerialPort, whatever is available on the device. And it was demonstrated over time with various complex design problems or complex problems, in general, have been implemented in post-script like seeing guys implementing web servers, seeing guys implementing ray tracing in OpenGL, guys running post-scripts for the milling machines, XML parses, or other languages parses. So it's a very general-purpose language and very powerful. However, the specification of post-script dates back the latest revision, as far as I remember, is 99. So there hasn't been too much review in a while. So I would say it didn't quite adapt it to the current security landscape. And one of the things which struck me and us during this research is that the post-script specification mentioned something about the interpreter or a shell or something like this, executive. So if you go to the specification, you'll see clearly that they say you can enter some kind of a debug mode. So if you ever worked with GoScript, which is a post-script interpreter for PCs or whatever, maybe you are very familiar with that console, which says GS and the greater sign. So basically, you can get the same on the printers. And basically, it is designed so that you can debug why your post-script document is not being properly printed, displayed, or why the printer just spits garbage. So you can enter, or a software engineer can enter the interpreter. And see what is the problem, debug the document, and format it properly. But it can be also used to play with the interpreter or find other hidden functions in the interpreter or the printer or whatever. So as far as we have seen various estimation notes is that around 80% of the MFPs and printers have this interpreter or executive or shell enabled, and 20 doesn't have it applicable or doesn't have it enabled. So you would ask how to enter this shell? It's quite simple. If you are familiar with PostScript or PGL or PCL, it's a PGL job where you enter the PostScript language, self-explanatory. We have the standard PS Adobe PostScript header, some comments, and then we just write this executive command. And we enter an interactive shell of a PostScript interpreter. So we'll have a demo. So we'll just ping our target MFP. And then we'll just connect it, again, whoever answered Xerox, the vendor. We talk about in this talk is Xerox. So those 5% were very close, despite they're quite secure products. So but this code works on HPs, on most HP models, and canons, and so on. So we have our PostScript language. We give it a title and just send this document as a job printing spool on the port 9100. And as you can see, it's popped up the interpreter software version and revision and copyright notes and other stuff. So you can basically start running any PostScript code which you had in mind and run this code on the printers. So you can do print or you can do some general purpose computation, matrix computation, and so on and so on, because it's a very powerful language. So I've used few operators, like product and version, and Pistec, which prints the stack, and so on and so on. So basically, you can go to your closest MFP or printer, try this, and you'll get this kind of shell. So you can start fuzzing the interpreter. Maybe there's a bug in interpreter, but the purpose of this talk is not exploiting the bug in specific interpreter. OK, so what did we find using this approach? So we needed like a PostScript-based firmware upload or a PostScript-based mechanism to execute code or non-graphics code on the MFP and printers. And we've been looking, looking, looking through the firmware, and it was like tons of downloads until we find a very nice user guide where the vendor tells you, go to the print page. Here's your .ps firmware upgrade, which already raises questions, how a .postcript file should upgrade your firmware. And then in the user guide, we are kind of stuck and see that they say, go, upload it, and hit the print button, because it's usually the printing page of the MFP where you can normal users go and upload a text file, a PDF file just for printing, but using the same print page, basically you can upgrade the firmware. And this is the intended mechanism. So we said it's very interesting. Let's see what this PostScript file contains. It's usually 40 or 50 megabytes long. And basically what we found is like a big set of APIs, right? And basically, most of these MFPs are implemented in some kind of real-time operating system, like Vakesworks or LynxOS or some kinds of this. This specific model line implements Vakesworks. So we found Vakesworks API, debugging QA API, like doing automation tests or performance tests. We found some logging APIs, some pump setup API, because it has some pumps for the ink and for other things. We had the RAM disk, RAM flash, and billing meters API. Billing meters is also a very interesting part, because the counterfeit industry tries to circumvent the metering and original components. So it was very good to be true in the sense that we got so many API very well linked to the hardware level, but exposed to the PostScript language. And writing PostScript is not very easy or not very sweet, so to speak, unless you adapt your mindset. But it was very, very interesting finding. So we just took one part of the API, and we found that it had some memory access, physical operating system memory access functionality. So you can say from PostScript, say Vakesworks, give me bytes from this physical address, and it will give you. So we wrote a memory damper, which dumps basically the memory. And it is an old technique, because as you might know, once you have the memory dump, you have basically all computation secrets on any computation platform, so to speak, because file system might not be involved, but everything which is in RAM or in the memory is basically a live state of a computing machine. So we said, OK, it's very, very nice to have this memory dumping technique. And then we just sit and wrote a couple of demos, and basically I'll be showing you the demos. So let's say we have this printer, and it has the administrative security settings where you can say enable the admin password and other power user settings like key user and key password, and we set them, and we disable any user from doing anything normally thought as administrative level operations. We save, and basically we get an acknowledgement that security settings were set on the device. So from this perspective, administrator or whoever is doing a security check says, OK, the printer is admin-locked. It should work fine, and nobody except admin knowing the password should be able to do something malicious, right? Because usually the admin interface is something that malicious users abuse. But we go from the back side. We go from the PostScript, from the normal document flow, document printing language. And what we do, basically, we just take our code. We run it. There was a PostScript code, which we didn't want at this particular moment to show. And we got a memory dump of whatever is there. So the first thing we notice is that a setting an admin password on the web interface doesn't necessarily fix the other modules like PostScript or other modules involved. So we see some different, it's too hot in the room, right? It should be too hot now. Because it doesn't prevent the attack being run on the printer. So it's one of the flows because it doesn't restrict special operations. So this is just a diagram of the attack that having a PostScript with a bomb inside circumvents the administrative setting and doesn't prevent the memory dumping. So then the next thing is we think that, OK, we have secured our product. And we have a password on it, one administrative interface. And let's say we change it regularly, right? We follow our policies. We change it every 30 days or so. We put strong passwords, strong usernames, right? And just for information, the password and usernames were the same, like admin 28c3. And we log on from time to time just to check that the printer or MFP is fine, right? Then we see we've logged in. And now the idea is that, as you can see, that pop-up is usually like a basic authorization authorization over HTTP. And we just let's compute its base 64, whatever is being sent over HTTP, actually, right? Admin username and password. But the attacker can send a very specific print job, which dumps a lot of memory, and does some searching, and so on and so on. And what we demonstrate in this demo is that we dump a specific region of the memory we know. And we take all the memory and using not very smart techniques. I mean, an attacker can get access to the password and username, right? From the memory, as you can see, whatever last username or last several usernames and passwords have been logging in to this admin interface. We have them all in the memory dump. So again, having this and using them often basically gives more chances to the attacker to get your passwords, right? So again, do not abuse your admin interfaces to check them often. And we can see other details like whatever browser the admin used. And we can see if the admin can be exploited, and so on and so on. You can think any other scenario. So basically, the diagram is simple. Authorization, OK. We get the post-crypt in memory. It gets the password to the attacker. OK. So basically, somebody would think, OK, let's enable HTTPS, right? We'll get everything encrypted. However, we have found using the same memory dumping technique, but even security protocols are being leaky in the sense that we have found various private keys, like in memory or IP sec, authentication keys, which again, basically, it's we don't have a demo which we decree the traffic because we didn't have to. We had other simpler means to hack it, right? But again, it's a warning, a big warning, once the attacker had the secrets from the memory, circumventing file access or any other means is useless. OK. And basically, we demonstrated that securing the web interface doesn't solve your problem, basically, in all the cases, right? So what about somebody printing, let's say, a very confidential and secure document and so on and so on? We simulate that, and we have found, as you see in the demo, we have a remote desktop. Let's say it's a high-rank official. And basically, the high-rank official wants to print a very secret document. OK. High-rank official has access to the printer. And we'll simulate as he was printing from his preferred document management application, but it's the same thing. Basically, everything goes on that board. And let's say the high-rank official sets a pin for the print job so nobody can print or take the printout from the machine until the correct pin is entered or some machines allow you passwords, right? And the content of this document is supposed to be secured. And even for you think that putting some security devices on both ends of that everything is encrypted on the wire and no wire shark can sniff it, we are running in the memory. So guess what? At some point, this encryption on the wire gets decrypted in the memory. So basically, whatever is being printed here, his user name and pin and so on, we'll just send it to the printer. And in a couple of seconds, we'll see what actually happens. OK, so the remote desktop, we simulate the printout. The job went to the printer, to the MFP. And I got a paper out of a tested device. OK. Blank because it wasn't too much of a thing to draw, like just a move to. On the other end, the attacker connects to the same MFP having the IP 101 and just running the specific memory dumping code. And on the specific region, we have tried to map. OK, just one sec. And again, you see a lot of memory dumping. Knowing the memory area gives us a lot of advantage because we can just go and check the details or write a simple matching function. And that's it. And let's say we have in the memory, as you can see, basically in the memory, everything which the high rank official, so to speak, or victim has printed and thought to be secure, basically is being clear text in the memory. And as you can see, the attacker also knows the IP from which the secret document was printed. And he knows the contents, knows the PIN code. He can basically harvest PIN codes and passwords from this user and get more advanced knowledge. OK, see? So basically, everything is in clear text in memory, even though you might think it goes even encrypted on the wire. Yeah, so basically, we have access to the interpreter memory and document processing. OK? So just it's simple. Password, lock, and encryption goes to the printer, post-script, inside the memory, the printed document goes to the attacker. So it's a very dangerous avenue because basically, you understand that data theft is pretty easy. OK, and at the end, you might be asking, for example, OK, an attacker can have the access to the memory, but what more he can do to take the data out? Because what I've been showing is just running some code in the back end. And with access to specific APIs, basically, we have found full BSD-style sockets. So you can understand that a specific full end-to-end program can take the memory dump, encrypt it for the attacker, or just strip the necessary details, and then send the full BSD-sockets to the attacker, and then also use the MFP as internal network scanning or attacking device. So basically, we just show that we ping the device, OK? And the direction in this was from our attacker computer to the printer. And now we turn it to the printer, we run the specific post-script code, OK? We see that attacker, OK, these ports are open because we simulate that we print something to the MFP. And basically, we take the code, run it on the MFP. And as you can see, now the ping request is from IP 102. The ping request comes from 102, 102 being the MFP. So basically, we have full BSD-style socket control in the MFP, and it's like a game over, right? You can initiate any kind of raw packets, raw socket, whatever your techniques you know, right? Yeah, so it seems pretty scary if you glue all this code together and run a very simple, small file document. Yeah, this is a simple diagram. So we try to summarize, and basically, on the attacks we have been trying on this machine or on this kind of line of the devices is the protection measures we try to fault where have been easily defeated by the demonstration we have shown. Basically, we have a privileged level separation failure where I showed the administration level not being enough to restrict the memory dumping and other API calls and so on and so on. So secure password setup, also password is being sent in clear text and intercepted in the memory. OK, so now from our research, we have found that basically all of these devices and device line is using the same PostScript firmware update mechanism, meaning that all of them share more or less a common base of exposed APIs and APIs which can be used in the same manner as demonstrated in the previous demos. So more or less a generic PostScript malicious program can be written which perfectly or more or less perfectly exploits all of these devices. Some of them have the same device number, but they are different in various configuration or Vakesworks version or platforms, but because we have PostScript, which is like a Java for printers, it is like platform independent. OK, so just to summarize, the attack in the nutshell, if you in a single slide would be like this, like from our 2010 demonstrations, the attacker sends if a MS Word document specially crafted, which has a malicious PostScript inside it, or he can send specific URLs to the victim on the email or messenger where the victim clicks and goes to specific sites. OK, in the case of the Word document, the user opens the attachment, sees nothing suspicious because there is no computer virus in it. It is a virus in PostScript for MFPs for which we are not aware of any antivirus or IDS or IPS existing on the market. And in the other two cases, it's just a web page requesting you to print something. Think of coupons, right? Who doesn't love coupons? It's like freebies. And the user just print the attachment or print from the web. The malicious payload hidden in the MS Word or Java applet or JavaScript just goes to the MFP and plants the PostScript. And the PostScript, as you can see, could see in the previous videos, can do any kind of malicious attacks on the network itself and also do data theft, document theft, and so on and so on. So basically, enterprise assets are at risk in this particular scenario. So what we envision next is to put everything together and basically make a kind of PostScript toolkit having various generic PostScript or zero specific PostScript which ties together the sockets and file system and other exposed APIs, port at least some metasploit samples, and just have an attacking demo toolkit for high level language like PostScript, which can be easily abused and can be a very powerful target even for other vendors because we didn't test all the vendors on all their other devices. So this kind of scenario would be very dangerous because, for example, PostScript is a Turing complete and you can basically write some bytes on the stack, then concatenate them, and then apply CVX operator and everything like string becomes executable and it executes and all kinds of mess. So it's very hard to actually detect a malicious byte stream because you can compose the executable programs from any combination of encoding, decoding filters and various hex byte manipulation techniques. So whatever techniques known in JavaScript and PDF combined and so on, we're easily transposed to PostScript. And as a solutions, basically we have various categories or actors which we try to give some advice. For example, for administrators, how easy is to defend against these attacks? You'll see in the following videos, but because of explicit documentation and the explanatory notes missing, it's not very easy to understand what those settings do. So admins just prefer not to touch those settings if everything works. So to defend against this attack is quite simple in the first perspective. So a user can go, if you own a Xerox listed there, I would suggest going right after this talk and okay, you can leave everything in or whatever settings you have. And there's a thing called language operator authorization. I'm not sure how much does it tell you as administrator of a device when you have heterogeneous networks with hundreds of device language operator authorization. So the idea is that you have to uncheck that box so that this kind of attacks will not be possible. However, the idea is simple that the language operator authorization is usually enabled by default. So most probably at the next unsecured patch it will be enabled by default. And the idea is if you disable it, you cannot actually upgrade the firmware. So to upgrade the firmware of the printer you have to enable it. And once you enable it, most probably you'll leave it like this or forget about it, otherwise you run into other kinds of problems. And this is a drawback. This should be, if the mechanism should be a little bit different or the documentation should be very easy to understand what this checkbox does. So basically just unchecking this box will help you to prevent in the short run and mitigate these kinds of attacks. So as you can see, basically we have this disabled and you can see we have invalid access given by the device. So in short term, it's a solution for you as administrator. You have zero of these models go and do this now. Don't forget to enable when you do firmware upgrades. Okay, should look for security bulletins for various vendors, depending how heterogeneous your MFP environment is. It's like keep an eye on HP, on Xerox, on Canon, on every vendors if you have all these vendors in a network because PostScript interpreters have their own bugs as well or various customization which has bugs. So it's very, very good to see. Sandbox the printer, so they have their own VLAN or have very limited and restricted environment and so on. And very important include MFPs in the security audit life cycle. So most of the, because they're not very homogeneous or doesn't have like a very usual security. Settings they're often left outside of the security audit life cycle because it's just a printer, it prints on the paper but as you could see, it's not the case. For the users, it's hard. You just can't advise what you cannot guard them or with their fingers. So just have to educate, the managers have to educate the users or users educate themselves. Do not print from untrusted sources or be suspicious what you print, especially it's freebie. Okay, and for the vendors before or during their life cycle to create realistic MFP threat models, meaning that try to put that MFP in a real world scenario, a real world security landscape because putting it out of a context and checking it for security, right. Admin interface is secured, everything is fine. We are great, but if you put it in another context, then it completely changes the game. So realistic MFP threat models is one of the things that can be improved and other thing as history has shown over and over again is that just do not enable or expose or do not use and implement super APIs and try then to hide them. Don't do this, it's the wrong way of doing, I think. Okay, so we'd like to thank Xerox security team because they were positively on responding to our responsible disclosure context and we are very active working with them and their side is well very active in checking the affected user base and propose active mitigations. And basically what are the takeaways from this talk is MFPs are really, really bad in security as we stand right now here in this room. So this has to be understood because in the last couple of years a lot of MFP and printer security talks evolved and techniques and we basically want to emphasize that there might be upcoming wave of various security threats targeting MFPs because of their weaknesses. Of course criminals or others could go for the easy prey and why not doing this. And basically the last thing is securing the MFP infrastructure requires better segmentation, strong credential, secure proactive thinking and basically continuous vulnerability patching in its all lifecycle meaning from vendor to the client, to the admins, to the user and so on. So it's not just a target to achieve a security compliance level but again it's a whole process in itself. So basically these are my contact details. If you have any detailed question afterwards for this moment I say thank you and if you have any questions in the room. Please try to remain seated while the question answers ongoing because it's extremely distracting if people are going to leave now en masse. So if you have questions queue up at the microphones I am seeing two already. This one was first. Very interesting talk, thanks. I have one question about something you alluded to in your slides. Given a Word document how can I embed a post script fragment in it that will execute on the printer? Have you explored that at all? Is that an avenue that's actually available to attackers? Basically this attack which you are asking about or document it's been demonstrated in my 2010, 2011 talks and in the slides you'll get a link to the YouTube showing this attack so it's not theoretical it's actually practical. I mean you can, there are really ways and I'm trying to also, we are trying to go with vendors of office or whatever right to see how it can be solved but it's like a legacy functionality which has been carried so it's available I think from Word 3.1 or whatever till now so it's a practical attack. To the last one, my memory is that you can embed an EPS into a Word document and that gets sent to the printer raw. Question, how certain are you that the super APIs are only available in executive mode? Come again please. Are the APIs also available outside the executive and can you prove they're not? Basically we don't care if at this particular moment we didn't care secret or hidden or super APIs being outside of the executive because once we had them in the executive it gives us a platform independence and basically it was the thing we found and we explored it but it doesn't exclude the possibility of having other hidden APIs and just to give you an example I have seen basically firmware updates where PCL and PCL being a very very restricted language compared to Postgres which is just drawing right but even there I found vendors which have secret APIs and do firmware updates through PCL which doesn't come even close to Postgres in powerful general purpose or other levels. So of course there are plenty of them but because their embedded system closed things very heavy to try to purchase and explore by independent researchers it's still hidden. Okay we are leaving no note behind so we have a question from the internet. Yeah, here somebody wants to know if it is possible to change the printer firmware so that the printer can damage itself leading up to completely destroy itself. I missed the second part. The question was rather it's possible for the printer to destroy itself by changing the firmware. Well basically I would not like to comment on this because there was like a big hype fuzz and so on and so on. Unless, I'll put it this way. Unless there is, okay just a complete thought. Printer fuzers especially laser ones have specific temperature ranges, right? Some of them go to 250, some of them go to 270. Normal paper burning temperature depends whether it's surface or there is an ignition source or not and so on and so on. And putting these things together is hard to say that plain paper would just start burning in the printer. Right, but, but, but. What I want to say is for example imagine if there's a more complex attack where the paper supplier is being actively attacked by whoever and puts sheets of paper with special powder or chemical substance whose auto ignition temperature is like 230 and there are like three or four substances which can do this. So in a combined attack, yes, this is pretty accomplishable even today, right? But these are just facts and unless there is a demo demonstrating this or unless there is an independent laboratory, safety laboratory which demonstrates otherwise it's really hard to tell but yes, this is true. Yes, it's like a P different than P, right? Okay, but I think this is a very stupid thing because if I want to burn the printer I can just put gasoline and then flame it. And so I don't need to know something about postcode. But I think that's another interesting thing. Would be interesting to buy exactly the same printer, have fun with the logic analyzer and modify the firmware. So I have my own printer modify a firmware, put in some special function that I want to have and then make a document with this modified firmware, send it to somebody I want to tease and he gets my special firmware and I can do some special stuff with his printer. And I think this would be more interesting and there's also one interesting point because modern photocopiers and bigger printers have hard disks and these hard disks store all the jobs. And so if you for example go cleaning you can exchange the hard disks every day. So if you maybe you say I'm a low skilled worker and I go cleaning and then you for example go for the hard disks. And this would be interesting for example to know if they are encrypted or not and then if they are encrypted to get the keys from the memory and then have fun with the hardest contents. The points are good. I just want to put some one point for each of your part. Basically, indeed having a custom firmware is interesting and indeed putting like a backdoor functionality there is even more exciting. However, I'll just try to emphasize which I wanted to actually during the talk is that demonstrations which I showed you relies basically on simple PostScript commands and I don't even have to know anything about the firmware format, firmware signatures, firmware packing and so on and so on. I just run PostScript. And this is very important point because compared for example for other attacks in order to write yourself a custom firmware it's not necessarily very easy because there as I said, a lot of steps involved like understanding the packaging format, understanding the signature, writing the firmware of completely heterogeneous and non very used hardware is indeed a challenge. And for, it depends what your scope, if you want to bug for example a specific country where you ship a specific model line, of course there's like all the possibility in this but if you target only specific user there are easier ways to go around. And the second point what you said about hard disk actually it is well known problem and in 2010 there was a big investigation done by CBS in the United States where recycled MFPs, printers, copiers got sold and they belonged to government agencies and there were unencrypted documents regarding criminals and prosecutions and orders and so on. And then it was raised at very high level and basically the vendors had to come with military standards for digital information shredding on the hard disk. However, we don't have any independent view and testing results over the efficiency and effectiveness of those shredding techniques implemented by the vendors. They're claiming, they're being certified but there is no like independent view on whether these are effective. Of course you can do a lot of work and actually this was done by a CBS investigative journalist and it was proven so. Are the firmware images somehow signed so that the printer says no, this is an illegal image. I don't want to print it and I will go into some debug me service number sound so mode and then do we have to call the service? So if you for example want to print a money bill they go also into a special service mode that you cannot print again. And so maybe they if you want to so if I would make a printer I would make it like this that if you print an illegal image that it goes into a special mode and locks it up. Well, it's again, you know, it's a philosophical problem. What if the same was done for your iPhone? For example, you could never use it again if you put some other firmware or signature or signature checking was indeed enforced, checked and so on. Would you be happy to have your device talk? It's again, there's no true, true, true balancing here and you cannot lock a user device. However, the takeaway from your question is to have secure hashing algorithm, not CRC32 and enforce it and check it properly. These are the takeaways. Now, whatever other things are going wrong in that direction is a totally different story, I think. But you haven't investigated if this is enforced by the Xerox printers? No, no. Okay, we all do this round robin. There was a question over there unless it's died of old age, okay. Then we have two questions at the front, one from the internet first, I think. Well, there is one. Has Xerox did anything against this attacks? Sir? Did Xerox do anything against the attacks? Basically, we are in the process of responsible disclosure and mitigation techniques and affected user-based discussion. So as you understand, it's like a longer patching process, like assessing the risk and so on and so on. So we are in the process, but it's not yet ended, so to speak. Okay, at one time only, Alfa, I bring the microphone to you. Okay, you have full memory dumps. Can you use them to have a software printer emulator so you can do all the security destruction on the software printer instead of destroying your physical printer, which is very expensive. Well, I don't know how much would destroying a virtual printer would help you in assessing the threat and risk of destroying the physical printer. So, but your first part, first point, which you mentioned actually is very valid in the sense that because PostScript is a Turing-complete language and it has very interesting primitives, you can actually redefine the language. And basically, whatever the user document contains, like draw this line, put this dash, use this character, you can route everything through your own APIs. So basically, you can write a virtual PostScript interpreter in PostScript and route any of the basic PostScript calls to you and store all the data in the file system for later retrieval. So basically, you do a virtual machine in a virtual machine, so to speak, using simple PostScript. It's a tedious process to write like a PostScript custom virtual machine on top and redefine all the operators and language and so on, but it's doable. It's there, there are samples on the internet and it's easy to do. Okay, we have five minutes left. There are remaining questions over there. So you've looked at a lot of these specialized operators in PostScript and I'm wondering if you've seen any bugs that look like they could lead to native code execution on the microprocessor that's implementing the PostScript interpreter. So just to understand if there are any bugs which we can exploit from PostScript to execute code on the microprocessor. Obviously the firmware update is one way to get native code execution, but I'm wondering if there's any runtime exploits. Yeah, basically in this particular scenario, you don't need even an exploit and I'll tell you what. There are two things. Actually, you can page the code in the memory. You can also have write access and if you know which memory to which device is being mapped and know that operator or code language, you can page it in the memory. This is one, this is an obvious exploit, but the second is everything is running in Vakesworks, a specific version where you can run it through QEMO or so on and so on. And there are file system APIs where we can actually write a binary blob to the physical operating system file system, okay? So you compile and executable for this Vakesworks version. You just upload it using PostScript and basically it executes as part of Vakesworks. We didn't go as far but everything is in place so with literally effort of compiling and uploading is like, you get the point. Okay, next question. Yeah, hi, I just like to add some notes on this hard disk issue or question so I did some research on that with a colleague and this... Can I pick another one? I'm just commenting on this hard disk issue which was just asked before. I did some research on that with a colleague and this whole thing with CQL file management and stuff turned out to be a total mess so even though the vendors claimed to use some CQL file management who were easily able to reconstruct a lot of files, so what they do is they create some kind of pseudo file system which is not easily recognizable and looks like something encrypted. However, if you've been working on the raw device we were easily able to reconstruct file headers and corresponding files and for several cases we reconstructed like 10,000 files which turned out to be basically everything which has been printed or scanned with this device in the last two years so yeah, you would not want to rely on that. Exactly, as mentioned. It's basically security but obscurity and I mean as we all know this doesn't work at all. It has to be independently tested and have a very open guideline for testing and assessing the security of these features actually. Sure, thanks. Okay, then our time is up. When you're leaving, please exit. Thank you again. Big applause.