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. Thanks 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 in the hardware. In particular for this talk, it's going to be NFC chips. So I reverse engineered 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 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 delayed with their interdepartmental systems or whichever.

And initially, because I submitted the Samsung S6 vulnerability, 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 started 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 bootloader of existing chips once they've already 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 chipsets of the current versions in the manufacturing lab.

So all of the bootloader is going to be patched as chips go out from now onwards. However, all the 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 as reverse engineering is load all their 8-bit buffers as they should into the 8-bit buffer in the hardware registers. This is done because that way the hardware itself can pick up the slack with these set and unset bits,

which is done to calculate parity between each set of bytes that are sent. 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 would be encrypted at that start of the process.

And that sort of bit-shift everything around by one on each part, because the buffer was 8 bits, but I had 9 bits of space to shove it in, so essentially I just had to bit-shift that around, which was a bit strange, but it did work. Did you get 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 using 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, etc.

All the parts that I could upload and download as needed. And I also hooked into the ITC interface so that every time a certain reader wrote to the tag as well and authenticated properly, it would then also write that final ITC so I could modify the binary file I had. This would mean 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 logs for how many things had been read, and some other interactive 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 well, so that I could basically modify persistently even if I stopped going to restart it. And this was quite useful in the end.

That's great. Saiga, do you have any questions? 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 MFC firmware

and wanted to take a whack at customizing it. Am I catching your motive correctly? Yes, so that is essentially how I started. Now, what I really started this off was I had this old Samsung S6 that we started at the start of the talk,

which I was essentially using to just mess around with different custom ROMs on it. And one of the things I did was port Debian into this. So I scraped up all of the Android operating system and shoved the Debian root file system into place. So instead of having it as a truth as I outlined in the talk, it was more of a full operating system advice. Now, this afforded quite a lot of functionality, but also meant that things like the screen didn't work so well.

I quite enjoyed this because I was going to add some sort of hacking tools, modified USB interface and things so that I could use gadget FFS, et cetera. But I thought it'd be interesting to see where I could push things like the NFC side. So I redeployed Lineage OS to the Samsung S6 phone, which is a very standard custom ROM, rooted it, and then started looking at the NFC chip. And that's where that project sprung off 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? It seems like a really deep and hyper specific long chain that you went through to patch in this functionality.

Yes, unfortunately, due to responsible disclosure, I can't discuss those at the moment. OK, fair enough. I'm very sorry about that. 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?

Or 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. So I'd like most of us to have a habit of rooting our last phone that we're using, not our current phone, because walking around with a rooted phone is not the best idea.

So I'd 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 I did was root it, and then start looking at seeing what I've been 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 chipset. Now that was very interesting.

I was looking into 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 root 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 really old phone hacks that they were, I think they were actually MP3 player hacks that you could turn them into FM transmitters.

Yeah, that would've been cool to get your phone to do it too. Sadly, I'm stuck with a Raspberry Pi with a wire sticking out of one of the pins at the moment, which is good enough now. 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 are used. 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 teardown, for instance. For instance, if you go in the vendor partition, there's all sorts of firmware blobs for things like Wi-Fi chipsets, etc.

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 sys files and turn that into a monitor-mode phone is very powerful. Like full-on passive monitor mode, no injection, but still full-on monitor mode that works really effectively.

Things like that, it's 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. What level of emulation is actually happening there? Is it just like 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 DEF CON 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 in order to write and read memory to start things up. Then you can hook both operations and reads and writes of 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.

I could override that just to a standard NOP 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, just saying 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 that I was writing to 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 on. So just the core operations, which is really cool. But 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, 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'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 started off emulating the actual firmware binary that I had rather than the bootloader. And what I did 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. Yeah. So how do you go about making the jump from these accessing a particular hardware address to saying, okay, this is an I2C chip, like external peripheral. 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 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 the hardware addresses are.

So as it was reading, it was literally bit shifting. What thumb code compares to often is shifting values down to hit a certain bit to check them. And I thought, OK, so it's probably checking for certain bits in some sort of an order. And so I just randomize 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. I thought, what happens if I start writing my code into it? So I started writing different operations and there's sort of a staggered approach, 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 what it's like. Yeah, but it's all assumption essentially. It's all guessing, it's all guesswork. And I imagine that like interacting with those pieces of hardware might allow you to say like, OK, 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 command zero, one, two and six, which were the first commands that the chip would see at the start of a firmware update.

So zero was a reset, one was get some version information and two was start sending the SHA-1 hash and the signature. And then command six was the secret one, which dumped any memory I wanted, which was correct. The fact that that existed was quite surprising.

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 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 would change just enough I could guess anyway.

So I could make inferences about where I'd overwritten the stack and I'd 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. So you could potentially use your custom firmware function to re-implement that kind of memory dumping, though, by jumping into that and then dumping everything back out to get the updated firmware version?

Yeah, so that's exactly what I did in the end. 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 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 a 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 and the fly-off 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 like this, and I wasn't really doing it from a security perspective, which is more of a reverse engineering thing, this 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 at 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 firmware, 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 at 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 anything, because they do seem very good about updating these things. Cool. So we got sort of a comment from someone in the channel. I really want to understand firmware and boot, much more in-depth. Looking through more established projects can be somewhat overwhelming.

Should I just grab a Pine phone or Pine Time Antique around, old Thinkpads, what kind of more entry-level paths might 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, learn a lot. There's a lot of tutorials that people have for things like compiling things like Lineage OS, which 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 as 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 probably the most used Cortex-M and ARM embedded chipsets around. There's huge numbers of very cheap development supports 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, access the mouse or whatever, in minutes using some of these tools and just deploy them to the phone. And that's where you would go if you want 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 Hydra or Redara or Ghidra, 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 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. 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 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 a threat model 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. If you really wanted to stop people doing this, which I don't agree with on a moral level, but I would say encrypting 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 DEFCON actually, which is when I was sitting in 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 Samsung S9 is when I really started focusing quite a lot of time away. 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've had 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're getting out.

It's literally just raw code. It's all guesswork. And that's sort of why it takes such a long-winded amount of time compared to some more desktop level projects where you can reverse engineer an application quite a lot more easily, I'd say.

So 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? 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 used 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 a tag.

This is used for like breaking authentication 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 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 that I mentioned in the tool 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's that was the goal. Yes. 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 it from interest.

So I've looked at several different aspects of things like how their bootloaders work, how they have like a 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 realize how much of a can 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 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 chips? That is 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 ARM 64 core, I believe, at the moment. I know there's been quite a lot of research done on Qualcomm in general on their chips. That's 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 no one would bother 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. There's so much to look at and 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. We got some potential questions coming back in. 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 get 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 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 from 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, 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 in the talk and the work back from there, found that it had no

function reference, thought maybe it'd say interrupt and then search for that value, which was then found in a 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 a talk, I think, which is probably bad because I just spoke about them for about three minutes. No, 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 wouldn't normally decompile. Not unless it, well, Gahidra is quite good at this, I've found, because it understands Cortex -M, whereas IDA is quite hands-off when it comes to things like Cortex-M chips. It allows, it tells you to work it out for yourself, essentially, a lot of the time.

Fair enough. Which would you say are other interesting targets, like not complex and wildly used chips? What I would recommend is something that I work with quite heavily, which is 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 the 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 off 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.

Great question. So you often find embedded projects like this using 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'd compiled. They had their own tool. Presumably, they had their own tool change 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. It just wasn't really meant to be on that point.

Often these RTOS have a lot of overhead as well, like they do debug strings, for instance. VxWorks is a table that I think can be compiled out, but is 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, from a security perspective, quite bad. They didn't use an RTOS. It was

just a straight running firmware. They'd put their own function calls and all that sort of thing. Other chipsets I've looked at that are similar or custom often implement their own custom RTOSes for this. But in this case, there 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 Iskuri1. So

that's my username and then one at the end because I didn't get the one without the number first for GitHub, Iskuri. 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 DEF CON safe mode. And have a nice day. Thank you very much, guys.