start	end	text
11570	17470	Okay, so today we've got Christopher Wade presenting on
18350	24050	BeyondRoot custom firmware for embedded mobile chipsets. So thank you for joining us, Christopher,
24050	28770	and I'll let you do any opening remarks, and then we'll go right into the questions.
32080	36400	Excellent. Hello, everyone. Thank you for coming to my talk.
38300	40540	Yeah, that's pretty much all I can say. Thanks very much. It's
41060	41500	definitely...
43400	48860	Could you tell us a little bit about yourself and just like a quick intro summary for your talk?
50360	56000	Yep, so quick introduction. This talk is mainly about custom firmware for embedded mobile chipsets.
56060	60680	This is essentially me hacking chips inside my phone, which aren't the core ARM chip used to
60680	64140	run the thing, in order to make it do different things in the hardware. In particular for this
64140	69060	talk, it's going to be NFC chips. So I reverse-engineer the firmware of an NFC chip,
69060	72060	break the signature checking, and then implement my own firmware onto it.
73920	78220	Excellent. Great. So we have one question already queued up.
78540	82080	So how did Samsung react to the disclosure of vulnerabilities?
83120	87800	Yeah, so Samsung reacted very positively. So I submitted it to their mobile security team
87800	92600	initially, and they accepted it, even though it was technically part of their Samsung
92600	98120	team. So I sent them the disclosure, and they delayed with their interdepartmental
98840	103500	systems or whichever. And initially, because I submitted the Samsung S6 vulnerability,
103500	106580	they said that this wasn't really something they were going to remediate, just because it was out
106580	112440	of scope. The Samsung S6 is no longer supported. But when I submitted the Samsung S9, they happily
112440	115560	took it and started the remediation process, which was pretty good.
116600	121620	And chips that have been manufactured, I believe you said, after April aren't vulnerable to this?
121620	125940	Yes. So what they have done is essentially, while they can't really patch the bootloaders
125940	130100	of existing chips once they've already been manufactured, as outlined in the talk,
130100	135040	what I have done is discussed with them about how they're going to remediate this. And what
135040	139340	they said was they're going to remediate all of the chipsets of the current versions
139340	143760	in the manufacturing plant. So all of the bootloaders can be patched as chips go out
143760	149420	from now onwards. However, all historical chips will still be affected. So that's why I decided
149420	153420	to make a custom firmware for them. They'll still have the vulnerable bootloader.
153420	156540	Yes, exactly. Which is very useful.
156900	161980	So near the end of the talk, there was a problem with a parity bit. Did you ever get that worked
161980	164700	out? Yes, so the parity bit was an interesting
164700	170280	one. What they tended to do in the initial firmware or the firmware reverse engineering
170280	175860	is load all their 8-bit buffers as they should into the 8-bit buffer in the hardware registers.
175860	180220	This is done because that way the hardware itself can pick up the slack with the set
180220	184220	and unset bits, which is done to sort of calculate parity between each set of bytes
184220	189480	that are sent. What I did was find a very specific hardware address and a very specific
189480	193580	bit in that hardware address set, which let me essentially control that parity bit. What
193580	198100	this meant was I set up 9-bit values, so that includes the 8 bits of the byte followed by
198100	202120	the 1-bit parity bit, which need to be encrypted, and that's the start of the process.
202120	207220	I had to sort of bit shift everything around by one on each part, because the buffer was
207220	211300	8 bits, but I had 9 bits of base to shove, so essentially I just had to bit shift that
211300	214460	around, which was a bit strange, but it did work.
215100	223300	Did you get NFC tag cloning working? Yes, so what I ended up doing in the end
223300	228780	was literally being able to read an NFC tag using the standard reader application that
228780	234080	existed, and use my tool to upload binary data through the I2C interface that I had,
234080	239880	so I could set each block of the data of the NFC tag as I wanted it, including the UID,
239880	244000	the write and read bits, etc, all parts that I could upload and download as needed, and
244000	249160	I also hooked into the I2C interface, so that every time some reader wrote to the tag as
249160	253860	well and authenticated it properly, it would then also write that via I2C, so I could modify
253860	259440	the binary file I had, this would mean things like access control systems and things, I
259440	263760	would be able to keep a check of what was going on, so some access control systems had
263760	267480	logs for how many things had been read, and some other imperative information to make
267480	274260	sure that no tags had been cloned or reused, and I basically did that so that I could clone
274260	278040	the tags while also allowing the data to be modified persistently, even if I stopped running
278040	281360	the resource, and this was quite slow in the end.
281920	286080	So do you have any questions?
286100	297540	Yeah, so not on the track yet, but I did notice that your talk was mostly a tutorial on reverse
297540	302060	engineering, and I think it seemed like you were starting out because you were curious
302060	311000	about the NFC firmware and wanted to take a whack at customising it, is that, am I
311000	312280	catching your motive correctly?
312900	317900	Yeah, so that is essentially how I started, what really started this off was I had an
317900	321920	old Samsung S6 that we started with at the start of the talk, which I was essentially
321920	326420	using to just mess around with different custom ROMs on, and one of the things I did was port
326420	330480	Debian to this, so I scraped up all of the Android operating system and shoved the Debian
330480	333860	root file system into place, so instead of having it as a shroof as I outlined in the
333860	337640	talk, it was more of a full operating system on the device.
337640	340800	Now, this afforded quite a lot of functionality, but also meant that things like the screen
340800	341960	didn't work so well.
342220	345380	I quite enjoyed this because I was going to add some sort of hacking tools, modify the
345380	349680	USB interface and things, so that I could use GadgetFS, et cetera, but I thought it
349680	352500	would be interesting to see where I could push things like the NFC side.
352500	357680	So I redeployed LineageOS to the Samsung S6 phone, which is a very standard custom ROM,
358200	361260	and then started looking at the NFC chip, and that's sort of where the project sprung
361260	361940	off from there.
361940	365540	So it started off as more of a standard custom ROM project, then it started off as a standard
365540	369100	reverse engineering project, but because I like reverse engineering, it sort of went
369100	369760	on from there.
369760	371480	It just sort of slid into it.
371480	372600	Yeah, that happens.
374820	377120	So have you looked at any other chips inside of phones?
377120	382500	This seems like a really deep and hyper-specific long chain that you went through to patch
382500	383500	in this functionality.
384040	385580	Um, yes.
385900	390300	Unfortunately, due to responsible disclosure, I can't discuss those at the moment.
390300	391020	Fair enough.
391020	392680	I'm very sorry about that.
392680	396800	So maybe I'll sort of ask around this.
396800	402440	Was this the first one, and you've just been able to successfully, responsibly disclose
402440	403280	this one?
403360	408700	Or what has your experience in the past led you, that brought you to this kind of point?
409780	411560	Yeah, so this is definitely the first one.
412420	416320	Unlike most of us, we have a habit of routing our last phone that we're using, not our current
416320	419340	phone, because walking around with a routed phone is not the best idea.
419640	424220	So I'd had a lot of older phones, and then I'd got a Samsung S6 for a few years, and
424220	426880	then replaced it with a new phone, and just had it lying around.
426880	429540	So the first thing I did was route it, and then start looking at seeing what I've been
429540	430080	doing.
430120	432460	I also looked at a few older phones at the same time.
432460	437600	So for instance, I had a very old Samsung Galaxy Mini, which has FM radio capabilities
437600	439320	based on a Broadcom chipset.
439440	440340	Now, that was very interesting.
440860	444840	Because it didn't seem to have any code signing with some of the binary files on there.
445780	449420	It looked like it wasn't just an FM radio receiver, but also a transceiver.
449420	452900	So I wanted to see if I could push it into doing FM transceiving.
452980	457420	Sadly, that didn't really go anywhere, because quite frankly, working on old Android versions
457420	459280	like that is incredibly tedious.
459300	463140	They don't always use device file appropriately, and they often route their circuitry around
463140	464200	in ways that just...
464200	468160	It doesn't work very well by comparison to more modern phones, where everything's laid
468160	471240	out, everything's documented, everything's open source in really nice ways.
471560	472560	That's super unfortunate.
472560	478370	I do remember some really old phone hacks that they were...
479520	483840	I think they were actually MP3 player hacks that you could turn them into FM transmitters.
485320	487520	Yeah, that would be cool to get your phone to do it too.
489260	492360	Sadly, I'm stuck with a Raspberry Pi with a wire sticking out of one of the pins at
492360	494560	the moment, which is good enough for now.
495240	496260	Fair enough.
503180	507860	Is there any other active projects that you're working on that you can talk about?
508900	511560	Yeah, so I'm still looking at different phone chipsets.
511560	513900	I've been looking around to see what other NFC chips that are used.
513900	517260	There's only a handful of manufacturers, and that's something I'm looking into.
517260	521860	But the big problem there is obviously price point, because phones are expensive things,
521860	523840	and it's not something you want to buy randomly.
523880	527040	The key thing I've been looking at is downloading custom ROMs for random phones that I thought
527040	530600	would be interesting, not just for NFC chips, but other firmware binaries.
530600	535020	Because if you download the ROMs and unpack them, then you can find quite a lot of information
535020	538040	about the hardware that you wouldn't be able to get just from a teardown, for instance.
538060	541800	For instance, if you go in the vendor partition, there's all sorts of firmware blobs for things
541800	543600	like Wi-Fi chipsets, etc.
543640	547740	And that's where it led me to things like... so I've got a Xiaomi Mi Note 3, which is an
547740	548520	old phone.
548700	553040	And while this isn't necessarily a firmware hack, being able to echo a single number into
553040	557580	the sys files and turn that into a monitor mode phone is very powerful.
557780	561500	Like full-on passive monitor mode, no injection, but still full-on monitor mode that works
561500	562500	really effectively.
562500	565000	Things like that is just something I keep looking through and looking through as much
565000	568340	as I can, because it's quite fun to mess around with phones in that way.
568340	569220	That's awesome.
569260	575520	So part of your project, you used... I believe it was called the Unicorn Engine for hardware
575520	576440	emulation.
576600	579980	What level of emulation is actually happening there?
579980	581640	Is it just like the CPU?
581640	584200	How does it handle peripherals and stuff?
584440	585000	Okay, yeah.
585000	587420	So the Unicorn Engine is a really powerful tool.
587420	590100	And I've seen a few talks on this by the people who've actually developed it.
590100	591780	I'm sure it was at Defcon as well.
593360	596640	As it's a library that's purely used for loading into other things.
596640	599160	Now, I always write my stuff in C, so I load it into C.
599940	602680	All it does is emulate the core architecture you want to go for.
602680	604120	So in my case, it was ARM sum.
604260	606560	Then it lets you map out memory mapping as you want.
606560	609640	So in order to write and read memory to start things up.
609640	614840	And then you can hook both operations and reads and writes of memory.
614840	617420	So when you hook into operations, you can make them act in weird ways.
617420	621540	For instance, one of the problems I had with my hardware was it would sometimes hit the
621540	625840	wait for interrupt operation, which wasn't supported by Unicorn.
625840	629060	And I could override that just to a standard NOP because I didn't need to think about it.
629520	633220	But hooking into the memory reads and writes was what was really key for me.
633260	637240	Because I can map out to say there's actually hardware addresses at certain points.
637240	641800	I could then just put an if statement, a switch statement, just saying if it hits this address,
641800	642640	mess with it in this way.
642640	646640	For instance, in the I2C interface, it was when it hits the I2C status buffer,
646640	647940	I want it to return random data.
647940	651220	So it eventually hits the OK status or sometimes the busy status.
651440	656180	And then when it hits the read and writes, I wanted it to read in data that I was writing
656180	659880	to it as if it was the physical chip and then write data back when it was the physical chip,
659880	661660	which is how I got that initial fuzzing working.
661660	663420	So it's really powerful for that.
663420	666540	But it has no integration for actual realistic hardware,
666540	668700	just the processing as it's going along.
668700	671520	So just the core operations, which is really cool.
671520	676520	But you can write basically functions that are at those memory addresses
676520	678560	just to pretend to be that hardware, right?
678560	682220	Yeah, so you can literally set R0, R1, R2, you know, the command.
682420	685140	And then the program counter will say go into this.
685160	686920	And you can also set the address to tell it to finish.
686920	688880	They can stick that at the end of the function.
689020	692100	And that way you'll run through the function, call the functions it needs to,
692100	694560	but also then stop when it's ready.
694600	696620	And you'll then be able to read out memories you want.
696740	699220	So for instance, what I wanted to do before I started up,
699220	701620	part of the project I didn't really mention was I start off
701620	705880	emulating the actual firmware binary that I had rather than the bootloader.
706020	709200	And what I did was load that in and let it run so that I could set up
709200	710580	all the hardware addresses I needed.
710580	713960	So RAM, et cetera, to see how that was laid out, to see if I could see anything.
713960	716360	Because you can let it start and then let it stop
716360	719980	and then dump the memory out as you need to without really any problems.
719980	723860	Oh, cool. That's actually really, really slick.
723900	725640	It's really powerful, yeah.
725640	730260	Yeah. So how do you go about making the jump from these
731260	735300	accessing a particular hardware address to saying,
735300	739440	okay, this is an I2C chip, external peripheral.
739960	742200	How do you make that inference?
742420	743860	Well, it was definitely inference.
743860	746160	I was pretty much guessing when it came down to it.
746640	749600	So what I was doing was when it hit that first...
749600	751000	I'll go step-by-step with what I did,
751000	753020	because it was pretty much as I outlined in the talk.
753020	755340	It hit that first address and would just keep looping and reading
755340	758100	and doing a few other operations before jumping back to the start
758100	759540	where it read that address again.
759680	761720	And I already knew that that was the correct hardware address
761720	765700	because it was at 400000, which is where the hardware addresses are.
766000	768660	So as it was reading, it was literally bit shifting.
768660	773200	What some code can pass to often is shifting values down
773200	775260	to hit a certain bit to check them.
775460	778000	And I thought, okay, so it's probably checking for certain bits
778000	779140	in some sort of order.
779660	781220	And so I just randomized that.
781540	783160	And then it started trying to read in bytes.
783160	784760	I was loading them into a buffer in RAM.
784760	786620	And I could see this in the emulation.
786620	789740	And I thought, what happens if I start writing my code into it?
789740	792000	So I started writing different operations in.
792000	793120	And there was sort of a staggered approach
793120	795920	because I didn't have interrupts, I think.
795920	797560	But for some reason, it wouldn't response right away.
797560	799820	So I gave it a whole list of commands I wanted to run.
799820	801540	And then it had like three of them.
801540	803260	And then it would start pumping out the responses.
803480	805060	So eventually that worked really nicely.
805060	806760	So it was quite cool in the end.
807660	809560	That is really what it looks like.
809860	811600	Yeah, but it's all assumption, essentially.
811600	812280	It's all guessing.
812280	813000	It's all guesswork.
813000	814300	And eventually it gets there.
814480	817280	And I imagine that interacting with those pieces of hardware
817280	821180	might allow you to say, okay, this is clearly a memory buffer
821180	823000	that's being shared with something else.
823000	825860	That kind of thing, just experience, will just help you with that kind of thing.
825980	828020	Yeah, and I sort of stepped through some of the parts of the code.
828020	830280	So I stepped through because there was that infinite loop that started,
830280	831860	which was constantly reading.
831880	833540	And I jumped into there and a few functions in.
833540	836660	And that's where I found the state machine command 0, 1, 2, and 6.
836760	842580	Which were the first commands that the chip would see at the start of a firmware update.
842580	843940	So 0 was a reset.
843940	845780	1 was get some version information.
845780	850440	And 2 was start sending the SHA-1 hash and the signature.
850460	852000	And then command 6 was the secret one,
852000	854520	which dumped any memory I wanted, which was correct.
854520	857900	But the fact that that existed was quite surprising.
860760	862300	Yeah, but I mean, it worked out.
862300	863920	It's like being able to find that.
863960	866260	So if you didn't have that command,
866260	869260	you briefly mentioned about doing that kind of reversing blind.
869260	871380	You already had the previous version.
871380	876040	You were able to use the knowledge you gained from that first stage to attack later on chip.
876340	880300	If you wanted to go about doing something like this blind,
880300	880700	could you?
880700	883260	Would it just be just an enormous amount more effort?
883260	885160	Or is it just not possible?
885580	888380	It probably would have been an enormous amount more effort, yes.
888380	890100	Because I had that bootloader to emulate,
890100	893460	and I could make assumptions about the two size values that made it a lot simpler.
893460	897160	It wasn't the full process, but it was helpful enough.
898180	900220	The blind part was very simple in the end,
900220	904020	because the bootloader had changed just enough that I could guess anyway.
904020	907160	So I could make inferences about where I'd overwritten the stack
907160	908380	and where I'd overwritten the memory,
908380	911520	which would have different kinds of responses over the I2C bus.
911520	913920	Because I could get the size of the stack,
913920	916900	I could overwrite it all with whatever addresses I wanted,
916900	918960	because eventually one of those would be the link register.
919200	922060	And when it jumped in, I literally just would have jumped through them in the same way,
922060	922740	essentially.
922740	926560	But it would have been a lot more difficult to find the initial vulnerability, I think.
927300	928020	Fair enough.
928660	934300	So you could potentially use your custom firmware function
934300	937900	to re-implement that kind of memory dumping, though,
937900	941440	by jumping into that and then dumping everything back out
941440	942920	to get the updated firmware version?
944240	946140	Yes, so that's exactly what I did in the end.
946140	948780	So that was my first port of call when I started making the custom firmware,
948780	952100	was adding arbitrary reads to the core firmware.
952100	953320	Instead of it being in a bootloader,
953320	955620	I made my own custom firmware capable of doing that.
956240	960720	It was a few steps, so I had to essentially find an I2C function
960720	963200	I wanted to mess with that worked via NCI,
963200	966900	and then modify that so I could send NCI responses with whatever I wanted
966900	968300	and override those functions.
968300	970400	So it was a good jumping off point,
970400	974160	and then I could modify my exploit to not load data from random addresses
974160	976660	to start off the exploit, which was a bit scary
976660	980200	when I actually saw what was working in the exploit in the live version.
981540	983440	So we got a question from the channel.
983780	987360	When starting your research, weren't you afraid to find old vulnerabilities
987360	991100	on your chip that were already patched since you started on an old phone?
991360	994400	Yes, so I thought it would have been patched, to be honest.
994800	997520	So I started with the Assumption S6,
997520	1000280	and I wasn't really doing it from a security perspective,
1000280	1002700	which is more of a reverse engineering thing that's fun.
1002840	1004940	But because they told me they weren't going to patch it
1004940	1006440	because it was so old, which was valid,
1006440	1009020	I thought, I don't think anyone's ever bothered
1009020	1012440	looking at something so innocuous as an NFC chip on a phone.
1012620	1016200	So I thought, if I bought a later phone,
1016200	1018480	which I was in the market for at the time anyway,
1018480	1020260	I'd be able to find something just the same,
1020260	1022000	and I did, which was excellent.
1022000	1025380	And it meant that, because there was firmware,
1025380	1027700	there were different chip versions between the two as well,
1027700	1029180	so this is just the latest version,
1029180	1030480	it was likely that all the ones in between
1030480	1032960	were also vulnerable to the same thing.
1032960	1036100	It wasn't just a one-to-one comparison, which was quite cool.
1036100	1037700	Do you know if Samsung took the approach
1037700	1041700	that all those middle versions were likely vulnerable as well,
1041700	1044880	and they're only going to be releasing the updated version at this point?
1045020	1046100	I don't know a huge amount,
1046100	1047900	but I do know which chips are in which phones,
1047900	1050400	so I can assume the ones that are supported by them
1050400	1052520	are going to be updated more than anything,
1052520	1054720	because they do seem very good about updating these things.
1054740	1059540	Cool. So we got sort of a comment from someone in the channel.
1059980	1063080	I really want to understand firmware and boot much more in depth.
1063080	1066140	Looking for the more established projects can be somewhat overwhelming.
1066140	1070460	Should I just grab a Pine phone or Pine Time and tinker around old Thinkpads?
1070460	1073480	What kind of more entry-level paths might you suggest to learn more?
1073520	1074660	Okay, yeah, excellent.
1074660	1076920	So it very much depends on which path you want to go through.
1076920	1080380	If you want to learn into custom ROMs and things on phones
1080380	1082780	and modifying phones in that manner,
1082780	1085900	then yes, something more like a standard Android device,
1085900	1087320	like a Pixel or something,
1087320	1090200	which has the capabilities with custom ROMs and OEM unlocking,
1090200	1091520	is the best port of call.
1091520	1094100	You can mess with the operating system as you want, learn a lot.
1094100	1097360	There's a lot of tutorials that people have for things like compiling,
1097360	1098440	things like Lineage OS,
1100380	1102320	which can be modified in certain ways.
1102320	1106540	For instance, you can unpack the zip files of some of the custom ROMs
1106540	1108880	and then just modify the boot script and things as you want,
1108880	1111360	or add your own things into the system image.
1111360	1112300	You can add these things.
1112300	1115200	That's sort of... it's kind of a big question on that side.
1115200	1117200	If you're looking at learning how to reverse engineer
1117200	1119900	much smaller chips, things like the NFC chip,
1119900	1123220	you should start looking at chipsets like the STM32.
1123680	1130120	These are probably the most used Cortex-M and ARM-embedded chipsets around.
1130120	1133160	There's huge numbers of very cheap development boards for them.
1133160	1135280	And you can write code for them using free tools.
1135280	1137740	There's also tools like the STM32 Cube,
1137740	1140640	which allows you to set specific pins and configurations.
1140640	1142620	You can create your own USB device,
1142620	1145680	access the mouse, whatever, in minutes using some of these tools,
1145680	1147160	and just deploy them to the phone.
1147160	1148860	And that's where you would go if you wanted to start learning
1148860	1150800	about how to develop firmware for these things.
1150800	1151820	To reverse engineer them,
1151820	1153120	all you need to do is take those binaries
1153120	1155020	and look at how they work more than anything.
1155020	1157040	Chuck them in EIDR or RADAR or, you know,
1157040	1160160	Ghidra, whichever one you like, and start looking around them.
1160180	1162600	There's a huge number of really good tutorials about how to do this,
1162600	1165320	but mostly all I can say is just dive in and try things.
1165320	1166700	And if you get frustrated too much,
1166700	1168500	then you're probably going the right way with it.
1173720	1176400	I mean, I don't want to tell you how hard it was
1176400	1178380	to find all the addresses and things in the firmware
1178380	1180380	that I reverse engineered for this project.
1180380	1183120	It took days and days and days for some of them,
1183120	1183900	especially when it came to things
1183900	1187040	like a lot of the functionality was based on interrupts.
1187040	1188680	And I didn't even know which interrupts were where
1188680	1190340	because there's no documentation for this chip
1190340	1192340	and everything is completely custom to Samsung.
1192440	1194020	These are really difficult things to come up with,
1194020	1195980	but you can start adding to your knowledge
1195980	1198040	just by doing the most frustrating things you can.
1198040	1200680	But if you're starting with embedded firmware in that style,
1200680	1202360	start with an STM32 dev board.
1202360	1203360	You can start with a Raspberry Pi
1203360	1204700	and just start looking at bare metal stuff
1204700	1206160	if you have one available.
1206400	1208400	There's all sorts of ways to go into it, really.
1208960	1209780	That's awesome.
1209780	1211760	That's a great and very thorough answer.
1211760	1212820	I appreciate that.
1213620	1215860	Do you believe that Samsung will eventually start
1215860	1218600	using signature verification for downloadable firmware?
1219460	1223480	So the chip did use signature verification in this instance.
1223520	1225040	What they should be adding to that
1225040	1227740	rather than modifying the signature verification
1227740	1229640	is encryption on top of that.
1229640	1232180	So at the moment, you could take the firmware
1232180	1234220	that they've deployed and analyze it in IDA with no problems
1234220	1236420	because there's no encryption whatsoever.
1236420	1239000	Now, different chips from different manufacturers,
1239000	1242760	even NFC chip ones, are encrypted and signed.
1242760	1244160	That means you can't reverse engineer them
1244160	1245380	to find any exploits.
1245380	1247660	You also can't deploy modifications to those firmware.
1247660	1248900	And that's sort of the way they should be going
1248900	1250360	more than anything.
1250900	1253380	Do you think that that's actually a good way
1253380	1255320	making it harder for reverse engineers
1255320	1258060	to inspect the actual firmware?
1258360	1260960	It's kind of a catch-22 on that point, isn't it?
1260960	1262660	I see where you're coming from.
1262660	1264980	The problem is, I think,
1264980	1266500	especially with a threat model such as this
1266500	1269340	where the only real reason
1269340	1270440	someone would reverse engineer this
1270440	1272180	is to make a cool NFC hacking tool
1272180	1274420	rather than to damage other people,
1274420	1276880	is that if you really wanted to stop people doing this,
1276880	1278920	which I don't agree with on a moral level,
1278920	1280680	but I would say encrypting it
1280680	1281660	and preventing them from doing that
1281660	1282560	is the best way to go.
1282560	1283860	Because then what they'll have to go for
1283860	1287320	is both guessing how the bootloader works
1287320	1289340	and also guessing what things
1289340	1291780	like secret vendor NCI functions are available,
1291780	1294080	which aren't necessarily all vulnerable to things,
1294080	1296900	but are available and people can brute force through them.
1299100	1301300	How much time did you spend on this project?
1302060	1303220	A lot.
1304240	1307180	I feel like my boss has probably asked me that in the chat.
1307460	1310080	So the project started off
1310640	1312660	at the end of the last DEF CON, actually,
1312660	1315120	which is when I was sitting in my hotel room
1315120	1316680	looking at the original firmware.
1316740	1318980	And then I just did it in little bits over time more than anything.
1318980	1320640	It wasn't a solid amount of time.
1320640	1322660	When it got to the point where I had a signature bypass
1322660	1323520	on the Samsung S9
1323520	1326200	is when I really started focusing quite a lot of time away.
1326200	1328120	So it took me about three weeks,
1328120	1329540	not every day, but three weeks in total,
1329540	1330840	to go through everything
1330840	1333920	and start implementing every single part of that firmware.
1333920	1335320	Because I was having to look through the entirety
1335320	1338020	of the firmware image,
1338020	1340000	which had no documentation whatsoever,
1340000	1342360	nothing to work with, no strings at all,
1342360	1344220	no function references that you'd get in that.
1344220	1345540	It's literally just raw code.
1345540	1347000	It's all guesswork.
1347180	1348800	And that's sort of why it takes
1348800	1349820	such a long-winded amount of time
1349820	1353780	compared to some more desktop-level projects
1353780	1355100	where you can reverse engineer,
1355100	1358260	say, an application quite a lot more easily, I'd say.
1361120	1363500	So other than the challenge of doing the reverse engineering
1363500	1364660	and figuring things out,
1364660	1367560	did you have a particular use case for the end product?
1367660	1371520	Like a sneaky version of the Proxmark or something?
1371560	1373920	A sneaky version of the Proxmark is exactly right.
1373920	1375540	Yes, that's very true.
1375540	1377840	I do have Proxmarks and I really like them.
1377840	1378980	So I've got one right next to me,
1378980	1380200	which I actually use for the reverse engineering
1380200	1382660	of this project really heavily for the NFC side.
1382760	1387280	Because it's so lax on things like the bit verification,
1387280	1388560	the parity checking,
1388560	1389880	it meant that I could build up the project
1389880	1390840	really simply from that.
1390840	1392500	Now, essentially, yes,
1392500	1394140	I was trying to make a fakie Proxmark.
1394140	1397300	And part of that was passive NFC sniffing.
1397300	1400780	So one of the tools on a Proxmark is this thing
1400780	1405500	where you can sniff high-frequency communication
1405500	1407120	between the reader and a tag.
1407120	1409700	This is used for breaking authentication and things.
1409700	1410420	I wanted to add that in
1410420	1411660	so you could go up someone with a phone
1412080	1413140	and stick it over them
1413140	1414880	as they're trying to open a door or something by accident
1414880	1416900	and pick up the communication.
1417420	1419580	Now, that feature is almost done,
1419580	1420640	but it's quite complicated now
1420640	1423340	because you have to switch between hardware registers.
1423340	1424880	Now, there's one block of hardware registers
1424880	1425860	that I mentioned in the talk,
1425860	1428060	and that handles every single aspect of NFC.
1428060	1428840	So that's the reader part
1428840	1431420	and the acting like a tag part.
1431420	1433080	So you have to switch between these constantly
1433080	1433860	in order to get that data.
1433860	1435220	And it sort of works,
1435220	1437340	but until I've got that full functionality in place,
1437340	1439260	it's really not replacement for the Proxmark.
1440000	1441780	That was the goal, yes.
1442020	1444600	Yes. That's really sneaky.
1444600	1445700	I really like it.
1448960	1452780	Why do you think so little has been done for...
1452780	1455080	Why do you think so little has been reverse-engineered
1455080	1457360	from a Qualcomm baseband?
1457360	1458480	Is it more challenging?
1459420	1460160	I'd say yes.
1460160	1462160	I've looked at some aspects of Qualcomm as well,
1462160	1464380	just from interest.
1464800	1467280	I've looked at several different aspects of things,
1467280	1468300	like how their bootloaders work,
1468300	1470860	how they have the Qualcomm emergency download mode
1470860	1472240	and all these sorts of features.
1472240	1474640	They've also got the baseband, which is highly complex.
1474800	1476680	The problem is you start looking into them
1476680	1479100	and then you realize how much of a can of worms
1479100	1480760	you've opened with reverse engineering.
1480760	1483360	This project, by comparison to something like a Qualcomm chip,
1483900	1485440	is very simplistic.
1485440	1488900	It's one very small 12K firmware to look through.
1488900	1490300	Whereas when you get to the Qualcomm baseband,
1490300	1492040	which is going to be hugely complex,
1492040	1493040	it's just a huge project.
1493040	1495660	It's better suited to a multi-person team
1495660	1497320	rather than just me on my own.
1497540	1500960	Is it largely the size of the firmware on Qualcomm chips
1500960	1503140	that is the limiting factor?
1505100	1508460	Is the Snapdragon still a natural ARM core
1508460	1510960	or is it something Qualcomm specific?
1511080	1513300	It's an ARM64 core, I believe, at the moment.
1515660	1517720	I know there's been quite a lot of research
1517720	1519360	on Qualcomm in general on their chipsets
1519360	1521340	because it is the focus of the phone.
1521340	1525880	That's why I chose a chipset that was a side aspect of a phone
1525880	1527980	because I thought no one would bother to look at them.
1527980	1529420	And they haven't with this one,
1529420	1530800	so I feel like the vulnerability I found
1530800	1532220	would probably be found quite quickly.
1532440	1535820	But yes, when it comes to the Qualcomm side of things,
1535820	1538420	it's just such a hugely complex chipset.
1538420	1539440	There's so much to look at
1539440	1541960	and so many potentials for bugs in different places
1541960	1544720	that, like any chipset of that complexity,
1544720	1546580	it would take a team and quite a lot of time
1546580	1547960	to find something, I think.
1547960	1549620	Yeah, fair enough.
1551800	1555680	It looks like we got some potential questions coming back in.
1556480	1561220	Yeah, is there any part of the talk that you omitted
1561220	1563720	because you just ran out of time?
1564820	1566240	Yes, quite a lot.
1566240	1568260	So I wanted to get into more details
1568260	1569600	about the reverse engineering side,
1569600	1571800	which was, considering it was only half the talk,
1571800	1574160	was the most time-consuming part of the topic.
1574180	1576620	But I found that it was quite dull to talk about
1576620	1578500	because it's literally me going,
1578500	1579860	oh, I thought this might be this.
1579860	1580920	I thought this might be this.
1580920	1583100	For instance, I mentioned interrupts earlier
1583100	1586300	and how these work on Cortex-M chips.
1586300	1588260	There's a big table at the start of the firmware,
1588260	1589640	which includes the reset vector,
1589640	1591100	which is where the chip starts from,
1591100	1592140	the start of the stack.
1592140	1593060	And then it has a bunch of interrupts
1593060	1594380	for things like the hardware and stuff.
1594380	1595960	Now, on top of this, it also has interrupts
1595960	1598540	for more complex hardware, like the NFC.
1598660	1602040	So one thing was all the NFC tag mode stuff
1602040	1603760	ran off one single interrupt.
1603760	1605520	So it hit that interrupt and would jump to some code.
1605520	1608340	That meant the code wasn't directly referenced by anything
1608340	1610060	and actually didn't disassemble
1610060	1611900	when I first looked at the firmware.
1612160	1615720	What this meant was what I started off doing
1615720	1617460	was overriding that interrupt in the first place,
1617460	1618680	but I had to know where it was.
1618740	1622780	So I found the select function that I mentioned in the talk
1622780	1623840	and then went back from there,
1623840	1625440	found that it had no function reference,
1625440	1626880	thought maybe it's an interrupt,
1626880	1628340	and then searched that value,
1628340	1630300	which was then found in a table, things like that.
1630300	1631660	These are things that are very valuable
1631660	1633500	from a reverse engineering perspective,
1633500	1636020	but they're very boring to talk about in a talk, I think,
1636020	1636640	which is probably bad
1636640	1638740	because I just spoke about them for about three minutes.
1638760	1640100	No, no, no, no, it's fine.
1640100	1641640	We've got time and people are...
1641640	1642660	Like, I'm interested.
1642660	1645420	I didn't know that things pointed exclusively
1645420	1648600	by the interrupt table wouldn't normally decompile.
1649460	1650320	Not unless it...
1650320	1652360	Well, Kahidra is quite good at this, I've found,
1652360	1654100	because it understands Cortex-M,
1654100	1656100	whereas Ida sort of is quite hands-off
1656100	1658520	when it comes to things like Cortex-M chips.
1658520	1660760	It allows you to work it out for yourself, essentially,
1660880	1661700	a lot of the time.
1661700	1663060	Fair enough.
1663400	1666540	Which would you say are other interesting targets,
1666540	1669220	like not-complex-and-wildly-used chips?
1670880	1672340	What I would recommend is something
1672340	1673700	that I work with quite heavily,
1673700	1677100	which is embedded IoT chips,
1677100	1680240	which are not custom chipsets in the first place.
1680240	1682920	They're usually STM cores or EFM cores
1682920	1684060	and these sort of things.
1684260	1685440	Why these are interesting
1685440	1687280	is they're a good jumping-off point to learn these things
1687280	1688400	because you're not guessing,
1688400	1690040	you've got documentation in place.
1690040	1692500	But also people implement bootloaders and things,
1692500	1695180	which you can then try and break.
1695180	1697880	Now, I did a talk at 44Con a while ago,
1697880	1699460	which is about breaking one of these bootloaders
1699460	1702800	by breaking the encryption mechanisms on the firmware update
1702800	1705040	by dumping RAM off an STM32 chip
1705040	1706400	as it was doing the firmware update.
1706400	1708640	Things like this are things you shouldn't start looking at
1708640	1711220	because there's millions of these IoT devices out there
1711220	1712800	with all sorts of different chipsets,
1712800	1714200	and they're the really fun targets.
1714200	1716380	When it comes to custom chips like this,
1716380	1718920	you're really not going to find much information online about them
1718920	1720660	just because they're hidden away.
1720660	1721860	There's about two links
1721860	1724020	if you search for some of these Samsung chips online,
1724020	1727120	apart from their accreditations from the NFC forum.
1727240	1728700	So, finding these chips in the first place
1728700	1729800	is probably your greatest goal
1729800	1731720	when you're starting off something like this,
1731720	1732720	more than anything.
1733660	1736560	Cool. And someone wants to know
1736560	1738920	if the firmware was based on an RTOS
1738920	1740520	or more along those lines,
1740520	1744460	which is like a standard raw microcontroller target.
1744620	1745840	Yep, great question.
1745840	1748800	So, you often find embedded projects like this
1748800	1751560	using RTOS like VxWorks or FreeRTOS
1751560	1753580	or Ecos and these sorts of things.
1753740	1755360	Now, they weren't
1755360	1758120	because it was literally a straight firmware
1758120	1758860	that they had compiled.
1758860	1759620	They had their own tool.
1759800	1762080	Presumably, they had their own tool chains at Samsung.
1762080	1763120	They compiled it up.
1763120	1768120	They had to have everything sorted as they wanted to
1768960	1770220	and laid out as they wanted to
1770220	1773600	because they had their firmware as they wanted.
1773600	1775180	And RTOSs are usually built for certain chipsets
1775180	1778240	or certain families of chipsets or certain styles.
1778240	1780880	It just wasn't really meant to be on that point.
1780880	1782860	Often, these RTOSs have a lot of overhead as well,
1782860	1784520	like they include debug strings, for instance.
1784940	1786920	VxWorks are the table that's, I think,
1786920	1787720	can be compiled out,
1787720	1789400	but it's at the end of pretty much all their firmware,
1789400	1791180	which includes all the function names,
1791180	1792180	which you can then reference back
1792180	1793620	to all the functions in the firmware,
1793620	1795280	which saves you a lot of time reverse engineering,
1795280	1798880	but it's also, from a security perspective, quite bad.
1799300	1800280	It didn't use an RTOS.
1800280	1801640	It was just a straight running firmware.
1801640	1802800	They'd put their own function calls in
1802800	1803800	and all that sort of thing.
1804380	1806580	Other chipsets I've looked at that are similar or custom
1806580	1809280	often implement their own custom RTOSs for this.
1809280	1810480	But in this case, there was none used.
1810480	1811940	It was literally just running as it needed to
1811940	1814560	and relying on interrupts more than threads.
1816280	1818580	Awesome. That was a great answer, by the way.
1818580	1819340	Thank you.
1821960	1825300	Well, it looks like we are running out of questions
1825300	1827900	and we're just about the end of our time anyways.
1828400	1831260	Is there any additional links you want to share
1831260	1833100	or code or anything like that
1833100	1835860	that you want to get out there?
1835860	1840200	Yeah, so if we're doing links and that sort of thing,
1840200	1843560	you can follow me at Twitter at Iscuri1.
1843560	1846000	So that's my username and then one at the end
1846000	1848600	because I didn't get the one without the number first.
1849020	1851420	For GitHub, it's just Iscuri.
1851460	1853940	And I should be putting out a blog in the next couple of days
1854560	1855780	outlining all of these details
1855780	1858000	as well as linking to the YouTube video of this
1858000	1861460	at pentestpartners.com, which is my company website.
1861460	1863080	So definitely feel free to have a look
1863080	1865340	if you want the really nitty-gritty technical details.
1865860	1869480	Awesome. Well, thank you so much for joining us for this QA session.
1870240	1871460	It's been great talking to you.
1871460	1874400	Thank you for providing content to our virtual DEF CON safe mode
1875740	1877220	and have a nice day.
1877260	1878720	You too. Thank you very much, guys.