 we appreciate it. I'm actually really excited to be here so it turns out if you organize an event and do a technical talk it's quite a challenge so I'm really glad we made it. It was not an early night last night but I think we're in good shape. Okay so first off does anyone here have these kinds of smart lights at home yet? Can we see a raise of hands? Also this may be a quarter to a half of the room here. This is very interesting. Hopefully you will have some new tricks up your sleeve after our talk. Okay so first off who are we? My name is Tom. I'm one of the organizers of the camp here. I'm a firmware engineer at Ultimaker and I have a little company that makes quirky electronic gadgets. I'm here with my long-term friend Gillet. Hi my name is Gillet Nostar. I am a security engineer and an internal blue team so I do incident response. I also like to also I'm quite an avid CTF player. I've been playing for about 10 years with my CTF team spotless and yeah we do I do quite a bit of stuff in my free time including projects such as this. I'm gonna move to Tom now to introduce the rest of the first talk. All right so what are we talking about today? We're talking about these these kinds of smart IoT lights. First we'll do a quick introduction of how we dove down the rabbit hole that we are in now. How we got to this. Then we'll talk a bit about the initial revision of hardware that we found then a big refamp with a new type of chip where we found some new things and finally we'll show you a vulnerability that we found out is running on millions of devices all over the world that we use to break free of internet connected servers and run these devices locally only inside of your own network. Hopefully at the end there will be some room for questions but we'll see how the time pans out. All right so starting with our inspiration in 2019 Dutch Hacker Space Hack 42 called up all the troops and said we found these devices at Action a local store. There are a power plug that's connected to your Wi-Fi and you can hack them to run locally. You can run whatever firmware you like on them and they organized this session to hack these devices together and they put it up on a wiki you see it on the right. They found that there's this tool called Tuya Convert that you can use to break free these devices of the firmware that they came with and instead flash your own on it and this Tuya Convert an open source tool turned out to be based on research from CCC 35 C3 by Michael from V-Trust who's actually sitting right here in the room. So he found a really cool bug that allowed you to take control of the device and flash your own firmware to it and how did it work? So the device connects to the server of the manufacturer. It has a sort of handshake where it sends some information including this thing called the PSK ID and then it starts encrypting the connection with TLS PSK pre-shared key. This pre-shared key though it was derived from the PSK ID that got sent. So it sent to the server all the information you need to figure out how to encrypt and decrypt the data and so using this knowledge you can actually get rid of the whole vendor server act like you're the server and take control of the device and this is the trick that was used to flash custom firmware then and so when we bought some of these lights for our home we figured okay we can just use this Tuya Convert and our entire home will be cheaply filled with smart IoT devices that we can do fun stuff with. Wrong. At some point Tuya the manufacturer of these devices and millions of devices like them they manufacture them white label for thousands of manufacturers. They changed their firmware they patched this stuff that that Michael found of course and from that point onwards the pre-shared key was no longer derived from stuff that you could see publicly. Instead it was seemingly we think generated randomly at the factory flash to the device unique per device and you could no longer see it. Shit. So now what? We got a whole bunch of these lights and we cannot do anything with them other than let them happily connect to their servers of Tuya. So we figured okay if they're not vulnerable anymore we simply have to make them vulnerable again right how hard could it be and so there's a couple options we thought one we can obtain the psk again either leaking it or changing it to some some value that we want or we can try to downgrade this version two of the protocol back to version one that was vulnerable and then use Tuya convert again or if all else fails we just get code execution on the light bulb right well you can guess where we ended up. So first off we started with this initial hardware revision of them this this was from lights light bulbs we bought in 2019 i think it contained the esp8266 chip a very popular microcontroller that has wi-fi super popular and because it's super popular there's also a whole bunch of tooling that you could use we could dump the firmware from these light bulbs using esp tool common tool for handling expressive chips you get a raw binary flash dump from that that you can then load into a tool called esp bin to elf that gives you an elf executable image which you can load into gidra using an extension a module for extensor architecture then you analyze the firmware you dumped and you find a whole bunch of functions that are not annotated they don't have symbols so you don't know what they do there's a simple trick that you can use to get at least symbols for many common functions which is you just compile a demo application using the expressive SDK you analyze that in gidra and then you can you compare the footprints of functions with each other so you have a list of functions on the right the list of functions on the left and you can map them there's tools to do this but of course we didn't know about it back then so we we made a simple one of our own we mapped these functions and got got a sort of lay of the land we found out that two other manufacturer runs free rt os on these devices in free rt os they they have a whole bunch of tasks one task the init task that starts all the other tasks and two to us particularly interesting ones a task called udp receiver which listens for broadcast traffic on the network and a task called smart frame task that handles commands that you send to it via including this udp receiver task and on top of this they have a bunch of drivers for controlling gpio and pwm peripherals and this kind of stuff all right so now how do we how do we get root on these things we found that there's a bunch of keys used in this firmware the psk key that we talked about previously that encrypts the connection to the server you see that in yellow on the slide but also other ones and this we we did not know about before so data inside of this tls encrypted connection is encrypted and signed by something called the os key which after you activate the device via their servers over the internet gets replaced by something called the sec key and all of that is separate from something called the local key which you obtain after activation with the server it's it's initially empty and after activation you you can you can get it to then use the device on your local network without an internet connection well we wanted to use it without connecting to the server in the first place right so our goal was to get ownership of these keys somehow without connecting to do yeah and for this part i will hand over to gellet so we've analyzed and reverse engineered the firmware for this particular revision for quite a while we actually stumbled on a few vulnerabilities throughout our analysis however as luck would have it we would not actually end up exploiting these particular vulnerabilities so there's more later of course otherwise the talk would pretty much end here but yeah so we think these vulnerabilities are interesting nonetheless we would like to share you share them with you and let's start with the first one so what you see in front of you on the slide right now is a function in the firmware it generates a random string you see it takes three parameters the first one is completely unused the second one is a character pointer it's really a pointer to a buffer and then actually the maximum length which is essentially the length of the buffer itself what the function does very briefly is it takes the current time and do keep in mind these devices are set up without a real-time clock working so essentially this really is just a counter from the boot time of the device it just keeps incrementing well every second sort of and it takes that it generates some index in it and it indexes into this interesting string that's highlighted in red this kind of an artifact from Gidro because that's where we copied the code from but this is essentially this really massive long string that is hard coded in the firmware and basically what this function does is it takes a substring of that returns it and calls it random now that's obviously not very random but of course you know for a lot of things yeah you don't really need a cryptographically secure random number generator or something of the sort so would have been fine if you maybe perhaps come up with a construction like this for other purposes however if you use it for TLS then you have other sort of problems what we ended up finding out is if you were to look at the traffic between the device and the cloud server just zooming in here on the client hello message from the client to the server you'll see that the random field that's highlighted in blue and also in the dump you see it bordered by red is essentially pretty much the first part like the first 30 something characters of that very very long string now in this particular setup because they use TLS with pre-shared keys this isn't actually much of an issue we actually talked to a friend who there's quite a bit of research on TLS and we were wondering if this could be exploitable in the TLS PSK setup however turns out TLS 1.2 and up are actually quite resilient protocols and this doesn't immediately lead to a vulnerability as far as we know however why do we think this vulnerability is interesting is should they at any point switch to using cipher suites that actually utilize a key exchange mechanism such as diffie helman miracle key exchanges using perhaps certificates for validating the exchange process then this would immediately yield the man in the middle attack because now that you have the client random which you can guess with relatively high frequency figure out what the correct value is if you just capture the first few handshakes between a client and a server then you can just go ahead and derive the TLS pre-master key once just keep reusing it over and over and that's pretty much a win. We did some more analysis now we found some protocols as Tom mentioned there were some function handlers that were handling messages from the network some of them were actually handling the messages from devices on the on the local network in particular these messages were completely unencrypted so we we thought that they would be interesting candidates to look at the functions that parse and handle them because well yeah those are ones that we can easily reach we don't need any keys to send messages to these handlers and so we did and we ended up finding two bugs there a stack buffer overflow in the function that parses it and a heap buffer overflow and the same function but for a different message for the stack buffer overflow the function is implemented as a free rtOS task what that really kind of means in traditional terms is its long running process it's essentially in this case an infinite loop that just keeps on running waiting for messages to come in and for every message it just parses it does some handling etc now we had control over the the stack somewhat it was a bug where we as long as we are not writing null bytes we can modify the contents on the stack at the location of the vulnerability and that allowed us to overwrite the return address should be a win right we should be able to just go ahead and take control of take control of the code flow and then perhaps do something useful however well yeah it's an infinitely running process it at no point does it ever return we could not find a way to maybe trigger it into a fault mode that would have it to do an early return on or some such and sadly also analyzing the stack parameters and around it we couldn't really find anything interesting that we could use to make it do something a little bit more so essentially we could just crash it and that was pretty much it for the heap buffer overflow kind of a similar story we could manipulate the metadata of the blocks that the heap allocator takes keeps track of for allocations and freeze we actually we so we decided to study it a little bit and we found out that tuya has just modified one of the heap implementations that's provided with free rt os but doing so far we've done all of this statically right we're just we have ghidra open we've got our decompiler disassemblers and we're just kind of analyzing code manually going through it by hand but when it comes to things like allocator misuse bugs it's at least in my experience a bit more tricky to do that just by hand usually it's quite nice to see if you can get some dynamic analysis going so some debugging getting a bit of a of an understanding of what's actually happening in memory when you're doing all sorts of stuff so we decided to take a little detour then and somehow rediscovered a nice hardware hacking technique which is if we just trigger the conditions that we want on the device reset it into bootrom and then use esp tool the tool that was already there we could actually get a really nice ram dump of the contents of memory at the time we triggered this process and turns out you can just take this ram dump and overlay it onto your binary in ghidra it supports that was quite nice and then you can kind of see so in this particular screenshot you actually see one of the the blocks of the heap allocator that the heap allocator use and you can kind of see the connections between them so it's a bit more of a hybrid you're not just reverse engineering code you also get some data in there and you can kind of see how this data relates to the instructions that act upon it we went a step further actually so searching on the internet for if we can do on-chip debugging with the esp8266 yielded a whole lot of nos but there was one yes there was one tutorial about using visual gdb to debug applications on the in esp8266 however we would have preferred to utilize just gdb and open ocd those are the tools that we're more familiar with so what we did is we took a we forked the benetails gdb extensa that's actually been tailored for the esp32 modified it just a little bit to get it to to work nicely with the esp8266 and got some help from some people on getting open ocd running properly with our debuggers of choice for the esp8266 now this helped us a lot we actually were able to debug what's happening on the chip as we're triggering the vulnerabilities and see how things progress and put breakpoints sadly just one breakpoint so it was a bit of a monkey jumping around with that one breakpoint it was not a very nice experience but it is what it is we got somewhere where we didn't expect to unfortunately as we analyzed it more and more we realized that the conditions for that heap buffer overflow in the ways that we found that we could possibly abuse it would actually need us to be able to write null bytes in locations where which are not at the end of that string which we could have possibly been able to do however we really needed to do it somewhere in the middle just to get it to to trigger writes just the right way so unfortunately this particular bug was not usable in this case so kind of wrapping up this stage of our research we found a few bugs that as I said weren't easily exploitable one of them actually didn't really apply at all but we thought it was really cool the tls one should they ever move to some sort of implementation with key exchange mechanisms then that that would immediately yield an attack we kind of rediscovered a nice technique or at least we thought it was quite nice we got debugging working and more importantly we learned a lot about two-year stack this would actually kind of be the most critical point of our journey with the first revision of the devices as it would actually help us a lot in the next stage and speaking of the next stage moving to Tom so a few months past we had no progress on the on the esp but still we were curious of course and one of us I forget who went to the action bought more of these lights different types and we got we got a bit startled because all of a sudden there was not an esp 8266 in there anymore but a new chip chinese manufacturer becken we didn't know anything about it a bk7231 and we thought oh my god has all of our research been in vain did they just swap out a new chip everything is different so we went in search for a datasheet of this new mystery chip we searched on mauser and digi key even chinese lcsc we could not find anyone supplying this chip and having a datasheet for it not on a western internet anyway by due to the rescue so by due a chinese search engine is used almost exclusively in china of course when we search there we we got a whole lot further some translations later we we got the datasheet for this for this chip inside of the datasheet is mentioned that there's an arm nine core inside of a specific type and that arm nine core that you can find on the western internet very easily from there you can get the reference manual and see all kinds of things about the debug peripherals it has what kind of memory mapping is inside and this gave us a whole lot of information on how to analyze this new device and what was even more interesting is what happened when you searched for this chip on the western internet not for a datasheet but just the chip name itself we came to this very interesting looking github repository do we now have an open source implement implementation from tuya the manufacturer of this device for the stk yeah it turned out we did they completely open sourced all of their stuff the stk example applications that we found out are being used by manufacturers of these lights almost exclusively it's all there of course some of the internals are in in binary blob libraries but because they're part of the stk you need to be able to link against them which means that they need to have symbols which means that now we can load the library into gidra and we have a complete list of function names and this kind of stuff structures so that you can imagine you this helps tremendously in reverse engineering so it did for us one thing that's interesting is that they named this new real-time operating system iot os and so we were curious to see if we would have to learn a different os in our future endeavors but luckily it turns out we do not it's just free rt os with some sauce of them of tuya on top of it so not only did we not lose progress we actually gained a lot the stack is still the same but now we have the source we have all the symbol names we have a lot nicer time debugging because this arm core chip supports a lot easier debugging than the expressive chip does it just has a jtech interface you can connect to and so now we we dove in again for this part i'll hand over to gellet again right so as tom mentioned the sdk and the blobs in it actually helped us quite a lot we thought hey we could get a really nice quick start on on analyzing this particular new revision by just well looking at the sdk itself so i started the reverse engineering sort of it is mostly symbolicated easy to go through the binary blobs that we found in the sdk and because we've already seen quite a lot of what tuya does we've been familiarized with the protocols at a pretty good idea of okay what are the usual suspect protocols that have some interface to the outside world that we can perhaps control so started looking through these and i stumbled upon this particular piece of code it's kind of condensed from the original of course just for for visuals but essentially what this is is a task definition for a free rt os task that the device runs when you set it in a particular configuration mode you do so by power cycling the device a specific number of times this sits at in what's called ap mode where the device essentially broadcasts an an access point and you connect to it with your with your mobile phone and you have tuya's app or any of their other branded apps on your phone which has a nice it tells you exactly what to do to get that device on boarded onto your home access point of your home network what this function does then is it actually listens on that ap network it listens for udp messages that the application sends and what these messages look like as an example shown on the right essentially it's pretty simple it's some simple format it's a type length value around a json blob completely unencrypted the app just sends that when it gets the parameters from you the user the first two parameters are the s id and the passphrase that's your home network configuration parameters that it will use to connect the last one is a token that it actually gets from the from tuya servers and it's essentially just used to get the device to initially authenticate with the server so looking on the left side how it's being parsed it's just using c json a small library for parsing json in c it's used quite quite heavily in embedded the embedded projects as we've seen so just use c json takes that json payload parses it and then it gets the data and then copies it into some structure so there's some global structure so this line access point network config and it copies the parameters in it we noticed one particular interesting copy over here it's highlighted then in red I hope you can see it for specifically the token field from the token on the right the ap configuration token the copy process is slightly different than the other two fields why not sure but what we saw is that the token length is first calculated as a c string so it calls a sterling on it gets the length of that and then uses mem copy to copy that much data that it just calculated with sterling into that field okay could be okay but there are no no checks on it but it depends on how big that field is and do keep in mind that the json messages are not allowed to be more than 256 bytes so it could still be alright however looking up this is actually the structure that it copies into that token field is only 64 bytes long we can go up to 256 bytes okay well what that really means is we can set a token field that is much much larger or at least just larger than 64 bytes and then we'll start overwriting fields in that global configuration structure that may actually yield something interesting and lo and behold there's something interesting almost way too convenient really there's this finish cb that's one of the fields in that structure it's a function pointer and it happens to be called immediately after our out of bounds right our mem copy so that's fantastic so all we have to do is just have a token that is 72 bytes or well seven longer than 72 bytes and it will start overwriting that callback function pointer so now we have control sorry now we have control over the program counter which essentially allows us to jump wherever we want in the firmware but all of this we've done so far on the on the sdk blobs we don't really know if the devices themselves are vulnerable we've tested them a little bit kind of black box by trying to exploit them but it's it's it's a little unclear so we decided the next step is to get firmware dumps the plan here was to dump the firmware analyze it reverse engineering either like we've done so far kind of compare and figure out okay does this actually exist in the same way additionally we also get to figure out which locations in the code are interesting however we really did not know much about this chip so as Tom mentioned you know documentation is scarce if nonexistent so how are we actually going to dump the firmware so turns out there is a serial protocol that this device implements in its bootloader that allows us to read flash read some of the device metadata as well and do keep in mind that flash is embedded on this device it's not actually external which is why this was a little tricky the only problem is we don't really know much about this serial protocol besides that well yeah it exists well turns out we knew a little bit more so Tuya had some developer documentation that actually explained for OEMs that would use their services how do you flash your firmware onto the device both using their own tools as well as using this very interesting binary called the bk7231 chip flashing tool so we started looking around for information about this based on this newfound knowledge and luckily we actually ended up finding an open source project from one of Bekin employees and Bekin is the company that makes these chips and it's this tool that actually implements this bootloader serial protocol however not very luckily the tool was quite unreliable for us we really could not get it to work to read flash at all for whatever reason it would just pick up or or something would go wrong and we weren't exactly sure what's wrong with it we tried to modify it but that's kind of didn't didn't work out all too well so we decided to use the information that we have from this tool and the fact that we have a copy of the bootloader in the SDK to both reverse engineer the the bootloader so we can actually see what that serial protocol does from the horse's mouth so to speak as well as use the library that we found the tool that we found as kind of a quick guide point because we can then just figure out okay what sort of artifacts do we really need to search for in the bootloader so we don't have to really go through the code in depth to figure out where we need to look for this part so we spent some time on it and after a while we've figured out how it works we decided to write our own tool it's called the bk7231 tools and essentially it allowed us to now dump the firmware but next step we just have a flash dump we actually need to analyze it before we can look at any code so luckily for us the the SDK is is open source and this this part of the the part of the linking of the blobs together after compilation is is available so we could just go through it what we learned is that there are two code partitions on on flash the first partition is just the bootloader itself the second stage bootloader after the bootrom and the second part is well what's interesting the user application or so they called it the user application is essentially what we're interested in there are other partitions as well and they're defined by this user application but of course in very you know embedded software fashion the code sections are encrypted and by encryption we really mean obfuscation because the incur the encryption key is just hardcoded in the SDK so we had to deal with that a little bit as well now of course we just implemented all of that in bk7231 tools so it just does the whole process now from dumping the the flash from the device with that serial protocol to decrypting the code blocks and actually unwrapping their custom sort of format that they use both for on-chip over the air updates it's called an rbl format so we did a little bit more reverse engineering around their their binary tools that they had in the in the SDK so now armed with all of this information it's now time to start making our bug a little bit more useful so let's do a quick recall this is actually what we had we had the configuration message coming in we had the token field and if it's longer than 72 bytes we would overwrite this function pointer so here's an idea we do have we don't actually have control at all on the stack at the time of invocation here however there are some registers that are that that point to data that we control namely the data that's parsing this json object so hey maybe we can write shell code and just jump to it on the stack you know this this usually works well turns out that was not quite the case this was quite surprising for us because the rmv9 is a very old old old chip and as far as we can tell it doesn't have any memory protection units or any sort of memory management units so there should be like almost all memory regions should be executable but for whatever reason this really did not work at all so even though we have control flow redirection well we didn't really have much yet but there are techniques to deal with that so we could do return oriented programming or call oriented programming or some version of them and basically reuse the code that is already in the in the firmware to to kind of do our bidding now we did actually end up figuring out something around that we thought that and from from previous runs with the esp version we knew that there is a way to overwrite the pre-shared key through a call to the api and then the device would pull that new key from the server and overwrite it in flash so we found that function and we thought okay this is a really nice function that we could jump into so this is a piece of code that's already on the device and all we have to do is just massage the parameters a little bit and if we just return to that function it will overwrite the pre-shared key for us and we'll end up with a win condition however it turns out that this was really not sufficient overwriting the psk worked we did actually get it to kind of downgrade into the previous protocol that it had that to your convert abused however the sdk is written such that it does not actually accept unencrypted traffic within the tls connection which the previous version did so we kind of had to reassess what can we do here what's what's our path thing to to to get this so we actually did manage to overwrite the psk the downgrade doesn't work code execution a little bit tricky still but we can maybe find a way to overwrite the security keys which turns out is exactly what we did so we thought okay they have some function that they use to write this pre-shared key parameter and persisted to flash perhaps we could just you know search for other functions that maybe use this function so we started on this little journey for what's called gadget hunting and a gadget really is just a piece of code that does something useful that we want to that we want to achieve and in this particular case we were looking for two gadgets we were looking for something that sets the security keys that we can just jump right into and let it do our bidding and perhaps one or more quote-unquote fix up gadgets and these just do simple tasks of moving registers about just to get things in the right order we use the tool called the wrapper to to analyze the firmware it's it's for for the second type of gadgets it's a tool commonly used in an exploitation also for traditional systems so as we moved about we actually ended up finding out one such nice target gadget so that function that overwrites all the keys we noticed that this wd gwbase if right was used to overwrite the psk and just by kind of cross referencing back what sort of other functions refer refer to that function we ended up finding this handy dandy function that does not seem to be called at all by any tasks but seems to exist for the purposes of writing these configuration parameters to the device in the factory through some serial protocol it's pretty straightforward all it does is it takes a jason payload over serial parses it and then just uses it to overwrite the the parameters in flash so this looked like a great and fantastic candidate for us to use and since we already had a jason blob that we actually sent to the to the to the task to actually exploit it essentially this was just a matter of swapping some registers around because we already had a nice pre-parsed jason object and in order to do this swapping around we have the fixed up gadgets also trampoline gadgets on the side as you can see this one it simply sets the first register r0 to the value of the register r7 i think in this particular case it was the jason object indeed and then it pulls r3 on the third line from some other data section that we actually had some control over so in this way we could do some jump that does some register swap and then from the register swap we can go to a secondary location which essentially should be our target gadget and kind of putting everything together over here we had the setup where we had the vulnerable function call the fixed up gadget does some register swaps and then we end up in our lovely function that did all the work for us now that's not quite over yet so we're just moving to tom here to explain what we did after that so now we we have an exploit we can can set the keys but it's not not usable for people aside from the two of us yet right so we built a small tool called to your cloud cutter it contains all of all of this exploit tool chain steps plus some additional things so you can use it to override all of the keys pska oski local key sec key by doing that it it this allows the device from connecting to two yeah so it's cut off from the cloud it allows you to connect locally with this local key and so you can use it in complete isolation on your own network and then also you can use to your cloud cutter to write your own firmware if you like if you're interested in it check it out on github there's a there's a link in the slides also but i think now we should use the last final minutes that we have for actually trying to show you i'm going to put this light bulb from action into ap mode by flicking the switch six times gellat is going to connect to it via his laptop and then he's going to run the first step of the the exploit tool chain so it's blinking slowly now which means it's in ap mode all right now we have the exploit all right so the exploit has run i don't i don't know if you can see it it's all the way at the bottom of the of the beamer here we put it in ap mode once again this time to configure it to join a different access point that's gellat has on his on his mobile phone his hotspot and then from there we can connect to it using the local key to make it do something and hopefully we can show you that it will do something of course these kinds of demos are super super dangerous to do on a camp like this so this is all connecting over wi-fi to each other on a stage with i don't know 50 people here and hundreds around so we've got configuration messages now from the device we've they we know the exploit worked because we can actually see them they're plain text so we're doing the manual correctly and now the device should be on our access point so let's scan for it we just need to figure out if it was onboarded correctly hopefully it is and oh i'm on the incorrect network tends to happen on live demos so right now the bulb should be connected to gellat's mobile phone it's running a hotspot he's connecting his laptop to the same hotspot and then the laptop can send commands directly to the live bulb if things work out we'll see yeah yeah there we go found the device just need to get its IP address we have a little script that would then use the local key that we've set on the device to actually make it do something a little bit more interesting such as this so we'll leave this running in the in the background there we go right now back to tom all right so in the in closing we found a really cool bug that seems to be present in all devices containing this new chip which we think is any device made by tuya millions of them since around 2020 we did a vulnerability disclosure to tuya they were really cool about it really nice people responded super quickly and they gave us a bug bounty for it we donated it to charity to a foundation that teaches kids how to hack which we thought was was really cool and for us this this was a first experience or for me it was the first experience of doing a vulnerability disclosure hella did it before so that was really nice and one takeaway for us as well was embedded security is catching up this kind of stuff we had with not being able to just send shellcode to the device and jump into it because of non-executable memory it shows that steps are being taken however it's still far behind personal computing so this makes it a really interesting target for us and so our message is that it's still juicy to look into these embedded devices because many of the tricks that have not worked in personal computing for quite a while now they still work here all right and with that we will leave you we want to thank a couple people use Blasty, Jilles and V-Trust for helping us along the way if you would like to get in touch with us our stuff is up there and thanks a lot for listening thank you so much that was amazing I'm not really a tech person and I understood so much of it we have two vacancies open at my school for computer science teachers so if you're interested um now if there are any questions to them there are mics in the middle please use them to ask a question if you have one no questions well I think if you come up with a question they're still approachable after the talk or somewhere around camp and thank you so much another big applause please