1 00:00:00,640 --> 00:00:08,200 NAND flash chips, a little different than standard flash chips, be a little more problematic. 2 00:00:08,200 --> 00:00:13,040 So we're going to talk about that and kind of step through with a number of demos. 3 00:00:13,040 --> 00:00:15,100 So great, let's go ahead and get started. 4 00:00:15,900 --> 00:00:21,360 So thanks everyone this evening or this afternoon based on where you're at in the United States. 5 00:00:22,140 --> 00:00:26,860 Presentation is NAND chips, introduction to NAND chip extraction and data reconstruction. 6 00:00:27,020 --> 00:00:29,760 This is an intro primer. 7 00:00:30,000 --> 00:00:34,800 We're going to cover a number of different topics and we have like three different demos. 8 00:00:35,020 --> 00:00:37,420 I think you'll get a lot out of this. 9 00:00:37,620 --> 00:00:38,680 So my name is Daryl Hyland. 10 00:00:38,680 --> 00:00:43,560 I'm the Principal Security Researcher for IoT at Rapid7. 11 00:00:43,640 --> 00:00:51,080 So section one, we're going to just give a basic introduction and look at structure. 12 00:00:51,240 --> 00:00:55,440 So what is a NAND flash memory? 13 00:00:55,580 --> 00:00:56,880 Simple, you can read it. 14 00:00:56,880 --> 00:01:03,020 It's non-volatile storage technology that doesn't require power to retain the data. 15 00:01:03,020 --> 00:01:04,340 Pretty straightforward. 16 00:01:04,700 --> 00:01:06,300 See those references there? 17 00:01:06,300 --> 00:01:15,620 If you're interested in learning more in the nitty-gritty, take a screenshot of that real quick because that is great references. 18 00:01:15,680 --> 00:01:27,020 I go back to these quite regularly to kind of refresh myself because some of this stuff can get pretty deep as you're trying to reconstruct data in a number of cases. 19 00:01:27,140 --> 00:01:29,680 So go ahead and get a screenshot of that. 20 00:01:29,680 --> 00:01:31,720 I'm getting ready to jump off of it now. 21 00:01:32,100 --> 00:01:34,580 So a couple of things. 22 00:01:34,580 --> 00:01:41,060 When we start thinking about NAND flash memory chips, you need to go to the data sheet. 23 00:01:41,060 --> 00:01:45,880 You really need to understand how things are laid out. 24 00:01:45,880 --> 00:01:49,740 This will play a part in recovery a number of times. 25 00:01:49,780 --> 00:01:56,780 So this is the memory array structure that lays out the page, the blocks, and the planes. 26 00:01:56,920 --> 00:02:04,040 In this case, the page is 2K in size or 2048 bytes. 27 00:02:04,040 --> 00:02:09,700 And then there's what's referred to as an OOB area, a 64-byte area at the end. 28 00:02:09,780 --> 00:02:11,020 And this is critical. 29 00:02:11,020 --> 00:02:12,080 So what is OOB? 30 00:02:12,080 --> 00:02:12,980 It's out of band. 31 00:02:12,980 --> 00:02:14,440 It's a spare area. 32 00:02:14,440 --> 00:02:24,500 It's used for containing error correction code information, bad block information, and it exists in every page. 33 00:02:24,500 --> 00:02:26,000 So what does that mean? 34 00:02:26,000 --> 00:02:35,740 Generally, what it means is you have all your data jammed full of potential garbage when you're trying to parse it out and rebuild the data. 35 00:02:35,740 --> 00:02:41,060 And this could be impactful and can cause problems in some cases. 36 00:02:41,060 --> 00:02:46,400 So we're going to talk about how we're going to fix that, and we're going to show that in a couple examples. 37 00:02:46,520 --> 00:02:51,760 The OOB area, the out-of-band area, is also laid out in two formats. 38 00:02:51,760 --> 00:02:57,040 One is known as adjacent, and one is known as separate. 39 00:02:57,160 --> 00:03:00,700 If it's laid out, the OOB is laid out adjacent. 40 00:03:00,700 --> 00:03:11,800 So a 2048-byte page would be laid out with a 16K or 16-byte of OOB after every 512 bytes. 41 00:03:11,800 --> 00:03:14,200 This would be an adjacent layout. 42 00:03:14,920 --> 00:03:18,540 The most common I see is what's known as separate. 43 00:03:18,540 --> 00:03:26,160 A separate area is the 64 bytes of data exist at the end of the 2048-byte page. 44 00:03:26,160 --> 00:03:27,960 This is the most common. 45 00:03:27,960 --> 00:03:36,080 But often you need to verify that as you're working through this and trying to remove the data or correct the problem. 46 00:03:36,080 --> 00:03:45,220 Another thing that comes in handy, and this is in reference to a number of the tools that we're going to use today, your chip ID code. 47 00:03:45,220 --> 00:04:07,840 An example, anytime you use a flash memory reader, so you pull a chip out, drop it into a memory chip reader, often it will, when you set it up for that chip, it associates that with a ID, and it'll read the chip, compare the ID on the chip to make sure it matches before it tries to read the data. 48 00:04:07,840 --> 00:04:15,620 Now, a lot of applications out there have a use for this type of chip ID data. 49 00:04:15,620 --> 00:04:18,020 This is out of the datasheet also. 50 00:04:18,020 --> 00:04:28,260 And in this example here, it's showing the datasheet for a S34MS02G1 chip, which is a 512-megabyte NAND flash. 51 00:04:28,260 --> 00:04:32,840 And you can see at the bottom, it shows what that chip ID is for that chip. 52 00:04:32,840 --> 00:04:40,580 And you'll see that we'll use this later on, and we'll probably come back and look at it in the datasheet again when we get ready to do that. 53 00:04:41,860 --> 00:04:44,820 So, at this point, are there any questions? 54 00:04:45,300 --> 00:04:52,340 So, Jonathan, has anyone posted any questions or anyone not have any questions about some of these basic concepts? 55 00:04:53,560 --> 00:04:54,780 Let's see here. 56 00:04:54,780 --> 00:04:58,060 So far, it looks like no questions posted here. 57 00:04:58,380 --> 00:05:02,360 One quick question that is actually coming up here that I'm seeing. 58 00:05:02,520 --> 00:05:19,780 Whenever you're, I guess, pulling firmware from NAND flash, do you have like a consistent philosophy that you follow, such as like always first see if you can, you know, first pull, maybe if you can like log into it via like serial port through UART? 59 00:05:19,780 --> 00:05:24,280 Or do you typically go straight for attempting to dump the NAND flash content? 60 00:05:24,280 --> 00:05:34,320 Yeah, usually the first way if I want to get the data, the most effective way is get the data when it's in a constructed fashion. 61 00:05:34,320 --> 00:05:52,620 That would mean if I can get a console on the device with the entire operating system running, and the entire partitions for all the data laid out, that's easier because then I could easily DD the partitions off the chip in their constructed fashion. 62 00:05:52,840 --> 00:05:56,680 And that would avoid me almost always having to do what we're going to talk about here. 63 00:05:56,780 --> 00:06:15,640 What we're going to talk about here is in that case where you actually have to read the data raw, right off the flash chip, either chip off where you remove the chip and drop it into a reader , or some other methods where you may be able to clip on or hook onto the device and read the raw data out of the chip. 64 00:06:15,780 --> 00:06:22,960 And that's when you get this structure that we're going to be dealing with today, and how to clean it up and a few methods of recovering that. 65 00:06:25,550 --> 00:06:39,110 So I shout out to everyone, if you're interested in interacting or asking questions during this, join the Zoom chat, the Zoom channel that we have set up for the webcast. 66 00:06:39,150 --> 00:06:46,950 Once you're into there, you'll be able to post questions up during the presentation, and hopefully we'll have time and we'll be able to answer them. 67 00:06:46,970 --> 00:06:48,990 So please do that if you can. 68 00:06:48,990 --> 00:06:51,050 It makes this way much more interactive. 69 00:06:51,050 --> 00:06:58,690 Instead of just being a data dump, we have a chance to actually interact with the audience and the people and learn more in this process. 70 00:06:58,950 --> 00:07:01,310 So I'll go ahead and move on. 71 00:07:01,410 --> 00:07:05,370 So section two is a general chip readers. 72 00:07:05,370 --> 00:07:13,330 Since I talked about chip off from the question Jonathan gave us, we get into chip readers. 73 00:07:13,910 --> 00:07:21,310 So when you're interacting with a NAND flash chip, here are the signals you're typically going to need to interact with. 74 00:07:21,310 --> 00:07:32,570 And they go everything from the 8-bit data channel, the bi-directional channel, all the way down to input signal, output signal structure, and some other various pieces. 75 00:07:33,050 --> 00:07:38,130 So if you end up buying an off-the-shelf chip reader, this kind of solves all these problems. 76 00:07:38,130 --> 00:07:41,930 But there was some work done out there by this gentleman here. 77 00:07:41,930 --> 00:07:45,310 I would recommend taking a look at this write-up. 78 00:07:45,310 --> 00:07:54,050 If you're interested in building your own chip reader, this one actually works against a TSOP48 NAND flash chip. 79 00:07:54,050 --> 00:08:01,510 And he uses a technique known as bit banging using this FTDI board that he has here. 80 00:08:01,510 --> 00:08:06,130 He's able to bit bang the data off of the actual chip. 81 00:08:06,210 --> 00:08:15,210 So I would look at looking at what bit banging is, because I'm not going to explain it here, and look at how he's set this thing up. 82 00:08:15,390 --> 00:08:20,770 If you're the hacker mentality and you like the idea of building things your own, I would check this out. 83 00:08:20,770 --> 00:08:21,950 It's kind of cool. 84 00:08:22,950 --> 00:08:30,190 If you're like me and you just like to throw money at it, these chip readers are reasonably inexpensive. 85 00:08:30,270 --> 00:08:35,050 The TI-866 Plus, you get all the sockets with it. 86 00:08:35,050 --> 00:08:36,590 It's like $130. 87 00:08:36,750 --> 00:08:40,370 This will read a number of NAND chips. 88 00:08:40,590 --> 00:08:41,530 Pretty good. 89 00:08:41,530 --> 00:08:43,630 And it uses a TSOP48. 90 00:08:43,710 --> 00:08:48,810 Right below it is a socket that doesn't come with the set that you need to buy. 91 00:08:48,810 --> 00:08:53,070 This socket is for from TSOP32s to 48s. 92 00:08:53,070 --> 00:08:54,770 It's known as NAND08. 93 00:08:54,770 --> 00:08:57,790 This is for larger memory chips. 94 00:08:57,790 --> 00:09:07,810 So anytime you encounter larger NAND flash memory chips in the TSOP48, the one that comes with the kit will not work and only work with smaller memory blocks. 95 00:09:07,810 --> 00:09:10,810 So you need to get the socket for that. 96 00:09:10,810 --> 00:09:19,950 The ProMan isn't made, this model wasn't made anymore, but they do make a similar version. 97 00:09:19,950 --> 00:09:24,050 So if you search for ProMan, you'll find a similar version out there. 98 00:09:24,050 --> 00:09:29,750 The socket below that is designed for 1.8 volts. 99 00:09:29,890 --> 00:09:33,870 The ProMan is typically a 3.3 volt device. 100 00:09:33,990 --> 00:09:38,890 And we're starting to see way more chips in the 1.8 volt arena. 101 00:09:38,890 --> 00:09:40,630 So it's good to have that add-on. 102 00:09:40,630 --> 00:09:44,950 Most of these add-ons are $8, $9, $10 on both of these chip readers. 103 00:09:44,950 --> 00:09:47,110 So they're fairly inexpensive. 104 00:09:47,570 --> 00:10:01,650 The thing I like about the ProMan is if I can't identify a TSOP48 , I can't find the data sheets or not, well, let's say I do have the data sheets and I can't find any information on none of my chip readers. 105 00:10:01,650 --> 00:10:04,170 They don't identify it, they can't detect it. 106 00:10:04,170 --> 00:10:18,330 This will let you hard set page OB block sizes into the actual tool that comes with the application that comes with this, so that you can attempt to read it using that kind of raw information. 107 00:10:18,430 --> 00:10:31,210 And it's been successful several times with me, making it possible for me to read a NAND flash chip where I had the data sheet to identify that structure, but none of my chip readers would recognize the chip. 108 00:10:31,770 --> 00:10:34,730 And the last one's RT809. 109 00:10:34,730 --> 00:10:42,030 And that one's a little more pricey if you buy it Amazon, but I think you can track that one down on AliExpress cheaper. 110 00:10:42,270 --> 00:10:43,690 I like this one. 111 00:10:43,870 --> 00:10:49,910 It's not a bad chip reader, and it has, you can buy a lot of different sockets for it. 112 00:10:50,610 --> 00:10:59,850 Most of the sockets that come with the TL866+, the one on the left, will work on this, all but the TSOP48 sockets. 113 00:11:00,310 --> 00:11:06,310 Because the TSOP48 sockets have a circuitry built into them, so they won't work on this reader. 114 00:11:06,310 --> 00:11:08,450 You have to have a straight pin through. 115 00:11:08,650 --> 00:11:14,930 And the one I have below shows that TSOP48 socket that's a straight pin through. 116 00:11:14,930 --> 00:11:24,410 I also recently had to pull a NAND flash that was a BGA ball girder array, 63 balls on the bottom of it. 117 00:11:24,410 --> 00:11:33,190 And I was able to buy this off AliExpress for the RT809 for about 40 bucks, which isn't bad. 118 00:11:33,350 --> 00:11:48,890 If you get into the high-end chip readers that run, start off at like $1,600, $1,700 and go up for them, the sockets for them start off at $100, $200 and go up into the thousands for BGA sockets. 119 00:11:48,970 --> 00:11:52,010 So, these things are very cost effective. 120 00:11:52,150 --> 00:11:55,930 The sockets are not high quality, so you have to take care of them. 121 00:11:55,930 --> 00:11:58,910 But they're overall, they're pretty good products. 122 00:11:58,910 --> 00:12:05,670 And I use them quite regularly in my lab without issues working with NAND chips. 123 00:12:06,070 --> 00:12:14,530 So, any questions in reference to the chip readers and chip reading process? 124 00:12:16,550 --> 00:12:18,310 One question here. 125 00:12:18,310 --> 00:12:23,830 What are the most challenging NAND packages or pitches to work with that you've encountered? 126 00:12:23,830 --> 00:12:28,770 Is there any package or pitch you would not attempt messing with? 127 00:12:28,850 --> 00:12:33,390 I would never say there's nothing I wouldn't attempt messing with. 128 00:12:33,390 --> 00:12:36,110 I would literally mess with everything. 129 00:12:36,110 --> 00:12:43,310 Probably some of the biggest problem is, obviously, if you're using a chip reader, try to read this. 130 00:12:43,310 --> 00:12:54,220 The BGAs or ball grid array devices are the more problematic, because there may not be a socket available for some of these devices. 131 00:12:54,440 --> 00:13:03,360 In cases like that, if you have the data sheets, you can always go to the process of dead bugging. 132 00:13:03,360 --> 00:13:22,800 That is turning the ball grid array chip on its backside and soldering small 40-gauge wire to the actual balls, and then feed that into a connector or a chip reader or a device for doing bit banging to actually be able to do that. 133 00:13:22,800 --> 00:13:27,280 I have been successful doing that a couple times, but it's a pain in the butt. 134 00:13:27,280 --> 00:13:37,200 It's way much easier to pull the chip with hot air or IR if it's a BGA, clean it up, drop it in some device, close the lid, and have it give you all the data. 135 00:13:37,480 --> 00:13:48,680 But typically, if I need the data off it, and I can't get it any other way other than chip off, I will chip off from the board. 136 00:13:48,680 --> 00:13:52,480 And if necessarily, I will dead bug one. 137 00:13:53,040 --> 00:14:00,300 I mean, yeah, me and you, Jonathan, we worked together at one time where we dead bugged that one weird device. 138 00:14:00,440 --> 00:14:13,520 We had a 0.25 millimeter pitch BGA, and we had to solder 40 wires to it or 20 wires to it to get it hooked up. 139 00:14:13,520 --> 00:14:15,220 So yeah, we're going to try anything. 140 00:14:15,220 --> 00:14:20,160 I'm not going to pass up any potential target if it has data on it that I want. 141 00:14:21,420 --> 00:14:22,340 Makes sense. 142 00:14:22,340 --> 00:14:25,080 And you're definitely bringing back some crazy memories with that. 143 00:14:25,080 --> 00:14:28,140 And actually, you partially answered the next question as well. 144 00:14:28,140 --> 00:14:32,980 The next question was, what hot air tools do you recommend for BGA removal? 145 00:14:34,120 --> 00:14:40,060 Actually, I have both hot air and I have a IR oven. 146 00:14:40,520 --> 00:14:42,680 I like the IR oven. 147 00:14:42,740 --> 00:14:52,900 Once I got it, it's a small it's a small device, it'll take a board that's probably eight by nine, eight by 10 inches or something like that. 148 00:14:52,900 --> 00:14:55,040 To me, that's the sweetest thing in the world. 149 00:14:55,180 --> 00:15:01,040 I usually just stick it in the oven, run it through the cycle that I brings it up to the temperature. 150 00:15:01,040 --> 00:15:06,240 And I take a suction tool, I pull the chip off of it, and then I let the whole board cool down. 151 00:15:07,340 --> 00:15:13,520 Because, you know, it heats up the whole board, you have to watch out for things like plastic components that are on the board. 152 00:15:14,060 --> 00:15:17,080 So you may have to remove those prior to putting them in the oven. 153 00:15:17,080 --> 00:15:20,400 But you can usually pick up one of these IR ovens. 154 00:15:20,400 --> 00:15:26,160 If I remember what was the name of the one I got, it's spelled P-U-H-U-I. 155 00:15:26,560 --> 00:15:31,520 It's a Chinese made product or Asian made product oven that I have. 156 00:15:31,520 --> 00:15:36,460 I think it's a model 2962 is what it is. 157 00:15:36,480 --> 00:15:37,420 Small oven. 158 00:15:37,420 --> 00:15:43,320 I think I only paid like $130, $140 for it, somewhere around there. 159 00:15:43,320 --> 00:15:45,860 And there's a number of products out there like that. 160 00:15:45,860 --> 00:15:50,240 But an infrared is way much better, in my opinion, than hot air. 161 00:15:53,520 --> 00:15:55,120 So... Another question. 162 00:15:55,120 --> 00:15:56,240 Sorry, Daryl. 163 00:15:56,780 --> 00:16:02,140 Elvis Cousin asks, is it hard to reball BGA without killing it to re-solder? 164 00:16:03,040 --> 00:16:03,780 Yes. 165 00:16:03,920 --> 00:16:09,300 It's not that hard. 166 00:16:09,400 --> 00:16:11,920 It's just a process of learning how to do it. 167 00:16:12,260 --> 00:16:17,680 Not to drag this all out, but I had a project where I wanted to learn how to do this. 168 00:16:18,040 --> 00:16:20,660 Because I wanted to get root access on a device. 169 00:16:20,660 --> 00:16:26,560 It had 153 ball BGA embedded multimedia controller on device. 170 00:16:26,740 --> 00:16:28,200 So I used hot air. 171 00:16:28,200 --> 00:16:29,440 I pulled it off. 172 00:16:30,340 --> 00:16:34,160 And I had a couple of devices because I wanted to, in case I killed one of them. 173 00:16:34,160 --> 00:16:38,540 The first one, when I put the balls back on, there's a couple ways of doing it. 174 00:16:38,540 --> 00:16:43,200 You can use screens with paste, or you can use just the balls. 175 00:16:43,320 --> 00:16:45,340 In my case, I just used the balls. 176 00:16:45,620 --> 00:16:51,440 I floated on there correctly, but I overheated the chip and it looked like a chocolate brownie when I was done. 177 00:16:51,640 --> 00:16:56,880 That's when I learned that you don't want to go on these BGA chips. 178 00:16:56,880 --> 00:16:59,200 You don't want to go over about 210. 179 00:16:59,320 --> 00:17:04,660 Well, melting temperature is about 183 degrees Celsius, if I remember right. 180 00:17:04,680 --> 00:17:11,240 And you don't want to go over more than 25, 27 on the temperature in Celsius. 181 00:17:11,240 --> 00:17:18,800 If you hit 215 or higher, it starts causing the fiberglass substrate of the chips to start breaking down. 182 00:17:18,800 --> 00:17:26,740 But if you keep it within those range and you don't shock it by overheating it too quick or cooling it too fast, it'll work. 183 00:17:26,740 --> 00:17:28,260 And I was successful. 184 00:17:28,260 --> 00:17:30,320 The first one I burned up and I failed. 185 00:17:30,320 --> 00:17:32,060 The second one was perfect. 186 00:17:32,060 --> 00:17:40,120 Since then, I've never had a problem ever working with BGAs, either pulling them or putting them back on without damage. 187 00:17:40,120 --> 00:17:43,460 And once I learned those temperature parameters. 188 00:17:46,390 --> 00:17:50,850 Okay, so the next section we want to move into is going to be demo. 189 00:17:50,850 --> 00:17:57,330 So, we're going to get off into the demo area and see how that works out. 190 00:17:57,530 --> 00:18:01,110 Hopefully, we won't have any technical problems. 191 00:18:01,270 --> 00:18:09,550 So, what we're going to do here is we have a flash memory that's been pulled. 192 00:18:09,550 --> 00:18:13,770 This has been pulled from... let's go ahead and look at a couple of them here. 193 00:18:13,770 --> 00:18:19,950 It's pulled from an Arlo device, which is a doorbell, if I remember rightly. 194 00:18:19,990 --> 00:18:24,790 It's actually a kind of like a ring doorbell type product. 195 00:18:24,850 --> 00:18:28,730 Its memory chip was a W25N01GV. 196 00:18:28,750 --> 00:18:33,550 So, typically when you pull this thing, what's the first thing you want to do is binwalk. 197 00:18:33,550 --> 00:18:39,190 And again, binwalk works many times, but sometimes it does not. 198 00:18:39,190 --> 00:18:43,390 So, we'll give this a try and see what happens here. 199 00:18:43,390 --> 00:18:46,470 Hopefully, we won't run into any real technical problems. 200 00:18:46,590 --> 00:18:48,490 And this is kind of the common flow. 201 00:18:48,490 --> 00:18:51,190 We see we hit a squash file system. 202 00:18:51,790 --> 00:18:57,830 We should have at least two squash file systems on there if it's coming off a standard embedded device. 203 00:18:57,830 --> 00:18:59,390 And there's a second one. 204 00:19:00,150 --> 00:19:02,470 And then it kind of hangs right there. 205 00:19:02,630 --> 00:19:08,310 If we sit here, this thing would sit here in idle for hours and not produce anything. 206 00:19:08,310 --> 00:19:09,930 So, we're going to stop that. 207 00:19:10,190 --> 00:19:20,550 So, if we change over to the extraction from binwalk, we can see that it opened up a bunch of stuff, but then there's a squash file system. 208 00:19:26,010 --> 00:19:30,030 So, as we notice, there's nothing in there. 209 00:19:30,870 --> 00:19:37,330 And truthfully, because it went past the squash file system file, it should have put something in there. 210 00:19:39,920 --> 00:19:43,680 So, as we can see, literally nothing in there. 211 00:19:43,680 --> 00:19:47,760 So, for the most part, this didn't work. 212 00:19:47,900 --> 00:19:54,140 This is actually a fresh rebuild of binwalk. 213 00:19:54,140 --> 00:19:59,600 And also, I have a binwalk pro account. 214 00:19:59,600 --> 00:20:06,560 The results are pretty much the same in this particular case because there's some things that have to be dealt with here. 215 00:20:06,560 --> 00:20:17,300 So, let's go ahead and remove this structure just so I don't start running into space issues by blowing all this stuff out of here. 216 00:20:18,480 --> 00:20:20,520 So, what do we want to do? 217 00:20:20,920 --> 00:20:26,640 Well, as we talked earlier, we talked about the actual OOB area. 218 00:20:26,740 --> 00:20:30,220 So, we want to be able to remove that area. 219 00:20:30,220 --> 00:20:33,940 So, we have a tool in here called NandDump. 220 00:20:34,300 --> 00:20:40,320 And at the end of this presentation, I'm going to have links for everything, which will cover all this stuff. 221 00:20:40,420 --> 00:20:44,200 So, here we can actually do input files, output files. 222 00:20:44,200 --> 00:20:46,660 Remember that ID I mentioned to you, chip ID? 223 00:20:46,660 --> 00:20:53,360 We can use chip ID, or we can specify actual page size, OOBs, and the layout. 224 00:20:53,360 --> 00:20:55,300 Remember, adjacent, separate. 225 00:20:55,460 --> 00:21:09,500 So, in this particular case, we are going to... well, before we go ahead and separate the OOB out of here, let's go ahead and look at the data sheet. 226 00:21:09,860 --> 00:21:16,980 So, as we look at the data sheet, we see that it is 2048 bytes by 64. 227 00:21:16,980 --> 00:21:19,980 So, it is in a separate format. 228 00:21:19,980 --> 00:21:23,400 That means the 64 bytes is at the end of the page. 229 00:21:23,400 --> 00:21:24,400 That's a good sign. 230 00:21:24,400 --> 00:21:25,960 That tells us the structure. 231 00:21:25,960 --> 00:21:28,180 You always want to go to the data sheet. 232 00:21:28,420 --> 00:21:36,220 But typically, I always like to dig a little deeper and make sure that the chip hasn't been kind of messed with. 233 00:21:36,680 --> 00:21:38,120 And why I say that? 234 00:21:38,120 --> 00:21:49,660 Because just because the data sheet says this is how the chip's going to be laid out, the manufacturer that actually used the chip, I've seen them do some strange things, to say the least, to the data. 235 00:21:49,660 --> 00:21:59,320 Meaning that, you know, you go and remove the OOB area, thinking you know where it's at, and literally have it not be laid out the same way. 236 00:21:59,320 --> 00:22:02,460 So, we're going to look at this with HexEdit. 237 00:22:02,460 --> 00:22:08,600 So, we're going to look at the raw data of the actual device so we can see what it looks like. 238 00:22:25,150 --> 00:22:26,350 There we go. 239 00:22:27,090 --> 00:22:40,030 So, at this point, we should be able to go to 2048, which would be 800 in hex, and it should be the beginning of the second block. 240 00:22:40,030 --> 00:22:43,090 So, we can see that there's something here. 241 00:22:43,090 --> 00:22:47,750 It looks a little different, but it may not be. 242 00:22:47,750 --> 00:22:49,490 We're not quite sure. 243 00:22:49,810 --> 00:22:51,310 It doesn't really tell us a lot. 244 00:22:51,310 --> 00:22:53,270 So, we could go to the next block. 245 00:22:53,590 --> 00:23:07,370 So, for example, if hex is 800, and we want to, of course, we want to go, remember, is 20, gosh, we get it right here. 246 00:23:07,470 --> 00:23:11,610 So, if we go 2048, we'll get it cleared here in a second. 247 00:23:11,610 --> 00:23:12,270 Try it again. 248 00:23:13,190 --> 00:23:23,950 2048, which would be 800, and we want to go up to the next beginning, which should be 2,112 bytes. 249 00:23:23,950 --> 00:23:33,310 Remember, 2048 plus the 64, and we look at this, it should be at 1040. 250 00:23:33,310 --> 00:23:34,870 So, if we go to 1040, 251 00:23:40,570 --> 00:23:54,250 we still see some interesting things, and this may tell us that this is correct, but I've seen a lot of devices where the actual OOB area was nothing but all Fs and wasn't actually configured. 252 00:23:54,350 --> 00:24:02,770 So, what we're going to do is let's look a little deeper so we can see some patterns, because I'm always a big fan of spotting patterns. 253 00:24:04,810 --> 00:24:12,770 So, we come over here, and get it going, and we're going to search for strings so we can get some data. 254 00:24:12,770 --> 00:24:13,990 So, here we are. 255 00:24:13,990 --> 00:24:19,050 So, we're in an area where there's a lot of strings, and let's scroll down until we see some patterns. 256 00:24:21,370 --> 00:24:23,890 And quickly, we see a pattern right here. 257 00:24:24,530 --> 00:24:26,850 So, got a pattern right there. 258 00:24:27,450 --> 00:24:28,450 So, if that is... 259 00:24:31,670 --> 00:24:37,570 So, we go, hold up, 2112, and go. 260 00:24:37,570 --> 00:24:38,570 So, it'd be 840. 261 00:24:38,570 --> 00:24:41,870 So, we go 840 plus E880. 262 00:24:43,710 --> 00:24:47,870 E880 equals F0C0. 263 00:24:47,870 --> 00:24:52,430 So, the next pattern should be an F0C0. 264 00:24:53,670 --> 00:24:57,390 And we can see that we're starting to see that pattern there also. 265 00:24:57,850 --> 00:25:07,970 So, as we can see, more than likely, we are witnessing the 64 bytes at the end of the 2048 as the OOB area is showing up. 266 00:25:07,970 --> 00:25:15,550 And again, if we look over in the string area, there's no common words, because I would not expect that to be in the area. 267 00:25:15,890 --> 00:25:17,630 So, let's scroll on down to the next one. 268 00:25:17,630 --> 00:25:25,970 There's another thing I like to do sometimes, especially if I'm having problems positively identifying this location. 269 00:25:25,970 --> 00:25:28,770 So, this will involve a little bit of math. 270 00:25:29,510 --> 00:25:32,070 So, I like to use a calculator for that. 271 00:25:32,070 --> 00:25:43,330 So, if we come over here, and we put this in here, like that, and we turn it to decimal . 272 00:25:43,710 --> 00:25:53,230 And then, because the programming calculator does not round off or have decimal points, we want to do this basic. 273 00:25:53,230 --> 00:25:55,870 So, what do we know about the overall structure? 274 00:25:56,150 --> 00:26:02,830 The first OOB area or OOB area showed up after 2048. 275 00:26:02,830 --> 00:26:04,590 So, we had the first 2048. 276 00:26:04,610 --> 00:26:09,230 And then, to get to the next leading ones, we had 2112. 277 00:26:09,230 --> 00:26:10,910 So, we go ahead and subtract. 278 00:26:11,570 --> 00:26:14,370 And hopefully, my math works here and doesn't mess it up. 279 00:26:14,770 --> 00:26:15,850 2048. 280 00:26:16,350 --> 00:26:21,750 And then, divide it by 2112. 281 00:26:22,090 --> 00:26:23,790 And hopefully, we'll get an even number. 282 00:26:23,790 --> 00:26:24,590 And we did. 283 00:26:24,590 --> 00:26:31,550 If you do not get an even number, then this is not mathematically correct for an OOB area. 284 00:26:31,550 --> 00:26:45,830 So, what we're seeing here is 0500F900 is actually the 39,749th page of data in this particular device. 285 00:26:45,930 --> 00:26:46,570 Okay. 286 00:26:46,570 --> 00:26:57,380 So, now that I punished you with some math, we're going to go ahead and strip that out of it. 287 00:27:01,280 --> 00:27:05,800 So, we have this command called NAND Dump PI. 288 00:27:05,800 --> 00:27:09,560 We're going to use .I Arlo for the input. 289 00:27:09,560 --> 00:27:11,560 The layout's separate. 290 00:27:11,800 --> 00:27:14,640 Page size happens to be 2048. 291 00:27:14,640 --> 00:27:16,720 The OOB size is 64. 292 00:27:16,720 --> 00:27:20,740 And then, the output will be Arlo No OOB. 293 00:27:20,860 --> 00:27:22,700 Hopefully, this runs. 294 00:27:22,700 --> 00:27:24,520 And it finished up. 295 00:27:24,820 --> 00:27:33,760 So, there, once we finished up, we have a file that's a little smaller, as you can see, where the OOB's been stripped out of it. 296 00:27:37,730 --> 00:27:45,970 And let's go ahead and run this and see if this works for us. 297 00:27:53,090 --> 00:27:54,790 The first squash system. 298 00:27:54,790 --> 00:27:56,850 You see, the pattern's different now. 299 00:27:56,950 --> 00:28:03,650 And then, we also see that there's an OOB structure also starting to show up. 300 00:28:05,050 --> 00:28:13,610 Often, you'll see inside an operating system on embedded device, you'll see squash file systems, which are typically read-only. 301 00:28:13,810 --> 00:28:17,130 OOB file systems allow read and write. 302 00:28:17,130 --> 00:28:25,350 So, it may be an area that's used dynamically that's being created that can use to read and write data into the device. 303 00:28:25,350 --> 00:28:25,870 Okay. 304 00:28:25,870 --> 00:28:27,850 So, that one actually finished. 305 00:28:27,850 --> 00:28:33,610 So, let's go ahead and jump over here and see if it worked for us. 306 00:28:34,210 --> 00:28:35,370 A little different there. 307 00:28:35,370 --> 00:28:36,750 We see we got three folders. 308 00:28:36,750 --> 00:28:38,590 We have an OOB root system. 309 00:28:38,690 --> 00:28:41,890 So, we go to squash root. 310 00:28:43,570 --> 00:28:45,170 And there you go. 311 00:28:45,170 --> 00:28:53,870 We were actually able to extract this data by effectively removing the out-of-band data within the NAND flash dump. 312 00:28:54,790 --> 00:28:57,690 So, do we have any questions? 313 00:28:59,110 --> 00:29:01,410 Yeah, we got a couple of questions here, T-Dub. 314 00:29:01,410 --> 00:29:05,890 So, Elvis Cousin asks, I have two BGAs on a daughterboard. 315 00:29:05,890 --> 00:29:13,190 Is it likely I can read each individually, or will I need to reassemble them somehow to try to get a squash FS? 316 00:29:13,190 --> 00:29:15,990 And they're also both Intel-based flash. 317 00:29:16,990 --> 00:29:22,690 Oh, you're saying you have two flash memory chips on the device. 318 00:29:23,270 --> 00:29:26,670 Really comes down to how they lay those out. 319 00:29:27,610 --> 00:29:32,770 I would not expect them to stripe across separate chips like that. 320 00:29:32,770 --> 00:29:34,550 I've never seen that. 321 00:29:34,550 --> 00:29:43,330 Often, when I've seen two chips done up like that, each one will contain a different partition, or they may be redundant of each other. 322 00:29:43,330 --> 00:29:47,790 But typically, they'll be partitioned separately on embedded. 323 00:29:47,790 --> 00:29:49,570 That's the way I've seen it. 324 00:29:49,570 --> 00:30:03,590 And I've seen everything from where one chip actually contained the boot, U-boot, and the kernel, and the other one contained the file system, as an example. 325 00:30:03,590 --> 00:30:10,630 So, the only way is to pull them off, examine the data, and make a determination from there to see if you can do it. 326 00:30:10,630 --> 00:30:19,550 Of course, the best solution is if you can get a root console on the device somehow, then obviously, you could figure that out more quickly and DD the partitions off that way. 327 00:30:19,550 --> 00:30:22,490 Which is also the sweetest way of doing it. 328 00:30:23,130 --> 00:30:28,410 But if you have to chip off, yeah, you still may have to do some analysis of them. 329 00:30:29,610 --> 00:30:39,390 Yeah, you kind of pivoted off that, said, both are connected to a common connector, but I don't have a pinout to try to recover a cross connector by soldering something. 330 00:30:40,730 --> 00:30:42,810 Yeah, it's kind of hard to say. 331 00:30:43,330 --> 00:30:57,090 If you have some kind of pictures or images of the data, or not the data, the chips and the layout and the board, shoot them to me sometime, and maybe I can take a look at it and help you come up with a plan of attack. 332 00:30:57,550 --> 00:31:00,810 Like I said, anyone's feel free to reach out to me anytime. 333 00:31:00,810 --> 00:31:05,850 I may or may not have an answer for you, but I'd be more than glad to give you a hand if I can. 334 00:31:06,850 --> 00:31:09,270 One final quick question here that I'm seeing. 335 00:31:09,570 --> 00:31:13,550 So, in this particular case, it looks like you're able to find the data sheet. 336 00:31:13,590 --> 00:31:20,110 Have you ever encountered a NAND chip that you wanted to dump but couldn't identify it or could not locate a data sheet for? 337 00:31:20,110 --> 00:31:22,410 If so, how did you approach that? 338 00:31:23,170 --> 00:31:26,070 Yes, guessing. 339 00:31:27,830 --> 00:31:46,250 Often, if I can't find a data sheet actually for that, I've actually gone out and looked at other chips that may have data sheets that are in that same series or produced by that manufacturer and figure out how they do their layout. 340 00:31:46,290 --> 00:31:58,390 Even though I may not be able to quickly identify the chip ID, there are ways to actually enumerate those, and it usually typically need a data sheet to do that. 341 00:31:58,530 --> 00:32:18,630 But guessing does work, and crazy as can be, I've actually dumped a lot of chips by going, hey, here's a manufacturer, and it seems like most of their chips, or a large portion of them within this structure range, are laid out this way. 342 00:32:18,630 --> 00:32:21,430 They have this page structure, this size. 343 00:32:21,510 --> 00:32:32,110 Often the naming conventions, like here on the screen, W25N01GV, that's one gigabit chip. 344 00:32:32,730 --> 00:32:37,390 And often in the name, you can figure out what the chip is a lot of times. 345 00:32:37,430 --> 00:32:45,150 So, that would be eight bits, 128 kbytes or whatever. 346 00:32:45,690 --> 00:32:54,770 So, it's doable just looking at the name sometimes to pull some typical information out of it, and then guessing on some of the other stuff. 347 00:32:54,770 --> 00:33:00,930 But again, I've also smoked chips by doing weird things to them that obviously didn't work. 348 00:33:00,930 --> 00:33:04,810 So, got to take some caution and take some risk. 349 00:33:05,610 --> 00:33:08,970 But amazingly enough, it can be successful. 350 00:33:08,970 --> 00:33:25,390 One of the things to do also is kind of look at, if you can get a UART console onto the main processor, let's say the main processor has a console, even though you can't get root access to it, capture all the debug data from the boot up. 351 00:33:25,810 --> 00:33:29,690 That can also be very revealing sometimes. 352 00:33:32,050 --> 00:33:34,030 Okay, time to move on. 353 00:33:34,350 --> 00:33:36,970 So, we've kind of done that. 354 00:33:36,970 --> 00:33:38,730 We're able to get the data off that. 355 00:33:38,730 --> 00:33:41,370 I'm going to go ahead and clean this up. 356 00:33:42,310 --> 00:33:47,130 Because we have a couple exercises to go to and I don't want to run out of time. 357 00:33:47,130 --> 00:33:47,730 So, 358 00:33:52,460 --> 00:33:54,640 okay. 359 00:33:54,640 --> 00:34:00,240 So, the next one we want to look at... I'm also going to RM the article 360 00:34:03,530 --> 00:34:04,010 . 361 00:34:04,210 --> 00:34:07,230 So, the next one we want to look at is the Nest. 362 00:34:07,770 --> 00:34:13,710 This actually came from a friend of mine who had his Nest thermostat crash out. 363 00:34:13,710 --> 00:34:15,190 It just died. 364 00:34:15,490 --> 00:34:20,070 He threw it my way, said, hey, can you get any interesting data off of it? 365 00:34:20,070 --> 00:34:25,370 So, and I struggled with getting data off of this, but it was eventually successful. 366 00:34:25,370 --> 00:34:28,670 We're going to show some of this. 367 00:34:28,990 --> 00:34:33,670 There was no confidential data actually extracted from the device. 368 00:34:33,670 --> 00:34:36,670 So, there's no problem with us using it here. 369 00:34:37,070 --> 00:34:44,150 But so, what we want to do is what we're going to use is a process where we're going to create a NAND sim. 370 00:34:44,570 --> 00:34:45,810 So, what does that mean? 371 00:34:45,810 --> 00:34:51,170 We're actually going to simulate a NAND chip in memory. 372 00:34:51,190 --> 00:34:54,230 We're going to use like ModProbe. 373 00:34:54,410 --> 00:35:01,990 If you haven't used ModProbe, ModProbe will let you load kernel modules onto the system. 374 00:35:01,990 --> 00:35:09,290 So, we're going to build a block device using ModProbe kernel modules. 375 00:35:09,290 --> 00:35:13,750 We're going to load those up and then we're going to write the data out to the chip. 376 00:35:14,010 --> 00:35:25,990 We're actually going to tell the data with NAND write to use the OOB data to reconstruct any error corrections and that type of stuff. 377 00:35:25,990 --> 00:35:28,410 And then we'll mount it up. 378 00:35:28,510 --> 00:35:37,530 So, this particular one, I actually ran Benwalk on this and it never recovered anything. 379 00:35:37,530 --> 00:35:41,770 I actually shot it out to good friends at 380 00:35:45,970 --> 00:35:47,890 that do the Benwalk Pro. 381 00:35:48,030 --> 00:35:53,770 And unfortunately, I didn't get back to the system for a couple weeks and it churned out there. 382 00:35:53,770 --> 00:35:58,390 So, I apologize to them again for eating up several terabytes of data. 383 00:35:58,390 --> 00:36:06,050 So, this thing was constructually a pain in the butt and running Benwalk was potentially catastrophic. 384 00:36:06,150 --> 00:36:09,270 It would eat up all your memory and produce nothing. 385 00:36:09,950 --> 00:36:30,430 And I'm not going to run it here, but if you run it, every page or every header for a GIFs to file system or every header for one of those, it would create a folder for it, put nothing in it, and literally eat up terabytes of data in a couple days quickly. 386 00:36:30,470 --> 00:36:32,950 So, let's go ahead and get going here. 387 00:36:32,950 --> 00:36:37,890 So, we're going to load ModProbe MTD, ModProbe Block. 388 00:36:37,890 --> 00:36:40,710 This will help us set up a block device. 389 00:36:41,330 --> 00:36:43,630 And then we're going to go ahead and 390 00:36:48,700 --> 00:36:50,340 we're going to load this up here. 391 00:36:50,340 --> 00:36:58,020 So, the way this works, ModProbe NANDSim, BCH is error correction functionality. 392 00:36:58,460 --> 00:37:02,140 This was the chip, it uses a 8-bit structure. 393 00:37:02,300 --> 00:37:07,120 There's a BCH16 for a 16-bit structure, if that's actually being used. 394 00:37:07,120 --> 00:37:10,640 And this here happens to be the chip ID. 395 00:37:11,000 --> 00:37:19,720 So, if we go over to this particular chip, that is not the one I want. 396 00:37:19,980 --> 00:37:22,560 So, this is the actual chip. 397 00:37:23,040 --> 00:37:26,860 And I believe we go to page 25. 398 00:37:27,380 --> 00:37:29,240 I have this memorized. 399 00:37:30,360 --> 00:37:31,280 Okay. 400 00:37:31,940 --> 00:37:35,540 And this would be the read ID, the ID of the actual chip. 401 00:37:35,540 --> 00:37:38,180 We know this chip is a 2-gig chip. 402 00:37:38,740 --> 00:37:41,400 It's organized in 8-bit structure. 403 00:37:41,640 --> 00:37:45,100 It is a 1.8-volt bit chip. 404 00:37:45,260 --> 00:37:49,880 So, 01 is the first one, AA, 90, 15. 405 00:37:50,060 --> 00:37:56,400 44 isn't used in this case, but it deals with error corrections and multi-plane information. 406 00:37:56,920 --> 00:38:17,800 Multi-plane information, just to make note here, if you have a chip that has multi-planes on it, and you'll see it in the datasheet, it may or may not stripe across the two planes, meaning it puts one block on one plane and one block on the next plane versus putting them contiguously on the same plane. 407 00:38:17,800 --> 00:38:21,160 I have not encountered this, but I have read about it. 408 00:38:21,160 --> 00:38:22,800 So, it's something to be noted. 409 00:38:22,860 --> 00:38:25,980 So, at this point, we're going to go ahead and load this up. 410 00:38:26,280 --> 00:38:42,380 So, now we've loaded up that particular module, kernel module, and now let's go ahead and just look at some information, mtdinfo, and this will tell us a little bit about what we just created. 411 00:38:44,300 --> 00:38:46,600 So, we created a simulated. 412 00:38:46,600 --> 00:38:48,380 It's how many bytes? 413 00:38:49,860 --> 00:38:57,200 256-megabyte chip, 2048, subpage size, 64 bytes, pretty straightforward. 414 00:38:57,200 --> 00:39:00,680 And then we go ahead, and this one may show some errors. 415 00:39:01,400 --> 00:39:04,020 Sometimes it does, sometimes it doesn't. 416 00:39:04,180 --> 00:39:08,600 And we're going to look at this within DMessage. 417 00:39:09,000 --> 00:39:18,360 And if we come down here, we can see that it took the manufacturer ID, chip ID, and information, and actually have identified the actual chip. 418 00:39:18,360 --> 00:39:23,360 That is the chip ID that does that and helps lay this out. 419 00:39:26,670 --> 00:39:30,650 So, the next thing is we want to be able to write into it. 420 00:39:30,670 --> 00:39:36,350 So, we're going to use NanWrite, which is another tool. 421 00:39:38,370 --> 00:39:40,450 Hope you don't mind me not typing. 422 00:39:40,490 --> 00:39:42,490 It saves you guys a lot of headaches. 423 00:39:42,890 --> 00:39:46,630 So, let's cancel out of that. 424 00:39:47,110 --> 00:39:48,110 NanWrite. 425 00:39:48,530 --> 00:39:50,350 I want to see the command. 426 00:39:50,390 --> 00:39:51,930 So, here's all the functions. 427 00:39:51,930 --> 00:39:55,490 So, what we're going to do is we're going to input contains OOB data. 428 00:39:55,670 --> 00:39:59,830 So, we're telling it to utilize the OOB data. 429 00:40:01,250 --> 00:40:03,550 And we're going to go ahead and let this run. 430 00:40:03,550 --> 00:40:05,830 And hopefully, it'll run through clean. 431 00:40:05,910 --> 00:40:06,510 Boom! 432 00:40:06,510 --> 00:40:11,070 There we wrote all of the blocks out onto the device. 433 00:40:11,110 --> 00:40:14,970 So, the next step is... we'll come over here so you see this. 434 00:40:14,970 --> 00:40:16,370 We go ls. 435 00:40:22,670 --> 00:40:25,010 And we can see there's nothing there. 436 00:40:25,350 --> 00:40:28,790 And then what we're going to do is cut and paste. 437 00:40:28,790 --> 00:40:30,790 So, I don't have to type. 438 00:40:34,300 --> 00:40:37,580 We're going to mount this up on block zero. 439 00:40:39,300 --> 00:40:41,880 Change directory to gifs. 440 00:40:43,200 --> 00:40:45,760 And voila, we have data. 441 00:40:46,220 --> 00:40:50,120 So, if we look through here, it starts looking pretty good. 442 00:40:50,120 --> 00:40:52,860 Hey, we've recovered all this data. 443 00:40:53,120 --> 00:40:58,720 The sad thing is most of this stuff is system logs. 444 00:41:01,700 --> 00:41:03,240 That we recovered. 445 00:41:03,240 --> 00:41:08,480 But if we get up here toward the top, we find some weird things. 446 00:41:08,540 --> 00:41:10,300 Here's bin. 447 00:41:10,380 --> 00:41:11,960 It's a file. 448 00:41:12,260 --> 00:41:14,500 etc is a file. 449 00:41:15,120 --> 00:41:18,720 Well, truthfully, this is bullcrap. 450 00:41:19,560 --> 00:41:21,660 We know that's not a file. 451 00:41:21,660 --> 00:41:26,120 So, if we cat etc, wow, look what we get. 452 00:41:26,120 --> 00:41:28,800 Now, I wouldn't expect to see that in etc. 453 00:41:28,800 --> 00:41:30,700 So, we recovered a lot of it. 454 00:41:30,700 --> 00:41:34,400 But some of it's corrupted in a weird fashion. 455 00:41:34,740 --> 00:41:36,800 So, how did I recover from this? 456 00:41:36,800 --> 00:41:38,340 I experimented. 457 00:41:38,340 --> 00:41:39,920 And we're going to go over that a minute. 458 00:41:39,920 --> 00:41:45,060 But before we go forward, I actually want to see if there are any questions. 459 00:41:49,890 --> 00:41:51,250 Jonathan, any questions? 460 00:41:51,910 --> 00:41:53,870 Yep, taking a look now. 461 00:41:53,870 --> 00:41:55,410 No updates here. 462 00:41:55,410 --> 00:41:57,430 I'm checking Twitch real quick. 463 00:41:59,050 --> 00:42:00,910 Yes, here's a question. 464 00:42:00,910 --> 00:42:06,490 In IoT devices you've examined, do you ever come across NAND storing non-file system data? 465 00:42:06,490 --> 00:42:12,810 If so, do you just dump and then use binwalk and other usual tools and methods for poking around? 466 00:42:13,530 --> 00:42:20,270 Yeah, I've had them storing non-file system data on NAND flash. 467 00:42:21,150 --> 00:42:32,730 So, yeah, typically I get into that and when I get those and there's no structure to them, I start off with throwing things like strings to the thing. 468 00:42:32,730 --> 00:42:41,370 With strings, can we identify any known structure in there? 469 00:42:41,930 --> 00:42:45,290 I will run binwalk just to see what it'll do. 470 00:42:45,290 --> 00:42:50,590 Sometimes it'll point out some structure headers that I can more quickly find. 471 00:42:50,590 --> 00:42:52,810 So, I think that plays a big role. 472 00:42:52,850 --> 00:42:59,670 But yeah, sometimes you'll have them storing things like blocks of configuration data. 473 00:43:00,130 --> 00:43:09,550 And I've seen them just blocks of encrypted data, which may be a file system structure, but they're not framed as such. 474 00:43:09,550 --> 00:43:14,310 So, it's just encrypted blocks of useless information. 475 00:43:14,430 --> 00:43:17,290 So, yeah, that's not all that in common. 476 00:43:17,370 --> 00:43:26,310 Well, most of the time when I get a NAND chip, it's a file system, but you will encounter those, to be honest. 477 00:43:27,470 --> 00:43:39,690 So, right now, before we move on to the next section, I want to remove the kernel modules so they don't conflict with what we're doing. 478 00:43:45,320 --> 00:43:46,840 Okay, and we are down to... 479 00:43:48,160 --> 00:43:51,020 we still got some time, doing pretty good. 480 00:43:51,360 --> 00:44:00,340 So, the next section I want to get into, we are going to use MTD RAM to actually do this. 481 00:44:00,520 --> 00:44:15,380 So, we're going to take that same system, that same dump that we just did, where we mounted up the file system, it did not come out exactly the way we want it. 482 00:44:15,540 --> 00:44:17,160 And we're going to mess with that. 483 00:44:17,160 --> 00:44:23,640 So, we're going to make a make directory, and we're actually going to create our own block structure. 484 00:44:29,350 --> 00:44:33,270 And then we'll go, and then we're going to make a node. 485 00:44:35,170 --> 00:44:44,150 If I learn how to spell it, I should just copy this over, make node dev slash MTD block. 486 00:44:44,710 --> 00:44:46,510 And we're going to create zero. 487 00:44:46,510 --> 00:44:49,130 We're going to create it as a block device. 488 00:44:49,130 --> 00:44:55,350 We're going to give it a master number, a primary number, and a minor number of zero. 489 00:44:55,350 --> 00:44:57,710 So, we're going to create that device in there. 490 00:44:57,930 --> 00:45:07,350 And then what we're going to do is we're going use modprobe, and we're going to bring in a kernel module called MTDRAM. 491 00:45:07,350 --> 00:45:10,470 So, this kernel module's MTDRAM. 492 00:45:10,470 --> 00:45:15,250 We're setting the total size to 274432. 493 00:45:15,250 --> 00:45:20,970 That is bigger than a 256 megabyte RAM area. 494 00:45:22,090 --> 00:45:29,370 256 megabyte RAM area would be 262144, and that would not contain OOB data. 495 00:45:29,370 --> 00:45:33,950 In this case here, we're bringing in the OOB data also. 496 00:45:34,430 --> 00:45:41,150 Because if I bring in without the OOB data, I noticed that we get the same results as the other one. 497 00:45:41,150 --> 00:45:46,310 So, experimenting, and I encourage you to experiment when you're dealing with these NAND chips. 498 00:45:47,030 --> 00:45:55,110 It can be quite fascinating what you can find and figure out and make work to get you data out of this system. 499 00:45:55,110 --> 00:45:57,010 I'm currently working on one. 500 00:45:57,010 --> 00:46:07,070 It has me slightly befuddled, but I will master it eventually, where the actual entire data on the chip is shifted 10 bytes. 501 00:46:07,190 --> 00:46:24,110 They even shifted all the OOB data 10 bytes, and it took looking at it manually to figure this all out and doing that math and looking at the data in the structure to determine that they had also shifted that. 502 00:46:24,110 --> 00:46:30,250 Because I was getting block errors saying that block is 10 bytes longer than it's supposed to be type thing. 503 00:46:30,250 --> 00:46:35,330 That's when we found out that everything was shifted and was able to confirm that the OOB was shifted too. 504 00:46:35,330 --> 00:46:36,450 But I digress. 505 00:46:36,450 --> 00:46:41,850 So, what we're going to do is we're going to load this up, and it's supposed to contain the entire thing. 506 00:46:41,850 --> 00:46:44,570 And then we want to load one more module. 507 00:46:47,250 --> 00:46:50,510 MTD block for kernel module. 508 00:46:52,210 --> 00:46:54,890 And then we're going to dd. 509 00:46:54,930 --> 00:46:56,410 Excuse me. 510 00:47:00,420 --> 00:47:03,280 And dd is a bit copy. 511 00:47:03,280 --> 00:47:04,880 I use this all the time. 512 00:47:04,880 --> 00:47:11,200 Matter of fact, if you get access to almost every embedded IoT device, you'll find dd is actually installed on it. 513 00:47:11,200 --> 00:47:16,600 Because most of the time, dd is actually used for doing firmware upgrades. 514 00:47:16,600 --> 00:47:21,940 You'll have duplicate root file structures, duplicate kernels on the device. 515 00:47:21,940 --> 00:47:24,540 And what happens is one is primary and running. 516 00:47:24,580 --> 00:47:38,800 So, what will happen is when the firmware comes down, it'll dd it over the secondary, and then it'll change the U-boot or secure boot arguments to make the new one primary and the old one secondary. 517 00:47:38,800 --> 00:47:44,200 That way, if you have a failed firmware update, it does not break the device. 518 00:47:44,200 --> 00:47:48,700 It just goes back to the original one, which was not overwritten. 519 00:47:49,220 --> 00:47:54,260 So, again, input file here is the nest file. 520 00:47:54,260 --> 00:47:57,560 And then output is to our block device that we created. 521 00:47:57,560 --> 00:48:02,080 And if I did everything right, this should start writing data. 522 00:48:02,080 --> 00:48:03,320 Should be fairly quick. 523 00:48:03,320 --> 00:48:14,680 And as you see, we're able to write out 277 megabytes of information fairly quick, because it's all internal to the system. 524 00:48:15,120 --> 00:48:21,860 So, from here, we're going to go ahead and mount this up. 525 00:48:22,020 --> 00:48:24,000 Same way we did on the other one. 526 00:48:24,360 --> 00:48:28,100 And we're going to mount MTD block zero up. 527 00:48:32,780 --> 00:48:40,360 Now, if someone wants to explain to me why this worked, because I really not sure why. 528 00:48:40,360 --> 00:48:45,920 As I said, often dealing with NAND chips, little quirky things have worked for me. 529 00:48:45,920 --> 00:48:48,880 So, I'm not going to speak bad of them. 530 00:48:48,880 --> 00:48:53,800 And now we can see etc and bin are actual files. 531 00:48:53,800 --> 00:48:55,780 We do have some corruptions in here. 532 00:48:55,780 --> 00:49:01,520 So, there's a few files actually corrupted within this. 533 00:49:01,520 --> 00:49:09,060 But for the most part, a large portion of them were actually able to be recovered properly. 534 00:49:17,990 --> 00:49:23,970 And so, these are methods that I use quite regularly for recovering. 535 00:49:24,250 --> 00:49:39,790 When you start working with UBI file systems, if I ever get some good methods, methodologies hammered out for working with some of the strange UBI file systems, like the one with the 10 bytes that's shifted. 536 00:49:39,790 --> 00:49:53,730 I did one on an engagement here earlier this year, where again, nothing are large portions of it were not laid out contiguously and trying to build good solid methodologies around UBI. 537 00:49:53,730 --> 00:50:00,090 I'll probably come back around and put together a training session presentation for that down the road. 538 00:50:00,090 --> 00:50:07,850 That's what I'm currently working on, trying to work out those kinks and bugs and build that knowledge level to build to work with us. 539 00:50:07,850 --> 00:50:18,710 Now, probably half the chips that are UBI file systems, I'm successful recovering them using various techniques and UBI tools that are available out there. 540 00:50:18,890 --> 00:50:35,990 But typically, GIFs, squash file systems, things like that can easily be quickly recovered from NAND flash chips using any one of these three methods that we covered today in this presentation. 541 00:50:36,210 --> 00:50:39,250 So, hopefully there's some questions out there. 542 00:50:40,550 --> 00:50:42,670 Yeah, I got a couple here. 543 00:50:42,990 --> 00:50:52,850 So, one question here asks, have you encountered an IoT device that was encrypting the data it was storing in the NAND flash? 544 00:50:54,330 --> 00:50:59,570 No, I haven't, which is kind of amazing to me. 545 00:50:59,850 --> 00:51:08,670 I mean, the only time I've ever seen IoT technology using any kind of encryption, if it was running an Android operating system. 546 00:51:08,670 --> 00:51:16,890 And by nature, Android can support the data section being completely encrypted. 547 00:51:16,890 --> 00:51:20,690 So, that's quite common. 548 00:51:20,690 --> 00:51:41,390 I do have some other tech that I consider IoT, but it's more enterprise IoT and not necessarily the normal consumer grade, which actually is very much encrypted and most of the, not all the file system, but most of the file system that contains user data, 549 00:51:41,390 --> 00:51:46,690 similar to the Android file system, is also encrypted. 550 00:51:46,950 --> 00:51:52,030 So, typically, if I see it's an Android, it's usually 50-50. 551 00:51:52,030 --> 00:52:00,490 If it is a standard phone-style Android operating system dumped on there, then most always it has encrypted. 552 00:52:00,490 --> 00:52:08,570 But yet, if it's an older Android style that's put on there, there was no requirement or typically that's not always encrypted. 553 00:52:08,570 --> 00:52:21,350 So, it's a mix and match, but it's pretty rare to see encrypted, at least from a lot of the IoT I've looked at, unless you get into more enterprise level technology. 554 00:52:23,690 --> 00:52:26,770 Anonymous attendee asks, Hi, I am new to this. 555 00:52:26,770 --> 00:52:29,410 Sorry, you already have the binary file. 556 00:52:29,410 --> 00:52:32,190 How did you extract it from the hardware device? 557 00:52:33,830 --> 00:52:38,030 In the cases of these, both of them were chip off. 558 00:52:38,750 --> 00:52:55,330 So, early in the presentation, and so you can rewatch this presentation, or in the presentation earlier today, where we talked about building an IoT lab and we showed a number of devices, I have a number of chip readers. 559 00:52:55,330 --> 00:52:57,750 So, I actually use those. 560 00:52:57,750 --> 00:53:10,130 Other ways are often if the chip that's being used has some kind of debug function, you can put it in debug and pull the data off of it. 561 00:53:10,130 --> 00:53:17,330 Also, you may be able to check, connect in with JTAG or SerWire debug and actually read it off the device. 562 00:53:17,330 --> 00:53:25,990 But if those fail, I often rely on just desoldering the chip and dropping it into a reader and extract the data from there. 563 00:53:25,990 --> 00:53:44,450 If I need to put the device back into functionality, then I'll go through either resoldering the chip back on or reballing the chip and reflowing it back on an IR oven, which are fairly cumbersome, at least the reballing BGAs, but it's still doable. 564 00:53:44,450 --> 00:53:47,370 And it's not all that complex. 565 00:53:47,430 --> 00:53:54,470 I did a presentation not last year, but the year before last at Nuit de Hacq. 566 00:53:54,470 --> 00:53:55,470 I did it there. 567 00:53:55,470 --> 00:54:04,030 I also did it, oh gosh, I did it in Perth, Australia, and I also did it at DerbyCon. 568 00:54:04,030 --> 00:54:07,770 And it was, I'm trying to remember the name of it. 569 00:54:07,770 --> 00:54:12,410 Basically, it was how to get root access the hard way. 570 00:54:12,570 --> 00:54:20,390 And it talks about slashing, smashing, cutting the device apart and rebuilding it to get root access or something to that effect. 571 00:54:20,390 --> 00:54:29,270 So you can look at that, and it goes through some of the concepts in my learning process on learning how to manually reball BGA chips. 572 00:54:31,050 --> 00:54:34,290 Elvis Cousin asks, these are all variants of Linux. 573 00:54:34,290 --> 00:54:40,150 On a Windows CE device, might it still use SquashFS or some other Windows thing? 574 00:54:40,310 --> 00:54:43,850 Ooh, probably some other Windows thing. 575 00:54:44,230 --> 00:54:49,390 I have not looked at a Windows CE device. 576 00:54:51,230 --> 00:54:55,350 I have been looking at some Chrome devices. 577 00:54:56,630 --> 00:55:11,550 In those particular cases, this has an SD drive, solid state drive, where you're able to get the data off of it and just mount it up on your system. 578 00:55:11,770 --> 00:55:14,510 I'm not sure if they have NAND chips. 579 00:55:14,510 --> 00:55:19,130 Is it going to be a Linux file system? 580 00:55:19,130 --> 00:55:19,910 Probably not. 581 00:55:19,910 --> 00:55:22,510 It's probably going to be some variation of Windows. 582 00:55:22,510 --> 00:55:30,010 But I have not tore into any Windows or Windows CE type devices to be able to give you a solid answer on that. 583 00:55:30,110 --> 00:55:32,110 Let me know if you find out. 584 00:55:35,970 --> 00:55:37,550 Any other questions? 585 00:55:38,130 --> 00:55:39,570 Nope, all caught up. 586 00:55:40,410 --> 00:55:41,150 All right. 587 00:55:41,150 --> 00:55:43,030 Well, I think we're... what time we start? 588 00:55:43,030 --> 00:55:43,770 Six o'clock. 589 00:55:43,770 --> 00:55:46,670 So we're probably right on time. 590 00:55:46,670 --> 00:55:50,090 So let me jump over here. 591 00:55:51,050 --> 00:55:55,230 Let's do a final stop to share. 592 00:55:55,510 --> 00:56:01,230 So let's go ahead and ask question one more time. 593 00:56:01,230 --> 00:56:06,510 Anyone have any questions, any requests for questions or information? 594 00:56:06,510 --> 00:56:16,850 If not, you'll probably catch me on Discord either here in a little bit after I've eaten or late tonight or tomorrow. 595 00:56:17,170 --> 00:56:20,110 Feel free to hit me up for any questions. 596 00:56:20,710 --> 00:56:22,850 Also, oh gosh, yeah, I was promising that. 597 00:56:22,850 --> 00:56:24,750 Hold on before you all drop off there. 598 00:56:24,750 --> 00:56:25,950 Let's get this up. 599 00:56:32,020 --> 00:56:36,840 So I had promised... slideshow. 600 00:56:46,460 --> 00:56:49,760 So I want to be able to get some of these things captured in the video. 601 00:56:49,760 --> 00:56:53,040 So here's the NAND sim example that I use. 602 00:56:53,040 --> 00:57:00,220 The mod probe commands, the NAND write commands, and the mount to be able to mount this particular GIF file system up. 603 00:57:00,840 --> 00:57:06,560 And here is the commands that I use for mtd-dram example. 604 00:57:10,460 --> 00:57:13,040 Quick note on some of the commands we use. 605 00:57:13,180 --> 00:57:20,900 There is the link for NAND dump tool, concept of mod probe, make node, NAND write, DD. 606 00:57:21,040 --> 00:57:24,440 And then here is the reference. 607 00:57:24,700 --> 00:57:26,660 So that gets captured in here. 608 00:57:26,660 --> 00:57:28,600 All of this is kind of cool material. 609 00:57:28,620 --> 00:57:32,200 There's a lot of great work that's been done out there on NAND chips. 610 00:57:32,300 --> 00:57:47,000 Like I said, I'm constantly reviewing and reading and consuming this material on a regular basis because every time I encounter NAND chip that wants to fight with me, I have to go out and start rethinking, okay, what am I missing? 611 00:57:47,000 --> 00:57:49,120 What do I need to learn to expand my knowledge? 612 00:57:49,320 --> 00:57:51,600 How do we kind of move forward from here? 613 00:57:51,600 --> 00:57:54,400 And there's been a lot of work done out there. 614 00:57:54,480 --> 00:58:04,380 And of course, we shared much of the information that these people provided in this demonstration today. 615 00:58:04,380 --> 00:58:17,600 Also, if you're interested in connecting up with me on Twitter, my handles are %X, so it would be P-E-R-C-E-N-T underscore X. 616 00:58:17,600 --> 00:58:24,500 And feel free to connect with me out there or reach out to me and ask questions out there. 617 00:58:29,980 --> 00:58:30,780 Awesome, Daryl. 618 00:58:30,780 --> 00:58:31,980 Thank you so much. 619 00:58:32,220 --> 00:58:32,940 Oh, man. 620 00:58:32,940 --> 00:58:34,020 Sure enough, Sam. 621 00:58:34,020 --> 00:58:35,320 Had a blast. 622 00:58:35,780 --> 00:58:36,180 Yeah. 623 00:58:36,180 --> 00:58:40,740 And I mean, honestly, if there are any last questions, we still have a little bit of time. 624 00:58:40,740 --> 00:58:43,440 So was there anything else that you saw there, Jonathan? 625 00:58:46,000 --> 00:58:48,820 Yeah, another quick question just popped up. 626 00:58:49,100 --> 00:58:54,300 It says, this is some very epic stuff, extracting flash from NAND chips. 627 00:58:54,300 --> 00:59:00,860 I have to ask, did you find anything epic while performing post-exploitation on the extracted firmware? 628 00:59:03,520 --> 00:59:04,860 Yeah, yeah. 629 00:59:04,860 --> 00:59:09,800 I mean, any remote shells? 630 00:59:09,800 --> 00:59:11,480 No, unfortunately. 631 00:59:11,840 --> 00:59:20,100 But again, it's information that we could feed back to manufacturers to help improve processes. 632 00:59:20,260 --> 00:59:22,520 You know, they get into hard-coded stuff. 633 00:59:23,560 --> 00:59:31,960 Mainly, a lot of this lately was purely an effort to go, hey, what happens when IoT is thrown in the trash type thing? 634 00:59:32,020 --> 00:59:39,060 You know, is there data is like the guy with the Nest thermostat? 635 00:59:39,060 --> 00:59:41,860 What happens when something dies if you throw it away? 636 00:59:41,860 --> 00:59:44,900 Does it contain PII information? 637 00:59:44,900 --> 00:59:51,040 So this was kind of a lot of it was driven out of that and some paid assessments. 638 00:59:51,600 --> 01:00:01,440 And also, you know, we tested a lot of devices from, hey, if you go ahead and flush the thing back to factory, does data stay on it? 639 01:00:01,440 --> 01:00:04,060 We kind of started checking for things like that. 640 01:00:04,060 --> 01:00:13,080 It's all about a privacy risk and issue, because we've gotten really big on the whole idea that, hey, we don't want to throw our hard drives away. 641 01:00:13,080 --> 01:00:16,900 But in this modern world, these chips are our hard drives. 642 01:00:16,920 --> 01:00:21,760 And we need to probably start thinking about the potential risks there. 643 01:00:22,400 --> 01:00:32,160 So that was kind of the main purpose of a lot of this, and the fact that I had been working on some engagements that involved band chips that were problematic. 644 01:00:32,320 --> 01:00:38,480 In those cases, we were working on things like reconstructing keys to gain access. 645 01:00:38,480 --> 01:00:46,060 A lot of this stuff ties into engagements also, where we're looking for data since we're testing an entire ecosystem. 646 01:00:46,060 --> 01:00:51,560 That isn't just the hardware, but it may be mobile apps, cloud services, and other devices. 647 01:00:51,560 --> 01:01:05,300 What can we get off this chip that could allow us to attack everything else or attack somebody else using the same product because of key reuse and key session keys and password reuse and things like that. 648 01:01:05,300 --> 01:01:08,120 So a lot of it's within that direction. 649 01:01:10,540 --> 01:01:12,400 Another question here. 650 01:01:12,720 --> 01:01:25,920 This individual asks, does it seem like it is possible to be able to create a module so that a chip reader would automatically be able to detect those out of the OOB areas of the flash memory? 651 01:01:26,040 --> 01:01:29,440 Oh, a number of chip readers will let you identify. 652 01:01:29,440 --> 01:01:34,200 Some of them will allow you to extract the chip, the data, without the OOB. 653 01:01:34,360 --> 01:01:36,000 So yeah, it's not uncommon. 654 01:01:36,000 --> 01:01:46,360 You can often manipulate data from the chip reader and include or not include OOB on some chip readers. 655 01:01:46,360 --> 01:01:50,360 Obviously, you get more control as the price of the chip reader goes up. 656 01:01:50,780 --> 01:01:55,600 And I don't necessarily have a $2,500 chip reader in here. 657 01:01:55,600 --> 01:02:00,180 But I think one of these actually had some OOB settings. 658 01:02:00,180 --> 01:02:07,100 But for some reason, I didn't necessarily trust it because I told it not to include OOB. 659 01:02:07,100 --> 01:02:10,740 And then when I visually looked at the data, the OOB data was there. 660 01:02:10,740 --> 01:02:13,120 So I kind of lost trust. 661 01:02:13,120 --> 01:02:23,400 I have a tendency to also like to map it out, not let the chip reader make the determination for me that this data is structured a certain way. 662 01:02:23,400 --> 01:02:34,280 Because like I said, it's not uncommon with vendors to futz with it, so that it may be incorrect, or that the OOB shifted or is not used in the same place. 663 01:02:34,280 --> 01:02:39,300 And they've just written a new controller to read the data the way they made it. 664 01:02:39,820 --> 01:02:43,840 This way allows me to go, hey, this is correct or isn't correct. 665 01:02:43,860 --> 01:02:51,720 And then I can easily manually remove it or modify code or scripts that are out there to take it out the way I wanted it removed. 666 01:02:51,720 --> 01:02:53,580 So that's kind of my take on it. 667 01:02:55,740 --> 01:02:56,880 That makes sense. 668 01:02:56,880 --> 01:03:00,220 I think that we're at the bottom of the list here for the questions. 669 01:03:00,740 --> 01:03:04,460 Okay, well, I think that kind of concludes it. 670 01:03:04,460 --> 01:03:11,920 If anyone has any questions, catch up with me later, or reach out through me on Twitter. 671 01:03:11,920 --> 01:03:17,060 And again, I'll be on Discord probably tomorrow and maybe later tonight. 672 01:03:17,060 --> 01:03:19,040 So I'll catch everyone later. 673 01:03:19,040 --> 01:03:20,440 Have a good night.