[00:00.000 --> 00:06.820] I'm just here to destroy. So, it's definitely a learning curve for me, where I'm just used to [00:06.820 --> 00:11.540] breaking the thing down, just to break it down, versus breaking it down to actually get some [00:11.540 --> 00:17.480] value out of it and turn it into something cool. So, yeah, I really appreciate all the support and [00:17.480 --> 00:24.020] all the help so far. It's been a great journey. Outstanding, outstanding. So, we're getting close [00:24.570 --> 00:33.680] kind of to the start point, just a minute or two out. Again, for those joining in the actual [00:35.780 --> 00:43.920] Zoom webinar, there is a button down there where you can actually post questions. I encourage you [00:43.920 --> 00:51.660] to please do so. The goal is, is we will try to answer any questions that come up. [00:51.660 --> 00:58.340] If we have the answer. U-Boot's kind of an amazing topic, and none of us claim to be, [00:58.340 --> 01:03.900] know possibly everything out there. But we'll do our best to be able to give you some good [01:03.900 --> 01:10.640] feedback on your questions. Also, after this is all over, I'll be jumping over to Discord. I think [01:10.640 --> 01:17.920] Garrett will be there also in the IoT Village Discord in the speaker area. So, if you have any [01:17.920 --> 01:27.360] follow-up questions after that, please reach out to Garrett or me or Jonathan, and we'd be more [01:27.360 --> 01:35.100] than glad to help you out. So, we're kind of at the go point. So, I'm going to turn this all over [01:35.100 --> 01:43.900] to Garrett to go ahead and get started. So, it's all yours, Garrett. All right, right on. Well, [01:43.900 --> 01:49.920] appreciate everyone taking some time out on Saturday. I know that normally we're in Vegas [01:49.920 --> 01:54.740] right now. So, it would be no harm and no foul to be taking time out on a Saturday. But appreciate [01:54.740 --> 02:03.600] y'all, you know, taking some time and tuning in today. So, without further ado, let's get this [02:03.600 --> 02:12.200] party started. So, you should be able to see my screen. We're looking at the U-Boot DC28 IoT [02:12.200 --> 02:20.100] Village is what we're going to be going over today. So, we got a couple agenda items to go [02:20.100 --> 02:24.580] over real quick. You know, what is U-Boot? First off, we're going to get that out of the way. [02:24.720 --> 02:31.040] Then we're going to go into pin glitching, a Philips Hue device, and then potentially getting [02:31.040 --> 02:36.660] root on that machine. And then we're going to switch gears a little bit and go over some common [02:36.660 --> 02:43.680] problems with Daryl Hyland. And it's common problems related to U-Boot and how U-Boot can [02:43.680 --> 02:51.040] solve them. Then we're going to be rooting a Luma Wi-Fi access point. It's like a mesh Wi-Fi [02:51.040 --> 02:59.980] device utilizing TFTP. And then following that, we're getting faded. So, that's the agenda for [02:59.980 --> 03:10.220] the day. And without further ado, let's get this party rolling. So, what is U-Boot? So, [03:10.220 --> 03:16.660] U-Boot is basically a universal bootloader. It's loaded by the system's ROM or read-only [03:17.640 --> 03:24.200] memory or BIOS. And for many one of these supported devices like, you know, SD cards, [03:24.200 --> 03:33.260] Flash, you know, using SPI or NAND Flash. And basically, it runs a command line interface [03:33.260 --> 03:40.840] over a serial port. And, you know, people like us can load and boot a kernel, possibly changing any [03:40.840 --> 03:45.160] of the parameters in there, you know, from the default to make it do what we want to do. Kind [03:45.160 --> 03:51.080] of take over and give it our own instructions versus something that comes from the manufacturer. [03:51.080 --> 03:59.120] You're also able to read device information, read and write Flash memory, you know, download files. [04:00.120 --> 04:07.720] There's a lot of different things that you can do with this. And, you know, basically, [04:07.720 --> 04:15.300] you can choose the memory locations of the kernel and other boot information and explicitly, [04:15.300 --> 04:19.300] you know, tell it, hey, I want to look at this destination, and I'm going to copy this [04:19.300 --> 04:26.700] information. So, it's really good at extracting data and pulling that out for further analysis, [04:26.700 --> 04:33.220] you know, outside of that U-boot connection. So, it's loaded from Flash memory. It's often [04:33.220 --> 04:39.760] accessible over a serial connection. And that's what we've used today is we're using a Chakra [04:41.320 --> 04:47.680] utilizing UART to connect to these devices. It also comes with a limited set of commands. So, [04:47.680 --> 04:55.800] several commands that we're going to be going over that come with U-boot. So, moving on. [04:57.900 --> 05:03.700] So, ping glitch on the Philips Hue. So, that's what we're going to be doing first. I'm going [05:03.700 --> 05:09.620] to get out of these slides. Boring, right? Let's get out of here. So, we're going to go up to [05:10.540 --> 05:14.760] my other screen over here. And just to show you some of the devices [05:15.540 --> 05:20.220] we're working with, we got the I'm looking all around me. It's right in front of me. [05:20.920 --> 05:26.460] The Philips Hue. It's basically it's been stripped down. You know, I can see the underlying [05:27.660 --> 05:33.760] form factor here. But, you know, this thing is to connect your lights in your house. So, [05:33.760 --> 05:37.440] if you wanted to, you know, have a bunch of different colored lights and then control [05:37.440 --> 05:41.300] them from your phone, you'd buy one of these devices. So, you can imagine a lot of people [05:41.300 --> 05:46.000] have these in their houses. I think you can connect up to, like, 50 light bulbs with this [05:46.000 --> 05:52.460] thing. And then we have the Luma, which is looks like a little Wi-Fi access point or something [05:52.460 --> 05:58.240] like that. But it's exactly what it is. It's a mesh Wi-Fi access point. It's got Ethernet on board. [05:58.240 --> 06:03.040] It's got a USB. It's got a bunch of other stuff in there you can't really see because [06:03.040 --> 06:08.140] camera's not very clear. But that's what we're going to be breaking down today. [06:08.140 --> 06:13.420] So, let me get my other situation going on here. [06:15.800 --> 06:20.340] And first off, got to set this up. So, bear with me here. [06:21.880 --> 06:25.720] And if you already have questions, you know, don't hesitate. Throw them out there while I get this [06:25.720 --> 06:37.540] thing set up here. Okay, that's in there. Perfect. So, just get some wires out of the way. I should [06:37.540 --> 06:43.860] remember that choice from last time. All good. So, just to break down what is on this now. [06:44.220 --> 06:52.000] So, we have the UART connection over here to my Shikra using ground over here, receive and [06:52.000 --> 06:58.560] transmit over here. So, we're connected to some headers that are on this motherboard. Then we have [06:58.560 --> 07:06.160] another set of headers over here that's set up for my ground out wire. So, I have a wire that has a [07:06.800 --> 07:12.780] paper clip shoved in the end of it that we may be using to glitch this thing out. So, that's a little [07:12.780 --> 07:19.240] bit about what's on this thing. You also have the two flash chips that we're going to be looking at. [07:19.240 --> 07:25.580] This one down here and this other rectangular guy right here. So, those are the two chips that are [07:25.580 --> 07:34.120] communicating that we're going to be disrupting. So, on the left-hand side, I have a terminal [07:34.120 --> 07:40.880] called... software called Cool Terminal. And it's free. You can download it. It's pretty [07:40.880 --> 07:44.800] versatile on Mac from, you know, the few times that I've been using it here. And [07:45.520 --> 07:50.280] so far, so good. You can actually see when it's transmitting and receiving. You can see when it's [07:50.280 --> 07:57.280] connected. A lot of good detail here. So, I'm going to disconnect and I'm going to clear the data. And [07:57.280 --> 08:01.600] I'm also going to look at these options. So, there has been some things that we did prior to this [08:01.600 --> 08:08.080] call to kind of set this up for success. So, I did change the port to my USB serial because we are [08:08.080 --> 08:18.080] using Ashikra. I did change the baud rate to 115200. And I also changed some of the terminal [08:18.080 --> 08:22.960] settings so that we can actually interact with this terminal and not pull our hair out because [08:22.960 --> 08:28.000] you can't backspace, you can't delete, and things start getting crazy. You know, if I can't go [08:28.000 --> 08:34.620] backwards, then how can we go forwards? So, a few of the options I just wanted to highlight. [08:35.600 --> 08:41.000] So, now that that's all said and done, let's get some power to this thing. So, [08:42.180 --> 08:46.760] you can't see it, but I have a power strip with my, [08:46.760 --> 08:52.700] controlled by my foot over here. So, let me just get power to this real quick. [08:54.960 --> 09:02.430] Okay, so we got power there. Got to take my shoe off because I can't do it with my shoe. I totally [09:02.430 --> 09:08.250] forgot I have to use my toe. So, all good. We're going to connect to this thing once we get some [09:08.250 --> 09:17.250] power on it. And we're in. So, this is just the normal boot up of this device. We're just looking [09:17.250 --> 09:24.750] at it from a terminal perspective. And with this, we can already get some good information, [09:24.750 --> 09:29.750] good value, because we all know when things boot up, there's a lot of information that's kind of [09:29.750 --> 09:35.710] sprayed out there. And sometimes it's machine communication, sometimes it's detailed information [09:35.710 --> 09:43.270] that we can actually use and take back and, you know, learn more about this system. So, you know, [09:43.270 --> 09:47.950] as it boots up, I think it takes about 32 seconds. So, we're almost there. This is a seconds [09:47.950 --> 09:56.730] timer on the left-hand side, if that wasn't clear. So, once we get to the login, I think it's... [09:57.710 --> 10:03.850] So, we're here. So, here's the login prompt. I don't know the password. I tried to look it up [10:03.850 --> 10:15.190] and I didn't find it. Let's see. Roots admin. Just try one. All right. So, it's not working. [10:15.210 --> 10:22.330] Okay. So, we cannot log in at this stage. So, let's take it to the motherboard, right? So, [10:22.330 --> 10:28.250] I'm going to clear this out. Okay. So, we're going to start fresh. I'm going to turn the power on [10:28.250 --> 10:38.930] this guy. My trusty index toe. There it is. So, I'm going to clear it. And let me get my wire ready. [10:39.890 --> 10:45.510] Hopefully get this on the first shot here. So, clear the data. We're connected. [10:47.490 --> 10:56.470] Power is on. And that's the pin. Oh, I'm shaking. Oh, there it is. Perfect. [10:56.470 --> 11:03.630] So, we got the command line. So, if you didn't see it, it was pretty quick. But there is a pin [11:03.630 --> 11:12.130] that I just lightly touched and pressed against this little paper clip thing right in there. So, [11:12.130 --> 11:18.730] if I can keep my hand steady, it's right around there. So, that is what got us to this point. [11:18.750 --> 11:26.330] And what can we do here? So, a few things. We can just ask for help. I mean, where are we? Help me. [11:26.810 --> 11:34.090] So, we get a lot of different commands. You know, there's boot commands. There's [11:34.090 --> 11:41.650] echo commands. We can echo arguments to the console. We can loop, infinite loop on an address [11:41.650 --> 11:47.630] range. We can ping. I think there's a ping option in here. Yeah, ping. So, we can even try to [11:47.630 --> 11:53.790] connect to other network assets, you know, that may be able to communicate to this device if we [11:53.790 --> 12:00.890] want to. We can print the environment variables. We can set the environment variables, save the [12:00.890 --> 12:07.510] environment variables. So, we have a lot of options here. We can even boot, TFTP boot if we wanted to. [12:07.770 --> 12:13.750] So, a lot of different things we can see at this point. So, we're just going to print [12:13.750 --> 12:20.210] the environment variables and see what else is in here. So, these environment variables [12:21.090 --> 12:28.010] are somewhat of the command and control area of this device. So, what we change in here does affect [12:28.010 --> 12:35.630] the entire system and the device. So, you know, we can see the baud rate there is set to 115200, [12:35.630 --> 12:41.410] which is how we're able to communicate. We see some more flash boot up details with the kernel. [12:42.090 --> 12:49.550] We also see some... what else is in here? We got some version information, [12:50.630 --> 12:55.490] production information. Oh, we got an IP address. So, we got some IP information. We got a server [12:55.490 --> 13:01.290] IP information. A lot of information in here. Boot delay. Oh, that looks good. [13:01.810 --> 13:07.570] Oh, some security thing with a hash. That's probably something. Let's see. So, I'm gonna [13:07.570 --> 13:12.870] just... so, we don't have to do that ping glitch again. I'm just gonna set the boot delay right now [13:12.870 --> 13:18.430] because I don't know about you, but my head got shaky hands and I don't want to have to do that [13:18.430 --> 13:21.850] every single time I reboot this thing. So, we're gonna set the environment variable [13:22.510 --> 13:27.650] for boot delay to five seconds just to make sure that that held. We're gonna check it again [13:28.970 --> 13:33.790] and it's there. So, we got five seconds on that boot delay. We have to save it. [13:33.790 --> 13:37.770] Otherwise, it just goes away. So, we're gonna save this. [13:39.290 --> 13:44.070] And that's all the jibber-jabber of saving that environment. Let's just print it one more time [13:44.070 --> 13:54.680] for safekeeping. And boot delay is five. So, we are there. So, I'm just gonna reset. [13:55.820 --> 14:00.400] Let this thing boot up again, except this time we should see a boot delay. [14:02.020 --> 14:10.920] Ah, there it is. So, I am going to interrupt. Rude, right? So, now that we're back in, [14:10.920 --> 14:15.280] what else can we do with this thing? So, let's take a look around back in those environment [14:15.280 --> 14:21.820] variables. And the one that kind of jumped out to me was the security and this weird hash [14:21.820 --> 14:28.700] following it. 1984, maybe there's some type of underlying message in here, but the security [14:28.700 --> 14:34.520] is something we can mess with. So, let's just set the environment of security [14:36.080 --> 14:43.240] to nothing. And nothing can be just two single ticks. Okay. So, if I save that or set that, [14:43.240 --> 14:54.160] let's check it. Ah, security equals nothing. Perfect. So, we do need to make sure we save this, [14:54.160 --> 14:58.690] save environment. No matter what, you always have to save. So, make sure that that's [14:59.050 --> 15:07.190] a, you know, nailed down. And we'll just try resetting. See if that did anything for us. So, [15:07.190 --> 15:13.550] essentially, what the manufacturer did with this is they hard-coded the password [15:14.210 --> 15:22.270] into the device. Not a good idea, in my opinion. But that's what they did. And that's why we're [15:22.270 --> 15:27.930] able to mess with it right now. So, we did let it go past the boot delay because we want to see [15:27.930 --> 15:33.130] what happens when it actually boots up now. Because before, we got hit with a login prompt. [15:33.310 --> 15:39.050] And I didn't have the password. So, we couldn't get anywhere with that. So, as this thing kind [15:39.050 --> 15:46.330] of boots up, same kind of song and dance with the boot up information. You know, it's writing, [15:46.330 --> 15:51.270] it's opening, it's loading, it's doing all these things. And any of those environments that we've [15:51.270 --> 15:59.290] changed may affect, you know, this time right now. So, if we just wait a few more seconds, [15:59.290 --> 16:09.290] the magic of television. And we are root. So, just by eliminating that environment variable security, [16:09.290 --> 16:16.310] it actually cleared out the password. And that was actually the password in a hash. So, removing it [16:16.310 --> 16:22.350] gave us root access. So, right on. High fives, air fives, you know, because the timing. But [16:23.030 --> 16:29.190] air fives all around. We got this thing. So, what can we do now? Well, lots of things. [16:29.410 --> 16:36.170] We can start looking at the mounted drives. We can dig into the root file system. We can look [16:36.170 --> 16:42.630] at the kernel. A bunch of different root drives in here. The root file system data drive. Maybe [16:42.630 --> 16:50.910] there's some good detail in there. You know, we're clearly at the helm here. We clearly have [16:50.910 --> 16:57.570] the reins of this device now. You know, we can look at other information on this thing and see [16:57.570 --> 17:03.750] if there's more details that we can pull out of it. More user details. Maybe some hashes. Who knows? [17:04.310 --> 17:14.470] But we are in like Flynn here. So, any questions on that so far? [17:15.450 --> 17:19.650] Hey, Garrett. Yeah, looks like we have a couple questions here cropping up. So, [17:19.650 --> 17:24.950] Strikeout looks like he's trying to do possibly some U-boot bypass through glitching on a wise [17:24.950 --> 17:30.190] came out door. And this individual is asking where did you actually put the paperclip out on the chip? [17:30.190 --> 17:31.610] A data line? [17:33.990 --> 17:40.410] Yes. So, that is a great question. It is a data line. And it's in between these two [17:41.030 --> 17:47.750] flash chips on the... I don't know if I can get a better view of this thing. But [17:49.210 --> 17:52.990] that's looking terrible. So, I can't... I don't have a micro... [17:54.870 --> 17:58.330] I don't have a magnifier to get you a better view of this. But [17:58.330 --> 18:04.930] basically, there is a pin in between the two chips that is sending data. [18:06.470 --> 18:13.670] It's basically this pin right here. It's a little silver flat pin there. And if you look close on [18:13.670 --> 18:19.290] the motherboard, you can see the tracks going between those chips. You can kind of see it, [18:19.290 --> 18:26.660] but now it's all blurry, of course. Yeah, to kind of add to that, this is [18:26.660 --> 18:33.960] real quick. Often, one of the best things to do is once you've identified the flash chips [18:33.960 --> 18:40.600] that you're going to attempt this on, is to track down the data sheets on those. [18:40.600 --> 18:47.000] And from the data sheets, in this particular case, I traced out the data zero line. [18:47.680 --> 18:55.620] So, between those two chips, this particular glitch is a little easier timing-wise because [18:56.320 --> 19:04.560] the smaller chip that's toward the bottom actually has U-boot on it. The other chip [19:04.560 --> 19:11.440] has the kernel on it. So, the goal is to find the data line for the chip containing a kernel [19:12.040 --> 19:19.920] and interrupt that by taking it to ground. And the attempt there is U-boot's loaded, [19:19.920 --> 19:24.280] and before it has a chance to actually load the kernel or call the kernel, [19:24.280 --> 19:30.460] you literally take one of those data lines to ground, causing it to [19:30.460 --> 19:35.540] fail to read it, as Garrett was talking about and as he showed there. [19:42.970 --> 19:47.270] One other question here, Garrett, that is cropping up. Individual asks, [19:47.270 --> 19:53.530] what type of device are you using to interact with the device here via UART? [19:53.530 --> 19:59.310] Are you using something like a Shikra? Yeah, let me show you. I can show you what [19:59.310 --> 20:09.570] that is here. We got one right here to show you. So, let me kill out this thing real quick. [20:12.450 --> 20:17.710] So, we're going to disconnect and pull this thing right out of my laptop for you. [20:21.300 --> 20:28.920] Hold power. All right. So, to give you a better idea of what this thing is, it's basically just [20:29.060 --> 20:36.960] a little USB with a chip attached to it with several different header connections on it. [20:37.300 --> 20:43.960] It comes with a data sheet that kind of breaks down what these connectors are, but that's literally [20:43.960 --> 20:49.980] all it is. It has three cables. I don't know where my camera is. It's got three cables, one for ground, [20:49.980 --> 20:56.720] one for receive and transmit. So, that's how I'm connected directly to this device. [20:56.720 --> 21:05.780] So, hopefully that helps. But you can pick these things up off the internet. I think they're [21:06.980 --> 21:12.780] 30 or 40 bucks. I can't remember how much they cost, but they're doable. [21:13.740 --> 21:15.760] And there's some other devices out there like [21:18.440 --> 21:23.760] Pirate. There's one called, I think, UART Pirate or something like that, or Pirate Bay. I can't [21:23.760 --> 21:28.580] remember what the name of it is, but there's several tools out there that do the same, [21:28.580 --> 21:32.100] essentially the same thing. This is just the one that we use today. [21:34.600 --> 21:38.520] Cool. That's, I think, the last of the cute questions that we have here. Bus [21:38.520 --> 21:42.200] Pirate, I think, was the word you're looking for. That's what it was, Bus Pirate. [21:43.860 --> 21:48.380] Oh, man. Yep. I knew it was something to do with the pirates. Pirate would be pretty good too, [21:48.380 --> 21:56.380] I like the ring to none. Right on. Cool. Well, let me, if that's all the questions, [21:56.380 --> 22:05.220] let me just get back to the slides here and move on. So, now we're going to switch gears a little [22:05.220 --> 22:13.420] bit. We're going to be going over some common problems with embedded devices and then using [22:13.420 --> 22:18.720] U-boot to solve them. So, I'm going to switch gears and pass it over to my colleague, Darryl [22:18.720 --> 22:27.220] Hyland, and take it away from there. Let me just stop my share. Thanks, Garrett. Let me go ahead [22:27.220 --> 22:38.000] and share my screen. Hopefully, everyone can see my screen. So, kind of get back to [22:39.320 --> 22:47.880] the actual hue. So, I went and configured this hue to kind of exhibit some of the common problem [22:47.880 --> 22:54.860] that you will often encounter. And I know I've hit it two or three times working on IoT gear [22:54.860 --> 23:04.480] in the last year or so. And I know Jonathan has also encountered it. And again, this here is just [23:04.640 --> 23:12.820] a standard hue. And then this here happens to be a quad UART device. I kind of like this one. [23:12.820 --> 23:17.720] It's a little different than the Shikra. This one actually takes four different UARTs and you can [23:17.720 --> 23:24.300] switch between three and a half and four volts. And it's all USB-based. So, it's kind of sweet. [23:24.300 --> 23:30.200] I like using that if I need multiple UARTs at the same time. Sometimes... let's go ahead and [23:30.200 --> 23:36.760] plug this device in. Make sure everything's going to come up here. So, again, often when you're [23:36.760 --> 23:42.740] encountering devices, they'll come up. And if you noticed, it had the boot delay. I put the boot [23:42.740 --> 23:49.460] delay on here just to avoid having the glitch again. But the ping glitch to force into a [23:49.460 --> 23:56.040] U-Boot console is a literally very common method. But as you see, we hit a point here where it's [23:56.040 --> 24:04.040] literally disabled. We no longer have a console. And this is not uncommon. You'll have a device [24:04.040 --> 24:15.160] where you're actually able to establish a UART connection on the device and start seeing it [24:15.160 --> 24:20.980] boot up. But then inevitably when it's booted up, there's literally no console whatsoever [24:20.980 --> 24:27.760] on that device. I've had it go up to this point. You'll see console disabled. I've seen it come up [24:27.760 --> 24:33.520] and not tell me console disabled, just say loading kernel. And then you see nothing after that. [24:33.520 --> 24:40.320] So, whether you need to use a ping glitch or they've enabled the boot delay or some method [24:40.320 --> 24:45.640] you can gain access to it, we're going to go ahead and go through that. And often, [24:45.640 --> 24:54.220] the fix for this is typically very simple. Let's see if I can catch this here. Okay. [24:56.800 --> 25:04.360] Actually, which is funny, that did not work for me. So, we'll see. [25:05.340 --> 25:09.960] This is going to be funny if this doesn't work. It wouldn't surprise me if Zoom [25:10.920 --> 25:18.220] caused the problem. Because, okay, we're able to get into it. So, back to those common commands [25:18.220 --> 25:23.020] that Garrett had mentioned, like print environment. So, we're going to come over here and print [25:23.020 --> 25:29.380] environment. And again, there's literally tons of environment variables. A lot of these environment [25:29.380 --> 25:35.060] variables are part of the boot process, like Garrett said. Some of these actually pass commands [25:35.060 --> 25:42.640] to the kernel. So, the kernel knows what to do as it's loaded up. And often, where you see [25:42.640 --> 25:49.600] alterations that need to be made, the most common one is bootargs. You'll see bootargs [25:49.600 --> 25:56.240] showing the configurations. But when we come over here, we see bootargs console is actually set [25:56.240 --> 26:01.620] normal. So, maybe it's somewhere else. But here, we found out they have another environment variable [26:01.620 --> 26:08.260] called standard bootargs. So, apparently, this is what's being called at some point. [26:08.700 --> 26:17.440] Thus, we see the null taking place in here. Sometimes, this will involve very experimental. [26:18.060 --> 26:22.700] First time, when I was setting this up to identify it, that's when I found out [26:22.700 --> 26:28.320] that this bootargs segment doesn't work. And then you need to do it some other way. [26:28.320 --> 26:35.380] And then turns out it was the standard bootargs. So, to go ahead and do this, again, like you did, [26:35.380 --> 26:49.780] you go, you set the environment, which was standard std bootargs. Something always to remember also. [26:51.780 --> 26:56.920] In this case, I'm going to rewrite the entire one. And we're going to set the console here. [27:04.280 --> 27:08.960] And look at our standard bootargs. Make sure there's not another one. You would be surprised [27:08.960 --> 27:14.100] how many times I've misspelled something. And it's easy to do. And what you end up doing [27:14.600 --> 27:19.760] is just creating another argument that isn't read by the system or used. [27:19.980 --> 27:25.400] So, then you boot the system. It goes, well, it didn't fix anything. What went wrong? Often, [27:25.400 --> 27:31.080] it's just a typo. You've seen where people have made typos up here. Here's an example. [27:31.080 --> 27:38.100] Security, security. That's kind of weird. So, again, that's probably a typo that took place [27:38.100 --> 27:43.120] there. So, at this point, we'll go ahead and go save environment variables. [27:44.460 --> 27:49.920] Write the environment variables back out. And then the reset command will cause the CPU to [27:49.920 --> 27:56.720] reset on the device from the U-boot console. So, let's see if this will actually work. [27:57.600 --> 28:06.320] And it's kind of amazing. Out of the number of times I've done this, more than [28:07.620 --> 28:12.700] three quarters of the time when the device did boot up. [28:14.590 --> 28:23.590] Oh, that's interesting. We seem to have a crash on the system. We had a kernel panic. [28:24.790 --> 28:37.530] That's interesting. So, demos do go bad. So, we will see what we have here. [28:39.030 --> 28:44.590] This doesn't come up. We're probably just going to move on. Typically, [28:45.770 --> 28:51.430] you make these changes on the system. Yep, we got another kernel panic. I'm going to take [28:51.430 --> 29:18.290] one more check and see what corrupted. Yeah, that's correct. [29:19.750 --> 29:26.750] So, we're not going to waste much time on this. And we're just going to move on. Typically, [29:26.750 --> 29:32.610] there may be something in here. Sometimes these things go bad. But normally, just by fixing the [29:32.610 --> 29:37.690] console setting, for some reason, my kernel's messed up. I'm not sure how that happened. [29:37.690 --> 29:41.770] Maybe from constantly rebooting this thing over and over and over. [29:42.410 --> 29:45.890] Maya finally said, hey, I'm not going to play anymore, corrupted something. [29:46.170 --> 29:53.470] But typically, when you go into the uBoot console, and you've broke into it, and you have a device [29:53.470 --> 29:59.230] that will not give you a console after boot up, a lot of times you can go in here and alter either [29:59.230 --> 30:05.450] boot args or some other reference that's used for the boot arguments that tell the kernel what [30:05.450 --> 30:10.690] console, what bauld rate, all those typical things, and set that, and it'll come up. [30:10.810 --> 30:14.930] Usually, three quarters of the time, when I've encountered this on commercial gear, [30:14.930 --> 30:20.210] where they've actually turned the console off trying to hide access, when I do allow it to [30:20.210 --> 30:27.010] boot up, it's giving me root access from the very get-go versus giving me a password prompt. [30:27.070 --> 30:34.130] It's giving me root access. So, again, the best way to do this is check the console settings, [30:34.130 --> 30:42.650] make sure they're correct, make sure they haven't turned initialization off. I've seen this [30:42.650 --> 30:49.250] messed with, which would cause weird things in killing consoles and stuff like that. [30:49.930 --> 30:55.050] But typically, nine times out of ten, it's literally going to be the console setting. [30:55.050 --> 31:02.190] If it's not set, often when you identify the processor that may be used in this case, [31:02.190 --> 31:10.590] you can do a little Google reference and identify the most common TTY setting for that. A lot of [31:10.590 --> 31:17.830] times it's in the data sheet and stuff like that, to identify how it is naming its primary console [31:17.830 --> 31:24.950] TTY. So, often data sheets, a little Google on the device or the processor in case, to be able [31:24.950 --> 31:31.270] to identify that, and that helps you to literally set the console where it actually needs to be. [31:31.270 --> 31:38.470] Unfortunately, that demo failed, even though it's worked 40 times up until today. And I will [31:38.470 --> 31:44.750] stop sharing and turn this over to Garrett, so he can attempt his next demo. Is there any [31:44.750 --> 31:51.750] questions related to this particular failure? Let's see. It looks like there's a couple folks [31:51.750 --> 31:57.370] that are helping to troubleshoot, and I saw one of the issues too, I think. I guess it looks like [31:57.370 --> 32:03.110] bootargs was double set. Also, the board equals appeared to be missing. The bootargs, I think, [32:03.110 --> 32:07.150] for sure, might have been one of them. The board equals might take a little troubleshooting, but [32:07.150 --> 32:11.350] that's a couple questions, I guess, that came up. But another... Oh, yeah, got it right there. I see [32:11.350 --> 32:18.870] it. Yep. Yeah. Good catch, guys. Yep. Often when you're cutting and pasting, it's very difficult [32:18.870 --> 32:25.070] to do that. Since I didn't define the board, that obviously called it. So, good catch out there. [32:25.070 --> 32:32.950] Yeah. Props to folks on Twitch as well as here in the panel as well that kind of caught that. [32:32.950 --> 32:38.510] But there is a couple questions that did crop up. One individual asks, how often do you find [32:39.070 --> 32:46.310] that IoT devices are actually using U-boot? Like, would you say about 75%, 50%? [32:46.890 --> 32:53.970] I'd have to say it's still probably a little higher than 50% that I engage devices that U-boot [32:53.970 --> 33:02.690] used. Now, if they're running the latest version of U-boot, this typical pin glitch will not work. [33:03.010 --> 33:09.750] So, what happens is the newer version of U-boot that is out there, if anyone is actually using it, [33:09.750 --> 33:16.210] is supposed to, when it can't learn, it can't load the kernel, will actually restart the U-boot [33:16.210 --> 33:22.390] process. So, it'll just go into an infinite loop until it can load the kernel in that case there. [33:22.390 --> 33:27.670] That's how they kind of started to fix this problem. I assure you there's probably attack [33:27.670 --> 33:33.070] methods in that case with that to get around to it. But the best fix, what we always recommend [33:33.070 --> 33:40.230] to most vendors on how do you solve the problem with U-boot being an issue is start using secure [33:40.230 --> 33:49.750] boot. That actually answers the last question that I had here was, what's the best way of [33:49.750 --> 33:54.130] overcoming some of these issues? And it sounds like secure boot's the best method for that. [34:02.870 --> 34:08.570] Yeah, I would say secure boot is the best solution to these issues that we're running through today. [34:11.610 --> 34:16.030] And I think we had another question just popped up here that we can kind of squeeze in before we [34:16.030 --> 34:19.070] move on. Because there's one more demo, is that correct, Garrett? [34:19.310 --> 34:23.750] Yeah, yeah, we still got one more. But yeah, more questions, the more the merrier. [34:23.750 --> 34:28.490] Okay, yeah. So, Asher asks, do you know why sometimes the environment variables cannot be [34:28.490 --> 34:33.490] modified even with root access to the U-boot console? This apparently has happened for this [34:33.490 --> 34:42.230] individual. The only thing I can think of off the top of my head is that the manufacturer hard [34:42.230 --> 34:49.490] set some of those environment variables to not allow change even at a root level. Or there's [34:49.490 --> 34:55.090] just some underlying permissions that, you know, even though we may feel we're root, there may be [34:55.090 --> 35:01.810] some hard coded just permission set there that we just can't get into. I don't know, maybe someone [35:01.810 --> 35:07.550] else has more to speak on that. But that's just my initial gut feeling. [35:09.270 --> 35:14.530] I'd have to agree with that. I actually had a device I was playing with the other day. [35:14.530 --> 35:21.050] And there was probably a half dozen arguments in the environment variables that when I changed [35:21.050 --> 35:29.830] them and saved them, they never saved nothing. So, U-boot's a funny beast. Everybody compiles [35:29.830 --> 35:35.530] it differently. So, the amount of features, functions, capabilities, and how it works [35:35.530 --> 35:41.510] is very configurable. And every vendor will compile it and use it different. [35:41.750 --> 35:49.330] Also, I've seen some where boot args and all of those settings are not even used by the kernel. [35:49.730 --> 35:57.130] That stuff is actually hard coded into some kernel configurations. So, alterations with boot [35:57.130 --> 36:04.870] args don't actually work, which can be problematic too when you're trying to carry out [36:05.330 --> 36:14.470] some level of tax. Based on that, I think what Garrett's going to demo here just shortly [36:15.070 --> 36:22.010] will actually open up some other possible opportunities. If you're able to break in [36:22.670 --> 36:28.430] to the U-boot console, some of the stuff he's going to show may be very helpful in [36:29.110 --> 36:40.860] gaining a level of access into the system. Awesome. Any other questions out there, John? [36:40.860 --> 36:43.740] I think we're kind of on the queue. I think we're good to go. [36:43.760 --> 36:52.400] All right. Right on. Moving on. So, next, we're going to be going over the Luma. [36:52.400 --> 36:59.100] The Luma is that mesh device that we were looking at. It's got a little bit more to it [36:59.100 --> 37:06.340] on the motherboard itself. There's just a lot more going on. It has onboard Ethernet. It's [37:06.340 --> 37:12.380] got a USB port. It's got several different places to connect wires. There's some headers. [37:13.300 --> 37:19.160] A lot of stuff going on. I think it's got a built-in Wi-Fi chip on it, possibly. I'm not sure. [37:19.160 --> 37:25.700] But a lot of stuff going on there. So, we're going to boot to root here real quick out of [37:25.700 --> 37:34.820] these slides back into the live action. Here we go. So, now I got my Luma set up here, broken down, [37:34.820 --> 37:42.540] ripped it apart. I've got my UART connection over here with my ground, my receive, and my transmit. [37:42.540 --> 37:48.360] We're all good. I have my Ethernet actually plugged in because I'm just going direct line [37:48.360 --> 37:55.200] to this thing. And then I also have a ground wire that you can't really see. But there is a ground [37:55.200 --> 38:03.560] wire soldered onto the board over here. So, the way that I did get into this thing initially was [38:03.820 --> 38:10.160] a pin glitch. And I'm not going to show that today. But if it's something you want to see, [38:10.160 --> 38:17.060] I can demo it later if we have time. But basically, this particular chip right here is the chip that [38:17.060 --> 38:23.380] we are compromising to break into this thing. And it's actually this pin right here, this data [38:23.380 --> 38:29.640] pin right over here, the second one up. I don't know if you can even see that. But there's eight [38:29.640 --> 38:39.120] pins around that square chip. And we're going to short the data line or the data pin on that thing. [38:39.120 --> 38:44.040] So, that's how we would have got into this thing. But since we already did that, the magic of [38:44.040 --> 38:51.240] television, we're just going to plug some power into this thing. Okay. We got power now. And a [38:51.240 --> 39:01.400] little bit more slack in that line. The trusty toe. Come on, toe. There it is. And we're connected. [39:01.400 --> 39:08.520] And there it goes. So, what's funny about Cool Term is you have these receive and transmit [39:08.520 --> 39:13.200] lights going on in the bottom. So, we know that we're getting data in some way somehow. [39:14.320 --> 39:20.000] And again, with the boot up process, a lot of information here. And obviously, we can all read [39:20.000 --> 39:23.500] extremely fast. That's how we're able to read everything that's going down the screen. [39:23.900 --> 39:30.260] No, probably not. There's ways to extract this if you wanted to. Kind of if you recorded this [39:30.260 --> 39:35.340] and just played it back slow. And you could be taking like screenshots as it goes through. [39:35.340 --> 39:41.900] There's plenty of ways to kind of extract everything that's going on here. This one actually [39:41.900 --> 39:47.280] takes a little bit longer to boot up than the Hue. I think just because it has more functionality [39:47.280 --> 39:53.480] to it. It's not just going to turn your lights blue or green or red or whatever the ambience for [39:53.480 --> 39:59.600] the evening happens to be. This time, it's actually going to provide internet connection. [39:59.760 --> 40:05.660] So, when people come over or you have parties, not so much anymore. But when we did, [40:05.660 --> 40:10.260] you want to have everyone be able to have internet. We got to be staying up to date on our [40:10.800 --> 40:16.560] socials. We got to be, you know, staying up to date on everything. So, internet is good. [40:17.340 --> 40:20.600] So, we may not wait for this whole thing to boot up. I think it takes about [40:21.080 --> 40:27.420] a couple minutes. And my patience is weak. So, as this thing kind of rounds the bend here, [40:27.420 --> 40:32.020] it looks like it's doing stuff with Wi-Fi. Looks like some connections were going on, [40:32.020 --> 40:38.500] some different channels. Let's just see what happens. Oh, okay. So, we got a login prompt. [40:40.260 --> 40:47.760] We can try to log in. I don't know the password, though. Let's give it a shot anyway. Login [40:47.760 --> 40:54.720] incorrect. So, no luck again. We're 0 for 2 there on trying to just log into these things. [40:55.460 --> 40:59.460] So, what can we do? We're just going to power cycle this thing. [41:01.680 --> 41:10.120] All right. So, clear. Clear. All right. Pinky toe in action. All right. So, [41:10.120 --> 41:16.560] like I said before, the, you know, how the cooking shows do it, they don't cook that whole [41:16.560 --> 41:21.160] turkey right in front of you. That would be crazy. But they have one already in the oven. So, that's [41:21.160 --> 41:26.540] kind of what happened here is I pin glitched this thing prior to this call so that I did set this [41:26.540 --> 41:33.020] boot delay so that I could break out of it and get in there and actually show you some stuff. So, [41:33.020 --> 41:37.380] similar to before, print environment variables. We can just ask for help, though. Just see what's [41:37.380 --> 41:45.280] different about the Luma versus the Hue. So, some slight differences. This one's not as long [41:45.280 --> 41:51.800] as far as the list of items that we can do. So, just kind of piggybacking on that final [41:51.800 --> 41:56.880] question before is, you know, U-Boot is configured differently on every device, [41:56.880 --> 42:04.600] or essentially it can be. So, I was even reading up on this company called Emac. I think they do, [42:06.460 --> 42:10.740] Skada devices. And the way that they configure U-Boot was completely different [42:10.740 --> 42:16.380] than another person who configured U-Boot. Because when I was looking things up on this [42:17.780 --> 42:22.860] stuff, I would find several different explanations. Like, well, wait a minute. [42:22.920 --> 42:27.880] Is this even the same thing? Like, yeah, it is. It just can be completely configured, [42:27.880 --> 42:33.020] you know, in several different ways. Or compiled, I guess is the right word to use. [42:33.020 --> 42:38.420] So, if we look at some of these things, what jumps out to me is the boot arguments, the boot [42:38.420 --> 42:46.500] IPQ, boot from a flash device, boot from memory, boot from a network connection using TFTP. [42:48.340 --> 42:56.600] Spoiler alert, maybe. We got ping, so we can actually test ping connections. Print environment, [42:56.600 --> 43:00.420] like we already know. Save environment, set environment, that's all there. [43:01.480 --> 43:09.300] Print the memory flash information. There's a TFTP boot command right there. [43:09.380 --> 43:13.800] Oh, and a USB boot. So, a lot of stuff. This thing has a USB onboard, so, [43:13.800 --> 43:22.180] you know, there's more opportunities here. So, today, let's get back into the print environment. [43:22.180 --> 43:27.340] Let's take a look back at this. Today, we already have set the boot delay. [43:27.340 --> 43:34.500] That's already done. Boot delay is set. This boot command, though, is set to that boot IPQ. [43:34.500 --> 43:40.220] And if you don't remember, we can just quickly look back at that boot IPQ. What the heck is that? [43:41.360 --> 43:48.280] So, here it is. Boot IPQ. And it's to boot from flash device. So, that's what it's set out of [43:48.280 --> 43:53.380] the box from the manufacturer there. So, if we get back into those environment variables, [43:53.380 --> 44:01.200] what else can we mess with? Let's see. So, IP address. Ah, IP address is important. [44:01.220 --> 44:09.060] And we also have server IP. So, what can we do with those? So, basically, this IP address, [44:09.060 --> 44:15.520] this Luma device does not have networking configured out of the box. So, when it turns on, [44:15.520 --> 44:22.720] it just has a random IP in there. And I just set it to an available IP on the network that [44:22.720 --> 44:29.000] isn't already being used by the Xbox or the PlayStation or the 10 Raspberry Pis or the [44:29.720 --> 44:34.640] N64. You know what I'm saying? All these devices out here. So, I just chose a random IP. Doesn't [44:34.640 --> 44:44.000] really matter. What does matter is the server IP. The server IP is going to be the TFTP server. [44:44.460 --> 44:50.900] So, we're gonna be using TFTP to boot this thing or to boot from TFTP. [44:50.900 --> 45:00.300] And that's where this extra server comes into play. So, I got my just a Ubuntu 16.04, [45:00.300 --> 45:06.160] just fresh ISO I just pulled down the other day. And just found a couple articles online [45:06.160 --> 45:11.340] on how to set up a TFTP server. It's really straightforward. You know, if I can do it, [45:11.340 --> 45:16.700] I'm sure anybody on the call can do it. Because it's just creating a file, setting the right [45:16.700 --> 45:21.980] parameters in that file, and then making sure the service is up and running. I can't tell you [45:21.980 --> 45:28.060] how much pain I was having literally yesterday about trying to get this thing to work. And [45:28.060 --> 45:31.840] literally, I didn't really change much. And it just started working again. So, [45:31.840 --> 45:38.660] we're gonna see how well today goes. But anyway, it looks like it's up and running. We can just [45:38.660 --> 45:44.780] see if this is still good to go. All the passwords, super secret. All right. So, [45:44.780 --> 45:52.160] we're still running as of 1529. So, right on schedule there. Cool. And if we look at the IP [45:52.160 --> 46:02.620] of this device, that might help, right? I have config. Let's see. So, this is 192.168.118. So, [46:02.620 --> 46:09.880] that's where that IP comes into play. All right. Cool. So, jumping back to this now. [46:10.560 --> 46:19.680] So, this boot command is set to this. We can actually override this particular boot command [46:19.680 --> 46:25.940] here. And these boot arguments. Sorry, there might be a neighbor calling for their cat. [46:25.940 --> 46:31.600] So, I've actually already gone ahead and wrote out this command just for sake of [46:31.600 --> 46:36.000] typoing this thing a million times. I'm just gonna copy it over. [46:38.460 --> 46:43.460] And if you notice, I didn't show it, actually. But if I go back to my VM, [46:43.460 --> 46:53.540] I have a kernel image over here that has been compiled using open WRT. So, it's this is the [46:53.540 --> 46:59.520] package or the image that we're gonna be calling from my TFTP server. So, I just dropped it on the [47:00.260 --> 47:05.900] desktop here. I have it in several locations just because I was testing. So, I think it just needs [47:05.900 --> 47:15.300] to be on the root drive, just accessible. So, good stuff there. And now that we're back here, [47:15.300 --> 47:24.150] I'm just gonna paste this command. Cool. Just like that. So, I'm using TFTP boot, [47:24.850 --> 47:29.710] which is one of those help arguments, if you remember. There was a TFTP boot argument that [47:29.710 --> 47:34.970] we could use. And then I'm telling it, which piece of memory do I want to boot from? And I [47:34.970 --> 47:41.310] want to boot this particular image. And then boot at this particular address in memory. So, [47:41.310 --> 47:46.310] that's what this command is meant to do. So, without further ado, let's see how it goes. [47:46.310 --> 47:54.950] Let's just hit the big red button. And right away, you can see that it's using an Ethernet device, [47:54.950 --> 48:04.910] eth0. So, it is connected. It's from the server, my TFTP server at 1.18. And then from our address, [48:05.810 --> 48:11.510] .25. So, looks like we might be in good shape here on the first go around. How about that? [48:12.450 --> 48:17.050] Looks like it's uncompressing the kernel image. It's booting it up. You can see the OpenWrt right [48:17.050 --> 48:23.930] here, if you catch it. And then it's off to the races. So, as this thing kind of boots up, [48:23.930 --> 48:31.010] we'll see if we got any further than that login prompt that we had before. And if you're not [48:31.010 --> 48:38.390] familiar with OpenWrt, it is open source. And those can also be kind of compiled a little bit [48:38.390 --> 48:46.470] differently depending on, you know, what you want to do with it. So, by the way, the devices, [48:46.470 --> 48:52.970] if you wanted to buy these devices, very cheap on eBay. You can pick them up here. Very cheap. [48:52.970 --> 49:00.410] Just search eBay. But this OpenWrt, it's basically just an open source project that you can compile [49:01.050 --> 49:08.630] different, you know, different things and connect to different devices. It's just fully customizable. [49:09.330 --> 49:12.290] So, that's a little bit about what's going on there. [49:14.370 --> 49:20.290] Let's see. So, as this thing kind of boots up, see if we just hit one of these random buttons [49:20.290 --> 49:29.830] over here. Boom. So, that did it. We are in a built-in shell on the Luma device. So, this [49:29.830 --> 49:36.430] technically is not the Luma OS. So, I want to be clear on that. We didn't just [49:36.430 --> 49:44.270] root the whole Luma device. What we did is we created a kind of a landing place for [49:45.490 --> 49:51.910] kind of like before the OS hits the ground, we created our own OS and said, hey, we want to [49:51.910 --> 49:59.210] boot to our OS before you even get to yours. Okay? So, that's what this is. And so, it's not the [49:59.210 --> 50:06.130] direct file system on the Luma. But we can still do things similar to the Hue where we can, you [50:06.130 --> 50:10.490] know, dig into the root file system. We can look at the kernel, the firmware. There's a lot of [50:10.490 --> 50:16.610] things that we can potentially get into. There's several different techniques to do that. One of [50:16.610 --> 50:23.470] them would be mounting these drives. So, assuming that we had full permission, then we would just [50:23.470 --> 50:30.110] mount these drives and start extracting data from there. If we don't, you know, in a situation where [50:30.110 --> 50:35.510] we don't have access, say like for right now, like we have all zeros here. So, it's possible that we [50:35.510 --> 50:43.690] don't have access to this right now. So, what we could do is use something like DD to extract the [50:43.690 --> 50:50.910] data that way. It's a command line tool or something like TFTP and just siphon the data to [50:50.910 --> 50:58.590] another medium and then perform, you know, additional analysis there. But as far as from [50:58.590 --> 51:03.130] where we are right here, there are some things that we can do. But it is kind of in this open [51:03.130 --> 51:09.750] WRT console now where we'd have to get a little bit creative and kind of use our noggins and [51:11.130 --> 51:15.170] find another path to the Luma OS. But it's possible. [51:16.510 --> 51:22.630] So, that's a little bit about what we got going on on this thing. We wanted to show, you know, [51:22.630 --> 51:31.070] booting to an OS that we compiled on the device itself. So, that's a little bit about what we got [51:31.070 --> 51:36.810] going on here. Any questions on how we got to this point? [51:39.650 --> 51:47.970] Yep. A couple questions here. Let me take a look. One individual asks, I assume all of these attacks [51:47.970 --> 51:54.610] require physical access. There's no way of performing this attack remotely. Is that correct? [51:55.470 --> 52:01.370] Yes. So, unfortunately, if you did want to, you know, start doing some war driving or something [52:01.370 --> 52:07.090] or mess with your family members, whatever, it's all ethical, right? You know, you would [52:07.090 --> 52:13.090] have to have physical access to these devices. I imagine you could get physical access one time [52:13.090 --> 52:19.230] and then set up some type of logic bomb or some type of, you know, hook into the device so that [52:19.230 --> 52:25.370] if it were online, it could call to us in some way or somehow. Probably some of the devices that have [52:25.370 --> 52:35.710] internet connection more so than not. But I know that I have the light bulbs from Costco. I think [52:35.710 --> 52:42.450] they're called... oh, man, now I'm drawing a blank on it. But it's basically the same thing as the [52:42.450 --> 52:48.490] Philips Hue. And it's the Costco version. I can't remember the name of it now. It's driving me nuts. [52:48.490 --> 52:55.390] But basically, they were on the internet, and they didn't have very much any security. And [52:55.950 --> 53:05.690] I was just afraid to even mess with it at that point. I'm like, [53:05.690 --> 53:14.530] physical access to this thing. But, you know, you never know. So, good question. [53:16.250 --> 53:24.130] All right. Taking a look at another question here. As far as... I think this was touched on a little [53:24.130 --> 53:29.990] bit earlier as well by Daryl. But how do you know which pin to take to ground when glitching? [53:29.990 --> 53:36.090] I know earlier we were talking about data zero, data one. But as far as testing is concerned, [53:36.090 --> 53:41.070] how would you know about taking which pin to ground whenever you're performing this type of [53:41.070 --> 53:48.090] glitching? Yeah, that's a good question. I do have the breakdown of that flash chip [53:48.090 --> 53:54.910] on another screen somewhere, somehow. Bear with me. Can you still see my screen? Is it still [53:54.910 --> 54:02.950] showing questions? Yes. Okay, give me one second and I can get that readout for you. [54:02.990 --> 54:12.110] But basically, it is a data line, and it is the one that we would want to break into. So, [54:12.110 --> 54:19.030] when you look at the data sheets for these devices, you do want to look for the data lines [54:19.030 --> 54:26.050] is kind of the idea in finding out where those actually exist. Let's see if I can't [54:27.550 --> 54:38.770] get a good shot of this. Give me one second. Okay, got that now. Let's just minimize some things. [54:40.890 --> 54:47.250] Okay. So, see if I can't get a better view of this device here. [54:50.200 --> 54:56.460] Okay. So, you can still see my screen. What I have on there now is basically the top down view [54:56.460 --> 55:04.840] of that exact chip. So, if I look back to the camera, this is the chip breakdown, this one [55:04.840 --> 55:10.220] right here. I don't know if you can see that, but the one with the little orange paint drop. [55:11.060 --> 55:17.660] So, that's what we're breaking down in this diagram here. If I can get my pen out. There we [55:17.660 --> 55:26.480] go. So, the line that we're shorting is this SO line. This SO line over here, that's the [55:27.240 --> 55:32.720] data line. I can't remember exactly what it stands for. Maybe Daryl remembers, but [55:34.400 --> 55:39.360] that's essentially what we're shorting in this example. [55:43.530 --> 55:47.610] Yeah, exactly. There's also an interesting question that came up. When glitching, [55:47.610 --> 55:54.390] would it be a little safer to use a resistor in lieu of a paper clip? There's a possibility you [55:54.390 --> 56:00.830] could short a 3.3 or 5 volt trace pin and burn a register. Yeah, there's always a chance. [56:02.650 --> 56:09.470] That's why it's very important to... I'm not against using a resistor. I mean, there is some [56:09.470 --> 56:17.330] value to that. If you'd have to experiment around, because obviously you want to interrupt the [56:17.610 --> 56:24.550] data significantly enough, and a resistor may or may not drop the voltage enough based on the [56:24.550 --> 56:31.010] resistor size. But in reference to doing that, again, like he's showing here, go ahead and get [56:31.010 --> 56:36.790] the data sheets, figure out what you're grounding out. So, literally, you don't like just smoke [56:36.790 --> 56:42.770] something. To randomly go into a device here and go, oh, I think I'll just start grounding stuff [56:42.770 --> 56:50.370] out. It's almost a guarantee that you will brick the device permanently. Now, I've had on these [56:50.370 --> 57:01.270] glitching attacks, probably successful. Anytime there's two chips used, where U-Boot is on one [57:01.270 --> 57:07.290] chip and the kernel file system is on another, I've had a hundred percent success every time [57:07.290 --> 57:14.850] in actually doing that. I've only had a problem on one device, and it was using... I can't remember [57:14.850 --> 57:20.330] the chip it was using. It was very much more high speed, so getting it at the right time was [57:20.330 --> 57:26.450] difficult. We never destroyed the chip, but during the attack, even though I was taking the data line [57:26.450 --> 57:36.670] down the ground, I ended up actually causing it to screw the U-Boot up, and it actually damaged [57:36.670 --> 57:45.450] the U-Boot so that the chip would not boot up anymore. It would come up actually giving you an [57:45.450 --> 57:50.270] error in the U-Boot. Now, how it altered part of the data in the U-Boot during this process, [57:50.270 --> 57:57.750] I have no clue. Maybe it did fry register in there or smoke something, but we were able to [57:57.750 --> 58:02.270] pull the chip and then successfully pull the entire operating system off and recover it all anyway, so [58:04.210 --> 58:05.390] problem solved. [58:07.730 --> 58:16.990] Yeah, and just to speak on that note too, I've definitely broken enough devices just tinkering [58:16.990 --> 58:21.610] just like that and not really looking, you know, doing the right diligence of looking at the data [58:21.610 --> 58:26.450] sheet, looking at what am I actually messing with. It was more like, it's how it works in the movies, [58:26.450 --> 58:29.710] so it's how it works in real life. You know, I'm just going to touch a bunch of stuff and [58:29.710 --> 58:33.950] now I'm in. So, I definitely have a bunch of devices that [58:34.850 --> 58:39.070] just are paperweights around, scattered around. [58:41.090 --> 58:43.790] Yeah, that's funny, dude. [58:46.750 --> 58:55.950] Good stuff. So, that is getting into the Luma and being able to boot up, [58:55.950 --> 59:01.190] another operating system such as OpenWrt. [59:03.210 --> 59:10.210] So, if those devices aren't readily available to you, like the Philips Hue and the Luma, [59:10.210 --> 59:14.830] things like this, or they're the ones that you use in your house and you're not trying to lose [59:14.830 --> 59:19.810] internet in your house, totally get that. But if you have a Pi laying around, you can do the [59:19.810 --> 59:29.530] exercise with a Raspberry Pi. There's several articles over the internet that you can find [59:30.050 --> 59:36.390] how to do this, how to set it up, what you can do with it, and it's pretty wide. So, [59:36.390 --> 59:41.490] this is just an example of a Raspberry Pi that we had connected, one of my colleagues set up [59:41.490 --> 59:47.410] for me for this demo. So, then you have Uboot going on on the right-hand side. It's doing the [59:47.410 --> 59:55.670] same kind of song and dance of getting into the flash memory, the kernel, and actually printing [59:55.670 --> 01:00:00.850] the environment variables so that we can tweak them and adjust them and then tell it what we [01:00:00.850 --> 01:00:13.610] wanted to do. So, it's just another example of a Raspberry Pi. Cool. So, that is all, folks. I [01:00:13.610 --> 01:00:18.710] really appreciate everyone who was able to join this session on a Saturday when we're not in [01:00:18.710 --> 01:00:25.110] Vegas. I'm assuming we're not in Vegas, but normally hungover at this time of the day and, [01:00:25.110 --> 01:00:33.310] you know, completely, you know, con funk is in full force. You know, I don't know what time it [01:00:33.310 --> 01:00:39.930] is. I don't know where I am. That's normally the status of this day for me. So, it's a little bit [01:00:39.930 --> 01:00:45.150] different doing this thing virtual. So, I appreciate everyone who was able to join and [01:00:45.150 --> 01:00:52.130] all the questions and, you know, really happy to be here. So, if you have any other questions, [01:00:52.130 --> 01:00:57.950] throw them out there. But that's the end of the show. Yeah, there was one more question I saw [01:00:57.950 --> 01:01:04.290] come in in the chat. It said, did you download someone else's build for the Luma or did you [01:01:04.290 --> 01:01:12.570] do it yourself? In this particular case, this build was... I actually built this a while back [01:01:12.570 --> 01:01:23.110] while I was doing some testing on the Luma. So, I used OpenWrt's program. This is built off an [01:01:23.110 --> 01:01:30.090] IPQ40 series processors, which is what the processor is on that particular Luma. And it's [01:01:30.090 --> 01:01:37.770] one of the chipsets that's actually supported within the OpenWrt. Now, in this particular case, [01:01:37.770 --> 01:01:44.770] the success of this wasn't 100%, as Garrett pointed out, that the root FS was showing [01:01:45.590 --> 01:01:51.270] nothing there or zero location. And the reason why that is, is because, remember, this is a [01:01:51.270 --> 01:01:58.670] two-chip system. And when you're building an actual firmware package, you have to build out a [01:01:58.670 --> 01:02:11.410] device tree. Now, most of all of the data available on OpenWrt was very well available [01:02:11.410 --> 01:02:18.630] dealing with one-chip environments. But the device tree for the second chip [01:02:18.630 --> 01:02:27.770] has not been built into this yet, which potentially made that an issue. But once you compile it [01:02:27.770 --> 01:02:33.610] and compile it with the right complete device tree, complete it, then what he showed with PROC [01:02:33.610 --> 01:02:40.690] MTD, which is the memory technology devices, kind of an abstract layer between the hardware, [01:02:40.690 --> 01:02:46.770] the physical flash hardware, and the other part, you can literally from those potentially [01:02:46.770 --> 01:02:53.250] mount those file systems up, or you can also DD them off by actually calling them directly [01:02:53.810 --> 01:03:02.170] through dev MTD 0 through 9 or 10, which is one of the methods. It's really easy once you get some [01:03:02.170 --> 01:03:08.250] kind of console, which would be the ultimate goal of bringing in a new kernel via TFTP, because you [01:03:08.250 --> 01:03:13.690] would come in, it would have the device tree, you would see the chips, even though they're not [01:03:13.690 --> 01:03:19.570] mounted up, you can easily DD all of those images off their file system, the root file system, [01:03:19.570 --> 01:03:27.850] and everything from a separate booted kernel like this, giving you the ability to do some offline [01:03:29.390 --> 01:03:35.970] binwalk and extract the data, hopefully find the root. Or inevitably, you could even, [01:03:36.610 --> 01:03:42.610] when you find the root, you could easily in this particular case, DD it off, explode it out, [01:03:42.610 --> 01:03:49.490] and then alter it, rebuild it, repack it back in, and then DD it back over that partition [01:03:49.490 --> 01:03:55.270] area, and then reboot the device. And in that fashion, actually change the root password. [01:03:55.430 --> 01:04:01.170] So this particular attack, as he addressed and talked about, will really open up a lot of new [01:04:01.170 --> 01:04:07.830] avenues to some hardened devices. But it all comes down to, can you get access to that UBoot console? [01:04:09.070 --> 01:04:18.530] And also, the presentation or the demo I ran, and the person pointed out where I missed board, [01:04:18.530 --> 01:04:21.910] that was correct. As soon as we jumped off and he moved on, I went ahead, [01:04:21.910 --> 01:04:28.070] fixed that typo, failed to copy and reboot it, and it came up to the root prompt. So [01:04:28.070 --> 01:04:33.170] that worked out pretty good. So good shout out to that person, was able to visually, [01:04:33.170 --> 01:04:37.890] quickly capture the idea that I missed that little piece. So totally cool. [01:04:38.910 --> 01:04:45.170] Nice. Yeah, I just wanted to add on that. Sometimes on the devices, if you can still [01:04:45.170 --> 01:04:54.510] see my screen, the prompt, the command prompts on the Luma is actually the name of the chip, [01:04:54.510 --> 01:05:01.610] the IPQ40. So sometimes you can get even more details from just the device itself, [01:05:01.610 --> 01:05:07.510] just telling you like, hey, this is what I am. Hope this helps, you know. But yeah, [01:05:07.510 --> 01:05:11.930] I just wanted to call that out. I didn't mention it earlier, but IPQ40, like what the heck is that? [01:05:11.930 --> 01:05:18.230] It's the name, it's the type of chipset that's on this thing, type of processor. So [01:05:19.750 --> 01:05:24.910] cool. Well, really appreciate everyone, if that's all the questions. [01:05:26.510 --> 01:05:32.290] Not sure if there's any more, but we're good to go, right on time. [01:05:32.710 --> 01:05:35.850] Yeah, Jonathan, do you see anything else in the Twitch we might have missed? [01:05:36.730 --> 01:05:41.030] I'm taking a look here. I do see that in Zoom, someone asks, it looks like it identified the [01:05:41.030 --> 01:05:47.050] attached flash as well. So I guess from the U-Boot output there, it identifies the flash. [01:05:47.490 --> 01:05:51.150] Pulling up Twitch, I think from Twitch, we're also good to go. So the last question, I guess, [01:05:51.150 --> 01:05:58.210] was there and the question was, it looks like it identified the type of flash. And that might be [01:05:58.210 --> 01:06:05.350] kind of equally a statement as it is a question. It did. It identified the one of the flash chips. [01:06:08.170 --> 01:06:16.270] So could you actually from that booted kernel potentially get to those current chips? [01:06:16.270 --> 01:06:23.910] Yeah, it's highly possible. You may have to do some manipulation. I haven't tried it yet. [01:06:23.910 --> 01:06:31.310] But typically, the easiest way is to build it into the device tree for the kernel that you're [01:06:31.310 --> 01:06:36.230] building for that processor. That's the most effective way. Once that's built in there, [01:06:36.230 --> 01:06:43.390] it makes it 10 times easier for gaining access and basically altering this data or extracting [01:06:43.390 --> 01:06:51.650] that data off there versus not necessarily have to figure out how do I access a chip when I don't [01:06:51.650 --> 01:07:02.030] have a device tree for it. It's going to be very difficult. So yeah. Sorry, I had someone that was [01:07:02.030 --> 01:07:11.930] playing the Linkin Park at the full capacity of the volume there. So I apologize as I drove by. [01:07:12.010 --> 01:07:17.210] Okay, yeah, you have one person out there says you need to put that cowboy hat on behind you. [01:07:17.410 --> 01:07:20.490] So you look like Billy Ray Cyrus. [01:07:27.010 --> 01:07:33.670] Oh, y'all are cracking me up. Oh, man. I appreciate y'all. Yeah, let's see what we got. [01:07:33.950 --> 01:07:36.650] Here we go. Hats on. [01:07:37.410 --> 01:07:43.910] We have to take this off. But there we go. We're locked and loaded now. [01:07:45.570 --> 01:07:50.030] Pretty great. This is how you find the real bones. [01:07:53.970 --> 01:07:55.070] Nice. [01:07:56.730 --> 01:08:00.910] I mean, the people in the audience, unless the presenters need to leave, [01:08:00.910 --> 01:08:10.690] we still have time. There's no rush to close out quite yet. There's 30 minutes before next talk [01:08:10.690 --> 01:08:16.210] comes on. So we still have just a little bit of time probably we could do another five minutes [01:08:16.210 --> 01:08:22.690] if the presenters are still available. Hey, let me go ahead and let me go ahead and boot my [01:08:22.690 --> 01:08:34.170] failure. So let's switch over to that. So let me go ahead and share my screen. Let's get that going. [01:08:37.290 --> 01:08:40.170] Okay, hopefully everyone can see everything fine now. [01:08:40.830 --> 01:08:43.830] So let's go ahead and power this. Watch this thing fail again. [01:08:44.770 --> 01:08:52.770] I should know when to walk away to a demo failure. So let's go ahead and stop here real quick. [01:08:52.770 --> 01:09:00.170] Let's go print environment. So we can see what I altered. So I altered standard boot. [01:09:00.430 --> 01:09:08.030] When I copied it over, I missed this word right here, board equals. So it ended up specifying [01:09:08.030 --> 01:09:14.390] this board. And what's kind of strange is often when you do boot args, and I've mistyped things [01:09:14.390 --> 01:09:19.810] before, I'd never had it cause a kernel panic like that before. So it's kind of interesting. [01:09:19.810 --> 01:09:25.750] I've had it just skip over that functionality or whatever. So that was kind of interesting. [01:09:26.210 --> 01:09:33.090] So the change I did this originally said null, we're able to identify with a little legwork [01:09:33.090 --> 01:09:39.110] watching the system normally boot up, looking at some of that stuff, identify the type of TTY [01:09:39.650 --> 01:10:07.570] and replace the console null out of there. So it's common to see these options also on devices [01:10:08.230 --> 01:10:14.570] that are outside of the U-boot where it says press F key, enter into failsafe mode. Sometimes [01:10:14.570 --> 01:10:20.330] these will put you into a single user mode when the vendor's crazy enough to leave them available. [01:10:20.330 --> 01:10:25.910] Something to think about from when you're watching a boot option, it's not part of the U-boot stuff, [01:10:25.910 --> 01:10:32.430] but it can be very helpful. It will put you in a very locked down system. There won't be network, [01:10:32.430 --> 01:10:38.890] there won't be device drivers, there won't be nothing on there. So inherently, there you go. So [01:10:39.450 --> 01:10:46.530] instantly you're able to get past that. And like I said, this is kind of a common issue that you [01:10:46.530 --> 01:10:52.770] can run into a number of times where they've just basically said, turn the console off before you [01:10:52.770 --> 01:10:59.550] boot kernel or turn the console off when kernel, before kernel runs. And because of that, you don't [01:10:59.550 --> 01:11:06.250] get a console. If you can gain access to U-boot, probably eight out of 10 times, you can change [01:11:06.250 --> 01:11:13.410] those settings to be able to gain access to a console. Now, whether you'll have full root access [01:11:13.410 --> 01:11:21.590] after boot is to be found or figured out. But believe it or not, I think over the last so many [01:11:21.590 --> 01:11:30.430] years, I've encountered three or four devices that had it set up to go ahead and halt the console so [01:11:30.430 --> 01:11:35.230] you can have it. And when I changed the argument so the console was enabled, at least half the time, [01:11:35.230 --> 01:11:43.210] I had a full root console at that point. And these settings here that I mentioned, [01:11:43.210 --> 01:11:49.150] the press one, two, just select the debug mode. Never had much luck with those. Sometimes they [01:11:49.150 --> 01:11:54.610] do things, sometimes they don't. But the F key, if you ever see that, takes you to failsafe mode. [01:11:54.610 --> 01:12:00.310] This will give you root level access, but it's amazing how complicated with root level access [01:12:00.310 --> 01:12:06.890] and no ability to move data on or out of the device. It's doable, but it becomes very [01:12:06.890 --> 01:12:11.810] problematic because often you actually have to build the device nodes. And if they harden the [01:12:11.810 --> 01:12:18.210] device and turn certain programs off and remove them, it becomes more difficult. From the Luma, [01:12:18.210 --> 01:12:24.250] just out of curiosity from the Luma, this had this and I was working to try to get data off of it. [01:12:24.250 --> 01:12:31.050] In a way I originally did it was go into the F mode and actually build, manually build all the [01:12:31.050 --> 01:12:41.350] device, not totally manually, but very close to manually reconstruct the device nodes, naming them [01:12:41.350 --> 01:12:47.130] all the correct pieces and parts to build a USB. And then from there was able to move the data off [01:12:47.130 --> 01:12:54.430] to the USB. Just some stuff to think about. A small question just came up, Daryl. I know [01:12:54.430 --> 01:12:59.410] you had mentioned this yesterday during your building the IoT lab. What is your FTDI device [01:12:59.410 --> 01:13:04.650] you're using for that one? Its name escapes me. Someone was asking on Twitch. Oh, gosh, [01:13:04.650 --> 01:13:09.530] this one I have right here. Yeah, it was that cool one that could do like more than just it had like [01:13:09.530 --> 01:13:22.240] it supported like SPI and others in addition to UART. Yeah, that's the one. Let's power this off. [01:13:22.320 --> 01:13:27.760] Let's see if this has this name, has a name on it. I don't know if this even has a name. It's [01:13:27.760 --> 01:13:34.700] very generic and I do not even have the box for it anymore. I bought this off Amazon. All I did [01:13:34.700 --> 01:13:44.860] was search for multi UART connector or multi port UART connector and this came up. If I remember [01:13:44.860 --> 01:13:55.500] the price of this was like twenty seven dollars. But to to the life of me, I do not know the name. [01:13:55.500 --> 01:14:03.520] This is a generic build device coming out of China and it works pretty good. So [01:14:04.700 --> 01:14:12.720] cool. But sadly, I do not know what its name is or who makes it. Gotcha. Another question [01:14:12.720 --> 01:14:19.720] cropped up. Is there a URL or GitHub of some type where one could get ROMs to access a processor [01:14:19.720 --> 01:14:24.420] or access to a processor to play around with and do this type of stuff? [01:14:26.420 --> 01:14:34.420] I think they're asking, is there, I guess, any like I guess I think I think what's being asked [01:14:34.420 --> 01:14:40.980] with it is are there maybe like a list of devices that that could be purchased in order to do things [01:14:40.980 --> 01:14:49.260] such as U-Boot exploitation? I would actually literally exactly what Garrett said, go to [01:14:51.360 --> 01:15:00.220] go on to eBay and look at buying some of the devices on eBay. I think would be bright. You [01:15:00.220 --> 01:15:07.200] get the Lumos. You can get the you can go ahead and get the Hughes out there. He actually had [01:15:07.320 --> 01:15:12.780] a screen where he was showing some that were available. They're not expensive. I'm not sure [01:15:12.780 --> 01:15:17.320] how this would work. This is a product that that I was playing around with just recently, [01:15:17.320 --> 01:15:24.880] and it's like 19 or 20 bucks. And basically, it has OpenWRT running on it right now. [01:15:24.880 --> 01:15:30.640] It has serial connections. There's a flash chip so you can practice pulling the chip off if you [01:15:30.640 --> 01:15:37.660] want reading it or using SPI chip reading techniques. You can probably trace out [01:15:38.360 --> 01:15:44.080] versus some of these headers or connectors. You may be able to trace out the actual [01:15:45.540 --> 01:15:53.660] JTAGs on this for the chip. It has Ethernet. It has Wi-Fi. It has USB. And literally, it's like [01:15:53.660 --> 01:16:01.880] 20 bucks. So this would be an easy, cheap device to possibly play with. And that's [01:16:05.840 --> 01:16:12.840] Vixby 300 wireless travel router. I would try playing around with that. But I have to admit, [01:16:12.840 --> 01:16:21.200] this was kind of footsy when it came to the actual U-boot arguments. I had a couple arguments [01:16:21.200 --> 01:16:26.460] that didn't work, and I couldn't alter and stuff like that. Here's another device. I think it's [01:16:26.460 --> 01:16:32.000] the exact same product. They're just white-labeled different. GL-iNet and Mini Smart Router also [01:16:32.980 --> 01:16:39.840] has all the same functions and features on it. I'm not sure if the Mango is still on the market. [01:16:39.840 --> 01:16:48.120] May be able to buy one used. But a lot of these cheap devices are out there, [01:16:48.120 --> 01:16:57.500] and it gives you a chance to experiment with UART and JTAG and SPI chips and sometimes NAND chips [01:16:57.500 --> 01:17:05.440] and flash chips. I mean, the list goes on and on and on, and they're often cheap. Like I said, [01:17:05.440 --> 01:17:11.620] Luma I like a lot because it has all of those same features, and you can get them for 20-30 [01:17:11.620 --> 01:17:21.340] bucks used. It has the USB. It has the Ethernet. It has UART connectivity. It has NAND flash chips [01:17:21.340 --> 01:17:31.040] on the device. It has SOIC8 SPI flash memory chips on the device. So it's a perfect platform [01:17:31.600 --> 01:17:37.940] for hacking, attacking, experimenting. The pin glitch works on it also as an example. [01:17:42.610 --> 01:17:49.390] Awesome. I was just catching up in the chat. It was a F-E-I-T, however you pronounce that. It [01:17:49.390 --> 01:17:55.310] was a fight bulb that I had from Costco that I just decided to put and leave in the drawer because [01:17:56.290 --> 01:17:58.770] just didn't feel very secure about it.