 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 on to 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 it 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 glazed with their, you know, interdepartmental systems or whichever. And initially, because I submitted the Samsung S6 when I brought it here, they said that this wasn't really something they were going to remediate just because it was out of scope. 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 already been manufactured as outlined in 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 are going to be patched as chips go out from now 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 or the firmware of reverse engineering is load all their 8-bit buffers as they should into the 8-bit buffer and hardware registers. This is done because that way the hardware itself can pick up the stack with the set and the set bits which are 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 parity 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've been encrypted and that starts the process. And that sort of like bitshift everything around by one on each part because the buffer was 8 bits. But I had 9-bit space to check and so essentially I just had the bitshift around which was a bit strange for teamwork. Did you get like an 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 reader applications that existed and use my tool to upload binary data through the IDC 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, etc. All parts that I could upload and download as needed. And I also hooked into the IDC interface so that every time some reader wrote to the tag as well and authenticated properly, it would then also write that binary IDC so I could modify the binary file I had. This was meaning 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 do with how many things had been read and some other parameter information to make sure that no tags had been cloned or reused. And yeah, I basically did that so that I could clone the tags while also allowing 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. Did I get 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. 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. Am I catching your motive correctly? Yeah, so that is essentially how I started to know what really started this off for. So I had an old something that we started at the talk which I was essentially using to just mess around with different custom runs on. One of the things I did was walk Debian into this. So I scraped a pool of the Android operating system and shoved the end Debian 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 on the device. Now this afforded quite a lot of functionality but it also meant that the screen didn't work so well. I quite enjoyed this so I was going to have some sort of hacking tools, modifying USB and things so that I could use gadgets, FSS, etc. But I thought it would be interesting to see where I could push things like the NFC side. So I redeployed LinearJOS to something at Sixphone which is a very standard custom ROM root set 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 because I like reverse engineering. It sort of went on from there. It 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 like 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. I'm very sorry about that. So maybe I'll sort of ask around this. The first one and like you've just been able to successfully responsible disclose this one or like what has your experience in the past led you that brought you to like this kind of point? Yeah, so this is definitely the first one. So I like my supposed to be have a habit of rooting our last phone that we're using, not our current phone because walking around with the rooted phone is not the best idea. So I had a lot of older phones and then I'd got something at Six for a few years and then replaced it with a new phone and just had it lying around. So the first thing that was rooted and then start looking at seeing what I'm doing. 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 that 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 very well by comparison to more modern phones where everything's laid out, everything's documented, everything's open source in really nice ways. That's super unfortunate. I do remember some like really old like phone hacks that like they were, I think 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 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 chips. I've been looking around to see other NFC chips that I use. There's only a handful of manufacturers and that's something I'm looking into but 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 because if you download the ROMs and unpack them then 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, if you go in the vendor partition there's all sorts of firmware blobs for things like Wi-Fi chips, et cetera and that's where it led me to things like so I've got a Xiaomi Mi Note 3 which is an old phone and while this isn't necessarily a firmware hack being able to echo a single number into the SIS files and turn that into a monitor mode phone is very powerful like full-on passive monitor mode no injection but still full-on monochrome that works really effectively. Things like that is just something I keep looking through and looking through as much as I can because it's quite fun to mess around with phones in that way. That's awesome. So part of your project you used I believe it was called the Unicorn Engine for hardware emulation like what level of emulation is actually happening there? Is it just like the CPU? How does it handle peripherals and stuff? Okay, yes. So the Unicorn Engine is a really powerful tool and I've seen a few talks on this by the people who've actually developed it. I'm sure it was at Defconn as well. 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. So in my case it was ARM thumb. Then it lets you map out memory mappings you want so in order to write and read memory to start things up and then you can hook both function calls or sorry, operations and reads and writes the memory. So 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 and 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 okay status or sometimes the busy status and then when it hits the read and writes I wanted it to you know read and date so I was writing to it 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 on so just the core operations which is really cool. You can write like basically functions that are at those memory addresses just 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 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'll 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 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 etc to see how that was laid out so 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 like go about making the jump from these accessing like a particular hardware address to saying okay this is an I2C like external peripheral like how do I enter and 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 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 just 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 addresses are so as it was reading it was literally some code compiles too often is shifting values down to hit a certain bit to check them and I thought okay so it's probably you checking the certain bits in some sort of order and so I just randomised that and then it started trying to read in bytes and was loading them into a buffer in RAM and I could see this in the emulation and I thought if what happens if I start writing my code into it? So I started writing different operations in and there was sort of a staggered approach where because I didn't have interrupts I think but for some reason it wouldn't respond 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 really That is really what it's like Yeah but it's all assumption essentially it's all guessing, it's all guesswork and eventually it gets that 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 that can't be experienced will just help you 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 0, 1, 2 and 6 which were the first commands that the chip would like see at the start of a firmware update so 0 was a reset, 1 was get some version information and 2 was start sending the show on hash and the signature and then command 6 was the secret one which was the firmware I wanted which was the the file that existed was quite surprising at the time Yeah but I mean it worked out just like being able to 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 gained from that first stage to attack the later on chip if you wanted to go about doing something like this would it 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 it made it a lot simpler now it wasn't the full process but it was helpful enough but the blind part was very simple in the end because the bootloader had changed just enough that I could guess anyway so I could make inferences about where I had overwritten the stack and overwritten the memory to have different kinds of responses over the I2C bus because I could get the size of the stack I could overwrite it always 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 I 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 function I wanted to mess with that worked 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 good jumping off point and then I could modify my exploit to not load 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 yes so I thought it would have been patched to be honest so I started with something a 6 and I wasn't really doing it from a security perspective it's more of a reverse engineering thing that's 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 at the time anyway I'd be able to find something just the same and I did which was excellent and it meant that because there was the firmware of 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 actually in 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 and OEM unlocking 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 linux os 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 M and armed embedded chipsets around there's huge numbers of very cheap development boards 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 RADAR or you know GEDRA or 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 because reverse engineering is a pain I mean I don't want to tell you 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 was 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 but if you're starting with embedded firmware in 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 that's where 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 them 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 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 so the project started off at the end of the last DEF CON actually which is when I was seeing my hotel room looking at the original firmware and 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 when I really started focusing quite a lot of time was so 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 enough, it's literally just raw code, it's all guest work and that's sort of why it takes such a long rendered 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. So other than 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, yes that's very correct. I do have Proxmarks and I really like them so I've got one right next to me which I actually use the reverse engineering of this project really heavily for the NFC side because it so lacks on things like the bit of 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 used for 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 by accident and pick up the communication now that's 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 attack part so you have to switch between those 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. That's really sneaky, I really like it. Why do you think so little has been done for why do you think so little has been reverse engineered from a Qualcomm 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 Qualcomm emergency download mode and all these sorts of features they've also got the baseband which is highly complex the problem is you start looking into them and then you realise 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. Largely the size of the firmware on Qualcomm chipset is the limiting factor or is it also that is the snapdragon still like a natural arm core or is it something Qualcomm specific? It's an ARM64 core I believe for the moment so 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 a side aspect of a phone because I thought I would rather bother to look at them and they 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 there's so many 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 got some potential questions coming back in. Yeah is there any part of the talk that you omitted because you just ran out of time? Yes 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 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 firmware 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 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 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 the select function that I mentioned in the talk and the word back from there found that had no function reference thought maybe it's a interrupt and then search for 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 five 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 well, Cahedra's quite good at this I found because it understands Cortex-M whereas I just sort of quite hands off when it comes to things like Cortex-M chips it allows it tells you to work that for yourself essentially a lot of the time fair enough which would you say are other interesting targets like not complex and well they use chips? What I would recommend is something that I work with quite heavily which is IOT embedded IOT chips which are not custom chipsets in the first place they're usually STM cores or EFM 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 44con a while ago which is about breaking one of these bootloaders by breaking the encryption mechanisms on the firmware update by dumping RAM off an STM32 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 accreditations 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 cool and someone wants to know if the firmware was based on an RTOS or more long slides which is like a standard raw microcontroller target yep great question so you often find embedded projects like this using an RTOS like VXWorks or FreeRTOS or ECOS and these sorts of things now they weren't because it was literally a straight firmware that they had compiled they had their own presumably they had their own tool genes 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 had their firmware as they wanted and RTOS is usually built for certain chipsets or certain families of chipsets or certain styles which 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 VXWorks are the table I think I mean compiled out but it's at the end of pretty much all their firmware which includes all the function names which you 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 and all that sort of thing other chipsets they've looked at they've done 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 awesome 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 yep so if you 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 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 DEF CON save mode and have a nice day thank you very much guys