Beyond Root: Custom Firmware For Embedded Mobile Chipsets
Wade, Christopher
Question and Answer session for Christopher Wade - Beyond Root Custom Firmware For Embedded Mobile Chipsets
 Okay, so today we've got Christopher Wade presenting on Beyond Root, custom firmware for embedded mobile chipsets. So thank you for joining us, Christopher, and I'll let you do any opening remarks and then we'll go right into the questions. Excellent. Hello, Ron, thank you for coming to my talk. Yeah, that's pretty much all I can say. Thank you very much. Could you tell us a little bit about yourself and just like a quick intro summary for your talk? Yep, so quick introduction. This talk is mainly about custom firmware for embedded mobile chipsets. This is essentially me hacking chips inside my phone which aren't the core ARM chip used to run the thing in order to make it do different things from hardware. In particular for this talk it's going to be NFC chips. So I reverse engineer the firmware of an NFC chip, break the signature checking, and then implement my own firmware onto it. Excellent. Great. So we have one question already queued up. So how did Samsung react to the disclosure of vulnerabilities? Yeah, so Samsung reacted very positively. So I submitted to their mobile security team initially and they accepted it even though it was technically part of their Samsung semiconductor team. So I sent them the disclosure and they delayed with their, you know, interdepartmental systems or whichever. And initially because I submitted the Samsung S6 when I brought it here, said that this wasn't really something they were going to remediate just because it was out of scope. So the Samsung S6 is no longer supported. But when I submitted the Samsung S9, they happily took it and signed their remediation process, which was pretty good. And chips that have been manufactured, I believe you said after April aren't vulnerable to this? Yes. So what they've done is essentially, while they can't really patch the bootloaders of existing chips once they've all really manufactured us outlining the talk, what I have done is discuss with them about how they're going to remediate this and what they said was they're going to remediate all of the chips of the current versions in the manufacturing line. So all of the bootloaders can be patched as chips go out from now on onwards. However, all historical chips will still be affected. So that's why I decided to make the custom firmware for them. They'll still have the vulnerable bootloader. Yes, exactly. Which is very useful. So near the end of the talk, there was a problem with a parity bit. Did you ever get that worked out? Yes, so the parity bit was an interesting one. What they tended to do in the initial firmware, the firmware reverse engineering, is load all their 8-bit buffers as they should into the 8-bit buffer in hardware registers. This is done because that way the hardware itself can pick up the stack with the set and the set bits, which is done to calculate parity between each set of bytes to the send. What I did was find a very specific hardware address and a very specific bit in that hardware address to set, which let me essentially control that priority bit. What this meant was I set up 9-bit values, so that includes the 8 bits of the byte, followed by the 1-bit parity bit, which you'd be encrypted, and that starts the process. And the apps will like bit shift everything around by 1 on each part, because the buffer was 8 bits. But I had 9 bits of base to chip, and certain chips had to bit shift around, which was a bit strange for Tidwork. Did you get like NFC tag cloning working? Yes, so what I ended up doing in the end was literally being able to read an NFC tag using the standard rewrap occasions that existed, and use my tool to upload binary data through the ITC interface I had. So I could set each block of the data of the NFC tag, as I wanted to, including the UID, the write and read bits, et cetera, all parts that I could upload down, and I also hooked into the ITC interface, so that every time some reader wrote to the tag as well and authenticated it properly, it would then also write that binary ITC, so I could modify the binary file I had, between things like access control systems and things. I would be able to keep a check of what was going on, so some access control systems had a lot to help me think has been read, and some other parent information to make sure that no tags were cloned or reused, and I basically did that so that I could clone the tags well, also allow the data to be modified persistently even if I stopped going to be faster, and this was quite useful in the end. That's great. Saige, you got any questions? Yeah, so I'm not on the track yet, but I did notice that your talk was mostly a tutorial on reverse engineering, and I think it seemed like you were starting out because you were curious about the NFS MFC firmware and wanted to take a whack at customizing it. Is that my catching your motive correctly? Yes, so that is essentially how I started to know what really started this software, so I had this old something that we started with at the talk, which I was essentially using to mess around with different custom ROMs on, and one of the things I did was pull up devian to this, so I scraped up all of the Android operating system and shoved the end devian root file system into place, so instead of having it as a true design line at the talk, it was more of a full operating system advice. Now this afforded quite a lot of functionality, but also a lot of things like the screen didn't work so well. I quite enjoyed this, so I was going to have some sort of hacking tools, modify the USB and things so that I could use GadgetFS, etc. I thought it would be interesting to see where I could push things like the NFC side, so I redeployed Lineage OS to something like Six Phone, which is a very standard custom ROM, Rooster, and then started looking at the NFC chip, and that sort of weather project sprung up from there, so it started off as more of a standard custom ROM project than it started off as a standard reverse engineering project, but because I like reverse engineering, it sort of went on from there. It just sort of slid into it. Yeah, that happens. So have you looked at any other chips inside of phones? This seems like a really deep and hyper specific long chain that you went through to patch in this functionality. Yes, unfortunately, due to a responsible disclosure, I can't discuss those at the moment. Fair enough. So maybe I'll sort of ask around this. Was this the first one, and you've just been able to successfully responsible disclose this one? What has your experience in the past led you that brought you to this kind of point? Yeah, so this is definitely the first one. I like my supposed to be have a habit of routing our last phone that we're using, not our current phone, because walking around with the routed phone is not the best idea. So I had had a lot of older phones, and then I'd got Samsung S6 for a few years and then replaced it with a new phone and just had it lying around. So the first thing that was router and then start looking at seeing what I can do. I also looked at a few older phones at the same time. So for instance, I had a very old Samsung Galaxy Mini, which has FM radio capabilities based on a Broadcom chip set. Now, that was very interesting. I was looking at this a bit because it didn't seem to have any code signing with some of the binary files on there. It looked like it wasn't just an FM radio receiver, but also a transceiver. So I wanted to see if I could push it into doing FM transceiving. Sadly, that didn't really go anywhere because quite frankly, working on old Android versions like that is incredibly tedious. They don't always use device file appropriately, and they often route their circuitry around in ways that just it doesn't work for you. By comparison to more modern phones where everything's laid out, everything's documented, everything's open source and really nice ways. That's super unfortunate. I do remember some really old phone hacks that they were actually MP3 player hacks that you could turn them into FM transmitters. Yeah, that would be cool to get your phone to do it too. Sadly, I'm stuck to the Raspberry Pi with a wire sticking out of one of the pins at the moment, which is a fair enough. Is there any other active products that you're working on that you can talk about? Yeah, so I'm still looking at different phone chipsets. I've been looking around to see what other NFC chips that I use. There's only a handful of manufacturers. That's something I'm looking into. The big problem there is obviously price point because phones are expensive things and it's not something you want to buy randomly. The key thing I've been looking at is downloading custom ROMs for random phones that I thought would be interesting, not just for NFC chips, but other firmware binaries. If you download the ROMs and unpack them, you can find quite a lot of information about the hardware that you wouldn't be able to get just from a tear down, for instance. For instance, if you go in the vendor partition, there's all sorts of firmware blobs for things like Wi-Fi chips, etc. That's really led me to things like Xiaomi Mi Note 3, which is an old phone. While this isn't necessarily a firmware hack, being able to echo a single number into the Sys files and turn that into a monitor mode phone is very powerful. It's full-on passive monitor mode, no injection, but still full-on monitor mode that works really effectively. Things like that are something I keep looking through and looking through as much as I can because it's quite fun to my phone. That's awesome. Part of your project, you used a, I believe it was called the Unicorn Engine for hardware emulation. What level of emulation is actually happening there? Is it just the CPU? How does it handle peripherals and stuff? The Unicorn Engine is a really powerful tool. I've seen a few talks on this by the people who have actually developed it. I'm sure it was at Defcon as well. As it's a library that's purely used for loading into other things. Now, I always write my stuff in C, so I load it into C. All it does is emulate the core architecture you want to go for. In my case, it was ARM thumb. Then it lets you map out memory mappings you want. In order to write and read memory to start things up. Then you can hook operations and reads and writes the memory. When you hook into operations, you can make them act in weird ways. For instance, one of the problems I had with my hardware was it would sometimes hit the wait for interrupt operation, which wasn't supported by Unicorn. I could override that just to a standard knob because I didn't need to think about it. But hooking into the memory reads and writes was really key for me because I can map out to say there's actually hardware addresses at certain points. I could then just put an if statement, a switch statement, and just say if it hits this address, mess with it in this way. For instance, in the I2C interface, it was when it hits the I2C status buffer, I wanted to return random data. So it eventually hits the OK status or sometimes the busy status. Then when it hits the read and writes, I wanted it to read in data so I was writing to it as if it was the physical chip and then write data back when it was the physical chip. Which is how I got that initial fuzzing working. So it's really powerful for that. But it has no integration for actual realistic hardware, just the processing as it's going along. So just the core operations, which is really cool. You can write basically functions that are at those memory addresses to pretend to be that hardware, right? Yeah, so you can literally set R0, R1, R2, you know, the command. And then the program counter and say go into this and you can also set the address to tell it to finish. They can stick that at the end of the function. And that way you go run through the function, call the functions it needs to, but also then stop when it's ready and you'll then be able to read out memory as you want. So for instance, what I wanted to do before I started up part of it, the project I didn't really mention was I start off emulating the actual firmware binary that I had rather than the bootloader. And what it was load that in and let it run so that I could set up all the hardware addresses I needed. So RAM, et cetera, to see how that was laid out to see if I could see anything because you can let it start and then let it stop and then dump the memory out as you need to without really any problems. Cool. That's actually really, really slick. It's really powerful. Yeah. So how do you, how do you like go about making the jump from these accessing like a particular hardware address to saying, okay, this is an I swear see chat like external peripheral. Like how do I enter? How do you make that inference? Well, it was definitely inference. I was pretty much guessing when it came down to it. So what I was doing was when it hit that first, so I'll go step by step with what I did because it was pretty much as I outlined in the talk, it hit that first address and which is keep looping and reading and doing a few other operations before jumping back to the start where it read that address again. And I already knew that that was the correct hardware address because it was at 400000 which is all the hardware, the hardware addresses are. So as it was reading it was literally bit shifting what some code compaustry often is shifting values down to hit the spurt some bit to check them. And I thought, okay, so it's probably you checking for certain certain bits and some sort of order. And so I just randomized that. And then it started trying to read in bikes and was loading them into a buffer in RAM and I could see this in the emulation. I thought, if what happens if I start writing my code into it. So I started writing different operations in and there's all the staggered approach where because I didn't have interrupts, I think, but for some reason it wouldn't response right away. So I gave it a whole list of commands I wanted to run. And then it had like three of them and then it would start pumping out the responses. So eventually that worked really nicely. So it was quite cool in the end. That is really, it's like, yeah, but it's all assumption essentially it's all guessing is all guess work and eventually it gets. And I imagine that like interacting with those pieces of hardware might allow you to say like, okay, this is a this is clearly a memory buffer that's being shared with something else. I can't think of experience will just help you with that kind of thing. Yeah, and I sort of stepped through some of the parts of the code. So I stepped through because there was that infinite loop that started which was constantly reading. And I jumped into there and a few functions in and that's where I found the state machine of command zero one two and six, which were the first commands that the chip would like see at the start of a firmware update so zero was a reset one was get some version information and two was sent start sending the shall one hash and the signature and then command six was the secret one which don't any memory I wanted which was the father that existed was quite surprising. Yeah, but I mean it worked out was like, you know, find that. So if you didn't have that command, you briefly mentioned about like doing that kind of reversing blind, you already had the previous version you were able to use the knowledge you gain from that first stage to attack later on chip. If you wanted to go about doing something like this blind, could you would just be just an enormous amount more effort or is it just not possible. It probably would have been an enormous amount more effort. Yes, because I had that bootloader to emulate and I could make assumptions about the two size values that made it a lot simpler. Now it wasn't the full process but it was helpful enough. But yeah, the blind part was very simple in the end because I didn't the bootloader had changed just enough that I could guess anyway so I could make inferences about where I'd overwritten the stack and might overwritten the memory which would have different kinds of responses over the I2C bus. So I could get the size of the stack. I could overwrite it all with whatever addresses I wanted because eventually one of those would be the link register. And when it jumped in I literally just would have jumped through them in the same way essentially, but it would have been a lot more difficult to find the initial vulnerability I think. Fair enough. You could then so you could potentially use your custom firmware function to reimplement that kind of memory dumping though, like by jumping into that and then dumping everything back out to get the updated firmware version. Yes, so that's exactly what I did and so that was my first port of call when I started making the custom firmware was adding arbitrary reads to the core firmware so instead of it being in the bootloader I made my own custom firmware capable of doing that. And it was a few steps so I had to essentially find an I2C functional where to mess with the work via NCI and then modify that so I could send NCI responses with whatever I wanted and override those functions so it was a sort of a good for jumping off point and then I could modify my export to not load data from running. Loads data from random addresses to start off the exploit which was a bit scary when I actually saw what was working in the exploit in the live version. So we got a question from the channel. When starting your research weren't you afraid to find old vulnerabilities on your chip that were already patched since you started on an old phone. Yeah, so I thought it would have been patched to be honest. So I started with something at six and I was more it wasn't really doing it from a security perspective it's more of a reverse engineering things is fun. But because they told me they weren't going to patch it because it was so old which was valid I thought I don't think anyone's ever bothered looking at something so innocuous as an NFC chip on a phone. So I thought if I bought a later phone which I was in the market for the time anyway, I'd be able to find something just the same and I did which was excellent and it meant that even because there was probably there was firmware of a different chip versions between the two as well. This is just the latest version. It was likely that all the ones in between were also vulnerable to the same thing. It wasn't just a one to one comparison, which was quite cool. Do you know if Samsung took the approach that all those middle versions were likely vulnerable as well and they're only going to be releasing the updated version of this point. I don't know a huge amount but I do know which chips are in which phones so I can assume the ones that are supported by them are going to be updated. More than I think they do seem very good about it but I think these things. Cool. So we got a sort of a comment from someone in the channel. I really want to understand firmware and boot much more in depth looking for the more established projects can be somewhat overwhelming. Should I just grab a pine phone or pine time and ticker around old think pads. What kind of more entry level paths you suggest to learn more. Okay, yeah, excellent. So it very much depends on which path you want to go through. If you want to learn into custom ROMs and things on phones and modifying phones in that manner, then yes, something more like a standard Android device like a pixel or something which has the capabilities of custom ROMs. OEM and locking is the best port of call. You can mess with the operating system as you want to learn a lot. There's a lot of tutorials that people have for things like compiling things like linear US which are can be modified in certain ways. For instance, you can unpack the zip files of some of the custom ROMs and then just modify the boot script and things as you want or add your own things into the system image. You cannot add these things. That's sort of it's kind of a big question on that side. If you're looking at learning how to reverse engineer much more the chips things like the NFC chip, you should start looking at chipsets like the STM32. These are the probably the most used Cortex Xammon armed embedded chipsets around this huge numbers of very cheap development for them. And you can write code for them using free tools. There's also tools like the STM32 cube, which allows you to set specific pins and configurations. You can create your own USB device acts the mouse whatever in minutes using some of these tools and just deploy them to the phone. And that's where you would go if you wanted to start learning about how to develop firmware for these things to reverse engineer them. All you need to do is take those binaries and look at how they work more than anything. Chuck them in IDRA or RIDARA or, you know, GEDRA, whichever one you like and start looking around them. There's a huge number of really good tutorials about how to do this, but mostly all I can say is just dive in and try things. And if you get frustrated too much, then you're probably going the right way with it. I mean, I don't want to say how hard it was to find all the addresses and things in the firmware that I reverse engineered for this project. It took days and days and days for some of them, especially when it came to things like a lot of the functionality was based on interrupts. And I didn't even know which interrupts were there because there's no documentation for this chip and everything is completely custom to Samsung. These are really difficult things to come up with. But you can start adding to your knowledge just by doing the most frustrating things you can. So starting with embedded firmware and that style, start with an STM32 Dev board. Even start with a Raspberry Pi and just start looking at bare metal stuff if you have one available. There's all sorts of ways to go into it, really. That's awesome. That's a great and very thorough answer. I appreciate that. Do you believe that Samsung will eventually start using signature verification for downloadable firmware? So the chip did use signature verification in this instance. What they should be adding to that rather than modifying the signature verification is encryption on top of that. So at the moment, you could take the firmware that they've deployed and analyze it in IDA with no problems because there's no encryption whatsoever. Now, different chips that's from different manufacturers, even NFC chip ones are encrypted and signed. That means you can't reverse engineer them to find any exploits. You also can't deploy modifications to those firmware and that's sort of the way they should be going more than anything. Do you think that that's actually a good way making it harder for reverse engineers to inspect the actual firmware? It's kind of a catch-22 on that point, isn't it? I see where you're coming from. I think, especially with the threat mobile such as this, where the only real reason someone would reverse engineer this is to make a cool NFC hacking tool rather than to damage other people, is that if you really wanted to stop people doing this, which I don't agree with on a moral level, but I would say encrypting it and preventing them from doing that is the best way to go. Because then what they'll have to go for is both guessing how the bootloader works and also guessing what things like secret vendor and CI functions are available, which aren't necessarily all vulnerable to things but are available and people can brute force through them. How much time did you spend on this project? A lot. I feel like my boss has probably asked me that in the chat. The project started off at the end of the last DEFCON actually, which is when I was seeing my hotel room looking at the original firmware. Then I just did it in little bits over time, more than anything. It wasn't a solid amount of time. When it got to the point where I had a signature bypass on the Simpsons, I started focusing quite a lot of time. It took me about three weeks, not every day, but three weeks in total, to go through everything and start implementing every single part of that firmware. Because I was having to look through the entirety of the firmware image, which had no documentation whatsoever and nothing to work with, no strings at all, no function references that you'd get in. It's literally just raw code. It's all guesswork. That's why it takes such a long-winded amount of time compared to some more desktop-level projects where you can rather as an engineer see an application quite a lot more easily, I'd say. Other than the challenge of doing the reverse engineering and figuring things out, did you have a particular use case for the end product? Like a sneaky version of the Proxmark or something? A sneaky version of the Proxmark is exactly right. I do have Proxmarks and I really like them, so I've got one right next to me, which I actually use for the reverse engineering of this project really heavily for the NFC side. Because it so lacks on things like the bit verification, the parity checking, it meant that I could build up the project really simply from that. Now, essentially, yes, I was trying to make a fakie Proxmark and part of that was passive NFC sniffing. So one of the tools on a Proxmark is this thing where you can sniff high-frequency communication between the reader and attack. This is useful like breaking authentication and things. I wanted to add that in so you could go up someone with a phone and stick it over them as they're trying to open a door or something back and pick up for communication. Now, that feature is almost done, but it's quite complicated now because you have to switch between hardware registers. Now, there's one block of hardware registers I mentioned in the talk and that handles every single aspect of NFC. So that's the reader part and the actually like a tag part. So you have to switch between these constantly in order to get that data and it sort of works. But until I've got that full functionality in place, it's really not a replacement for the Proxmark. That was the goal, yes. Yes, but that's really sneaky. I really like it. What do you think so little has been done for? Why do you think so little has been reverse engineered from a Qualcamp baseband? Is it more challenging? I'd say yes. I've looked at some aspects of Qualcomm as well, just from interest. So I've looked at several different aspects of things like how their bootloaders work, how they have like the Qualcomm emergency download mode and all these sorts of features. They've also got the baseband, which is highly complex. So when you start looking into them and then you realize how much of a kind of worms you've opened with reverse engineering, this project by comparison to something like a Qualcomm chip is very simplistic. It's one very small, say 12K firmware to look through. Whereas when you get to the Qualcomm baseband, which is going to be hugely complex, it's just a huge project and it's something which is better suited to a multi-person team rather than just me on my own. So is it largely the size of the firmware on Qualcomm chipset as the limiting factor or is it also that because is the Snapdragon still like a natural arm core or is it something Qualcomm specific? It's an ARM64 core, I believe, at the moment. I know there's been quite a lot of research done on Qualcomm in general on their chipsets because it is the focus of the phone. I mean, that's why I chose a chipset that was side aspect of a phone because I thought no one would have bothered to look at them. And I haven't with this one because I feel like the vulnerability I found would probably be found quite quickly. But yes, when it comes to the Qualcomm side of things, it's just such a hugely complex chipset. And there's so much to look at and so many like potentials for bugs in different places that like any chipset of that complexity, it would take a team and quite a lot of time to find something, I think. Yeah, fair enough. It's like we're we got some potential questions coming back in. Yeah, is there any part of the talk that you omitted because you just like ran out of time? That's quite a lot. So I wanted to go into more details about the reverse engineering side, which was considering it was only half the talk was the most time consuming part of the topic. But I found that it was quite dull to talk about because it's literally going me going, oh, I thought this might be this I thought might this might be this for instance I mentioned interrupts earlier and how these work on Cortex M chips is there's a big table at the start of the stack which includes the reset factor, which is where the chip starts from the start of the stack and then it has a bunch of interrupts rings like the hardware and stuff. Now on top of this it also has interrupts for more complex hardware like the NFC. So one thing was all the NFC tag mode stuff ran off one single interrupt. So it hit that interrupt and jumped some code. That meant the code wasn't directly referenced by anything and actually didn't disassemble when I first looked at the firmware. And what this meant was I wanted to override what I started off doing was overriding that interrupt in the first place but I had to know where it was. So I found the select function that I mentioned the talk and the word back from there found that had no function reference thought maybe it's a interrupt and then search that value, which was then found as table things like that. These are things that are very valuable from a reverse engineering perspective but they're very boring to talk about in the talk I think, which is probably bad because I just spoke about them for about 10 minutes. No, no, no, it's fine. We've got time and people are like I'm interested. I didn't know that things pointed exclusively by the interrupt table where wouldn't normally decopile. Not unless it will. Coedra is quite good at this I found because it understands Cortex and whereas I just sort of quite hands off when it comes to things like Cortex and chips. It allows it tells you to work that for yourself essentially a lot of the time. So what would you say are other interesting targets like not complex and wild. They use chips. What I would recommend is something that I work quite heavily which is IOT pro embedded IOT chips, which are not custom chipsets in the first place. They usually STM cores or, you know, FM cores and these sort of things. Why these are interesting is they're a good jumping off point to learn these things because you're not guessing you've got documentation in place, but also people implement bootloaders and things which you can then try and break. Now, I did a talk at 44 con a while ago, which is about breaking one of these bootloaders by breaking the encryption mechanisms on the firmware update by dumping round off an STM 32 chip as it was doing the firmware update. Things like this are things you shouldn't start looking at because there's millions of these IOT devices out there with all sorts of different chipsets and they're really fun targets. When it comes to custom chips like this, you're really not going to find much information online about them just because they're hidden away. There's about two links if you search for some of these Samsung chips online, apart from their accreditation from the NFC forum. So finding these chips in the first place is probably your greatest goal when you're starting up something like this, more than anything. And someone wants to know if the firmware was based on an RTOS or more long slides, which is like a standard. Rob microcontroller target. Yep, great question. So you often find embedded projects like this using RTOS like VX works or free art or so Ecos and these sorts of things. Now, they weren't because it was literally a straight firmware that had compiled. They had their own tool presumably they had their own tooltune at Samsung. They compiled it up. They had to have everything sorted as they wanted to and laid out as they wanted to because they have their firmware as they wanted. And RTOS is usually built for certain chipsets or certain families of chipsets or certain styles. It just wasn't really meant to be on that point. Often these RTOS have a lot of overhead as well. I think do debug strings, for instance, VX works for the table that's I think being compiled out, but is at the end of pretty much all their firmware, which includes all the function names, which can then reference back to all the functions in the firmware, which saves you a lot of time reverse engineering, but it's also a security perspective quite bad. It didn't use an RTOS. It was just a straight running firmware. They'd put their own function calls in all that sort of thing. Other chipsets that looked at the similar or custom often implement their own custom RTOS for this. But in this case, that was none used. It was literally just running as it needed to and relying on interrupts more than threads. That was a great answer, by the way. Thank you. Well, it looks like we are running out of questions and we're just about the end of our time anyways. Is there any additional links you want to share or code or anything like that that you want to get out there? Yeah. So if we're doing links and that sort of thing, you can follow me at Twitter at iscuri1. So that's my username and then one at the end, because I didn't get the one without the number first for GitHub. It's just iscuri. And I should be pushing out a blog in the next couple of days, like, outlining all of these details as well as linking to the YouTube video of this at pentestpartners.com, which is my company website. So definitely feel free to have a look if you want the really nitty-gritty technical details. Awesome. Well, thank you so much for joining us for this QA session. It's been great talking to you. Thank you for providing content to our virtual DEFCON save mode. And have a nice day. Thank you too. Thank you very much, guys.
 Okay, so today we've got Christopher Wade presenting on Beyond Root,  custom firmware for embedded mobile chipsets. So thank you for joining us,  Christopher, and I'll let you do any opening remarks and then we'll go right  into the questions.  Excellent. Hello, Ron, thank you for coming to my talk. Yeah, that's pretty much all I can say.  Thank you very much. Could you tell us a little bit about yourself and  just like a quick intro summary for your talk? Yep, so quick introduction. This  talk is mainly about custom firmware for embedded mobile chipsets. This is  essentially me hacking chips inside my phone which aren't the core ARM chip  used to run the thing in order to make it do different things from hardware. In  particular for this talk it's going to be NFC chips. So I reverse engineer the  firmware of an NFC chip, break the signature checking, and then implement my  own firmware onto it. Excellent. Great. So we have one question already queued up.  So how did Samsung react to the disclosure of vulnerabilities? Yeah, so  Samsung reacted very positively. So I submitted to their mobile security team  initially and they accepted it even though it was technically part of their  Samsung semiconductor team. So I sent them the disclosure and they  delayed with their, you know, interdepartmental systems or whichever.  And initially because I submitted the Samsung S6 when I brought it here, said  that this wasn't really something they were going to remediate just because it was out of  scope. So the Samsung S6 is no longer supported. But when I submitted the  Samsung S9, they happily took it and signed their remediation process, which was  pretty good. And chips that have been manufactured, I believe you said after  April aren't vulnerable to this? Yes. So what they've done is essentially, while  they can't really patch the bootloaders of existing chips once they've all  really manufactured us outlining the talk, what I have done is discuss with  them about how they're going to remediate this and what they said was they're  going to remediate all of the chips of the current versions in the manufacturing  line. So all of the bootloaders can be patched as chips go out from now on  onwards. However, all historical chips will still be affected. So that's why I  decided to make the custom firmware for them. They'll still have the vulnerable bootloader.  Yes, exactly. Which is very useful. So near the end of the talk, there was a  problem with a parity bit. Did you ever get that worked out? Yes, so the parity bit was an  interesting one. What they tended to do in the initial firmware, the firmware  reverse engineering, is load all their 8-bit buffers as they should into the 8-bit  buffer in hardware registers. This is done because that way the hardware itself can pick up the stack with the set and the set bits, which is done to calculate parity between each set of bytes to the send.  What I did was find a very specific hardware address and a very specific bit in that hardware address to set, which let me essentially control that priority bit.  What this meant was I set up 9-bit values, so that includes the 8 bits of the byte, followed by the 1-bit parity bit, which you'd be encrypted, and that starts the process.  And the apps will like bit shift everything around by 1 on each part, because the buffer was 8 bits.  But I had 9 bits of base to chip, and certain chips had to bit shift around, which was a bit strange for Tidwork.  Did you get like NFC tag cloning working? Yes, so what I ended up doing in the end was literally being able to read an NFC tag using the standard rewrap  occasions that existed, and use my tool to upload binary data through the ITC interface I had.  So I could set each block of the data of the NFC tag, as I wanted to, including the UID, the write and read bits, et cetera, all parts that I could upload down,  and I also hooked into the ITC interface, so that every time some reader wrote to the tag as well and authenticated it properly,  it would then also write that binary ITC, so I could modify the binary file I had, between things like access control systems and things.  I would be able to keep a check of what was going on, so some access control systems had a lot to help me think has been read,  and some other parent information to make sure that no tags were cloned or reused, and I basically did that so that I could clone the tags well,  also allow the data to be modified persistently even if I stopped going to be faster, and this was quite useful in the end.  That's great. Saige, you got any questions? Yeah, so I'm not on the track yet, but I did notice that your talk was mostly a tutorial on reverse engineering,  and I think it seemed like you were starting out because you were curious about the NFS MFC firmware and wanted to take a whack at customizing it.  Is that my catching your motive correctly? Yes, so that is essentially how I started to know what really started this software,  so I had this old something that we started with at the talk, which I was essentially using to mess around with different custom ROMs on,  and one of the things I did was pull up devian to this, so I scraped up all of the Android operating system and shoved the end devian root file system into place,  so instead of having it as a true design line at the talk, it was more of a full operating system advice.  Now this afforded quite a lot of functionality, but also a lot of things like the screen didn't work so well.  I quite enjoyed this, so I was going to have some sort of hacking tools, modify the USB and things so that I could use GadgetFS, etc.  I thought it would be interesting to see where I could push things like the NFC side, so I redeployed Lineage OS to something like Six Phone,  which is a very standard custom ROM, Rooster, and then started looking at the NFC chip, and that sort of weather project sprung up from there,  so it started off as more of a standard custom ROM project than it started off as a standard reverse engineering project,  but because I like reverse engineering, it sort of went on from there. It just sort of slid into it. Yeah, that happens.  So have you looked at any other chips inside of phones? This seems like a really deep and hyper specific long chain that you went through to patch in this functionality.  Yes, unfortunately, due to a responsible disclosure, I can't discuss those at the moment. Fair enough.  So maybe I'll sort of ask around this. Was this the first one, and you've just been able to successfully responsible disclose this one?  What has your experience in the past led you that brought you to this kind of point?  Yeah, so this is definitely the first one. I like my supposed to be have a habit of routing our last phone that we're using, not our current phone,  because walking around with the routed phone is not the best idea. So I had had a lot of older phones,  and then I'd got Samsung S6 for a few years and then replaced it with a new phone and just had it lying around.  So the first thing that was router and then start looking at seeing what I can do.  I also looked at a few older phones at the same time. So for instance, I had a very old Samsung Galaxy Mini, which has FM radio capabilities based on a Broadcom chip set.  Now, that was very interesting. I was looking at this a bit because it didn't seem to have any code signing with some of the binary files on there.  It looked like it wasn't just an FM radio receiver, but also a transceiver. So I wanted to see if I could push it into doing FM transceiving.  Sadly, that didn't really go anywhere because quite frankly, working on old Android versions like that is incredibly tedious.  They don't always use device file appropriately, and they often route their circuitry around in ways that just it doesn't work for you.  By comparison to more modern phones where everything's laid out, everything's documented, everything's open source and really nice ways.  That's super unfortunate. I do remember some really old phone hacks that they were actually MP3 player hacks that you could turn them into FM transmitters.  Yeah, that would be cool to get your phone to do it too.  Sadly, I'm stuck to the Raspberry Pi with a wire sticking out of one of the pins at the moment, which is a fair enough.  Is there any other active products that you're working on that you can talk about?  Yeah, so I'm still looking at different phone chipsets. I've been looking around to see what other NFC chips that I use. There's only a handful of manufacturers. That's something I'm looking into.  The big problem there is obviously price point because phones are expensive things and it's not something you want to buy randomly.  The key thing I've been looking at is downloading custom ROMs for random phones that I thought would be interesting, not just for NFC chips, but other firmware binaries.  If you download the ROMs and unpack them, you can find quite a lot of information about the hardware that you wouldn't be able to get just from a tear down, for instance.  For instance, if you go in the vendor partition, there's all sorts of firmware blobs for things like Wi-Fi chips, etc.  That's really led me to things like Xiaomi Mi Note 3, which is an old phone.  While this isn't necessarily a firmware hack, being able to echo a single number into the Sys files and turn that into a monitor mode phone is very powerful.  It's full-on passive monitor mode, no injection, but still full-on monitor mode that works really effectively.  Things like that are something I keep looking through and looking through as much as I can because it's quite fun to my phone.  That's awesome. Part of your project, you used a, I believe it was called the Unicorn Engine for hardware emulation.  What level of emulation is actually happening there? Is it just the CPU? How does it handle peripherals and stuff?  The Unicorn Engine is a really powerful tool. I've seen a few talks on this by the people who have actually developed it.  I'm sure it was at Defcon as well. As it's a library that's purely used for loading into other things.  Now, I always write my stuff in C, so I load it into C. All it does is emulate the core architecture you want to go for.  In my case, it was ARM thumb. Then it lets you map out memory mappings you want.  In order to write and read memory to start things up. Then you can hook operations and reads and writes the memory.  When you hook into operations, you can make them act in weird ways.  For instance, one of the problems I had with my hardware was it would sometimes hit the wait for interrupt operation, which wasn't supported by Unicorn.  I could override that just to a standard knob because I didn't need to think about it.  But hooking into the memory reads and writes was really key for me because I can map out to say there's actually hardware addresses at certain points.  I could then just put an if statement, a switch statement, and just say if it hits this address, mess with it in this way.  For instance, in the I2C interface, it was when it hits the I2C status buffer, I wanted to return random data.  So it eventually hits the OK status or sometimes the busy status.  Then when it hits the read and writes, I wanted it to read in data so I was writing to it as if it was the physical chip and then write data back when it was the physical chip.  Which is how I got that initial fuzzing working.  So it's really powerful for that.  But it has no integration for actual realistic hardware, just the processing as it's going along.  So just the core operations, which is really cool.  You can write basically functions that are at those memory addresses to pretend to be that hardware, right?  Yeah, so you can literally set R0, R1, R2, you know, the command.  And then the program counter and say go into this and you can also set the address to tell it to finish.  They can stick that at the end of the function.  And that way you go run through the function, call the functions it needs to, but also then stop when it's ready and you'll then be able to read out memory as you want.  So for instance, what I wanted to do before I started up part of it, the project I didn't really mention was I start off emulating the actual firmware binary that I had rather than the bootloader.  And what it was load that in and let it run so that I could set up all the hardware addresses I needed.  So RAM, et cetera, to see how that was laid out to see if I could see anything because you can let it start and then let it stop and then dump the memory out as you need to without really any problems.  Cool.  That's actually really, really slick.  It's really powerful.  Yeah.  So how do you, how do you like go about making the jump from these accessing like a particular hardware address to saying, okay, this is an I swear see chat like external peripheral.  Like how do I enter? How do you make that inference?  Well, it was definitely inference. I was pretty much guessing when it came down to it.  So what I was doing was when it hit that first, so I'll go step by step with what I did because it was pretty much as I outlined in the talk, it hit that first address and which is keep looping and reading and doing a few other operations before jumping back to the start where it read that address again.  And I already knew that that was the correct hardware address because it was at 400000 which is all the hardware, the hardware addresses are.  So as it was reading it was literally bit shifting what some code compaustry often is shifting values down to hit the spurt some bit to check them.  And I thought, okay, so it's probably you checking for certain certain bits and some sort of order.  And so I just randomized that.  And then it started trying to read in bikes and was loading them into a buffer in RAM and I could see this in the emulation.  I thought, if what happens if I start writing my code into it.  So I started writing different operations in and there's all the staggered approach where because I didn't have interrupts, I think, but for some reason it wouldn't response right away.  So I gave it a whole list of commands I wanted to run.  And then it had like three of them and then it would start pumping out the responses. So eventually that worked really nicely.  So it was quite cool in the end.  That is really, it's like, yeah, but it's all assumption essentially it's all guessing is all guess work and eventually it gets.  And I imagine that like interacting with those pieces of hardware might allow you to say like, okay, this is a this is clearly a memory buffer that's being shared with something else.  I can't think of experience will just help you with that kind of thing.  Yeah, and I sort of stepped through some of the parts of the code. So I stepped through because there was that infinite loop that started which was constantly reading.  And I jumped into there and a few functions in and that's where I found the state machine of command zero one two and six, which were the first commands that the chip would like see at the start of a firmware update so zero was a reset one was get some version information and two was sent start sending the shall one hash and the signature and then command six was the secret one which don't any memory I wanted which was  the father that existed was quite surprising.  Yeah, but I mean it worked out was like, you know, find that.  So if you didn't have that command, you briefly mentioned about like doing that kind of reversing blind, you already had the previous version you were able to use the knowledge you gain from that first stage to attack later on chip.  If you wanted to go about doing something like this blind, could you would just be just an enormous amount more effort or is it just not possible.  It probably would have been an enormous amount more effort. Yes, because I had that bootloader to emulate and I could make assumptions about the two size values that made it a lot simpler.  Now it wasn't the full process but it was helpful enough.  But yeah, the blind part was very simple in the end because I didn't the bootloader had changed just enough that I could guess anyway so I could make inferences about where I'd overwritten the stack and might overwritten the memory which would have different kinds of responses over the I2C bus.  So I could get the size of the stack.  I could overwrite it all with whatever addresses I wanted because eventually one of those would be the link register.  And when it jumped in I literally just would have jumped through them in the same way essentially, but it would have been a lot more difficult to find the initial vulnerability I think.  Fair enough.  You could then so you could potentially use your custom firmware function to reimplement that kind of memory dumping though, like by jumping into that and then dumping everything back out to get the updated firmware version.  Yes, so that's exactly what I did and so that was my first port of call when I started making the custom firmware was adding arbitrary reads to the core firmware so instead of it being in the bootloader I made my own custom firmware capable of doing that.  And it was a few steps so I had to essentially find an I2C functional where to mess with the work via NCI and then modify that so I could send NCI responses with whatever I wanted and override those functions so it was a sort of a good for jumping off point and then I could modify my export to not load data from running.  Loads data from random addresses to start off the exploit which was a bit scary when I actually saw what was working in the exploit in the live version.  So we got a question from the channel.  When starting your research weren't you afraid to find old vulnerabilities on your chip that were already patched since you started on an old phone.  Yeah, so I thought it would have been patched to be honest. So I started with something at six and I was more it wasn't really doing it from a security perspective it's more of a reverse engineering things is fun.  But because they told me they weren't going to patch it because it was so old which was valid I thought I don't think anyone's ever bothered looking at something so innocuous as an NFC chip on a phone.  So I thought if I bought a later phone which I was in the market for the time anyway, I'd be able to find something just the same and I did which was excellent and it meant that even because there was probably there was firmware of a different chip versions between the two as well.  This is just the latest version.  It was likely that all the ones in between were also vulnerable to the same thing.  It wasn't just a one to one comparison, which was quite cool.  Do you know if Samsung took the approach that all those middle versions were likely vulnerable as well and they're only going to be releasing the updated version of this point.  I don't know a huge amount but I do know which chips are in which phones so I can assume the ones that are supported by them are going to be updated.  More than I think they do seem very good about it but I think these things.  Cool.  So we got a sort of a comment from someone in the channel.  I really want to understand firmware and boot much more in depth looking for the more established projects can be somewhat overwhelming.  Should I just grab a pine phone or pine time and ticker around old think pads.  What kind of more entry level paths you suggest to learn more.  Okay, yeah, excellent.  So it very much depends on which path you want to go through.  If you want to learn into custom ROMs and things on phones and modifying phones in that manner, then yes, something more like a standard Android device like a pixel or something which has the capabilities of custom ROMs.  OEM and locking is the best port of call.  You can mess with the operating system as you want to learn a lot.  There's a lot of tutorials that people have for things like compiling things like linear US which are can be modified in certain ways.  For instance, you can unpack the zip files of some of the custom ROMs and then just modify the boot script and things as you want or add your own things into the system image.  You cannot add these things.  That's sort of it's kind of a big question on that side.  If you're looking at learning how to reverse engineer much more the chips things like the NFC chip, you should start looking at chipsets like the STM32.  These are the probably the most used Cortex Xammon armed embedded chipsets around this huge numbers of very cheap development for them.  And you can write code for them using free tools.  There's also tools like the STM32 cube, which allows you to set specific pins and configurations.  You can create your own USB device acts the mouse whatever in minutes using some of these tools and just deploy them to the phone.  And that's where you would go if you wanted to start learning about how to develop firmware for these things to reverse engineer them.  All you need to do is take those binaries and look at how they work more than anything.  Chuck them in IDRA or RIDARA or, you know, GEDRA, whichever one you like and start looking around them.  There's a huge number of really good tutorials about how to do this, but mostly all I can say is just dive in and try things.  And if you get frustrated too much, then you're probably going the right way with it.  I mean, I don't want to say how hard it was to find all the addresses and things in the firmware that I reverse engineered for this project.  It took days and days and days for some of them, especially when it came to things like a lot of the functionality was based on interrupts.  And I didn't even know which interrupts were there because there's no documentation for this chip and everything is completely custom to Samsung.  These are really difficult things to come up with.  But you can start adding to your knowledge just by doing the most frustrating things you can.  So starting with embedded firmware and that style, start with an STM32 Dev board.  Even start with a Raspberry Pi and just start looking at bare metal stuff if you have one available.  There's all sorts of ways to go into it, really.  That's awesome. That's a great and very thorough answer. I appreciate that.  Do you believe that Samsung will eventually start using signature verification for downloadable firmware?  So the chip did use signature verification in this instance.  What they should be adding to that rather than modifying the signature verification is encryption on top of that.  So at the moment, you could take the firmware that they've deployed and analyze it in IDA with no problems because there's no encryption whatsoever.  Now, different chips that's from different manufacturers, even NFC chip ones are encrypted and signed.  That means you can't reverse engineer them to find any exploits.  You also can't deploy modifications to those firmware and that's sort of the way they should be going more than anything.  Do you think that that's actually a good way making it harder for reverse engineers to inspect the actual firmware?  It's kind of a catch-22 on that point, isn't it? I see where you're coming from.  I think, especially with the threat mobile such as this, where the only real reason someone would reverse engineer this is to make a cool NFC hacking tool rather than to damage other people,  is that if you really wanted to stop people doing this, which I don't agree with on a moral level, but I would say encrypting it and preventing them from doing that is the best way to go.  Because then what they'll have to go for is both guessing how the bootloader works and also guessing what things like secret vendor and CI functions are available,  which aren't necessarily all vulnerable to things but are available and people can brute force through them.  How much time did you spend on this project?  A lot. I feel like my boss has probably asked me that in the chat.  The project started off at the end of the last DEFCON actually, which is when I was seeing my hotel room looking at the original firmware.  Then I just did it in little bits over time, more than anything. It wasn't a solid amount of time.  When it got to the point where I had a signature bypass on the Simpsons, I started focusing quite a lot of time.  It took me about three weeks, not every day, but three weeks in total, to go through everything and start implementing every single part of that firmware.  Because I was having to look through the entirety of the firmware image, which had no documentation whatsoever and nothing to work with, no strings at all, no function references that you'd get in.  It's literally just raw code. It's all guesswork.  That's why it takes such a long-winded amount of time compared to some more desktop-level projects where you can rather as an engineer see an application quite a lot more easily, I'd say.  Other than the challenge of doing the reverse engineering and figuring things out, did you have a particular use case for the end product?  Like a sneaky version of the Proxmark or something?  A sneaky version of the Proxmark is exactly right.  I do have Proxmarks and I really like them, so I've got one right next to me, which I actually use for the reverse engineering of this project really heavily for the NFC side.  Because it so lacks on things like the bit verification, the parity checking, it meant that I could build up the project really simply from that.  Now, essentially, yes, I was trying to make a fakie Proxmark and part of that was passive NFC sniffing.  So one of the tools on a Proxmark is this thing where you can sniff high-frequency communication between the reader and attack.  This is useful like breaking authentication and things.  I wanted to add that in so you could go up someone with a phone and stick it over them as they're trying to open a door or something back and pick up for communication.  Now, that feature is almost done, but it's quite complicated now because you have to switch between hardware registers.  Now, there's one block of hardware registers I mentioned in the talk and that handles every single aspect of NFC.  So that's the reader part and the actually like a tag part.  So you have to switch between these constantly in order to get that data and it sort of works.  But until I've got that full functionality in place, it's really not a replacement for the Proxmark.  That was the goal, yes.  Yes, but that's really sneaky. I really like it.  What do you think so little has been done for?  Why do you think so little has been reverse engineered from a Qualcamp baseband? Is it more challenging?  I'd say yes. I've looked at some aspects of Qualcomm as well, just from interest.  So I've looked at several different aspects of things like how their bootloaders work, how they have like the Qualcomm emergency download mode and all these sorts of features.  They've also got the baseband, which is highly complex.  So when you start looking into them and then you realize how much of a kind of worms you've opened with reverse engineering, this project by comparison to something like a Qualcomm chip is very simplistic.  It's one very small, say 12K firmware to look through.  Whereas when you get to the Qualcomm baseband, which is going to be hugely complex, it's just a huge project and it's something which is better suited to a multi-person team rather than just me on my own.  So is it largely the size of the firmware on Qualcomm chipset as the limiting factor or is it also that because is the Snapdragon still like a natural arm core or is it something Qualcomm specific?  It's an ARM64 core, I believe, at the moment.  I know there's been quite a lot of research done on Qualcomm in general on their chipsets because it is the focus of the phone. I mean, that's why I chose a chipset that was side aspect of a phone because I thought no one would have bothered to look at them.  And I haven't with this one because I feel like the vulnerability I found would probably be found quite quickly.  But yes, when it comes to the Qualcomm side of things, it's just such a hugely complex chipset.  And there's so much to look at and so many like potentials for bugs in different places that like any chipset of that complexity, it would take a team and quite a lot of time to find something, I think.  Yeah, fair enough.  It's like we're we got some potential questions coming back in.  Yeah, is there any part of the talk that you omitted because you just like ran out of time?  That's quite a lot. So I wanted to go into more details about the reverse engineering side, which was considering it was only half the talk was the most time consuming part of the topic.  But I found that it was quite dull to talk about because it's literally going me going, oh, I thought this might be this I thought might this might be this for instance I mentioned interrupts earlier and how these work on Cortex M chips is there's a big table at the start of the  stack which includes the reset factor, which is where the chip starts from the start of the stack and then it has a bunch of interrupts rings like the hardware and stuff. Now on top of this it also has interrupts for more complex hardware like the NFC.  So one thing was all the NFC tag mode stuff ran off one single interrupt. So it hit that interrupt and jumped some code. That meant the code wasn't directly referenced by anything and actually didn't disassemble when I first looked at the firmware.  And what this meant was I wanted to override what I started off doing was overriding that interrupt in the first place but I had to know where it was. So I found the select function that I mentioned the talk and the word back from there found that had no function reference  thought maybe it's a interrupt and then search that value, which was then found as table things like that. These are things that are very valuable from a reverse engineering perspective but they're very boring to talk about in the talk I think, which is probably bad because I just spoke about them for about  10 minutes. No, no, no, it's fine. We've got time and people are like I'm interested. I didn't know that things pointed exclusively by the interrupt table where wouldn't normally decopile.  Not unless it will. Coedra is quite good at this I found because it understands Cortex and whereas I just sort of quite hands off when it comes to things like Cortex and chips. It allows it tells you to work that for yourself essentially a lot of the time.  So what would you say are other interesting targets like not complex and wild. They use chips.  What I would recommend is something that I work quite heavily which is IOT pro embedded IOT chips, which are not custom chipsets in the first place. They usually STM cores or, you know, FM cores and these sort of things.  Why these are interesting is they're a good jumping off point to learn these things because you're not guessing you've got documentation in place, but also people implement bootloaders and things which you can then try and break.  Now, I did a talk at 44 con a while ago, which is about breaking one of these bootloaders by breaking the encryption mechanisms on the firmware update by dumping round off an STM 32 chip as it was doing the firmware update.  Things like this are things you shouldn't start looking at because there's millions of these IOT devices out there with all sorts of different chipsets and they're really fun targets.  When it comes to custom chips like this, you're really not going to find much information online about them just because they're hidden away.  There's about two links if you search for some of these Samsung chips online, apart from their accreditation from the NFC forum.  So finding these chips in the first place is probably your greatest goal when you're starting up something like this, more than anything.  And someone wants to know if the firmware was based on an RTOS or more long slides, which is like a standard.  Rob microcontroller target.  Yep, great question. So you often find embedded projects like this using RTOS like VX works or free art or so Ecos and these sorts of things.  Now, they weren't because it was literally a straight firmware that had compiled. They had their own tool presumably they had their own tooltune at Samsung.  They compiled it up. They had to have everything sorted as they wanted to and laid out as they wanted to because they have their firmware as they wanted.  And RTOS is usually built for certain chipsets or certain families of chipsets or certain styles.  It just wasn't really meant to be on that point.  Often these RTOS have a lot of overhead as well.  I think do debug strings, for instance, VX works for the table that's I think being compiled out, but is at the end of pretty much all their firmware,  which includes all the function names, which can then reference back to all the functions in the firmware, which saves you a lot of time reverse engineering,  but it's also a security perspective quite bad.  It didn't use an RTOS. It was just a straight running firmware. They'd put their own function calls in all that sort of thing.  Other chipsets that looked at the similar or custom often implement their own custom RTOS for this.  But in this case, that was none used. It was literally just running as it needed to and relying on interrupts more than threads.  That was a great answer, by the way. Thank you.  Well, it looks like we are running out of questions and we're just about the end of our time anyways.  Is there any additional links you want to share or code or anything like that that you want to get out there?  Yeah. So if we're doing links and that sort of thing, you can follow me at Twitter at iscuri1. So that's my username and then one at the end,  because I didn't get the one without the number first for GitHub. It's just iscuri.  And I should be pushing out a blog in the next couple of days, like,  outlining all of these details as well as linking to the YouTube video of this at pentestpartners.com, which is my company website.  So definitely feel free to have a look if you want the really nitty-gritty technical details.  Awesome. Well, thank you so much for joining us for this QA session.  It's been great talking to you. Thank you for providing content to our virtual DEFCON save mode.  And have a nice day.  Thank you too. Thank you very much, guys.
DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_0_3047.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_3048_3119.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_3120_3803.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_3804_6839.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_6840_7187.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_7188_7835.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_7836_8315.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_8316_10463.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_10464_10535.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_10536_12503.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_12504_13235.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_13236_20243.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_20244_23603.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_23604_24431.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_24432_32447.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_32448_36383.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_36384_36479.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_36480_37463.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_37464_38375.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_38376_38927.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_38928_39947.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_39948_41195.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_41196_41699.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_41700_43499.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_43500_44615.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_44616_44711.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_44712_44771.png DEF_CON_Safe_Mode_-_Christopher_Wade_-_Beyond_Root_npY5XLaRMlA_44772_46981.png
Okay, so today we've got Christopher Wade presenting on Beyond Root, custom firmware for embedded mobile chipsets. So thank you for joining us, Christopher, and I'll let you do any opening remarks and then we'll go right into the questions. Excellent. Hello, Ron, thank you for coming to my talk. Yeah, that's pretty much all I can say. Thank you very much. Could you tell us a little bit about yourself and just like a quick intro summary for your talk? Yep, so quick introduction. This talk is mainly about custom firmware for embedded mobile chipsets. This is essentially me hacking chips inside my phone which aren't the core ARM chip used to run the thing in order to make it do different things from hardware. In particular for this talk it's going to be NFC chips. So I reverse engineer the firmware of an NFC chip, break the signature checking, and then implement my own firmware onto it. Excellent. Great. So we have one question already queued up. So how did Samsung react to the disclosure of vulnerabilities? Yeah, so Samsung reacted very positively. So I submitted to their mobile security team initially and they accepted it even though it was technically part of their Samsung semiconductor team. So I sent them the disclosure and they delayed with their, you know, interdepartmental systems or whichever. And initially because I submitted the Samsung S6 when I brought it here, said that this wasn't really something they were going to remediate just because it was out of scope. So the Samsung S6 is no longer supported. But when I submitted the Samsung S9, they happily took it and signed their remediation process, which was pretty good. And chips that have been manufactured, I believe you said after April aren't vulnerable to this? Yes. So what they've done is essentially, while they can't really patch the bootloaders of existing chips once they've all really manufactured us outlining the talk, what I have done is discuss with them about how they're going to remediate this and what they said was they're going to remediate all of the chips of the current versions in the manufacturing line. So all of the bootloaders can be patched as chips go out from now on onwards. However, all historical chips will still be affected. So that's why I decided to make the custom firmware for them. They'll still have the vulnerable bootloader. Yes, exactly. Which is very useful. So near the end of the talk, there was a problem with a parity bit. Did you ever get that worked out? Yes, so the parity bit was an interesting one. What they tended to do in the initial firmware, the firmware reverse engineering, is load all their 8-bit buffers as they should into the 8-bit buffer in hardware registers. This is done because that way the hardware itself can pick up the stack with the set and the set bits, which is done to calculate parity between each set of bytes to the send. What I did was find a very specific hardware address and a very specific bit in that hardware address to set, which let me essentially control that priority bit. What this meant was I set up 9-bit values, so that includes the 8 bits of the byte, followed by the 1-bit parity bit, which you'd be encrypted, and that starts the process. And the apps will like bit shift everything around by 1 on each part, because the buffer was 8 bits. But I had 9 bits of base to chip, and certain chips had to bit shift around, which was a bit strange for Tidwork. Did you get like NFC tag cloning working? Yes, so what I ended up doing in the end was literally being able to read an NFC tag using the standard rewrap occasions that existed, and use my tool to upload binary data through the ITC interface I had. So I could set each block of the data of the NFC tag, as I wanted to, including the UID, the write and read bits, et cetera, all parts that I could upload down, and I also hooked into the ITC interface, so that every time some reader wrote to the tag as well and authenticated it properly, it would then also write that binary ITC, so I could modify the binary file I had, between things like access control systems and things. I would be able to keep a check of what was going on, so some access control systems had a lot to help me think has been read, and some other parent information to make sure that no tags were cloned or reused, and I basically did that so that I could clone the tags well, also allow the data to be modified persistently even if I stopped going to be faster, and this was quite useful in the end. That's great. Saige, you got any questions? Yeah, so I'm not on the track yet, but I did notice that your talk was mostly a tutorial on reverse engineering, and I think it seemed like you were starting out because you were curious about the NFS MFC firmware and wanted to take a whack at customizing it. Is that my catching your motive correctly? Yes, so that is essentially how I started to know what really started this software, so I had this old something that we started with at the talk, which I was essentially using to mess around with different custom ROMs on, and one of the things I did was pull up devian to this, so I scraped up all of the Android operating system and shoved the end devian root file system into place, so instead of having it as a true design line at the talk, it was more of a full operating system advice. Now this afforded quite a lot of functionality, but also a lot of things like the screen didn't work so well. I quite enjoyed this, so I was going to have some sort of hacking tools, modify the USB and things so that I could use GadgetFS, etc. I thought it would be interesting to see where I could push things like the NFC side, so I redeployed Lineage OS to something like Six Phone, which is a very standard custom ROM, Rooster, and then started looking at the NFC chip, and that sort of weather project sprung up from there, so it started off as more of a standard custom ROM project than it started off as a standard reverse engineering project, but because I like reverse engineering, it sort of went on from there. It just sort of slid into it. Yeah, that happens. So have you looked at any other chips inside of phones? This seems like a really deep and hyper specific long chain that you went through to patch in this functionality. Yes, unfortunately, due to a responsible disclosure, I can't discuss those at the moment. Fair enough. So maybe I'll sort of ask around this. Was this the first one, and you've just been able to successfully responsible disclose this one? What has your experience in the past led you that brought you to this kind of point? Yeah, so this is definitely the first one. I like my supposed to be have a habit of routing our last phone that we're using, not our current phone, because walking around with the routed phone is not the best idea. So I had had a lot of older phones, and then I'd got Samsung S6 for a few years and then replaced it with a new phone and just had it lying around. So the first thing that was router and then start looking at seeing what I can do. I also looked at a few older phones at the same time. So for instance, I had a very old Samsung Galaxy Mini, which has FM radio capabilities based on a Broadcom chip set. Now, that was very interesting. I was looking at this a bit because it didn't seem to have any code signing with some of the binary files on there. It looked like it wasn't just an FM radio receiver, but also a transceiver. So I wanted to see if I could push it into doing FM transceiving. Sadly, that didn't really go anywhere because quite frankly, working on old Android versions like that is incredibly tedious. They don't always use device file appropriately, and they often route their circuitry around in ways that just it doesn't work for you. By comparison to more modern phones where everything's laid out, everything's documented, everything's open source and really nice ways. That's super unfortunate. I do remember some really old phone hacks that they were actually MP3 player hacks that you could turn them into FM transmitters. Yeah, that would be cool to get your phone to do it too. Sadly, I'm stuck to the Raspberry Pi with a wire sticking out of one of the pins at the moment, which is a fair enough. Is there any other active products that you're working on that you can talk about? Yeah, so I'm still looking at different phone chipsets. I've been looking around to see what other NFC chips that I use. There's only a handful of manufacturers. That's something I'm looking into. The big problem there is obviously price point because phones are expensive things and it's not something you want to buy randomly. The key thing I've been looking at is downloading custom ROMs for random phones that I thought would be interesting, not just for NFC chips, but other firmware binaries. If you download the ROMs and unpack them, you can find quite a lot of information about the hardware that you wouldn't be able to get just from a tear down, for instance. For instance, if you go in the vendor partition, there's all sorts of firmware blobs for things like Wi-Fi chips, etc. That's really led me to things like Xiaomi Mi Note 3, which is an old phone. While this isn't necessarily a firmware hack, being able to echo a single number into the Sys files and turn that into a monitor mode phone is very powerful. It's full-on passive monitor mode, no injection, but still full-on monitor mode that works really effectively. Things like that are something I keep looking through and looking through as much as I can because it's quite fun to my phone. That's awesome. Part of your project, you used a, I believe it was called the Unicorn Engine for hardware emulation. What level of emulation is actually happening there? Is it just the CPU? How does it handle peripherals and stuff? The Unicorn Engine is a really powerful tool. I've seen a few talks on this by the people who have actually developed it. I'm sure it was at Defcon as well. As it's a library that's purely used for loading into other things. Now, I always write my stuff in C, so I load it into C. All it does is emulate the core architecture you want to go for. In my case, it was ARM thumb. Then it lets you map out memory mappings you want. In order to write and read memory to start things up. Then you can hook operations and reads and writes the memory. When you hook into operations, you can make them act in weird ways. For instance, one of the problems I had with my hardware was it would sometimes hit the wait for interrupt operation, which wasn't supported by Unicorn. I could override that just to a standard knob because I didn't need to think about it. But hooking into the memory reads and writes was really key for me because I can map out to say there's actually hardware addresses at certain points. I could then just put an if statement, a switch statement, and just say if it hits this address, mess with it in this way. For instance, in the I2C interface, it was when it hits the I2C status buffer, I wanted to return random data. So it eventually hits the OK status or sometimes the busy status. Then when it hits the read and writes, I wanted it to read in data so I was writing to it as if it was the physical chip and then write data back when it was the physical chip. Which is how I got that initial fuzzing working. So it's really powerful for that. But it has no integration for actual realistic hardware, just the processing as it's going along. So just the core operations, which is really cool. You can write basically functions that are at those memory addresses to pretend to be that hardware, right? Yeah, so you can literally set R0, R1, R2, you know, the command. And then the program counter and say go into this and you can also set the address to tell it to finish. They can stick that at the end of the function. And that way you go run through the function, call the functions it needs to, but also then stop when it's ready and you'll then be able to read out memory as you want. So for instance, what I wanted to do before I started up part of it, the project I didn't really mention was I start off emulating the actual firmware binary that I had rather than the bootloader. And what it was load that in and let it run so that I could set up all the hardware addresses I needed. So RAM, et cetera, to see how that was laid out to see if I could see anything because you can let it start and then let it stop and then dump the memory out as you need to without really any problems. Cool. That's actually really, really slick. It's really powerful. Yeah. So how do you, how do you like go about making the jump from these accessing like a particular hardware address to saying, okay, this is an I swear see chat like external peripheral. Like how do I enter? How do you make that inference? Well, it was definitely inference. I was pretty much guessing when it came down to it. So what I was doing was when it hit that first, so I'll go step by step with what I did because it was pretty much as I outlined in the talk, it hit that first address and which is keep looping and reading and doing a few other operations before jumping back to the start where it read that address again. And I already knew that that was the correct hardware address because it was at 400000 which is all the hardware, the hardware addresses are. So as it was reading it was literally bit shifting what some code compaustry often is shifting values down to hit the spurt some bit to check them. And I thought, okay, so it's probably you checking for certain certain bits and some sort of order. And so I just randomized that. And then it started trying to read in bikes and was loading them into a buffer in RAM and I could see this in the emulation. I thought, if what happens if I start writing my code into it. So I started writing different operations in and there's all the staggered approach where because I didn't have interrupts, I think, but for some reason it wouldn't response right away. So I gave it a whole list of commands I wanted to run. And then it had like three of them and then it would start pumping out the responses. So eventually that worked really nicely. So it was quite cool in the end. That is really, it's like, yeah, but it's all assumption essentially it's all guessing is all guess work and eventually it gets. And I imagine that like interacting with those pieces of hardware might allow you to say like, okay, this is a this is clearly a memory buffer that's being shared with something else. I can't think of experience will just help you with that kind of thing. Yeah, and I sort of stepped through some of the parts of the code. So I stepped through because there was that infinite loop that started which was constantly reading. And I jumped into there and a few functions in and that's where I found the state machine of command zero one two and six, which were the first commands that the chip would like see at the start of a firmware update so zero was a reset one was get some version information and two was sent start sending the shall one hash and the signature and then command six was the secret one which don't any memory I wanted which was the father that existed was quite surprising. Yeah, but I mean it worked out was like, you know, find that. So if you didn't have that command, you briefly mentioned about like doing that kind of reversing blind, you already had the previous version you were able to use the knowledge you gain from that first stage to attack later on chip. If you wanted to go about doing something like this blind, could you would just be just an enormous amount more effort or is it just not possible. It probably would have been an enormous amount more effort. Yes, because I had that bootloader to emulate and I could make assumptions about the two size values that made it a lot simpler. Now it wasn't the full process but it was helpful enough. But yeah, the blind part was very simple in the end because I didn't the bootloader had changed just enough that I could guess anyway so I could make inferences about where I'd overwritten the stack and might overwritten the memory which would have different kinds of responses over the I2C bus. So I could get the size of the stack. I could overwrite it all with whatever addresses I wanted because eventually one of those would be the link register. And when it jumped in I literally just would have jumped through them in the same way essentially, but it would have been a lot more difficult to find the initial vulnerability I think. Fair enough. You could then so you could potentially use your custom firmware function to reimplement that kind of memory dumping though, like by jumping into that and then dumping everything back out to get the updated firmware version. Yes, so that's exactly what I did and so that was my first port of call when I started making the custom firmware was adding arbitrary reads to the core firmware so instead of it being in the bootloader I made my own custom firmware capable of doing that. And it was a few steps so I had to essentially find an I2C functional where to mess with the work via NCI and then modify that so I could send NCI responses with whatever I wanted and override those functions so it was a sort of a good for jumping off point and then I could modify my export to not load data from running. Loads data from random addresses to start off the exploit which was a bit scary when I actually saw what was working in the exploit in the live version. So we got a question from the channel. When starting your research weren't you afraid to find old vulnerabilities on your chip that were already patched since you started on an old phone. Yeah, so I thought it would have been patched to be honest. So I started with something at six and I was more it wasn't really doing it from a security perspective it's more of a reverse engineering things is fun. But because they told me they weren't going to patch it because it was so old which was valid I thought I don't think anyone's ever bothered looking at something so innocuous as an NFC chip on a phone. So I thought if I bought a later phone which I was in the market for the time anyway, I'd be able to find something just the same and I did which was excellent and it meant that even because there was probably there was firmware of a different chip versions between the two as well. This is just the latest version. It was likely that all the ones in between were also vulnerable to the same thing. It wasn't just a one to one comparison, which was quite cool. Do you know if Samsung took the approach that all those middle versions were likely vulnerable as well and they're only going to be releasing the updated version of this point. I don't know a huge amount but I do know which chips are in which phones so I can assume the ones that are supported by them are going to be updated. More than I think they do seem very good about it but I think these things. Cool. So we got a sort of a comment from someone in the channel. I really want to understand firmware and boot much more in depth looking for the more established projects can be somewhat overwhelming. Should I just grab a pine phone or pine time and ticker around old think pads. What kind of more entry level paths you suggest to learn more. Okay, yeah, excellent. So it very much depends on which path you want to go through. If you want to learn into custom ROMs and things on phones and modifying phones in that manner, then yes, something more like a standard Android device like a pixel or something which has the capabilities of custom ROMs. OEM and locking is the best port of call. You can mess with the operating system as you want to learn a lot. There's a lot of tutorials that people have for things like compiling things like linear US which are can be modified in certain ways. For instance, you can unpack the zip files of some of the custom ROMs and then just modify the boot script and things as you want or add your own things into the system image. You cannot add these things. That's sort of it's kind of a big question on that side. If you're looking at learning how to reverse engineer much more the chips things like the NFC chip, you should start looking at chipsets like the STM32. These are the probably the most used Cortex Xammon armed embedded chipsets around this huge numbers of very cheap development for them. And you can write code for them using free tools. There's also tools like the STM32 cube, which allows you to set specific pins and configurations. You can create your own USB device acts the mouse whatever in minutes using some of these tools and just deploy them to the phone. And that's where you would go if you wanted to start learning about how to develop firmware for these things to reverse engineer them. All you need to do is take those binaries and look at how they work more than anything. Chuck them in IDRA or RIDARA or, you know, GEDRA, whichever one you like and start looking around them. There's a huge number of really good tutorials about how to do this, but mostly all I can say is just dive in and try things. And if you get frustrated too much, then you're probably going the right way with it. I mean, I don't want to say how hard it was to find all the addresses and things in the firmware that I reverse engineered for this project. It took days and days and days for some of them, especially when it came to things like a lot of the functionality was based on interrupts. And I didn't even know which interrupts were there because there's no documentation for this chip and everything is completely custom to Samsung. These are really difficult things to come up with. But you can start adding to your knowledge just by doing the most frustrating things you can. So starting with embedded firmware and that style, start with an STM32 Dev board. Even start with a Raspberry Pi and just start looking at bare metal stuff if you have one available. There's all sorts of ways to go into it, really. That's awesome. That's a great and very thorough answer. I appreciate that. Do you believe that Samsung will eventually start using signature verification for downloadable firmware? So the chip did use signature verification in this instance. What they should be adding to that rather than modifying the signature verification is encryption on top of that. So at the moment, you could take the firmware that they've deployed and analyze it in IDA with no problems because there's no encryption whatsoever. Now, different chips that's from different manufacturers, even NFC chip ones are encrypted and signed. That means you can't reverse engineer them to find any exploits. You also can't deploy modifications to those firmware and that's sort of the way they should be going more than anything. Do you think that that's actually a good way making it harder for reverse engineers to inspect the actual firmware? It's kind of a catch-22 on that point, isn't it? I see where you're coming from. I think, especially with the threat mobile such as this, where the only real reason someone would reverse engineer this is to make a cool NFC hacking tool rather than to damage other people, is that if you really wanted to stop people doing this, which I don't agree with on a moral level, but I would say encrypting it and preventing them from doing that is the best way to go. Because then what they'll have to go for is both guessing how the bootloader works and also guessing what things like secret vendor and CI functions are available, which aren't necessarily all vulnerable to things but are available and people can brute force through them. How much time did you spend on this project? A lot. I feel like my boss has probably asked me that in the chat. The project started off at the end of the last DEFCON actually, which is when I was seeing my hotel room looking at the original firmware. Then I just did it in little bits over time, more than anything. It wasn't a solid amount of time. When it got to the point where I had a signature bypass on the Simpsons, I started focusing quite a lot of time. It took me about three weeks, not every day, but three weeks in total, to go through everything and start implementing every single part of that firmware. Because I was having to look through the entirety of the firmware image, which had no documentation whatsoever and nothing to work with, no strings at all, no function references that you'd get in. It's literally just raw code. It's all guesswork. That's why it takes such a long-winded amount of time compared to some more desktop-level projects where you can rather as an engineer see an application quite a lot more easily, I'd say. Other than the challenge of doing the reverse engineering and figuring things out, did you have a particular use case for the end product? Like a sneaky version of the Proxmark or something? A sneaky version of the Proxmark is exactly right. I do have Proxmarks and I really like them, so I've got one right next to me, which I actually use for the reverse engineering of this project really heavily for the NFC side. Because it so lacks on things like the bit verification, the parity checking, it meant that I could build up the project really simply from that. Now, essentially, yes, I was trying to make a fakie Proxmark and part of that was passive NFC sniffing. So one of the tools on a Proxmark is this thing where you can sniff high-frequency communication between the reader and attack. This is useful like breaking authentication and things. I wanted to add that in so you could go up someone with a phone and stick it over them as they're trying to open a door or something back and pick up for communication. Now, that feature is almost done, but it's quite complicated now because you have to switch between hardware registers. Now, there's one block of hardware registers I mentioned in the talk and that handles every single aspect of NFC. So that's the reader part and the actually like a tag part. So you have to switch between these constantly in order to get that data and it sort of works. But until I've got that full functionality in place, it's really not a replacement for the Proxmark. That was the goal, yes. Yes, but that's really sneaky. I really like it. What do you think so little has been done for? Why do you think so little has been reverse engineered from a Qualcamp baseband? Is it more challenging? I'd say yes. I've looked at some aspects of Qualcomm as well, just from interest. So I've looked at several different aspects of things like how their bootloaders work, how they have like the Qualcomm emergency download mode and all these sorts of features. They've also got the baseband, which is highly complex. So when you start looking into them and then you realize how much of a kind of worms you've opened with reverse engineering, this project by comparison to something like a Qualcomm chip is very simplistic. It's one very small, say 12K firmware to look through. Whereas when you get to the Qualcomm baseband, which is going to be hugely complex, it's just a huge project and it's something which is better suited to a multi-person team rather than just me on my own. So is it largely the size of the firmware on Qualcomm chipset as the limiting factor or is it also that because is the Snapdragon still like a natural arm core or is it something Qualcomm specific? It's an ARM64 core, I believe, at the moment. I know there's been quite a lot of research done on Qualcomm in general on their chipsets because it is the focus of the phone. I mean, that's why I chose a chipset that was side aspect of a phone because I thought no one would have bothered to look at them. And I haven't with this one because I feel like the vulnerability I found would probably be found quite quickly. But yes, when it comes to the Qualcomm side of things, it's just such a hugely complex chipset. And there's so much to look at and so many like potentials for bugs in different places that like any chipset of that complexity, it would take a team and quite a lot of time to find something, I think. Yeah, fair enough. It's like we're we got some potential questions coming back in. Yeah, is there any part of the talk that you omitted because you just like ran out of time? That's quite a lot. So I wanted to go into more details about the reverse engineering side, which was considering it was only half the talk was the most time consuming part of the topic. But I found that it was quite dull to talk about because it's literally going me going, oh, I thought this might be this I thought might this might be this for instance I mentioned interrupts earlier and how these work on Cortex M chips is there's a big table at the start of the stack which includes the reset factor, which is where the chip starts from the start of the stack and then it has a bunch of interrupts rings like the hardware and stuff. Now on top of this it also has interrupts for more complex hardware like the NFC. So one thing was all the NFC tag mode stuff ran off one single interrupt. So it hit that interrupt and jumped some code. That meant the code wasn't directly referenced by anything and actually didn't disassemble when I first looked at the firmware. And what this meant was I wanted to override what I started off doing was overriding that interrupt in the first place but I had to know where it was. So I found the select function that I mentioned the talk and the word back from there found that had no function reference thought maybe it's a interrupt and then search that value, which was then found as table things like that. These are things that are very valuable from a reverse engineering perspective but they're very boring to talk about in the talk I think, which is probably bad because I just spoke about them for about 10 minutes. No, no, no, it's fine. We've got time and people are like I'm interested. I didn't know that things pointed exclusively by the interrupt table where wouldn't normally decopile. Not unless it will. Coedra is quite good at this I found because it understands Cortex and whereas I just sort of quite hands off when it comes to things like Cortex and chips. It allows it tells you to work that for yourself essentially a lot of the time. So what would you say are other interesting targets like not complex and wild. They use chips. What I would recommend is something that I work quite heavily which is IOT pro embedded IOT chips, which are not custom chipsets in the first place. They usually STM cores or, you know, FM cores and these sort of things. Why these are interesting is they're a good jumping off point to learn these things because you're not guessing you've got documentation in place, but also people implement bootloaders and things which you can then try and break. Now, I did a talk at 44 con a while ago, which is about breaking one of these bootloaders by breaking the encryption mechanisms on the firmware update by dumping round off an STM 32 chip as it was doing the firmware update. Things like this are things you shouldn't start looking at because there's millions of these IOT devices out there with all sorts of different chipsets and they're really fun targets. When it comes to custom chips like this, you're really not going to find much information online about them just because they're hidden away. There's about two links if you search for some of these Samsung chips online, apart from their accreditation from the NFC forum. So finding these chips in the first place is probably your greatest goal when you're starting up something like this, more than anything. And someone wants to know if the firmware was based on an RTOS or more long slides, which is like a standard. Rob microcontroller target. Yep, great question. So you often find embedded projects like this using RTOS like VX works or free art or so Ecos and these sorts of things. Now, they weren't because it was literally a straight firmware that had compiled. They had their own tool presumably they had their own tooltune at Samsung. They compiled it up. They had to have everything sorted as they wanted to and laid out as they wanted to because they have their firmware as they wanted. And RTOS is usually built for certain chipsets or certain families of chipsets or certain styles. It just wasn't really meant to be on that point. Often these RTOS have a lot of overhead as well. I think do debug strings, for instance, VX works for the table that's I think being compiled out, but is at the end of pretty much all their firmware, which includes all the function names, which can then reference back to all the functions in the firmware, which saves you a lot of time reverse engineering, but it's also a security perspective quite bad. It didn't use an RTOS. It was just a straight running firmware. They'd put their own function calls in all that sort of thing. Other chipsets that looked at the similar or custom often implement their own custom RTOS for this. But in this case, that was none used. It was literally just running as it needed to and relying on interrupts more than threads. That was a great answer, by the way. Thank you. Well, it looks like we are running out of questions and we're just about the end of our time anyways. Is there any additional links you want to share or code or anything like that that you want to get out there? Yeah. So if we're doing links and that sort of thing, you can follow me at Twitter at iscuri1. So that's my username and then one at the end, because I didn't get the one without the number first for GitHub. It's just iscuri. And I should be pushing out a blog in the next couple of days, like, outlining all of these details as well as linking to the YouTube video of this at pentestpartners.com, which is my company website. So definitely feel free to have a look if you want the really nitty-gritty technical details. Awesome. Well, thank you so much for joining us for this QA session. It's been great talking to you. Thank you for providing content to our virtual DEFCON save mode. And have a nice day. Thank you too. Thank you very much, guys.
Okay, so today we've got Christopher Wade presenting on Beyond Root, custom firmware for