 My name is Annex, there's not so much to tell about me, I'm not formally, not professional security researcher or something, I'm just a dude. And I was kind of forced to do this talk by a good friend of mine who has been asking me for like a decade to visit one of the events he attends, he basically attends every event, I don't. So this talk is basically exclusively for him, but it's also for you as well, so have fun. Maybe it's a good idea to start off with a few questions, as so many do. It's a question that has been asked quite a lot in talks I guess. So how many of you have a Wi-Fi router? That's some people, it's not as much as I expected. So how many of you have a smartphone? That's more. How many of you trust your Wi-Fi router? That's not many. How many of you trust your smartphone? All right. Actually that's pretty encouraging, at least for me, because it shows you're actually skeptical of security issues, I guess, on those devices. I'm afraid many people are not, and that's why the first topic I'm going to talk about is Wi-Fi routers. I guess I'm not going to tell you a whole new story here, so Wi-Fi routers can be safe, they can be fun, they can be great for surfing wirelessly, primarily. But they can also be a menace, especially if you have default passwords set up that are pretty much easy to guess, or even plain readable. So there's been a lot of talk about this, there's like five to seven common models here in Germany alone that you can basically have a script, calculate the default password for, and just have free Wi-Fi, right? And of course it's not that simple, people may change their passwords, some routers have default passwords that we just did not reverse engineer yet, I guess. Some seem to be safe over the course of time, but in general you could say that there's a lot of models out there that have insecure default passwords and are still in use. So if you go along in LA here in Germany you will find like 50 boxes and maybe 30 of them still have their default password, they still have the default password on the admin page as well, so you could actually change things. For some people that may be cool, if you happen to be out of bandwidth for your cell phone, there's free Wi-Fi, right? But it's also a problem if you have grandparents or maybe your parents even don't change that password, you're gonna be fucked basically by just entering their network, kind of drive by. So that's the problem, totally forgot, think about your parents. And even worse, that's not the end to the menace of Wi-Fi routers, usually a Wi-Fi router is, if it's Linux based, is a system of a chip, chipset that is usually produced by huge companies, something, a company like Broadcom or something, and they give you a development kit with it, they have a nice demo board and other companies come and get this development kit and kind of make their products and put them out there. The trouble is they don't make updates for those machines. So it's not only that you can access a wide range of networks, you could possibly do whatever you want with those networks, like have ports forwarded to you or lock the owner out or something, but they're actually running old software in many cases. And so yeah, I'm just forgetting to skip through here, please forgive me, because I didn't have time to prepare this so much. So there's reasons for this, I basically mentioned one of them, you have those chip producers, they basically do the initial part of the software, give you a development kit and the company's making the final product, basically rebranding them, they make their fixes, they make their changes probably at a Gizmo or two maybe, but they are not the masters of their code, they basically depend on the chip developer to give them updates, sometimes they do patches if you have a good vendor, like I don't know, I wouldn't call dealing good, but they make updates if something breaks, you can download an update from their page. And so even if there are updates, many people don't know that they are important, many people don't know that they could be installed and many people don't know that it's a problem at all. So there are some reasons out there, many vendors claim that it's just too expensive to have regular updates and they will only move if it's really, really, really, really dangerous and an update is needed to prevent like total mayhem, but actually they won't even do that, so there are reasons they are just not convincing. So those systems are Linux, right? So let's just fix all those systems. Well, first of all, Linux isn't Linux. It's a sad but hard truth that I had to learn, I did a lot of embedded development myself trying to modify those systems, trying to get them to do my bidding and what I learned is even if the source code, for example, for the kernel is available, you might be locked out of the bootloader, so you can just install a new kernel, it just ends there and you have to resort to accessing the hardware, disassembling the bootloader to find some way to work your way around the signature and to update the router in the end. I'm sorry, I'm getting a bit too technical. So coming with that, sorry, Linux is best imagined if you have a desktop computer and the full experience should be like you can build a new kernel, you can make all devices run somehow by getting your device drivers right, compiling some kernel modules, sometimes even more exotic kernel modules that will sometimes even be proprietary, sorry, so after all, it's really messy, you don't really want to do that without proper support, you would like to have the dev kit for example from the chip vendor, that would totally help but usually you don't get to that, there's a contract, you have to sign, usually you have to pay a lot of money to get access to those things and if you're not in education or something, you can basically forget that. I'm independent, I don't have any university backing me so I wouldn't get the nice stuff. So that annoys me, it's really messy and nobody wants to do that. Actually there's people who love reverse engineering stuff, people who love finding things out but this is a multiplication problem, you don't have just one router out there, you have like hundreds of them, hundreds of models and if you have fun assembling like one boot loader, maybe the second won't be funny anymore, maybe the third will be really annoying and maybe the fourth you won't do at all. After all, we need some way around that, it would be nice if we just got the complete sources for every distribution that's out there, not just the kernel sources but also the sources to their web front and they use the VPN solutions that are installed and stuff and it would be nice so I would say give us all your code but I'm just saying that, nothing will happen. So next up is smartphones, you can see I'm skipping over it because in the course of the development of this talk, something changed. My point was kind of made by somebody. So we're not going to talk about apples and Microsoft today because that would be too easy, right? It just doesn't make sense to bash them. So Android is Linux 2, right? But it has the same problem somehow. So in the Android world, you have chipset vendors, people like Broadcom again or MediaTek, there's a lot more and if you're not Samsung or like Google, you don't control the complete chain of creating this product. So you usually have a chipset vendor and if you're a chipset vendor, you basically put together such a system where you have a system on a chip, you have some fancy gizmos attached to it and you basically put it all together in a nice package and says, tell people this is the new generation of smartphone technology. Usually this ends up in a demo board with some vanilla Android attached to it. So now you have to find someone who wants to be Samsung, of course that's easy. There's literally hundreds of companies out there trying to do this. And those companies would be the product vendor. I have, for example, I have a device from Vico, it's a French company doing the exact same thing. And they basically make a nice design with shiny 3D animations and gloss on it and stuff and they figure out how to pack the PCB, the battery and everything into that device and they basically will prepare a campaign for that, launch the product and then of course money. And that's how far they think. Usually this goes on for like a year or something and then something bad happens. For example, like an exploit could be a buck that just crashes the device and bricks it or something. But in our case, let's assume it's an exploit. So usually Google would assess the exploit, would really deeply look into it or Samsung. It's not just Google, a serious company would look into that exploit, devise a fix, fix the bug, make a nice package and push it out to the users and bug them to basically install it because it's so important, it's an update. You have to do it. And then there's how many other vendors do it. So this is a huge problem. They don't do anything. They don't do anything. They just sit it out and hope nothing will happen. They hope nothing will happen. So let me tell you the story of my weekend. On Wednesday, I believe it was Wednesday, good friend called me and he said, well, I'm going to Easter egg and we have a problem. There's two workshops where the people couldn't come and couldn't you come over and like do something. And I was like, oh, a workshop? No, I can't do a workshop. Maybe I can do a talk. What's the furthest away day? I can do something. And he said, yeah, well, Monday. I had a little idea talking about the lack of software updates on Android and on Wi-Fi routers. And I was kind of joking with him and saying, yeah, well, the really good example to show how big a problem that is would be something like kernel level remote code execution. But when does that ever happen? Like when you can reach it? So I don't know. Out of a guess or a hunch, I just Googled that. And I was like, well, I don't know what phrase. And few days earlier, as it happens, there was an exploit was made public. So you can see it was actually found in 2016. That's a name and just a researcher that found the exploit. And what it basically does is own your PC. And I was like, well, I don't know. So I just looked at it remotely with full powers. You're not root. You're beyond root. You define what root is your kernel level. And it's actually pretty easy to write exploit for this because you can link against Kali seek directly, but it's out of scope. So what about this bug? It's something you should be honest about. That's why I had the word play with Ernest and kernels. It's Oscar white novel. You don't have to get that. But it's serious. It's serious. It's severe. It's pretty bad. It's really bad. But everything needs a context. And even this exploit is not almighty. Turns out it just refers to the receive from receive message function. I don't know why the road receive from. It's basically the same. It gets linked in glibc to this is called receive message. Concerning UDP used with the message peak flag. That sounds very technical. Basically, what this does and it's a totally legit use of code. I have to stress that and I will stress it multiple times because names will show up and you will hate those names and no, it's all cool. You can do that. And the bug is on the kernel side. Every software I will tell you about from here on is perfectly innocent. The kernel was the problem actually. As you can see, the current kernel version is something around 4.10 or maybe 4.11 already. I don't know. This was 4.5. Still a pretty recent kernel. Many stable releases have not yet made it this far. So what you can definitely say is that no Android device has such a recent kernel. And what you can definitely say is that probably no Wi-Fi router out there has such a kernel. So maybe to clarify the context we have to clarify what UDP is. Maybe not everybody knows that. Let's rehash. It's TCP sister protocol. TCP is basically a stream-based protocol. You have a two-way connection and you can write to the other side. You can read to the other side. The order will not be changed and it will be guaranteed to be delivered if possible. UDP on the other hand is a packet-based protocol. So you have no guarantee over the order. You have no guarantee over the arrival of messages. You have no guarantee at all. You might get an error back. You might. So it's lighter than TCP. That's one of the main reasons we have it. It's very versatile. You can basically build TCP on top of it or some other protocol. And it's used in some pretty, pretty, pretty important parts of the Internet like DNS that gives you Google.com or any other domain you could possibly want. And it's also used in DHCP, which is the protocol giving you your IP address when you enter a Wi-Fi network or some other network that has automatic address distribution. So those are pretty core. Those happen to be everywhere, those two protocols. It is also used to penetrate network address translation, which is measure or a technique. Your Wi-Fi router and other routers will use to make multiple users use one connection, basically. I will explain this in detail now. Well, not really. The reason we have IPv4 is that IPv4 is running out of addresses. And we have a replacement UDP. What the fuck am I? We have a replacement that's IPv6 and that one is not coming along very well. It's getting better. It's being implemented here and there. But not everyone has it. And many people still just get an IPv4 address to use the Internet with. And that's why we have NAT. So basically if you have a computer here and a computer there, the NAT will note and remember which computer wanted to talk with which site on the Internet. And when the response comes, redirect it to the correct computer, to the computer that actually made the request. So that's nut. The industry tends to tell us that nut is a security technique. It is not just like virtualization is not a security technique. You should really not trust any machine that runs one thing to be completely disconnected from the other thing. There's always ways around it. And CPUs have caches. So it's wrong that nut is a security technology. But right now it may be actually be the sad truth. At least do we know more. Why am I saying that? Because the situation with this exploit is pretty, pretty, pretty complex and pretty vast. It could be the end. But I'm pretty sure it will not be the end. So it's probably going to raise some eyebrows here and there and make people pretty nervous. Maybe even make someone release an update who hasn't released an update in 10 years. I don't know. So what we have to find out is which software is affected. And this is crazy because usually you would do the reverse thing. You would see which software has a bug. But this time we have to look for software that doesn't have a bug. We have to look for software that uses totally legit code on a broken kernel. And will therefore forsake your system and your whole security. And that was pretty adventurous, I can tell you, the past few days. I didn't have that much time to do it in detail. But I was so shocked that I kind of decided to make this the bigger part of the talk. I was actually just going to reference it as, you know, here's one perfect example where you should update your operating systems even on embedded devices, even on your Wi-Fi router. So IPv6 is affected as well. There is another way to get around your NAT. If you are so lucky to already have IPv6, many ISPs have not yet found out how to configure a firewall for IPv6. They just have IPv4 rules. It's pretty devastating. So this could be a problem as well, but I didn't look too deep into it. If it works, it works. If it doesn't, it won't. If you are on this Wi-Fi right now, you won't have NAT anyways. If you are on, like the local Wi-Fi with your cell phone, your firewall won't help you. There will be no NAT around you. If somebody could exploit that bug and you would, you would have some software running that is prone to this attack. By the way, you could do that by! So are you really sure? Nobody in this room has Skynet already? I have Skynet. So what software would really do that? Messagepeak is a flag that makes the kernel give you the next packet. In this case, could be the next few bytes on another protocol, but in this case it will give you the next packet without deleting it. So you can just take a peek. Is there something interesting for me? And if there's nothing interesting, you can just go on with your life. If there's something interesting, you let the evil intruder become rude and just be done with it. So keep in mind, using this combination is totally legit. It's just an interface the kernel offers and the kernel broke. So even if you hear a few more popular names here or if you don't don't curse the software I'm going to put up now. So what apps do actually use that call? I did a quick search, downloaded all the Debian and Arch sources and grabbed through them. I have fast internet connection at home. So that's actually too big. Just a sec. Sorry. So now everything is going down. I don't know what happened. Okay, there's a lot of packets. I found like 800 packets when I started out just looking for message peek. So it's not that uncommon. Famous German security researcher said, well, that's not so uncommon. I can't cite any case. He was shown a few cases in the ensuing hours. So there's loads of programs that possibly could expose this bug. The artist finding out which programs really have this bug. So the first thing that came into my mind when I read UDP was the DNS protocol because it's the most core, most essential protocol of the internet. The internet wouldn't work the way we know it without it. So in this case you had to check like core libraries, the G-Lib C library for example, how they handle DNS requests, how they ask the server and wait for the answer because that's the point where the exploit could actually be used. And turns out there's no danger here, no apparent danger here. Let's say a bit of a distance. I checked Bionic to be safe. It's a derivative of other Libs so it was pretty improbable that they actually added something like that. But I wanted to be on the safe side and it doesn't look like DNS would be affected anywhere. Because I'm a Stripped Kitty and use Node.js I also checked LibUV because it's used almost everywhere for event management and a lot of stuff but it looks safe to me. So that's the good news. In more good news people speculated that system would be affected which is a system, we have a good German word for it. It's called the application that brings up your system, checks the time, if you have a service here it can totally receive a package, start the service, pass on the message just like Inet was doing a few decades ago. No. So it's very popular, many distributions use it, the Debian has it as default. If that would be exploitable we all would be fucked. So there was one line over there, it said receive message, peak, if the peak variable was set, fortunately I checked which file descriptor type it was calling and it was a net link socket, it's not UDP, the kernel should, if the kernel was not again in error, the kernel should totally call the write receive message or receive from function, not the UDP function. So that was close. So let's get over to the bad news. What's probably affected is anything local, of course, it's a remote exploit that goes to kernel level. You usually have software locally that would expose that exploit. I looked into a few things I could think of, any NetCut version has it, NetCut is a program to just pipe network streams here and there. It's like a Swiss Army knife of networking and it's probably affected just as Nmap, very important security researcher tool, etc. There's even open SSH is a NetCut implementation, if you don't have a NetCut, open SSH will give you this version, even it seems to be affected and keep in mind it's not affected as in it does something wrong, it's affected as in the kernel will harm it if it does that call. So busybox could be, there's one case where I'm pretty sure UDP sockets could end up being called with this message peak flag. There's also an iNet de-implementation but I think that's a control port. I didn't have time to check it in depth because it was really confusing in that five busyboxes. I don't know. It's pretty clean but it can be disturbing sometimes. What's really a problem is DTLS. If you know TLS or heard of SSL it's what usually makes your browser connection safe. DTLS is the version for data-gram-based protocols and it's basically used by banks to trade a lot. So it's kind of an important protocol and not many people actually know it outside of the realms where it's used but it exists and it has been used for some jobs quite extensively. I really hope those people are aware of it because I checked some implementations. This is just don't be angry at OpenSSL again. It didn't do anything wrong this time. So DTLS seems to be affected and that could be a really big problem although the markets didn't crash as far as I know. I hope my talking about it will not change that. So let's come to really, really, really bad part. Most of the Wi-Fi routers out there based on Linux will have some kind of embedded Linux low-size system basically being based on busy box or some lightweight tools that they can use to do stuff other systems do with hundreds of megabytes in let's say four. So I looked into DNS mask because it was speculated it would be vulnerable to. Turns out it is vulnerable. So as far as I checked, you don't please don't take this as an absolute verdict because as I said I didn't get to check everything very deeply. I couldn't do like a life exploitation test on it because it just didn't work and I had to abort the test in order to write the rest. So VPN software is also probably affected but only if it uses for example the Ike program I found some suspicious lines in there as well. But the really bad thing is DHCP because it's going to be used. We can be sure it's going to be used. The rest is basically would be bonus. So your Wi-Fi router is probably affected if your provider doesn't force upgrade it or the vendor gives you an update, you're basically only protected by your nut. So think about whom you let into your Wi-Fi. If it's actually the case and that should be verified, I really don't want to have a final verdict on that yet but it's UDP, it's used with that flag and it seems pretty bad. So also virtually all cheap Android devices and that's why I explained the whole food chain of Android earlier. Somewhere in this food chain people will just try sitting it out, probably don't make an update and that's why this vulnerability can even be probably even be exploited in 10 years if somebody happens to have a cheap Chinese Android phone that is going to run in 10 years. So this also shows another problem we cannot control because it's not open source, there's a lot of voice over IP software out there and video software out there like Facebook, Skype and stuff. We can't look into their source code of course they have external audits but in this case we would actually have to see if they use the syscall on the binary, it's possible. I just didn't want to download Skype right now to check it but this should be checked as well and I obviously didn't do it but the essential thing is voice over IP protocols use UDP to break through your firewall to enable direct communication between the video chat partners so it's probably going to happen and they're probably affected without knowing it yet. The hotspot function on Android uses DNS mask as well because it's just it's a very nice program I use it myself to just set something up quickly I hate the config file and I hate the config syntax but everything else it does quite good and finally this is basically the core problem of this somebody at some point in the future could like give you an app that is totally legit using this syscall you just don't have a kernel that was patched against this bug it was fixed and he could just use this bug and of course it's android you have to press ok I grant this app every network access it wants but that's the kind of kind of click almost everyone does even even I do because you know I'm paranoid but that's a pretty standard request you want to talk to the internet okay do it so Android does things to prepare stuff like that to prevent stuff like that but it could ultimately be exploited and it could basically happen to me if I don't if I don't see it coming if you know in one year I will have forgotten about this probably and somebody will pass me an app and yeah fuck them I so let's come to the really scary part your internet service provider usually has a box at the side of the street cell phone tower I don't know those are usually big Wi-Fi routers or big routers usually running Linux usually needing some kind of authentication and because providers are the kind of people who want to pay nothing and take money for that and basically complain how expensive nothing is they use free radios it's a radio implementation radios is a TCP or UDP based protocol UDP is pretty popular on radios so I look into this and they are definitely using the rights is called definitely using UDP sockets if this setup would be running like this they would just as you are would just be protected by their nuts and firewalls if they had direct exposure to the network they could be exploited possibly very possibly if this whole thing works I you know I could be an easter egg maybe this exploit doesn't even exist I mean it's like a wet dream actually so you really don't want to look into browsers it's it's just scary I did a grab and I actually killed the grab because it was too scary it's used in WebRTC it's used in diverse other protocols you someone should really have a deep deep deep deep deep look into that so this is a rather broad scope every machine that cannot be patched your PC for example will possibly not even have it anymore because you updated at some point and you got in your kernel and it's no problem anymore every server on the internet you can just update there's just that's no problem so even if it's not open SSH remote code execution it is still pretty bad it affects services that run by default and that run in pretty prominent places and exposed places so this is certainly a bad wolf scenario just to get the doctor who reference here and so you might be asking yourself can we just fix it and the answer is it's already fixed it was it was not even deliberately fixed somebody discovered this bug in retrospectively this bug was fixed in 4.5 and he just discovered it last last year and end of last year when it was like 4.8 or 4.9 I don't know this bug is already fixed that's not the problem we can if you can install a kernel yeah but not everyone can do that and actually at this point I was going to show you how I would do it right now with my cell phone my famous Viko cell phone because they actually published the kernel sources for my device and I could just go into the kernel sources apply a tiny patch that changes three lines and I would be rid of the problem the whole action if it worked would take maybe about 10 minutes flashing rebooting and stuff and most of the time I would be angry about my cell phone because it was slowing down the process but not everyone can do that as well so we're in a bad situation right now so this is the patch actually oh it's four lines but okay maybe you can see what happened here but it's it's hard without the context it's a very context-based bug it's hard to spot and so we can all speculate about the NSA putting it there maybe even Skynet I wouldn't go so far I would say the NSA is just enough so we should still check this out I as I said I didn't do complete analysis of this thing I just went through the whole code base and saw what could be affected how far could the problem go something we call a threat assessment but as it was not finished yet is it is not finished yet you can't even call it that it's just a talk it's just me talking and please don't panic right now nevertheless you should take this seriously and if you can we should fix what we can because as we know in infection cases it's it's always helpful to immunize as much people as possible so they can actually have something we can actually have something like herd immunity and I think that is going to be a topic concerning this bug and probably other bugs that will follow because this was only a matter of time and you you rarely get such a beautiful one and of course it wasn't the end of the world because if that would happen on TCP we would be standing here nobody of you would be here anymore North Korea would have taken over and that would be the end of the world we were actually pretty lucky it was just udp so we should make vendors release current kernel trees at least and that's the thing that has been done you can put legal pressure on them you could do public pressure on them the thing that counts is that we get the sources and the kernel kernel tree even if it's messy would make me happy but we actually need device drivers as well because usually you may get a running kernel you can even boot your device with a mainline kernel like the top edge development kernel but you won't get your baseband modem on the smartphone running or you cannot use your graphics card because it's it uses a blob a piece of software that you don't have the source code for and you just have to talk to by a standard interface in order for it to talk to the graphics card for you and this is a fairly popular problem and so we want to drive us as well and that's that's one thing you can we can fix it also we have to think about the future we should make more informed choices about the products we buy and we should refuse having hardware pushed onto us especially if it's not updated as well so conclusions we need access to the kernel sources just to see what's going on if they changed something if they didn't patch something we need need to be able to see that because it's pretty hard reversing that and usually I'd say everything is possible if it's just one incident you can go miles to get an information but if you have it have to do it in like a hundred million cases for hundreds of models of smartphones and wifi routers this is not going to be fun that's something we can do a distributed but it's not fun for most of the people so we need the drivers we want them to and we want the bootloaders to be unlocked in order to take full control of course something needs to be it needs to change with the general situation as I described you can't have this whole situation where the information is kept back by a chip vendor hiding behind the product vendor hiding behind the sales clerk on your car hiding behind the car sales what you know you know what I mean it's been a long day so if you don't do that those markets may collapse because consumers may lose trust and this is just the first buck of this kind I'm not even sure if it actually works as I said I just try to present a colorful assessment of the possible threat if that all works out so consumers might be pretty disappointed and turn towards apple or microsoft and we can have that right so be aware winter is here so if you want you can ask some questions we have still a few minutes left maybe five minutes of questions if you have any I'll sit do you know if that is also usable as a local previous escalation so if yes and there's millions of ways to do it locally you could write this code yourself millions of ways you are talking a lot about the problem of devices of embedded devices that don't get updates with this bug in particular but isn't this problem isn't this a problem for every bug with devices that aren't getting updated and what makes this bug so special well I actually wanted to spread awareness about devices not being updated with this talk I just came over this bug and so the talk came was best specific to this bug I actually would have given you a broader scope with internet of things in it and many other things but current events change that so I have another question what kind of network access is required to create such a UDP packet that triggers this bug is an invalid UDP packet or invalid IP packet or what needs to be done to exploit the bug so as I said I never managed to reproduce the bug itself uh because of short time as far as I said I understand it you can send basically a pretty standard UDP packet you just have to trigger the the context in which the bug would be triggered and for that um I unfortunately uh was lacking the expertise and time but uh the bug is real it's uh it's um it has a cv e number it's rated 10 in every category so I guess it is exploitable if it finds a tech surface and that's what I was assessing I just didn't go into that if I had more time I would have done that I actually was hoping to be able to demonstrate something quickly but never works about your special device um there's the binary modules in the kernel like my cell phone yeah yeah yes I have um blobs for the baseband modem and I have blobs for the graphics card and um as I have seen it on all the embedded platforms I've worked on um be it raspberry pi be it uh more router specific chipsets with lower power um they all have kind of this problem they will all require um proprietary uh proprietary software at some point although the raspberry pi has been pretty unlocked uh very far so um the whole raspberry pi experience is is in my opinion is about unlocking the nda clauses uh on the hard uh on the hardware and getting the information to write open source drivers and the pi is the furthest one I guess uh you can always buy google nexus and stuff uh something you won't get um you won't get a binary blob free hardware um but it will be better you will have better uh uh support through the code base and it will just work but uh that's I guess that's not the phones most people can afford or want to have that so that's sad maybe a bit more of a comment besides the smartphone market and tablet market there are some uh silicon vendors which produce stocks for which we now have uh yeah full mainline uh kernel support graphic support and video support so on top of my mind there's uh the free scale imx6 which has the atomvif driver which some colleagues of mine uh worked on and are maintaining and yes but and there's also the the raspberry pi where there will be probably some good quality 3d acceleration and measure you you're making a very good point there everyone get a pyra everyone get a pyra that's one of the possibilities to get such a platform and it will actually rock if it's ever done and I'm pretty confident it will be done so it's not as fast as current smartphone ships no but actually don't require do we require like eight cores with two gigahertz two gigahertz each I think most of us don't yeah it's a trade-off you have a fully open system you have full control over the host and you can fix bugs so that's worth a lot more than fast graphics you preach into the choir choir are you afraid you shouldn't be um can you explain the bug if it's possible to understand easily um okay yeah basically the root of the bug was uh uh that um the checksum a checksum that was calculated uh uh in uh second level paths of uh uh uh logic this a check check sum was wrong the first time it does the re uh the right check sum and the second time this uh check fails because something is gone already or has uh has been has been uh um um has been excluded by logic and um that's that's what's actually this small patch fixes and um it's hard to explain because I was actually sure what's happening and uh what was happening and then it didn't work when I tried to exploit it so I'm totally confused now you should probably ask somebody who's unbiased and you know didn't try for like a half an hour to to to get it working and was was was really disappointed because it didn't so I think timing wise we're about through we have like almost two and I think talk is afterwards thank you and uh please would you have a little applause for my friend Max here who invited me who made me come over here who made me make up this talk while I was eating cake with my sisters on sunday he's the best the very best thank you