1 00:00:00,240 --> 00:00:03,630 - Let's welcome Lennert Wouter from Belgium, 2 00:00:03,630 --> 00:00:06,033 talking about Starlink compromise. 3 00:00:06,970 --> 00:00:09,970 (audience applauds) 4 00:00:13,290 --> 00:00:14,610 - Okay, good morning, everyone. 5 00:00:14,610 --> 00:00:16,260 Thank you for being here. 6 00:00:16,260 --> 00:00:18,577 This talk is titled "Glitched on earth by humans. 7 00:00:18,577 --> 00:00:20,167 "A black-box security evaluation 8 00:00:20,167 --> 00:00:22,587 "of the SpaceX Starlink user terminal". 9 00:00:23,730 --> 00:00:25,560 A quick introduction on Starlink. 10 00:00:25,560 --> 00:00:26,760 I guess everyone knows this, 11 00:00:26,760 --> 00:00:29,220 but for every satellite internet system, 12 00:00:29,220 --> 00:00:31,950 you need a space segment and an Earth segment. 13 00:00:31,950 --> 00:00:34,500 In the space segment, we have satellites. 14 00:00:34,500 --> 00:00:36,810 These satellites can, in some cases, 15 00:00:36,810 --> 00:00:39,243 communicate with each other over laser links. 16 00:00:40,080 --> 00:00:42,780 And the idea is that you, as a user, buy a user terminal 17 00:00:42,780 --> 00:00:45,240 that sends your data up to the satellite, 18 00:00:45,240 --> 00:00:48,660 the satellite relays it back down to Earth to a gateway, 19 00:00:48,660 --> 00:00:51,093 and in this way you can access the internet. 20 00:00:52,260 --> 00:00:55,160 Now, for some reason, SpaceX wouldn't give me a satellite, 21 00:00:56,070 --> 00:00:58,380 which meant that I had to buy a user terminal 22 00:00:58,380 --> 00:01:00,783 and try to get in it that way. 23 00:01:02,580 --> 00:01:04,050 So we bought a user terminal, 24 00:01:04,050 --> 00:01:06,480 we put it up on the roof of a university building 25 00:01:06,480 --> 00:01:08,760 and connected it to the network. 26 00:01:08,760 --> 00:01:10,410 Everything was working well, 27 00:01:10,410 --> 00:01:12,930 but at that point we just had a second internet connection 28 00:01:12,930 --> 00:01:14,980 and there wasn't that much to do with it. 29 00:01:15,960 --> 00:01:18,450 So I started looking at what other people had done 30 00:01:18,450 --> 00:01:21,150 or what other people were working on at the time. 31 00:01:21,150 --> 00:01:25,590 So the top three, or the first three videos on the top, 32 00:01:25,590 --> 00:01:27,240 were already out when I started working 33 00:01:27,240 --> 00:01:28,440 on that user terminal. 34 00:01:28,440 --> 00:01:30,630 So some people had bought a user terminal, 35 00:01:30,630 --> 00:01:33,390 tore it open to see what was on the inside. 36 00:01:33,390 --> 00:01:36,180 The video by "The Signal Pad" went in more depth 37 00:01:36,180 --> 00:01:38,670 about the RF side of things. 38 00:01:38,670 --> 00:01:40,800 And then when I started working, 39 00:01:40,800 --> 00:01:43,059 some other people were also working on it, 40 00:01:43,059 --> 00:01:45,690 like Colin O'Flynn did a tear down with a blow torch, 41 00:01:45,690 --> 00:01:47,580 and he started poking at the board 42 00:01:47,580 --> 00:01:49,710 a bit more than the others. 43 00:01:49,710 --> 00:01:52,110 There's a nice blog post by Oleg 44 00:01:52,110 --> 00:01:56,250 on the wifi router that you get with the system. 45 00:01:56,250 --> 00:01:58,110 And then Dan Murray did a tear down 46 00:01:58,110 --> 00:02:00,150 of the square user terminal 47 00:02:00,150 --> 00:02:02,193 and even made a 3D printed case for it. 48 00:02:03,360 --> 00:02:05,280 Now, one thing that was missing, for me at least, 49 00:02:05,280 --> 00:02:07,200 in all of these videos and teardowns 50 00:02:07,200 --> 00:02:08,910 was that I was mostly interested 51 00:02:08,910 --> 00:02:10,830 in the security of this system. 52 00:02:10,830 --> 00:02:12,603 And that's what this talk is about. 53 00:02:14,010 --> 00:02:15,480 Now I think I've already mentioned 54 00:02:15,480 --> 00:02:17,940 there's a few hardware revisions of the user terminal, 55 00:02:17,940 --> 00:02:19,470 but I think very few people realize 56 00:02:19,470 --> 00:02:22,890 how many hardware revisions there have been over the time. 57 00:02:22,890 --> 00:02:24,270 So the circular user terminal, 58 00:02:24,270 --> 00:02:25,830 the one that we have here on the stage, 59 00:02:25,830 --> 00:02:28,470 is about 60 centimeters in diameter. 60 00:02:28,470 --> 00:02:30,270 It was meant for residential use, and as you can see, 61 00:02:30,270 --> 00:02:33,660 there have been multiple hardware revisions of it. 62 00:02:33,660 --> 00:02:37,260 You can also see that there was an SoC cut 3 and cut 4, 63 00:02:37,260 --> 00:02:38,220 so meaning that there have been 64 00:02:38,220 --> 00:02:41,403 at least two silicon revisions of the main system on chip. 65 00:02:42,840 --> 00:02:45,420 Then we had the square user terminal. 66 00:02:45,420 --> 00:02:47,220 This is often referred to as 67 00:02:47,220 --> 00:02:50,070 the third revision of the hardware, 68 00:02:50,070 --> 00:02:52,170 and you can see even of that third revision 69 00:02:52,170 --> 00:02:54,780 there have been multiple revisions. 70 00:02:54,780 --> 00:02:57,420 Then there's also a high performance user terminal now, 71 00:02:57,420 --> 00:02:59,640 that's more meant for business use. 72 00:02:59,640 --> 00:03:02,160 And finally we have transceiver units. 73 00:03:02,160 --> 00:03:03,630 There's some information about these 74 00:03:03,630 --> 00:03:05,460 in the code on the user terminal, 75 00:03:05,460 --> 00:03:07,590 but there's not a lot of public information. 76 00:03:07,590 --> 00:03:09,510 So the idea here is that you have a transceiver box 77 00:03:09,510 --> 00:03:11,610 to which an external antenna is connected. 78 00:03:12,930 --> 00:03:14,790 Now the research I did 79 00:03:14,790 --> 00:03:17,580 used the user terminals we could buy at the time, 80 00:03:17,580 --> 00:03:18,840 and that meant that we worked 81 00:03:18,840 --> 00:03:21,813 with a rev2_proto2 and a rev2_proto4. 82 00:03:22,650 --> 00:03:24,480 At some point I broke one of the two, 83 00:03:24,480 --> 00:03:25,860 and then it was replaced 84 00:03:25,860 --> 00:03:28,650 and that's how I had basically two dishes. 85 00:03:28,650 --> 00:03:30,266 So what you can see is that 86 00:03:30,266 --> 00:03:33,000 I worked with an SoC cut 3 and SoC cut 4. 87 00:03:33,000 --> 00:03:34,890 I did the attack on both, 88 00:03:34,890 --> 00:03:36,630 and this also means that the attack will work 89 00:03:36,630 --> 00:03:39,330 on all of the other hardware that's listed on the screen, 90 00:03:39,330 --> 00:03:43,533 because they all use an SoC cut 4, at least for now. 91 00:03:45,330 --> 00:03:47,610 So this is what you get if you open up the user terminal, 92 00:03:47,610 --> 00:03:50,310 you're greeted with this big metal shield on the inside. 93 00:03:50,310 --> 00:03:51,780 There's a small cut-out that reveals 94 00:03:51,780 --> 00:03:55,110 part of the printed circuit board with three connectors. 95 00:03:55,110 --> 00:03:57,720 The first connector is for power over ethernet. 96 00:03:57,720 --> 00:03:59,940 The second one is for motors, 97 00:03:59,940 --> 00:04:02,940 so normally this dish can orient itself 98 00:04:02,940 --> 00:04:04,263 towards the satellites. 99 00:04:05,550 --> 00:04:07,890 And then the third unpopulated connector in this case 100 00:04:07,890 --> 00:04:09,600 is a UART connector, 101 00:04:09,600 --> 00:04:12,390 and UART is always interesting if you're hacking hardware 102 00:04:12,390 --> 00:04:15,243 because oftentimes it leads to a root shell quite easily. 103 00:04:16,140 --> 00:04:18,060 Now, that wasn't the case here. 104 00:04:18,060 --> 00:04:20,970 So you can see that while the user terminal is booting, 105 00:04:20,970 --> 00:04:22,470 it prints out some information. 106 00:04:22,470 --> 00:04:24,900 You can see it's using the U-Boot boot loader, 107 00:04:24,900 --> 00:04:26,742 but you can also see that SpaceX 108 00:04:26,742 --> 00:04:29,460 had disabled all of the serial input. 109 00:04:29,460 --> 00:04:32,790 So whatever input you would provide over the serial console, 110 00:04:32,790 --> 00:04:35,603 it would be ignored and you wouldn't be able to do anything. 111 00:04:36,480 --> 00:04:38,880 If you allow the dish to boot fully, 112 00:04:38,880 --> 00:04:40,830 then you get this login prompt. 113 00:04:40,830 --> 00:04:43,260 You can try it to enter as many passwords as you want, 114 00:04:43,260 --> 00:04:44,370 it won't work, 115 00:04:44,370 --> 00:04:46,560 because there's not really a password set, 116 00:04:46,560 --> 00:04:47,580 as long as the dish 117 00:04:47,580 --> 00:04:49,730 doesn't believe it is development hardware. 118 00:04:52,020 --> 00:04:53,670 So that meant we had to go deeper. 119 00:04:53,670 --> 00:04:57,000 So we removed the metal shield from the PCB, 120 00:04:57,000 --> 00:04:59,340 and then you see this big PCB on the inside, 121 00:04:59,340 --> 00:05:01,040 the one that's also here on stage. 122 00:05:02,070 --> 00:05:03,540 And there's a few interesting areas 123 00:05:03,540 --> 00:05:04,890 on this board that we can mark. 124 00:05:04,890 --> 00:05:07,980 So you have the area with the GPS receiver, 125 00:05:07,980 --> 00:05:10,710 there's an area with a clock generation circuit 126 00:05:10,710 --> 00:05:13,200 that's used to generate a clock for the SoC 127 00:05:13,200 --> 00:05:15,120 and for some other parts, 128 00:05:15,120 --> 00:05:19,020 and then there's a power over ethernet circuit, of course. 129 00:05:19,020 --> 00:05:21,720 And then the part we're most interested in is the SoC. 130 00:05:22,590 --> 00:05:26,190 So this part contains the SoC, some eMMC memory, and DM. 131 00:05:26,190 --> 00:05:28,320 And then there's of course, one obvious part 132 00:05:28,320 --> 00:05:31,830 on this entire printed circuit board that I haven't circled, 133 00:05:31,830 --> 00:05:35,250 and that's all of the other parts basically. 134 00:05:35,250 --> 00:05:38,160 And the remainder of the hardware looks like this. 135 00:05:38,160 --> 00:05:42,720 So there's a digital beamformer made by STMicroelectronics, 136 00:05:42,720 --> 00:05:44,700 it's code named "Shiraz", 137 00:05:44,700 --> 00:05:45,727 and each of these beamformers 138 00:05:45,727 --> 00:05:48,390 is paired with 16 front-end modules. 139 00:05:48,390 --> 00:05:51,240 So these are the smaller chips on the scheme 140 00:05:51,240 --> 00:05:52,857 and their code name is "Pulsar". 141 00:05:53,940 --> 00:05:56,010 Now, when I was working on one of these dishes, 142 00:05:56,010 --> 00:05:59,430 I had broken it and SpaceX was nice enough to replace it, 143 00:05:59,430 --> 00:06:01,650 but I didn't want to just let it go to waste. 144 00:06:01,650 --> 00:06:04,560 So I desoldered a few of these chips from the board, 145 00:06:04,560 --> 00:06:06,660 and I sent them off to John McMaster, 146 00:06:06,660 --> 00:06:09,180 and John was nice enough to decapsulate these chips for us 147 00:06:09,180 --> 00:06:10,710 and image them. 148 00:06:10,710 --> 00:06:12,750 And the pictures are online now, 149 00:06:12,750 --> 00:06:14,490 so you can view these pictures 150 00:06:14,490 --> 00:06:16,860 in high resolution in your browser. 151 00:06:16,860 --> 00:06:17,940 And there's a few interesting things 152 00:06:17,940 --> 00:06:19,410 you can see here in the picture. 153 00:06:19,410 --> 00:06:22,500 So the chip on the left is the beamformer, 154 00:06:22,500 --> 00:06:24,960 and you can see that the same pattern 155 00:06:24,960 --> 00:06:26,880 is basically repeated 16 times, 156 00:06:26,880 --> 00:06:28,350 and these are the 16 channels 157 00:06:28,350 --> 00:06:30,600 for all of the front-end modules. 158 00:06:30,600 --> 00:06:32,400 On the right you see a front-end module, 159 00:06:32,400 --> 00:06:33,990 which is divided into two parts, 160 00:06:33,990 --> 00:06:37,833 and it has basically a receive and a transmit part. 161 00:06:40,020 --> 00:06:41,133 Now this is the area on the PCB 162 00:06:41,133 --> 00:06:43,410 that we are most interested in for this talk, 163 00:06:43,410 --> 00:06:45,390 and it contains the system-on-chip. 164 00:06:45,390 --> 00:06:47,460 The system-on-chip is a custom quad-core 165 00:06:47,460 --> 00:06:51,990 ARM Cortex-A53 processor made by ST, and as I said, 166 00:06:51,990 --> 00:06:54,780 there have been multiple silicon revisions of this chip. 167 00:06:54,780 --> 00:06:57,810 The code for this one is "Catson". 168 00:06:57,810 --> 00:07:00,750 You can also see that there's a separate secure element, 169 00:07:00,750 --> 00:07:02,430 and at the end of the talk, 170 00:07:02,430 --> 00:07:05,040 I'll give a bit more details about what this is used for. 171 00:07:05,040 --> 00:07:07,080 Then we have some eMMC memory, 172 00:07:07,080 --> 00:07:09,840 so this stores all of the firmware of the dish. 173 00:07:09,840 --> 00:07:12,753 And then finally we have eight gigabits of DDR3. 174 00:07:14,400 --> 00:07:15,510 In the left on the slide 175 00:07:15,510 --> 00:07:18,090 you can see some pull up and pull down resistors, 176 00:07:18,090 --> 00:07:20,460 and these are basically used to indicate to the SoC 177 00:07:20,460 --> 00:07:22,710 which hardware revision of the board this is. 178 00:07:25,140 --> 00:07:26,670 Now what you can see on this picture, as well, 179 00:07:26,670 --> 00:07:27,600 for the system-on-chip, 180 00:07:27,600 --> 00:07:30,180 is that it has this metal shield on top, 181 00:07:30,180 --> 00:07:32,610 and this means that it's a flip-chip package 182 00:07:32,610 --> 00:07:34,560 with an integrated heat spreader. 183 00:07:34,560 --> 00:07:35,820 If you remove the heat spreader, 184 00:07:35,820 --> 00:07:37,890 you see the backside of the die. 185 00:07:37,890 --> 00:07:39,510 Backside of the die means that you can also 186 00:07:39,510 --> 00:07:42,510 make images of the chip through the backside. 187 00:07:42,510 --> 00:07:44,160 So this is a picture we made in our lab 188 00:07:44,160 --> 00:07:46,413 with a laser fault injection setup, 189 00:07:47,670 --> 00:07:49,800 and a picture like this is useful 190 00:07:49,800 --> 00:07:51,600 if you're trying to do physical attacks, 191 00:07:51,600 --> 00:07:53,010 because for some physical attacks 192 00:07:53,010 --> 00:07:56,160 you want to target a specific area of the die. 193 00:07:56,160 --> 00:07:58,320 So one thing you can see on the bottom right corner 194 00:07:58,320 --> 00:08:01,680 are the four CPU cores that this chip has. 195 00:08:01,680 --> 00:08:04,170 I donated this picture to the Siliconpr0n project 196 00:08:04,170 --> 00:08:05,720 so you can also view it online. 197 00:08:08,190 --> 00:08:09,480 So the first step now was 198 00:08:09,480 --> 00:08:11,940 to extract the firmware from the dish 199 00:08:11,940 --> 00:08:14,340 in the hopes of finding an easy software vulnerability 200 00:08:14,340 --> 00:08:15,453 to get into it. 201 00:08:16,440 --> 00:08:20,760 To read an eMMC chip you basically need three test points, 202 00:08:20,760 --> 00:08:23,040 command clock, and data zero. 203 00:08:23,040 --> 00:08:25,560 The way I identified them is by soldering wires 204 00:08:25,560 --> 00:08:27,450 to all of these test points, 205 00:08:27,450 --> 00:08:29,700 then connecting those to a logic analyzer, 206 00:08:29,700 --> 00:08:31,140 restarting the user terminal, 207 00:08:31,140 --> 00:08:32,880 and then by just looking at these signals 208 00:08:32,880 --> 00:08:35,430 you can figure out which signal is clock, 209 00:08:35,430 --> 00:08:37,980 which one is command, and which one is data zero. 210 00:08:37,980 --> 00:08:39,120 I have marked them on the slide, 211 00:08:39,120 --> 00:08:41,843 so if you want to redo this at home it should be easier. 212 00:08:42,900 --> 00:08:44,760 Now an eMMC chip is quite similar 213 00:08:44,760 --> 00:08:46,560 to an SD card in many ways, 214 00:08:46,560 --> 00:08:48,551 and that also means that you can use an SD card reader 215 00:08:48,551 --> 00:08:50,610 to read out the chip. 216 00:08:50,610 --> 00:08:53,010 So on the left, you can see an SD card reader 217 00:08:53,010 --> 00:08:54,840 backed with a level shifter in this case, 218 00:08:54,840 --> 00:08:57,750 because the eMMC is running at one volt eight, 219 00:08:57,750 --> 00:08:58,950 and then you can simply plug in 220 00:08:58,950 --> 00:09:01,170 that SD card reader into your PC, 221 00:09:01,170 --> 00:09:03,720 and just make an image of the chip. 222 00:09:03,720 --> 00:09:05,010 Now, if you want to redo this at home, 223 00:09:05,010 --> 00:09:06,390 I would recommend that you buy 224 00:09:06,390 --> 00:09:09,690 a low voltage eMMC adapter from the expolitee.rs. 225 00:09:09,690 --> 00:09:12,720 These are only $12 and they make your life a lot easier. 226 00:09:12,720 --> 00:09:14,940 The only reason I did what is shown on the left 227 00:09:14,940 --> 00:09:17,103 is that I was too impatient to get one. 228 00:09:19,350 --> 00:09:21,990 Now, once you have a dump of the eMMC, 229 00:09:21,990 --> 00:09:24,330 you can start pulling it apart, 230 00:09:24,330 --> 00:09:26,910 and for this the U-Boot GPL sources that are available 231 00:09:26,910 --> 00:09:29,520 are, yeah, quite helpful. 232 00:09:29,520 --> 00:09:30,630 So what we can see is that there are 233 00:09:30,630 --> 00:09:33,270 multiple trusted firmware boot stages. 234 00:09:33,270 --> 00:09:34,830 These are firmware image packages 235 00:09:34,830 --> 00:09:37,031 that you can unpack with the fiptool. 236 00:09:37,031 --> 00:09:38,520 There's a flattened uImage tree 237 00:09:38,520 --> 00:09:41,520 that you can unpack with u-boot tools, 238 00:09:41,520 --> 00:09:43,290 and there's a SpaceX runtime, 239 00:09:43,290 --> 00:09:44,970 a SpaceX calibration partition 240 00:09:44,970 --> 00:09:47,460 that's specific for every dish, 241 00:09:47,460 --> 00:09:48,930 there's an EDR partition, 242 00:09:48,930 --> 00:09:51,153 and a dish configuration partition. 243 00:09:52,380 --> 00:09:53,850 Now one thing you can already see here 244 00:09:53,850 --> 00:09:56,593 is that the dish is using trusted firmware A, 245 00:09:56,593 --> 00:09:58,920 so a secure boot implementation, 246 00:09:58,920 --> 00:10:00,450 and all of the other partitions 247 00:10:00,450 --> 00:10:04,560 are verity protected or LUKS encrypted. 248 00:10:04,560 --> 00:10:06,060 So this means that if you would just 249 00:10:06,060 --> 00:10:07,530 rewrite the firmware on the eMMC, 250 00:10:07,530 --> 00:10:08,460 the dish wouldn't boot, 251 00:10:08,460 --> 00:10:10,460 and you wouldn't be able to do anything. 252 00:10:11,370 --> 00:10:13,530 If you want more details about how to extract the firmware, 253 00:10:13,530 --> 00:10:16,230 I wrote a blog post on that and it's available online. 254 00:10:17,670 --> 00:10:19,200 So there's quite a few interesting things 255 00:10:19,200 --> 00:10:21,000 that you can find in the firmware. 256 00:10:21,000 --> 00:10:23,580 So one thing people have asked me in the past is, 257 00:10:23,580 --> 00:10:25,530 how does the dish handle its thermals? 258 00:10:25,530 --> 00:10:28,020 How hot can it get before it shuts down? 259 00:10:28,020 --> 00:10:30,270 If you extract the firmware there's actually a file 260 00:10:30,270 --> 00:10:33,750 that nicely explains this in a lot of detail. 261 00:10:33,750 --> 00:10:34,740 Another thing you can find 262 00:10:34,740 --> 00:10:36,900 are all of the RF channels that are being used, 263 00:10:36,900 --> 00:10:38,610 so the uplink and dialing channels, 264 00:10:38,610 --> 00:10:41,190 and what frequencies they operate at. 265 00:10:41,190 --> 00:10:43,350 And you can even find the frequencies of the lasers 266 00:10:43,350 --> 00:10:45,600 that are being used by the satellites, 267 00:10:45,600 --> 00:10:48,270 and this is because some of the code base is shared 268 00:10:48,270 --> 00:10:50,470 between the satellite and the user terminal. 269 00:10:51,960 --> 00:10:53,220 Another interesting thing we found 270 00:10:53,220 --> 00:10:55,260 are development geofences, 271 00:10:55,260 --> 00:10:58,290 so if you have a development user terminal 272 00:10:58,290 --> 00:11:01,056 and you would use it outside of one of these geofences, 273 00:11:01,056 --> 00:11:03,213 then SpaceX would get an alert, basically. 274 00:11:04,770 --> 00:11:07,770 Most of these development geofences make a lot of sense, 275 00:11:07,770 --> 00:11:11,220 so some of them are clearly at SpaceX facilities. 276 00:11:11,220 --> 00:11:13,740 Others make less sense, so for example, 277 00:11:13,740 --> 00:11:16,980 the one on the right is the Connections Museum in Seattle, 278 00:11:16,980 --> 00:11:19,530 and for some reason they have development hardware. 279 00:11:21,000 --> 00:11:23,400 Now, if you zoom in far enough on Google Maps, 280 00:11:23,400 --> 00:11:25,500 you can actually see that there are user terminals 281 00:11:25,500 --> 00:11:27,780 on top of this SpaceX parking lot, 282 00:11:27,780 --> 00:11:30,150 so if someone really wants development hardware, 283 00:11:30,150 --> 00:11:32,283 this might be the easiest way to get it. 284 00:11:34,350 --> 00:11:35,610 Another thing we can see in the code 285 00:11:35,610 --> 00:11:38,820 is that SpaceX is collecting all of telemetry 286 00:11:38,820 --> 00:11:40,800 on how you use the user terminal. 287 00:11:40,800 --> 00:11:43,260 I know some people have mounted user terminals 288 00:11:43,260 --> 00:11:44,700 on top of their car, 289 00:11:44,700 --> 00:11:48,450 I even know someone is here that mounted it in their plane. 290 00:11:48,450 --> 00:11:50,490 And you can be sure that if you do that sort of thing, 291 00:11:50,490 --> 00:11:51,363 SpaceX will know. 292 00:11:53,460 --> 00:11:54,960 Now that we have the firmware of the dish, 293 00:11:54,960 --> 00:11:56,040 we can also start looking at 294 00:11:56,040 --> 00:11:58,890 how this login prompt is implemented. 295 00:11:58,890 --> 00:12:01,440 And we can see that it's a simple shell script, basically, 296 00:12:01,440 --> 00:12:03,870 that prints development login enabled. 297 00:12:03,870 --> 00:12:06,270 then it checks if this is a production unit 298 00:12:06,270 --> 00:12:07,380 or a development unit, 299 00:12:07,380 --> 00:12:11,370 and then accordingly it prints "yes" and sets a password, 300 00:12:11,370 --> 00:12:14,013 or it prints "no" and you're not allowed to log in. 301 00:12:15,300 --> 00:12:19,440 Now, if you look at this from a more physical perspective, 302 00:12:19,440 --> 00:12:22,350 this is what the logic analyzer trace looks like 303 00:12:22,350 --> 00:12:24,270 for this UART output. 304 00:12:24,270 --> 00:12:26,910 So the dish prints development login enabled, 305 00:12:26,910 --> 00:12:29,860 then there's a two millisecond gap, and then it says, "no". 306 00:12:30,720 --> 00:12:32,610 Now if we want to get into this user terminal, 307 00:12:32,610 --> 00:12:33,780 it would be very convenient 308 00:12:33,780 --> 00:12:36,150 if the dish would think it's development hardware, 309 00:12:36,150 --> 00:12:38,373 and then prints "yes" so that we can log in. 310 00:12:39,450 --> 00:12:40,890 Now how can we make it believe 311 00:12:40,890 --> 00:12:42,660 that it is development hardware? 312 00:12:42,660 --> 00:12:44,613 Well we did this using fault injection. 313 00:12:45,510 --> 00:12:47,640 And fault injection, 314 00:12:47,640 --> 00:12:49,910 there's a lot of different ways of doing it. 315 00:12:49,910 --> 00:12:52,320 In this case, as I said, it's a flip-chip package 316 00:12:52,320 --> 00:12:54,660 and the backside of the die is exposed. 317 00:12:54,660 --> 00:12:56,490 And then oftentimes we start thinking about 318 00:12:56,490 --> 00:12:59,640 very fancy types of attacks like laser fault injection, 319 00:12:59,640 --> 00:13:01,743 body bias injection, or EMFI, 320 00:13:03,000 --> 00:13:04,620 but we had a problem. 321 00:13:04,620 --> 00:13:06,930 This PCB is so big that it doesn't fit 322 00:13:06,930 --> 00:13:08,250 on any of the lab equipment 323 00:13:08,250 --> 00:13:11,910 we have to do these more sophisticated attacks. 324 00:13:11,910 --> 00:13:14,700 And of course, if you would want to do 325 00:13:14,700 --> 00:13:16,080 a laser fault injection attack 326 00:13:16,080 --> 00:13:17,820 while the dish is mounted on a roof, 327 00:13:17,820 --> 00:13:21,660 that wouldn't be very, very easy to do. 328 00:13:21,660 --> 00:13:25,680 So the first picture on the left is a microstepping table. 329 00:13:25,680 --> 00:13:26,760 You could say, that it's used 330 00:13:26,760 --> 00:13:30,810 to accurately position EMFI equipment on top of the die, 331 00:13:30,810 --> 00:13:32,250 and you can see the dish is way bigger 332 00:13:32,250 --> 00:13:33,960 than the setup itself. 333 00:13:33,960 --> 00:13:35,790 On the right we have a metal box 334 00:13:35,790 --> 00:13:38,970 that contains a laser fault injection setup on the inside, 335 00:13:38,970 --> 00:13:40,970 and the dish wouldn't even fit in there. 336 00:13:42,270 --> 00:13:43,560 Another problem we faced is that 337 00:13:43,560 --> 00:13:46,620 there are no development kits for this chip available, 338 00:13:46,620 --> 00:13:49,470 so this means that the attack was completely black box. 339 00:13:49,470 --> 00:13:51,090 We didn't have any data sheets, 340 00:13:51,090 --> 00:13:53,340 we didn't have open development samples. 341 00:13:53,340 --> 00:13:56,220 So all of the work in figuring out 342 00:13:56,220 --> 00:13:58,380 glitch parameters and offsets, 343 00:13:58,380 --> 00:14:00,933 yeah, it takes more effort this way, let's say. 344 00:14:02,550 --> 00:14:04,470 And there's a few more attack factors we can look at. 345 00:14:04,470 --> 00:14:07,050 We can look at the clock signal to the SoC, 346 00:14:07,050 --> 00:14:09,510 but most of the time there's PLLs in these chips 347 00:14:09,510 --> 00:14:12,390 that sort of eat your clock glitches. 348 00:14:12,390 --> 00:14:14,340 There's a reset line that we could play with, 349 00:14:14,340 --> 00:14:17,343 but ultimately I chose to attempt voltage fault injection. 350 00:14:18,510 --> 00:14:20,850 So initially we started with a very simple setup. 351 00:14:20,850 --> 00:14:22,800 So we have a ChipWhisperer-Lite 352 00:14:22,800 --> 00:14:25,450 connected to the core voltage supply of the main SoC, 353 00:14:26,850 --> 00:14:28,680 and this ChipWhisperer will basically 354 00:14:28,680 --> 00:14:32,430 momentarily short the core voltage to ground, 355 00:14:32,430 --> 00:14:34,053 and this can cause a glitch. 356 00:14:35,220 --> 00:14:36,450 Now, as you can see, I didn't remove 357 00:14:36,450 --> 00:14:38,850 any of the decoupling capacitors from the board 358 00:14:38,850 --> 00:14:40,410 because we are trying to glitch it 359 00:14:40,410 --> 00:14:42,390 while it's already running Linux, 360 00:14:42,390 --> 00:14:43,440 and at this point you could say 361 00:14:43,440 --> 00:14:45,810 that the SoC is already unstable 362 00:14:45,810 --> 00:14:48,513 because it's being pushed to higher clock frequencies. 363 00:14:49,650 --> 00:14:51,120 Something that you can't see here on the slide 364 00:14:51,120 --> 00:14:52,440 is an external oscilloscope 365 00:14:52,440 --> 00:14:55,020 that we used to trace the UART signal, 366 00:14:55,020 --> 00:14:57,090 and that then traced the ChipWhisperer. 367 00:14:58,800 --> 00:15:00,180 Now this is an example output 368 00:15:00,180 --> 00:15:02,460 of the sort of results you can get with this. 369 00:15:02,460 --> 00:15:04,890 So the dish prints "development login enabled", 370 00:15:04,890 --> 00:15:06,387 and even prints "yes", 371 00:15:07,380 --> 00:15:08,220 but then there's also 372 00:15:08,220 --> 00:15:10,050 a null pointer dereference in the kernel, 373 00:15:10,050 --> 00:15:12,980 and the entire system comes crashing down, 374 00:15:12,980 --> 00:15:14,670 so you weren't able to log in. 375 00:15:14,670 --> 00:15:15,990 Now, if you try this often enough, 376 00:15:15,990 --> 00:15:19,290 then the dish will print "development login enabled: yes", 377 00:15:19,290 --> 00:15:21,000 you can log with the username "root" 378 00:15:21,000 --> 00:15:22,740 and the password "Falcon", 379 00:15:22,740 --> 00:15:25,800 and you have a root shell on the user terminal. 380 00:15:25,800 --> 00:15:27,030 So this was nice for us, 381 00:15:27,030 --> 00:15:28,800 because it meant that the proof of concept worked 382 00:15:28,800 --> 00:15:31,020 and we knew that the SoC is at least 383 00:15:31,020 --> 00:15:34,500 somewhat susceptible to voltage glitches, 384 00:15:34,500 --> 00:15:37,740 and the attack was also reproduced by the SpaceX team. 385 00:15:37,740 --> 00:15:40,863 So it's easy to produce undesirable faults, 386 00:15:41,850 --> 00:15:44,160 but the issue with this attack is that it's very slow. 387 00:15:44,160 --> 00:15:46,350 So we have to reboot to the user terminal, 388 00:15:46,350 --> 00:15:48,420 then glitch it and hope we get lucky, 389 00:15:48,420 --> 00:15:51,450 and you can only do this once every 12 seconds. 390 00:15:51,450 --> 00:15:54,273 So this meant that it's a very unreliable attack. 391 00:15:55,740 --> 00:15:58,230 So I decided I would move up in the boot chain 392 00:15:58,230 --> 00:16:01,080 and go to the early boot stages to try and do the attack. 393 00:16:02,370 --> 00:16:06,690 So because this dish implements ARM trusted firmware 394 00:16:06,690 --> 00:16:09,900 it has a ROM boot loader, of course, in the SoC, 395 00:16:09,900 --> 00:16:12,810 and this ROM boot loader reads a root of trust public key 396 00:16:12,810 --> 00:16:14,013 from eFuses in the SoC. 397 00:16:16,613 --> 00:16:18,690 It will use this rule of trust public key 398 00:16:18,690 --> 00:16:21,120 to cryptographically verify the signature 399 00:16:21,120 --> 00:16:24,360 of all of the consecutive firmware stages. 400 00:16:24,360 --> 00:16:25,530 So in a bit more detail, 401 00:16:25,530 --> 00:16:29,100 the ROM boot loader, or BL1, will load a certificate 402 00:16:29,100 --> 00:16:32,430 related to the second stage from the eMMC. 403 00:16:32,430 --> 00:16:34,320 The certificate was in a custom format 404 00:16:34,320 --> 00:16:36,930 from STMicroelectronics, 405 00:16:36,930 --> 00:16:41,160 and the certificate contains a hash digest over the firmware 406 00:16:41,160 --> 00:16:43,443 and a signature over that digest. 407 00:16:44,880 --> 00:16:46,680 So the next step, of course, for the ROM boot loader 408 00:16:46,680 --> 00:16:48,180 is to verify the certificate, 409 00:16:48,180 --> 00:16:51,090 and it does that by verifying the signature. 410 00:16:51,090 --> 00:16:53,790 Afterwards, if the signature check succeeds, 411 00:16:53,790 --> 00:16:56,490 it loads the firmware itself into memory, 412 00:16:56,490 --> 00:16:59,643 and then verifies the hash digest over the firmware. 413 00:17:00,780 --> 00:17:02,370 Now, if you've done fault injection before, 414 00:17:02,370 --> 00:17:03,900 there's two obvious points here 415 00:17:03,900 --> 00:17:05,730 where you could try to attack. 416 00:17:05,730 --> 00:17:09,840 So one is attacking the certificate signature check, 417 00:17:09,840 --> 00:17:12,063 and the second one is the hash comparison. 418 00:17:13,200 --> 00:17:15,510 Now because this is a completely black box scenario, 419 00:17:15,510 --> 00:17:18,330 we don't really know which point to attack, 420 00:17:18,330 --> 00:17:21,180 we just have to try a lot of different combinations 421 00:17:21,180 --> 00:17:23,913 and be very patient until we get lucky once. 422 00:17:24,990 --> 00:17:26,310 This is the setup that we made 423 00:17:26,310 --> 00:17:31,310 for this initial exploration, you could say, of the attack. 424 00:17:31,470 --> 00:17:33,060 A few tricks that you can apply 425 00:17:33,060 --> 00:17:34,710 in a completely black box scenario 426 00:17:34,710 --> 00:17:38,070 are to try to boot the dish with invalid signatures, 427 00:17:38,070 --> 00:17:41,130 invalid hashes, invalid firmware images, and so on, 428 00:17:41,130 --> 00:17:43,770 and then compare how the boot flow changes. 429 00:17:43,770 --> 00:17:44,910 And this gives you an idea 430 00:17:44,910 --> 00:17:47,790 of what is happening at what point in time. 431 00:17:47,790 --> 00:17:50,430 You can also try to glitch a valid certificate 432 00:17:50,430 --> 00:17:52,920 into a signature verification failure, 433 00:17:52,920 --> 00:17:56,133 and that way you can at least optimize the glitch with. 434 00:17:57,810 --> 00:17:59,040 So the top right of the picture, 435 00:17:59,040 --> 00:18:02,370 you can see an EM probe on the backside of the die, 436 00:18:02,370 --> 00:18:05,460 right in the same corner where the four CPU cores are. 437 00:18:05,460 --> 00:18:07,620 And this EM antenna gives us a nice side-channel, 438 00:18:07,620 --> 00:18:11,073 and gives us some information about what the SoC is doing. 439 00:18:11,966 --> 00:18:12,840 In the bottom right, you can see 440 00:18:12,840 --> 00:18:15,183 that I removed all the decoupling capacitors. 441 00:18:16,080 --> 00:18:18,630 This is required to get the glitch to work, 442 00:18:18,630 --> 00:18:21,420 and the reason for that is that initially when the SoC boots 443 00:18:21,420 --> 00:18:23,250 there's only one core that's running, 444 00:18:23,250 --> 00:18:25,590 and it's running at a much lower clock frequency, 445 00:18:25,590 --> 00:18:28,533 and that makes it less susceptible to voltage glitches. 446 00:18:30,900 --> 00:18:34,980 This is a plot that shows the UART output 447 00:18:34,980 --> 00:18:37,080 and an EM side-channel that was captured 448 00:18:37,080 --> 00:18:39,090 using that EM antenna, 449 00:18:39,090 --> 00:18:41,400 and basically what you see at this point in time 450 00:18:41,400 --> 00:18:44,047 is that the dish prints "I've loaded the certificate, 451 00:18:44,047 --> 00:18:46,527 "and I'm going to start verifying the signature." 452 00:18:47,370 --> 00:18:49,200 And you can see from the EM side-channel 453 00:18:49,200 --> 00:18:52,140 that the signature verification is already starting 454 00:18:52,140 --> 00:18:55,230 when the last byte of this message is being sent out, 455 00:18:55,230 --> 00:18:58,320 and this information for us as an attacker is very useful. 456 00:18:58,320 --> 00:19:00,330 So this side-channel is also very useful, 457 00:19:00,330 --> 00:19:01,620 and this way we can figure out 458 00:19:01,620 --> 00:19:04,320 when the signature verification starts. 459 00:19:04,320 --> 00:19:06,810 So sometimes when you glitch something it's easier 460 00:19:06,810 --> 00:19:09,900 to attack the start of the operation than the end, 461 00:19:09,900 --> 00:19:10,733 because in this way, 462 00:19:10,733 --> 00:19:13,053 you might skip the entire operation altogether. 463 00:19:13,980 --> 00:19:16,050 And that's what ended up working for us. 464 00:19:16,050 --> 00:19:16,883 So if we glitched 465 00:19:16,883 --> 00:19:20,310 at the very start of the signature verification, 466 00:19:20,310 --> 00:19:23,070 then it was skipped entirely. 467 00:19:23,070 --> 00:19:24,900 So you can see that the dish printed 468 00:19:24,900 --> 00:19:26,790 that it's loaded the certificate, 469 00:19:26,790 --> 00:19:29,220 it's going to start verifying the signature 470 00:19:29,220 --> 00:19:32,193 and immediately after the same skip check succeeded, 471 00:19:33,090 --> 00:19:35,880 so we skipped the entire process. 472 00:19:35,880 --> 00:19:38,430 And this you can clearly see in the EM side-channel 473 00:19:38,430 --> 00:19:39,453 if you compare them. 474 00:19:41,550 --> 00:19:43,200 So at this point, we can execute 475 00:19:43,200 --> 00:19:45,900 our own second stage boot loader, 476 00:19:45,900 --> 00:19:48,300 meaning that we can already start 477 00:19:48,300 --> 00:19:50,580 exploring the system in a bit more detail. 478 00:19:50,580 --> 00:19:52,290 And this way I started 479 00:19:52,290 --> 00:19:54,960 reading memory regions on the SoC chip, 480 00:19:54,960 --> 00:19:56,430 and I figured out that the ROM boot loader 481 00:19:56,430 --> 00:19:58,630 is mapped at the address shown on the slide. 482 00:19:59,940 --> 00:20:03,000 And it's also readable from the second stage boot loader, 483 00:20:03,000 --> 00:20:04,980 meaning that we can dump the ROM boot loader 484 00:20:04,980 --> 00:20:06,960 and start analyzing it. 485 00:20:06,960 --> 00:20:09,480 So I emulated the ROM boot loader in Unicorn Engine 486 00:20:09,480 --> 00:20:12,960 and tried fuzzing it with AFL++ in Unicorn mode, 487 00:20:12,960 --> 00:20:17,130 but this didn't result in any software vulnerabilities. 488 00:20:17,130 --> 00:20:18,450 And that's, of course, unfortunate 489 00:20:18,450 --> 00:20:21,390 because that means that we cannot easily scale our attack 490 00:20:21,390 --> 00:20:22,650 and we will have to glitch it 491 00:20:22,650 --> 00:20:25,233 every single time we boot the SoC. 492 00:20:26,790 --> 00:20:28,920 Another thing I did in Unicorn Engine is I tried 493 00:20:28,920 --> 00:20:32,070 to simulate the effect of the faults I was injecting, 494 00:20:32,070 --> 00:20:34,200 and I did this using a very simple fault model 495 00:20:34,200 --> 00:20:36,750 in which we skip a single instruction. 496 00:20:36,750 --> 00:20:38,970 And it turns out that skipping a single instruction 497 00:20:38,970 --> 00:20:43,970 is not sufficient to compromise secure boot in this system 498 00:20:43,980 --> 00:20:46,080 because there are fault injection counter measures 499 00:20:46,080 --> 00:20:48,403 implemented in the ROM boot loader. 500 00:20:49,380 --> 00:20:51,120 It's difficult to say what really happens 501 00:20:51,120 --> 00:20:52,110 when we do our attack, 502 00:20:52,110 --> 00:20:54,150 but I think it's likely that we are skipping, 503 00:20:54,150 --> 00:20:57,453 or modifying at least, multiple instructions. 504 00:21:04,860 --> 00:21:06,393 And my slides no longer work. 505 00:21:07,980 --> 00:21:11,940 Okay, so here's an example of a glitch that was detected 506 00:21:11,940 --> 00:21:14,160 by a counter measure in the ROM boot loader. 507 00:21:14,160 --> 00:21:16,380 So the first part of UART output 508 00:21:16,380 --> 00:21:19,800 is basically saying that it has loaded the certificate, 509 00:21:19,800 --> 00:21:22,320 and it's going to start signature verification. 510 00:21:22,320 --> 00:21:25,080 In this case, we loaded the certificate with a valid, 511 00:21:25,080 --> 00:21:27,000 an invalid signature, 512 00:21:27,000 --> 00:21:28,960 and then of course we glitch the SoC 513 00:21:29,820 --> 00:21:32,643 and it accepts our invalid signature. 514 00:21:33,750 --> 00:21:34,583 Now, at this point, 515 00:21:34,583 --> 00:21:36,360 it's loading the second stage boot loader, 516 00:21:36,360 --> 00:21:37,590 verifying the hash. 517 00:21:37,590 --> 00:21:41,040 The hash is correct, but still at the end of the boot, 518 00:21:41,040 --> 00:21:43,020 it says authentication error, 519 00:21:43,020 --> 00:21:44,880 and this is because one of the counter measures 520 00:21:44,880 --> 00:21:47,013 basically detected our glitching attempt. 521 00:21:48,990 --> 00:21:50,490 Here in the slide, you can see how this 522 00:21:50,490 --> 00:21:52,710 or one of these counter measures is implemented. 523 00:21:52,710 --> 00:21:55,380 So there's some control flow checks, 524 00:21:55,380 --> 00:21:58,860 and there are some redundant operations in the code. 525 00:21:58,860 --> 00:22:00,244 I don't have the time 526 00:22:00,244 --> 00:22:01,650 to go into detail here what's happening, 527 00:22:01,650 --> 00:22:03,963 but you can look at the code in the slide. 528 00:22:06,090 --> 00:22:09,180 Now an issue we had when glitching this chip 529 00:22:09,180 --> 00:22:13,380 is that if we want to bypass signature verification 530 00:22:13,380 --> 00:22:15,002 in the ROM boot loader, 531 00:22:15,002 --> 00:22:16,770 we have to remove all of the decoupling capacitors 532 00:22:16,770 --> 00:22:18,480 to get this to work. 533 00:22:18,480 --> 00:22:20,400 But if we remove all of the decoupling capacitors, 534 00:22:20,400 --> 00:22:23,340 the dish is no longer able to boot completely 535 00:22:23,340 --> 00:22:25,590 because the system becomes too unstable. 536 00:22:25,590 --> 00:22:27,240 And this meant that we had to come up with a way 537 00:22:27,240 --> 00:22:31,050 to enable and disable decoupling capacitors at will. 538 00:22:31,050 --> 00:22:34,500 This took quite a lot of manual experimentation. 539 00:22:34,500 --> 00:22:36,750 I tried different types of MOSFETs, 540 00:22:36,750 --> 00:22:38,730 high side and low side switching, 541 00:22:38,730 --> 00:22:40,380 different gate voltages, 542 00:22:40,380 --> 00:22:42,210 different types of MOSFET drivers, 543 00:22:42,210 --> 00:22:44,730 different capacitor sizes, and of course, 544 00:22:44,730 --> 00:22:46,770 timing how I was turning off and on 545 00:22:46,770 --> 00:22:48,183 the decoupling capacitors. 546 00:22:49,110 --> 00:22:50,310 The picture on the left shows 547 00:22:50,310 --> 00:22:53,880 a hand soldered example that didn't work, 548 00:22:53,880 --> 00:22:56,130 and on the right is the first example that did work. 549 00:22:56,130 --> 00:22:58,560 So we made a small interposed PCB 550 00:22:58,560 --> 00:23:00,798 that you solder to the main board, 551 00:23:00,798 --> 00:23:04,053 and this then allows you to switch on two capacitor banks. 552 00:23:05,130 --> 00:23:06,870 So this meant that we had the full attack 553 00:23:06,870 --> 00:23:07,860 working in the lab. 554 00:23:07,860 --> 00:23:10,590 We could glitch the ROM boot loader, 555 00:23:10,590 --> 00:23:12,870 modify all of the following boot stages 556 00:23:12,870 --> 00:23:15,630 and end up in a root shell on the dish. 557 00:23:15,630 --> 00:23:17,460 But the setup was still using, of course, 558 00:23:17,460 --> 00:23:20,550 an oscilloscope, power supplies, and signal generators, 559 00:23:20,550 --> 00:23:23,970 which would be very impractical if we wanted to do this 560 00:23:23,970 --> 00:23:25,920 on the roof of the university building. 561 00:23:27,150 --> 00:23:28,227 At this point, I contacted SpaceX 562 00:23:28,227 --> 00:23:31,500 and I told them I have the full attack working in the lab, 563 00:23:31,500 --> 00:23:34,500 and they offered to send me a Yubikey that would allow me 564 00:23:34,500 --> 00:23:39,090 to SSH into the user terminal to continue my research, 565 00:23:39,090 --> 00:23:40,170 but at this point I decided 566 00:23:40,170 --> 00:23:42,570 I was already too far down the rabbit hole, 567 00:23:42,570 --> 00:23:44,373 and I didn't accept their offer. 568 00:23:46,530 --> 00:23:49,620 So I decided I was going to make a more mobile setup, 569 00:23:49,620 --> 00:23:51,510 and this is basically the first prototype 570 00:23:51,510 --> 00:23:52,980 of this mobile setup. 571 00:23:52,980 --> 00:23:54,720 It uses a Raspberry Pi Pico, 572 00:23:54,720 --> 00:23:57,480 and that Pico drives basically MOSFETs 573 00:23:57,480 --> 00:24:00,090 to turn on and off the coupling capacitors 574 00:24:00,090 --> 00:24:02,730 and to inject the glitch. 575 00:24:02,730 --> 00:24:05,220 So this is the first working example of this, 576 00:24:05,220 --> 00:24:07,370 but as you can see, it's still quite messy. 577 00:24:08,910 --> 00:24:10,680 So I decided to make a modchip 578 00:24:10,680 --> 00:24:14,094 that we could solder onto the user terminal. 579 00:24:14,094 --> 00:24:17,910 The way I did this is I made a scan of part of the dish, 580 00:24:17,910 --> 00:24:19,380 because it's too big, 581 00:24:19,380 --> 00:24:21,060 and then I loaded it into Inkscape, 582 00:24:21,060 --> 00:24:24,810 and in Inkscape, you can then draw the board layout, 583 00:24:24,810 --> 00:24:27,690 basically, at, yeah, real size. 584 00:24:27,690 --> 00:24:28,860 You can then export this 585 00:24:28,860 --> 00:24:31,113 and load it into KiCad as an edge cut layer. 586 00:24:32,460 --> 00:24:34,917 This is the finished modchip where you can see 587 00:24:34,917 --> 00:24:37,440 that we have a Raspberry Pi microcontroller 588 00:24:37,440 --> 00:24:39,990 over clocked to 250 megahertz, 589 00:24:39,990 --> 00:24:42,510 and that's driving the MOSFET driver. 590 00:24:42,510 --> 00:24:46,980 The MOSFET driver is switching the two decoupling MOSFETs 591 00:24:46,980 --> 00:24:48,420 that allows it to switch on 592 00:24:48,420 --> 00:24:53,040 these two separate decoupling banks, you could say. 593 00:24:53,040 --> 00:24:56,100 And then finally, we have a glitch/crowbar MOSFET 594 00:24:56,100 --> 00:24:58,533 that inserts the actual glitch. 595 00:24:59,430 --> 00:25:02,310 So the board itself is about six centimeter in size. 596 00:25:02,310 --> 00:25:04,590 You can see it also soldered onto the user terminal 597 00:25:04,590 --> 00:25:05,463 here on stage. 598 00:25:07,050 --> 00:25:10,230 And one of the goals for this talk 599 00:25:10,230 --> 00:25:13,080 is that other people can recreate this research, 600 00:25:13,080 --> 00:25:15,630 and can use that to start looking at 601 00:25:15,630 --> 00:25:18,180 the network infrastructure that's behind all of this, 602 00:25:18,180 --> 00:25:21,840 so that people can also look how secure that's implemented. 603 00:25:21,840 --> 00:25:22,770 And because of that, 604 00:25:22,770 --> 00:25:25,200 I made the modchip available on GitHub. 605 00:25:25,200 --> 00:25:28,140 The repository is still private at the moment, 606 00:25:28,140 --> 00:25:29,850 so once I get a minute after the talk, 607 00:25:29,850 --> 00:25:31,053 I will make it public. 608 00:25:32,460 --> 00:25:33,480 This is a picture of the modchip 609 00:25:33,480 --> 00:25:35,180 installed on to the user terminal. 610 00:25:36,305 --> 00:25:38,430 There's a few extra wires that you have to solder as well. 611 00:25:38,430 --> 00:25:41,070 So one wire is used to leach 12 volts 612 00:25:41,070 --> 00:25:42,390 from the user terminal. 613 00:25:42,390 --> 00:25:44,400 One wire is connected to the enable pin 614 00:25:44,400 --> 00:25:45,690 of the voltage regulator, 615 00:25:45,690 --> 00:25:50,580 and basically allows you to power cycle the user terminal. 616 00:25:50,580 --> 00:25:52,620 And then we have a connection to one volt eight 617 00:25:52,620 --> 00:25:53,620 for a level shifter. 618 00:25:55,770 --> 00:25:58,830 This is a setup that someone at the university made for us. 619 00:25:58,830 --> 00:26:01,920 It allows us to hang the dish outside of the lab window, 620 00:26:01,920 --> 00:26:04,770 and this is more convenient than always going up to the roof 621 00:26:04,770 --> 00:26:07,053 when something isn't working, and so on. 622 00:26:09,390 --> 00:26:11,580 Now, everything was working, 623 00:26:11,580 --> 00:26:13,740 I could connect to the Starlink network. 624 00:26:13,740 --> 00:26:15,450 I was planning to start looking at 625 00:26:15,450 --> 00:26:18,270 all of the network infrastructure that was there, 626 00:26:18,270 --> 00:26:20,190 and then I made a big mistake. 627 00:26:20,190 --> 00:26:23,280 I was reading on Reddit that the recent firmware updates 628 00:26:23,280 --> 00:26:25,200 made the connection a lot better, 629 00:26:25,200 --> 00:26:26,430 and because the user terminal 630 00:26:26,430 --> 00:26:28,620 is mounted right up to the sky, 631 00:26:28,620 --> 00:26:30,660 the connection wasn't that good. 632 00:26:30,660 --> 00:26:32,490 So I decided I will do a firmware update. 633 00:26:32,490 --> 00:26:34,563 and that will fix my connection issues. 634 00:26:35,730 --> 00:26:37,110 Now it turns out that SpaceX 635 00:26:37,110 --> 00:26:39,480 still had a hidden eFuse that they could blow 636 00:26:39,480 --> 00:26:42,450 to disable all of the UART outputs of this dish. 637 00:26:42,450 --> 00:26:43,620 And my modchip was, of course, 638 00:26:43,620 --> 00:26:45,843 designed to trigger on this UART signal. 639 00:26:46,770 --> 00:26:49,983 So this meant that we had to improvise, adapt, and overcome. 640 00:26:51,870 --> 00:26:54,390 I was quite lucky that I started working on this early, 641 00:26:54,390 --> 00:26:56,220 so I had logic analyzer captures 642 00:26:56,220 --> 00:26:59,850 of both eMMC data and UART outputs, 643 00:26:59,850 --> 00:27:00,780 and I could of course make 644 00:27:00,780 --> 00:27:04,233 a new capture of the dish with the eFuse blown. 645 00:27:05,580 --> 00:27:07,950 And I had this very nice side-channel trace, 646 00:27:07,950 --> 00:27:11,910 and this meant that even on the dish with the blown eFuse, 647 00:27:11,910 --> 00:27:13,830 I could take a new side-channel capture, 648 00:27:13,830 --> 00:27:17,100 and then basically visually find the new offset in time 649 00:27:17,100 --> 00:27:18,700 where I had to insert my glitch. 650 00:27:19,740 --> 00:27:21,780 I slightly modified the modchip 651 00:27:21,780 --> 00:27:24,873 to trigger on eMMC data zero, instead of UART. 652 00:27:25,800 --> 00:27:27,510 It's a bit ugly, but it works. 653 00:27:27,510 --> 00:27:29,280 So if you want to make a nicer solution, 654 00:27:29,280 --> 00:27:33,063 you have to basically spin a new PCB revision. 655 00:27:36,360 --> 00:27:39,453 So at that point you can start exploring the network. 656 00:27:40,290 --> 00:27:43,560 And as it turns out, things don't really get easier here 657 00:27:43,560 --> 00:27:45,060 because all of the interesting communication 658 00:27:45,060 --> 00:27:50,060 with backend service is using mutually authenticated TLS, 659 00:27:50,940 --> 00:27:54,540 and for that, the STSAFE secure element is being used. 660 00:27:54,540 --> 00:27:58,080 So this means that most standard libraries don't work. 661 00:27:58,080 --> 00:27:59,130 I started implementing, 662 00:27:59,130 --> 00:28:01,260 or I have implemented STSAFE support 663 00:28:01,260 --> 00:28:05,310 in the tlslite-ng Python TLS implementation. 664 00:28:05,310 --> 00:28:07,020 And with that I made a Python script 665 00:28:07,020 --> 00:28:09,900 that allows me to fetch the latest firmware updates. 666 00:28:09,900 --> 00:28:11,430 So whenever I see someone post 667 00:28:11,430 --> 00:28:13,320 that they have a new firmware update, 668 00:28:13,320 --> 00:28:15,060 I just take the version number, 669 00:28:15,060 --> 00:28:17,580 I put it into my script, and I can download it. 670 00:28:17,580 --> 00:28:18,420 And this is convenient 671 00:28:18,420 --> 00:28:21,570 because usually firmwares are rolled out in stages, 672 00:28:21,570 --> 00:28:24,960 and you don't always get the newest firmware immediately. 673 00:28:24,960 --> 00:28:27,570 I also started making my own firmware update archive, 674 00:28:27,570 --> 00:28:28,950 and this is convenient to compare 675 00:28:28,950 --> 00:28:31,400 what has been changing over time in the firmware. 676 00:28:33,660 --> 00:28:36,240 Most of the network communication is over IPv6, 677 00:28:36,240 --> 00:28:38,070 which also means that you can't easily scan 678 00:28:38,070 --> 00:28:40,500 all of the hosts that are up there. 679 00:28:40,500 --> 00:28:42,480 One host in particular seems interesting 680 00:28:42,480 --> 00:28:44,520 because it has a lot of open ports. 681 00:28:44,520 --> 00:28:45,480 A lot of the communication 682 00:28:45,480 --> 00:28:48,090 is using GRPC with the backend service, 683 00:28:48,090 --> 00:28:49,500 and again, there's no nice support 684 00:28:49,500 --> 00:28:51,960 for the secure element in these libraries. 685 00:28:51,960 --> 00:28:55,680 So this means that everything takes more time to implement. 686 00:28:55,680 --> 00:28:56,670 And this is also where I hope 687 00:28:56,670 --> 00:28:58,966 that other people will start making a modchip 688 00:28:58,966 --> 00:29:01,716 and will start playing with the network infrastructure. 689 00:29:02,940 --> 00:29:05,490 So, as I said, my hope is people will make these modchips, 690 00:29:05,490 --> 00:29:07,680 will implement them in their own dish, 691 00:29:07,680 --> 00:29:10,350 and then explore the network. 692 00:29:10,350 --> 00:29:12,330 Another thing you can start playing with at that point 693 00:29:12,330 --> 00:29:15,120 is you can play with the digital beamformers. 694 00:29:15,120 --> 00:29:17,100 It seems that they run their own firmware 695 00:29:17,100 --> 00:29:20,160 that you can likely update from the main SoC. 696 00:29:20,160 --> 00:29:22,080 There's also some nice binaries that allow you 697 00:29:22,080 --> 00:29:25,950 to do some diagnostics of the beamformers and so on. 698 00:29:25,950 --> 00:29:28,290 So maybe someone could even try to implement 699 00:29:28,290 --> 00:29:31,293 a point-to- point link using two of these user terminals. 700 00:29:33,930 --> 00:29:35,550 So to conclude, 701 00:29:35,550 --> 00:29:37,260 we were able to bypass secure boot 702 00:29:37,260 --> 00:29:41,100 using voltage fault injection in the ROM boot loader. 703 00:29:41,100 --> 00:29:43,800 This is a quad-core Cortex-A53 processor, 704 00:29:43,800 --> 00:29:44,810 and we did the entire attack 705 00:29:44,810 --> 00:29:46,920 in a completely black box scenario, 706 00:29:46,920 --> 00:29:49,140 meaning we didn't have any documentation, 707 00:29:49,140 --> 00:29:52,590 we didn't have an open development sample, and so on. 708 00:29:52,590 --> 00:29:53,760 We also had to figure out a way 709 00:29:53,760 --> 00:29:56,910 to enable and disable decoupling capacitors. 710 00:29:56,910 --> 00:29:59,460 And it's important to realize that fault injection 711 00:29:59,460 --> 00:30:01,620 counter measures implemented in software 712 00:30:01,620 --> 00:30:03,810 are only as good as the fault model 713 00:30:03,810 --> 00:30:06,000 that is used to implement them. 714 00:30:06,000 --> 00:30:07,620 And in this case, the used fault model 715 00:30:07,620 --> 00:30:10,413 doesn't, yeah, reflect reality. 716 00:30:12,150 --> 00:30:14,070 I think this is a very well designed product, 717 00:30:14,070 --> 00:30:16,920 at least from a security standpoint. 718 00:30:16,920 --> 00:30:18,480 I didn't find any very obvious, 719 00:30:18,480 --> 00:30:20,250 low hanging fruit in the firmware, 720 00:30:20,250 --> 00:30:23,890 which forced me basically to go the hardware route 721 00:30:25,020 --> 00:30:27,690 In contrast to many other devices, 722 00:30:27,690 --> 00:30:28,860 even if you get a root shell 723 00:30:28,860 --> 00:30:31,833 there's no obvious way to come up with a scalable attack. 724 00:30:34,140 --> 00:30:36,000 Of course, I reported all these vulnerabilities 725 00:30:36,000 --> 00:30:38,700 to the SpaceX Product Security Incidents Response Team. 726 00:30:38,700 --> 00:30:40,740 They were very responsive and helpful. 727 00:30:40,740 --> 00:30:42,630 Even when I broke a dish during my research, 728 00:30:42,630 --> 00:30:44,133 they were happy to replace it. 729 00:30:46,260 --> 00:30:49,440 So with that, I'm almost ready to end my talk. 730 00:30:49,440 --> 00:30:51,420 There's a link to the repository on the slide. 731 00:30:51,420 --> 00:30:54,000 You can always email me if you have questions, 732 00:30:54,000 --> 00:30:56,340 or send me a message on Twitter. 733 00:30:56,340 --> 00:30:58,020 But before we really end this talk, 734 00:30:58,020 --> 00:30:59,943 I want to try and do a demo. 735 00:31:02,310 --> 00:31:06,753 Now this is tricky, especially if it caches. 736 00:31:29,250 --> 00:31:31,020 I can already try to answer a question maybe, 737 00:31:31,020 --> 00:31:32,259 in the meantime. 738 00:31:32,259 --> 00:31:33,270 - [MC] Yeah, I can ask? 739 00:31:33,270 --> 00:31:34,163 - [Lennert] Yeah, sure. 740 00:31:37,890 --> 00:31:39,533 - [MC] Anybody have any questions? Huh? 741 00:31:41,485 --> 00:31:43,110 - [Audience Member] How long did it take you 742 00:31:43,110 --> 00:31:46,320 from start to finish, this process? 743 00:31:46,320 --> 00:31:47,670 - Difficult to say. 744 00:31:47,670 --> 00:31:50,490 The entire process from getting the user terminal 745 00:31:50,490 --> 00:31:53,940 to having the full attack working was about one year, 746 00:31:53,940 --> 00:31:56,520 But it's not the only project I worked on in the meantime, 747 00:31:56,520 --> 00:31:59,320 So I don't know exactly how many hours I've spent on it. 748 00:32:04,260 --> 00:32:06,150 - [Audience Member] Did they blow everybody's eFuse, 749 00:32:06,150 --> 00:32:08,580 or just yours because of something you were doing? 750 00:32:08,580 --> 00:32:09,840 And I'm wondering if security 751 00:32:09,840 --> 00:32:12,000 is gonna be increasing and increasing 752 00:32:12,000 --> 00:32:15,240 now that this is deployed in a war in Ukraine? 753 00:32:15,240 --> 00:32:17,460 - So for the first part of the question, 754 00:32:17,460 --> 00:32:19,260 yes, all eFuses are blown. 755 00:32:19,260 --> 00:32:22,200 So if you connect to the UART connected on your dish now, 756 00:32:22,200 --> 00:32:24,420 you won't see any output whatsoever. 757 00:32:24,420 --> 00:32:25,440 I didn't completely get 758 00:32:25,440 --> 00:32:27,390 the second part of the question, sorry. 759 00:32:28,470 --> 00:32:29,520 - [MC] He's talking about the, 760 00:32:29,520 --> 00:32:32,490 is there gonna be any outcome because of the war in Ukraine, 761 00:32:32,490 --> 00:32:34,860 where these have been deployed? 762 00:32:34,860 --> 00:32:36,180 - I still don't really get it. 763 00:32:36,180 --> 00:32:38,040 - The war in Ukraine. 764 00:32:38,040 --> 00:32:40,169 Do you think there's going to be 765 00:32:40,169 --> 00:32:42,030 any outcome like increased security 766 00:32:42,030 --> 00:32:44,630 because they're being deployed in a war environment? 767 00:32:45,990 --> 00:32:47,790 - It's difficult to fix this issue 768 00:32:47,790 --> 00:32:50,760 without making a new revision of the SoC, 769 00:32:50,760 --> 00:32:52,860 and that's probably going to take a while. 770 00:32:58,980 --> 00:33:00,730 So I have some issues with my demo. 771 00:33:05,850 --> 00:33:08,300 It worked fine at Black Hat, but apparently... 772 00:33:09,990 --> 00:33:12,630 - [Audience Member] So first and foremost, a lot of respect. 773 00:33:12,630 --> 00:33:15,513 It's a lot of work, I appreciate it. 774 00:33:16,710 --> 00:33:18,780 So, one of the things you mentioned 775 00:33:18,780 --> 00:33:21,420 that you made your own custom boot loader, 776 00:33:21,420 --> 00:33:23,250 like a second boot loader. 777 00:33:23,250 --> 00:33:26,610 So it was a black box, how you did the second boot loader? 778 00:33:26,610 --> 00:33:28,470 And what was the output of the, like, 779 00:33:28,470 --> 00:33:32,460 memory that you investigated? 780 00:33:32,460 --> 00:33:36,120 So what were the memory outputs, how you actually get it? 781 00:33:36,120 --> 00:33:39,150 Through the serial, or through the...? 782 00:33:39,150 --> 00:33:40,350 - It's very difficult 783 00:33:40,350 --> 00:33:43,050 to understand the questions up here, for some reason. 784 00:33:43,050 --> 00:33:44,772 - [Audience Member] Okay. 785 00:33:44,772 --> 00:33:46,650 You made your own second boot loader, right? 786 00:33:46,650 --> 00:33:48,115 - Yeah. 787 00:33:48,115 --> 00:33:49,448 - [Audience Member] So was it like 788 00:33:49,448 --> 00:33:51,810 a completely custom thing, or you used something? 789 00:33:51,810 --> 00:33:53,843 - I patched the original one, so I- 790 00:33:53,843 --> 00:33:55,360 - [Audience Member] Oh, you patched the original one? 791 00:33:55,360 --> 00:33:56,580 - Yeah, yeah. 792 00:33:56,580 --> 00:33:59,040 I loaded that one into (indistinct), started analyzing it, 793 00:33:59,040 --> 00:34:02,790 and then modified it to do what I wanted basically. 794 00:34:02,790 --> 00:34:05,250 - [Audience Member] Okay, so it was like a binary patch? 795 00:34:05,250 --> 00:34:06,330 - Yeah, binary patch. 796 00:34:06,330 --> 00:34:09,060 - [Audience Member] Okay, and you were getting the output, 797 00:34:09,060 --> 00:34:13,560 like a memory prints through serial, or...? 798 00:34:13,560 --> 00:34:15,090 - I was getting what, sorry? 799 00:34:15,090 --> 00:34:17,042 - [Audience Member] So you mentioned 800 00:34:17,042 --> 00:34:21,550 that you dumped the memory through the second boot loader. 801 00:34:21,550 --> 00:34:22,508 - Yeah. 802 00:34:22,508 --> 00:34:24,390 Oh, yeah, I was outputting the ROM boot loader over serial. 803 00:34:24,390 --> 00:34:25,746 Yeah, exactly. - [Audience Member] Okay, 804 00:34:25,746 --> 00:34:27,150 so it was through the serial, okay. 805 00:34:27,150 --> 00:34:29,013 Yeah, it's pretty cool. Thank you. 806 00:34:33,189 --> 00:34:35,170 - There's one more question up here. 807 00:34:36,990 --> 00:34:38,748 - [Audience Member] Did you ever test it 808 00:34:38,748 --> 00:34:40,597 on the new terminal? 809 00:34:40,597 --> 00:34:43,350 - I didn't, because I don't have a new terminal, 810 00:34:43,350 --> 00:34:44,970 but it's the same SoC, 811 00:34:44,970 --> 00:34:46,820 so the same attack shells were there. 812 00:34:48,030 --> 00:34:50,250 So you basically have to design a new PCB 813 00:34:50,250 --> 00:34:53,034 that fits that board and that will work. 814 00:34:53,034 --> 00:34:55,050 - [Audience Member] And how do you know (indistinct)? 815 00:34:55,050 --> 00:34:57,113 - I know from the code, it's the same chip. 816 00:35:29,670 --> 00:35:30,990 I'm sure that the demo worked 817 00:35:30,990 --> 00:35:33,436 like two hours ago in my hotel room, but... 818 00:35:33,436 --> 00:35:36,120 (audience laughs) 819 00:35:36,120 --> 00:35:37,320 Yeah, I guess we'll call it 820 00:35:37,320 --> 00:35:39,120 and then I'll try to set up the demo somewhere else 821 00:35:39,120 --> 00:35:40,970 and then you can see it there, sorry. 822 00:35:42,002 --> 00:35:45,002 (audience applauds)