 we come to our next talk. It's about the Amazon Dash button. Who of you knows what the Amazon Dash button is? Okay, kind of everybody who has an Amazon Dash button, who has used it to buy something. Okay. So for everybody who has never seen an Amazon Dash button, you now get the chance. I brought one. It looks like this. It's a small, tiny thing. You can click on it. You can order stuff. And you can order great stuff. Like things which make sense, like dog food, shampoo, stuff like that. But also fun things. So things you need regularly. But also fun things like Play-Doh. You know, it's stuff for kids. I have no idea who regularly needs to buy Play-Doh. So I mean, where does it go? Is it like your child eat it all up so you need new one? So this is something we perhaps won't learn in this talk. So why we need this? But we will learn how you can hack it to use it for a different purpose. Some of you might say, okay, right. I have heard already about something like that. Yes. Because the first version which was shipped out, there's such an analysis was already done. But there's a new version. And like it's often with the Internet of Things stuff, they try to make it more secure. I mean, that's what the S stands for in IOT. So what we'll hear about is about the hardware, the software, and also how the communication with the server looks like. And Hunts will give us a talk about this. He's somebody hacking hardware since quite a time. So let's give him a warm round of applause. And let's learn. Thanks. Nice to see you. Let's have a closer look at the Amazon Dash button now. The Dash button is basically a Wi-Fi connected button. It's been around in the United States since about 2014, I think. And in Germany, it's available since August of this year. There are two hardware revisions. And in this talk, I'll only cover revision 2, because that is the current revision. I don't think you can still get the old revision. The old revision is also quite hacked already. This button can be used to order or reorder certain consumables like pet food or washing supplies and such stuff. It's only available for certain brands and products. And you cannot configure it freely. It costs five euros. And you get a refund on your first button triggered order. There's also a customizable version available at least in the United States for $20. And you still cannot load your own code on this button. But you can use the Amazon Web Services to get the button presses. So what's interesting about this thing? Well, it has Wi-Fi. And it must be some sort of a computer. So it's a sort of Internet of shit device, though it might be more useful than certain other products. One question, of course, is how does it work? We just want to know. Then what about security? If you put this thing on our network, is this a security risk and can it be abused for cyber? DDoS and so on. Another important aspect for the hardware hackers is whether we can program it for our custom Internet of thing projects. It's more powerful than the common ESP8266 and the price is comparable. The next point is, of course, if we cannot run code on it, we don't really own it. So we want to run our code on this. There's some prior research that has already been done for the old button. You can get those lights from the Fablan. And I will refer to these two links later during the talk. Yeah. So this has been done already. You can read it up. And the easy way of repurposing the dash button is to use the smartphone app and configure the dash just normally, but you close the app once you get to choosing a product. Then this prevents the dash from ordering anything. The product selection is stored server side while the Wi-Fi configuration is stored in the button. So the button still contacts the server and says, I want to order something, whatever there is configured. The server says, nope, there's nothing configured. And the button blinks red and that's it. So you don't get stuff. And of course, it does a lot of things to get online. It connects to your Wi-Fi. It does a DHCP request, app request, DNS lookup and so on. So you can monitor all these things to find out when the button is activated and monitoring the DHCP log file, of course, is the most easy way, I guess. Who's doing this already? Okay. A few. About three people. Yeah, we'll go a lot further than this in this talk. First, we'll have a look at the hardware. So what's in this dash button? The communication protocols and the crypto. The firmware revision and this revision was still the most recent on 25th, I checked it last. And we will run some custom code on the button without disordering anything. I didn't analyze the Amazon smartphone apps because this is way too high level for me. Yeah. Regarding the hardware, the housing is sealed plastic. So you cannot open a screw. You have to somehow break it open or cut it open. My first attempt was with a knife cutting along the seal. But that didn't work so well. I removed some SMD components in this process. And while my latest attempt was, and this was successful, using a cutting wheel from the top because I already knew where the stuff is, where I want to get. You can see the test points here. And this is the microcontroller. So I simply cut it open. There's some space between the plastics package and the PCB. The PCB has four layers and a lot of SMD 201 parts. You can see those here. So this is all very tiny. And you can see that here you can see the pads of the microcontroller. Here you cannot because there's some black stuff poured over it. I don't know why exactly they are doing this, but you can remove it carefully and it can be softened a bit with acetone. That makes things easier. Yeah. The microcontroller is actually quite powerful. It's a Cortex M4 with a floating point unit and it runs at, or it can be clocked at 120 MHz. It has half a megabyte of flash and 160 kilobytes of RAM. The downside is the package of this chip. So you cannot easily solder additional stuff there and the black stuff. Yeah. Then there's the Wi-Fi IC. This is this chip here and it's 2.4 GHz and that's up to 72 Mbit. It does VPA 1, 2 of course. And there's a bit in IP stack. So it works a bit like you do with sockets in Unix. This Wi-Fi chip basically handles all the IP stuff and you simply open a socket from the controller and then you can communicate using this socket. It does have built-in SSL and TLS support and plenty of stuff. Yeah. Of course there needs to be a voltage regulator because there's a single AAA battery with 1.5 volts or less on this in the button and this needs to be boosted to 3.3 volts. So this is done with a voltage regulator. This is actually a quite powerful regulator. They could have used a cheaper one. Anyway, there's also Bluetooth low energy and you can see this here. This is the Bluetooth low energy. I'm not sure if they are using this already. They might do with the iOS app but I haven't analyzed this. There's a 4 Mbit SPI flash. This is this here and a microphone. This is here. You can see the package removed. This happened accidentally. Then there's an LED. Cannot be seen here but it's three LEDs actually, red, green and blue. And the thing is clocked from a 32 kHz oscillator. This is this thing here and it generates a higher clock frequency internally using PLLs. So there are also some discrete semiconductors here. They use them for the powering stuff. If we put it all together it looks more or less like this. This is a bit more simpler than the reality but we have the Bluetooth connected to a UART. The Wi-Fi is connected to a SPI bus and the SPI flash is also connected to another SPI bus. The interesting thing here is that there's an additional UART that's just for debugging. The voltage regulator gets started by the button press and one interesting thing is there is no other wake-up source. No real-time clock or something like that. That means the button can never wake up on its own terms. You always have to press the button and once it goes back to sleep it cannot wake up again without the button being pressed. Power enabled is held by an external latch so the microcontroller simply clears this latch and then it goes to shut down. The microcontroller can also measure the battery voltage using the ADC and there's an enable signal to connect or disconnect the battery from the ADC. This value is also sent to the server so Amazon knows when your battery is getting empty regarding the power consumption. Petrov already did a lot of measurements regarding this and you can see that Wi-Fi is throwing a lot of power, 400mW. Without Wi-Fi it's down to about 80mW and with some power saving you should be able to go down to about 50mW. Built-in battery holds about half a watt hour and so that's about 75 minutes with Wi-Fi enabled and about 10 hours with some very good power saving. So basically you could make an acoustic bug with this and listen to the microphone for some time and then transmit it via Wi-Fi but it's still limited with this battery power. So the debugging interface is also there. You already saw those test points earlier. The old dash button had single wire debugging enabled and a serial console with debugging commands. You could simply dump memory using the serial console. The new button has test pads for single wire debug and a serial console but single wire debugging is disabled and the serial console is stripped down to a few boring commands. We'll come to these later. Here you can see the debugging interfaces from the bottom side. You can mount a connector there. Which connector you can find on the Petrov website. All of these Ios are 3.3 volts. The pinout is basically compatible to the old button. So here are some URT commands. You can see there are three different modes. There's a test mode menu. This has a lot of more commands and they probably use this in the factory to do some calibration and testing. This is the user mode menu you have if you open the button and connect the serial port. There's just some firmware revision you can query and you can measure the battery voltage. Immortal and mortal is... Immortal prevents the automatic shutdown. It stays then on. It then does stay on until you issue a shutdown or you switch to mortal again. The developer mode menu has some more interesting commands. There's still no memory access but you can enter certain modes, configure mode, access point mode, scan for Wi-Fi and so on. So let's have a look at the communication protocols and the crypto stuff. The communication works like this. You have the SAMG55 as the microcontroller. Then you have those Wi-Fi chip. This is this AT-Wink and this chip handles all the TLS stuff. So those two communicate in plain text using SPI and then the dash button seems to use this HTTPS when connecting to the Amazon server. So you can see plain text data here and it's clocked at 40 MHz. So this is rather fast. One of the first things I did was I wanted to analyze the communication that was there because I didn't actually know if they are using TLS inside the Wi-Fi nick or if they are doing the TLS in the microcontroller. They did it in the microcontroller in the last hardware revision. So I put an FPGA between those two things and locked all the data that came by. I did cut the bus so I could do a man in the middle as well. I did this before I had the full dash firmware. The knowledge now this wouldn't really have been necessary. It looked like this. So you can see I removed the microcontroller here and added plenty of wires. This then go to some sort of baseboard where I can plug in a breakout board for the microcontroller. The microcontroller is actually here on this board. There are some LEDs for... Yeah, they are the RGB LEDs. Here I have a serial console. Here I have a single wire debugging. Here's the reset button and here is the actual dash button. This here is 3.3 volts supply and you can see a lot of jumpers here. These are all the connections to Bluetooth and Wi-Fi so I can simply remove the jumper and do man in the middle there. This is the thing with the FPGA board plugged in. Yeah, so that's how I analyze this communication that I'm now going to present. The Wi-Fi based configuration is used by the Android Amazon app. I don't know if the iOS app uses the same mode. To get into the configuration mode you have to press the button for several seconds until the RGB LED fades blue. Then the button is in access point mode and you can connect to a network called Amazon ConfigurMe. There's also a DHTP server for IP assignment and there's a simple HTTP server running on this thing. It actually runs on the ARM CPU and not on the Wi-Fi controller and there's a webpage with basic info. It looks like this. You have the serial number and the firmware and the battery level is in percent. They always do the battery level in percent. Yeah, not very interesting. The app on the other side does more interesting things. It fetches the device info from the root location as well but it sets the content type to application JSON and it gets more information. It gets a list of all the Wi-Fi networks that are there and yeah. Then the app generates an elliptic curve Diffie Helman key and posts this pub key to this location and then gets the same or the peer public key from the dash button from the same location. It posts the local config. We'll see what this is later. The local config is not very interesting and therefore it's in plain text. It posts an encrypted token to S-Token and it posts the encrypted network config to the network location. After this configuration is basically complete for the button. The button then connects to Wi-Fi and registers with the Amazon server and now an interesting step happens. It gets a customer secret. This is a specific secret key that is stored in the flash and then used for the orderings. There are a few secret keys involved. The device secret is 20 Charles uppercase and digit mix and it is written to the flash during production. This is fixed for the device. It cannot be changed. The customer secret is obtained during the configuration or at the end of the configuration phase from the Amazon server and this is generated randomly by the server, I guess. You'll get a new secret if you do a new registration. Both of these are stored in the internal flash of the microcontroller and they are used for HMEG on the requests. The elliptic curve during conflict uses a prime 256 curve and this is then used to generate a temporary symmetric key for the counter mode with is. They are using char256 to generate this key. The data for the is counter mode is TLV encoded. You need three tags. Tag zero is the cipher text and you need the initialization vector and a tag. The length of this TLV is 16 bit and then the plain text data is JSON encoded. That's a bit funny and they seem to like parses because they're using TLV for the encrypted data and once you decrypt it you get JSON data. Here's some example data. You can see public key and locale is actually just the country. The is token is the server token. This is something the Amazon app gets from the Amazon server once you start it and start the configuration of a new dash button because this ties your account. The token is 32 bits and the network is encoded in this way and interesting thing is that the HTTP server has another unused location. At least the app doesn't use it. It's called flash and this seems to allow flash access. I haven't analyzed this in detail but it seems to be some authentication going on so you can easily use this without understanding the crypto. The final registration at the Amazon server, the button does once it has been configured by the app. It does a post to this URL on the Amazon server and it transmits the device serial number. You can see this here and there's a transaction counter. This is a 32-bit counter and also you can see the token from the app. The transaction counter is later used during the order requests as well. It prevents replays. Then they do an HMAC using the device secret key because there's no customer secret key yet and the response then includes the customer secret key. This is then used to sign the orders. There are also some timestamps. They are always using your next state here. Now, once you press the button after all the configuration stuff and to order something, it does two post requests to this gateway here from Amazon and it uses content type binary RIO. The B request is the actual order request and it does a second request with debugging info. They are sending some metrics about how often the button has been pressed and how often it was appeared with Bluetooth and such things. I think I have an example in the appendix of the slides. It's not really that interesting. But an interesting thing is that the server can demand a firmware update of the button and then an additional post to the F location is triggered and the firmware is downloaded. The post to the order location looks like this. Again, we have the device serial number, transaction counter and the HMAC. This is then generated with a customer secret. Then you get the status code from the server obviously and this is used to determine if the order was successful or not. If the button blinks green, it must have been 200 HTTP status and 412, for example, is used to signal that you didn't complete the product selection. There's also a timestamp in the body and here's the flag for firmware update request. Before I had all the secret keys, I used the FPGA to toggle this flag to get a firmware update, but the server said, no, no, you already have the latest firmware. It was a bit disappointed. Regarding the security conclusions, during the configuration phase with the access point mode, you can simulate a dash button because the dash button doesn't have to authenticate to the app. This allows for evil twin and men in the middle attacks. This means an attacker can obtain the Wi-Fi credentials and the dash token for the ordering thing. If you set up this stuff and some day your neighbor gets a dash button and configures it, you can grab his Wi-Fi credentials. But you have to have it running for quite some time, I think. So the risk isn't that high because the time span of this configuration is actually pretty low or pretty short. The configuration with the server uses HTTPS and I think they check the server set. At least that's what the internet says. The client requests, so the client does not have a security cert. The buttons do not have certs. They only use this HMAC using the counter and the secret keys. But this prevents replays and ordering without knowing the secret key. So this is pretty solid, I think. But most interesting thing when it comes to security is that the button is really only active after key press and connected to Wi-Fi for a few seconds. So there's no self-induced wake-up and the battery life limits, the damage that can be done with this thing and also there are no open ports. It doesn't use UMP or something like that. So there's not really much you can do from the outside. So let's have a look at the firmware analysis then. The old button has a Broadcom-wise chipset and a real-time operating system from ExpressLogic with a NETIX IP stack. The new button has a custom OS. I think Amazon wrote it themselves. They also wrote the boot loader themselves, it seems. You cannot find anything on the internet about this. You can see some, this is the output of the serial port. I'm not sure, I don't think it does normally give you all this info. I enabled developer mode and enabled logging to get all these info. I come to that later how that worked. Yeah. They have multiple tasks, main tasks, action tasks, avocado button tasks, avocado seems to be their project name for the dash button. There's an extra task for the RGB LED comment handler and network manager tasks. You can see some of those tasks here. Yeah. Now, when you want to dump the firmware, obviously, we'll try single wire debug first. But this cannot be used because they are using the security lock bit to prevent access using the single wire debug. And you cannot get into the boot room either. That's prevented as well. And the only way, according to the data sheet of the micro controller, is to clear this lock bit is with a full flash erase. Yeah. And a full flash erase can be done by using the erase pin, but that is wired hard to the ground. So you have to desolder the complete micro controller to get there. And it erases all the flash content. So that's not so good if you want to dump the firmware. Well, I had a look at the external flash and soldered it out. You can see it here. I soldered it to a tiny piece of PCB and hooked it up to a Raspberry Pi and dumped it. There's this tool called flash ROM. It's actually pretty good. And you can dump more or less any flash ROM there is out there. And you can find the firmware in this flash, at least part of the firmware. Now, the thing with this is that the micro controller cannot execute the firmware directly from this SPI flash. It has to be copied into an internal memory, either to RAM or to flash. And therefore, the firmware must also be present in the internal flash. So you have a duplicate, probably. And we can dump this and analyze it using Hex editor and disassembler. And that's what I did. So if you analyze the SPI flash, you can see that it contains the firmware and some dynamic storage that's used with Shona Ling. The dynamic storage seems to start at this location. And this includes debug logs. So you can see in text output what the button did. And you can also find the transaction counter there. The start of the flash contains a list of static blocks. It looks like this. And you see the structure is pretty simple. There's just the name of the block. And at the end, there's the version of the block. And then there's the offset within the flash and the length of this block. This can be figured out quite easy. And yeah, so I wrote the structure and pass the list. And this is what we get. So the SamG55 obviously has to be the firmware for the microcontroller. It's 477 kilobytes. So that matches pretty good with the half megabyte of flash. You can see there's an additional header for this firmware. And yeah, the payload of this block includes this header. And the other are probably for the Bluetooth and for the Wi-Fi chip. So the Wi-Fi chip also has a built-in microcontroller. But it's not ARM. It's some other architecture. And it also has plenty of flash storage. You can see this here. The firmware is about 400 kilobytes as well. But well, that's an IP stack. Okay, so I dumped the SamG55 block to an extra file and analyzed it. And if you want to analyze a piece of firmware that goes into an ARM microcontroller in Cortex M3 or M4, M0 as well, you know that the static RAM usually starts at this location. And the internal flash usually starts here. So at the beginning of this flash, or yeah, you usually have the nested vector interrupt controller table. This is the table with all the interrupt service routines. And you also have the exception handlers there and the reset entry point. And so we would expect to find the vector table somewhere in the firmware. And this is what we look for. The stack pointer should point to RAM. So somewhere here to the end of the RAM, actually, somewhere around the end of the RAM. And the handler should point into the flash. If you have a closer look at the firmware, this is the additional header we had before. So we can see that it doesn't really make sense to use this as a vector table because the first thing obviously is a flash address. And after that, it's an invalid address. So that's how I figured out that this must be the length of the firmware and so on. Then there are plenty of zeros. And at this location in Hex, we can find the stack pointer and after the stack pointer, the handler entries for the vector interrupt controller. So my initial assumption was that the first 200 bytes had to be stripped. And this thing put to this location. However, that didn't work out because if you get the base offset wrong, you can see this in the disassembler that the references don't match up. So I gave it another try and put it at the and didn't strip this header and then everything was fine. So I had the firmware and a disassembly or at least part of the firmware. And yeah, the problem here was that it started at 4,000 in the flash. So there must be obviously some kind of bootloader code before that and this code I didn't have. Also, I later found out that apart from the bootloader, there's the configuration storage which includes the MAC address and serial number of the device and the secret key of the device and user configuration. And this is the part where the Wi-Fi config is stored. So this is before the actual firmware, which I found in the external flash. So I tried something and it would be great if we could execute the dumped firmware without this bootloader. And so I simply wrote this firmware to an empty microcontroller. It's a compatible one. And duplicated the vector table to the start of the flash. So all the pointers would match fine. And yeah, I set the lock bit to start from the flash and the firmware worked. So I did have debug output and yeah, everything was great. And I had debugging using single wire debug. So I could use OpenOCD and connect with a debugger to this thing. And I had suddenly I had a developer console on the serial UART. So I had analyzed this a bit and I found out that they simply check the security lock bit. And if the security lock bit isn't checked, it's obviously in the developer mode. So however, there was a slight problem because obviously I wasn't able to use this new button because the credentials of the secret keys were missing. And so somehow I needed to dump the internal flash of the locked microcontroller and I wanted a dump of the bootloader anyway. So I went for code execution. That meant exploiting the firmware somehow. If you have a disassembly of the firmware and debugging access, it cannot get any more comfortable when you try to exploit things because you can set break points, you can do tracing, you can look at the registers and all the things. And this makes things a lot easier. So the first attempt obviously was putting a really long line on the serial console. However, that didn't work. And they really had length checking in place on the serial console. So it's limited to 200 and 256 bytes. So that was surprising. So I thought some other options. And exploiting low-level network protocols like DHCP would hit the Wi-Fi I see and that wouldn't help me because I actually want the ARM microcontroller. And on the ARM microcontroller, there's the HTTP server running. And it has a TLV and JSON parser. So that might be an interesting thing. But there's also something from earlier, the audio configuration, the audio configuration protocol. This was used by the old button. If you used an iOS app, I'm not sure if it's still used with a new button or if it's been replaced by Bluetooth. And however, this code is still there and it still does support the audio configuration protocol. This protocol has been analyzed by Jay Greco. And before digging into this, I contacted him because I didn't have sample data. So I asked him if he could send me a sample file with a recording so I could have valid credentials and analyze them. And he did send me a sample and he also sent me an update on his block. And it's not actually ASK but FSK and with four carriers. And it simply looked like ASK because of the low-pass filtering. So I knew it was FSK and I had valid sample data and so I analyzed the sample data I had. And this is the payload of the audio protocol. There's a preamble. The packet length is one byte and the complete packet must be smaller than 128 bytes. There's a CRC. This ID is the token from the server. There's SID password and the realm is the country code stuff again. Now, if we have a closer look at the function that processes this payload, we can find that apart from this 128 length check, there's not a single length check in place. So all those buffers like realm, they are simply copied, mem copied to the stack and so they are trivial to exploit. I used the realm because I think it was the last thing on the stack and yeah. Now we can have a look at the stack. We can see the realm buff and there's some additional usable space where we can also put our payload and there's also some additional space in the password and as SID buffers but we have to make sure that we do not exceed the 127 total payload length. So the problem is that after this additional space, there's some values on the stack and if we override them, it will trigger the exception handler because there are some pointers and there are some values for mem copy, some length values and if we simply write zeros there, the mem copies won't do a thing and the exception handler won't get triggered. But there was another thing we needed. IRQ disable, we have this real-time operating system so there's plenty of IRQ stuff going on and once we fuck up the stack, things won't go very well if we do some task switching. Yeah, then watchdog needs to be serviced. There's actually a watchdog in the in the dash active and it shuts the dash down after a while. This is this immortal and mortal thing. And before the program counter on the stack, we have the register for and afterwards some additional stack where we can put some payload and so I built this payload. I put the, this is the instruction to disable the interrupts and these two instructions I put directly after the program counter and afterwards I put some additional registers because normally on ARM you have to do a load relative to the program counter. And this takes two plus four bytes per load and with this method you can save some space, two bytes per register. Immediate values are always needed. We need this for the watchdog and so on and yeah, putting them on the stack and popping them saves a few bytes so I did it this way and now we can dump the flash. So I put the source pointer, this is basically the start of the flash. I put this pointer into register one and register two is the UART base. Then since I have analyzed the firmware of the dash button, I have found the UART write function. It's basically something like write to UART, write n bytes to a UART and yeah, this function takes the base address of the UART, it takes the source pointer and the number of bytes that should be written to the UART. Then I needed to service the watchdog, otherwise it would reset after a while. So I used the destination for the watchdog register and well, the watchdog value in register four and five. So the payload is actually pretty small. I do some chunks, I do chunks of four kilobytes and afterwards after each chunk I poke the watchdog with some length checking in place to find out if I have reached the end of the flash and once I reach the end of the flash, yeah, here is an endless loop, jump to done, this instruction is missing on the slide, I can see. So I simply let the watchdog expire and the dash button will shut down again to save the battery. I have a demo video of this. So here I have the dash button open with the serial cable connected and one cannot really see this very good, but this is the earplug of an earphone, of headphones and here I made a tiny script. The script I can give some assembler instructions and it will generate me some audio that includes this assembler instruction in the complete exploit and here in the background you can see the serial output of the dash button. I piped it through a filter to strip away my private secret keys and so on and yeah, then I simply enter configuration mode and invoke my script which generates the audio file and plays it using the headphone. So let's try this, this is the normal output from the dash button here and now it's in configuration mode, here starts my script and bam, it's dumping all the flash now. So this takes a bit because it's half a megabyte and so yeah, the audio is actually quite short, it doesn't really have to, you don't need, it gets repeated several times so one of those packets is correctly received. The internal speakers work as well. I even thought about building a YouTube video for this, yeah, but well it works so far and now the question is how to proceed. So eventually Amazon will probably fix this with a firmware update and the thing is they cannot update current buttons unless the server can reach them. So if you want to exploit your button and yeah, and you want to reprogram it some way, you should deregister it from the server, so if you press it, it cannot get the firmware update accidentally. Now the thing is clearing the security bit without arrays doesn't work, so I cannot use this exploit to simply clear the security bit. It might be possible to trigger a full erase using software, I haven't tried this yet and otherwise we would need some sort of multi-stage loader to rewrite the flash with a custom firmware. You can grab the stuff, I did so far here from the sketch repository, there's also the disassembly annotations file in there and yeah, it's also linked using, there's also a link on the Fablan page and well, I'm not really sure if I will do some further work on this thing, so if you want to carry on, contact me and I will happily help. You can contact me using this credentials and yeah, well that concludes my talk for now, so we'll get to the questions. So same procedure like everywhere, if you have questions, please come up to one of the microphones, we have eight here, so the way should never be so far and yeah, so we have our first question, microphone number one please. Hello, first off, good work, that's quite impressive just to get code execution on it. The only question I have is how did you manage to solder those tiny, tiny wires on like the spy flash and everything else? Yeah, well one by one. I usually put my finger above the ones I already have soldered and then I try to tip the next one just briefly without touching the other ones and yeah, and I keep the other ones pressed down with the finger and that's basically the magic. What diameter wire did you use? Is that magnetic wire or? 0.1 millimeters. Okay, we have a question from the internet. Yes, thank you. First thanks for the talk, excellent, good job. What was the disassembly you used? I don't know. Okay. Microphone number four? Cool talk, just a question, how long did it take to reverse engineer everything and you get the results you presented? Days, weeks, months? Yeah, that's a good question and I don't really keep track of time when I do these things for my hobby because some guys buy a cinema ticket for about 10 euros and get about 90 minutes of fun and I buy the dash button for five and have plenty of weekends. Actually, it wasn't really that hard because there were some assertions in the code and there are several assertions so you can get the function names quite easily and then put it all together somehow. Okay, cool, thanks. Up there, just a question? Yes, so in the beginning there was a timestamp, did I see that correctly that was a four by timestamp? Don't they know about 2038? Yeah, well yeah, I have no idea what happens then. Maybe we'll issue a firmware update or something like that. Also the certificates are stored in the Wi-Fi controller so they probably need to update the certificates from time to time and they'll probably do this with a firmware update as well. I just thought that was terribly sloppy of them. Microphone number four? Yeah, great work. I tried to dump the firmware using a power line attack but I had no luck so I have a question. Do you have any idea what a UART connection to the Bluetooth module is used for? Well, I thought maybe they are using it in the iOS app but I do not have an iOS device so I cannot confirm or this. They do talk to the Bluetooth chip a bit and they check if it's there so once I disconnected it the firmware didn't come up but I didn't have a closer look at what's going on there. Okay, thanks. So the Android app doesn't make use of the Bluetooth low energy. Okay, we have another question from the internet? Yes, do you think it's possible to install an operating system like Linux on the bottom? No. The difference between a microcontroller and the CPU is the memory management unit and the microcontroller does not have a memory management unit. Basically one could try micro Linux, you see Linux but I don't think 160 kilobytes of RAM are sufficient for this either. So there are plenty of tiny real-time operating systems, open source, one could use but not Linux. Okay, thank you very much. Please give him another round of applause.