WEBVTT 1 00:00:00.080 --> 00:00:04.000 Okay, let's unpack this. Imagine your smartphone. It's not just 2 00:00:04.040 --> 00:00:08.199 a device, right, it's practically a digital extension of yourself, 3 00:00:08.400 --> 00:00:11.720 a complete, often unfiltered record of your life. 4 00:00:11.800 --> 00:00:12.800 That's a good way to put it. 5 00:00:12.880 --> 00:00:15.960 Every text you sent, every photo you've snapped, every place 6 00:00:16.000 --> 00:00:18.640 you've been, it's all tucked away in there. But what 7 00:00:18.800 --> 00:00:23.199 happens when that well intensely personal digital vault needs to 8 00:00:23.239 --> 00:00:26.640 be opened, maybe for an investigation or just you know, 9 00:00:26.760 --> 00:00:29.480 more broadly, what does it tell us about the hidden 10 00:00:29.519 --> 00:00:33.200 depths of our own data? Today we're taking a deep 11 00:00:33.320 --> 00:00:38.920 dive into the fascinating, incredibly complex world of mobile forensics. 12 00:00:39.560 --> 00:00:42.119 We're drawing from a really comprehensive guide on the subject. 13 00:00:42.200 --> 00:00:43.240 Yeah, it's a dense field. 14 00:00:43.600 --> 00:00:46.880 We're going to explore how experts actually acquire and analyze 15 00:00:46.920 --> 00:00:49.320 data from the very devices that are, let's be honest, 16 00:00:49.399 --> 00:00:51.799 glued to our hands most of the time. You'll learn 17 00:00:51.840 --> 00:00:54.240 not just the how, but the why these techniques are 18 00:00:54.320 --> 00:00:57.399 so critical, and importantly, what they reveal about your own 19 00:00:57.439 --> 00:00:59.600 digital footprint, whether you realize it or not. 20 00:01:00.079 --> 00:01:03.600 And what's truly fascinating here, I think, is how mobile 21 00:01:03.640 --> 00:01:07.159 forensics has just exploded. It's gone from this sort of 22 00:01:07.239 --> 00:01:11.680 niche area to an absolutely essential branch of digital investigation. 23 00:01:11.879 --> 00:01:15.239 Really it's that central now, Oh absolutely, The sheer volume 24 00:01:15.319 --> 00:01:18.640 and frankly the sensitivity of the data on these devices 25 00:01:18.640 --> 00:01:22.840 present unique challenges and you know, incredible opportunities for uncovering 26 00:01:22.840 --> 00:01:27.439 critical information. Right, It's about more than just pulling data 27 00:01:27.439 --> 00:01:31.840 off a phone. It's about validating its integrity, understanding its context, 28 00:01:31.920 --> 00:01:33.599 and making sure it can actually stand up in a 29 00:01:33.680 --> 00:01:35.400 legal setting. That's key. 30 00:01:35.560 --> 00:01:39.840 Okay, So our mission today navigate this intricate landscape of 31 00:01:39.920 --> 00:01:43.640 mobile operating systems. We're talking iOS, Android, maybe even a 32 00:01:43.680 --> 00:01:46.640 quick look at the now retired Windows phone. Yep. 33 00:01:46.719 --> 00:01:48.120 Got to cover the bases. 34 00:01:47.920 --> 00:01:51.359 Understanding their unique security features, the well sometimes cutting edge 35 00:01:51.400 --> 00:01:54.359 methods used to extract data, and what all this ultimately 36 00:01:54.400 --> 00:01:58.159 means for privacy and evidence. Sound good, sounds like a plan, right, 37 00:01:58.200 --> 00:02:00.680 So to kick us off for some someone may be 38 00:02:00.840 --> 00:02:06.040 new to this specific corner of digital investigation, What exactly 39 00:02:06.200 --> 00:02:08.879 is mobile forensics and what makes it one of the 40 00:02:08.919 --> 00:02:10.199 trickiest areas to master? 41 00:02:10.439 --> 00:02:14.280 Okay? At its core, mobile forensics is the let's say, 42 00:02:14.400 --> 00:02:19.479 scientific process of acquiring, recovering, and analyzing evidence from mobile devices. 43 00:02:20.280 --> 00:02:23.199 But it has to be done in a forensically sound manner. 44 00:02:23.280 --> 00:02:29.680 Forensically sound meaning repeatable, documented, and defensible. Now why is 45 00:02:29.719 --> 00:02:33.159 it so difficult? Well, unlike a traditional computer, where you 46 00:02:33.159 --> 00:02:35.680 can often use a rite protector, that's a hardware device 47 00:02:35.719 --> 00:02:38.680 that stops any data being written back to the original evidence. 48 00:02:38.759 --> 00:02:39.960 Drive right, I've heard of those. 49 00:02:40.400 --> 00:02:43.280 Yeah, that whole principle of not altering the original evidence 50 00:02:43.360 --> 00:02:46.520 is incredibly difficult with phones. A lot of forensic tools 51 00:02:46.560 --> 00:02:49.680 actually need two way communication with the device just to work. 52 00:02:49.719 --> 00:02:52.159 Wait. Really, so a simple right blocker just won't cut it. 53 00:02:52.240 --> 00:02:55.759 Often, No, the device needs to interact. So just connecting 54 00:02:55.800 --> 00:02:58.680 a phone to a forensic workstation could inherently change things 55 00:02:58.719 --> 00:03:02.759 on the device itself. Little things maybe, but changes nonetheless. 56 00:03:03.080 --> 00:03:06.199 Wow. Okay, that's a huge hurdle right from the start. 57 00:03:06.680 --> 00:03:10.360 Our guide even talks about like detaching chips or installing 58 00:03:10.360 --> 00:03:14.400 custom bootloaders. That sounds incredibly intense, almost like performing surgery 59 00:03:14.439 --> 00:03:15.000 on a phone. 60 00:03:15.080 --> 00:03:17.800 It absolutely can be, and yes, those methods exist. That's 61 00:03:17.800 --> 00:03:21.199 why the process is meticulously broken down. You've got seizure, 62 00:03:21.719 --> 00:03:26.960 then acquisition, and finally examination analysis three distinct phases. 63 00:03:27.120 --> 00:03:29.039 Okay, walk me through that seizure. 64 00:03:29.199 --> 00:03:32.039 Right, Let's think about the seizure phase. Imagine a phone 65 00:03:32.120 --> 00:03:34.599 is found and its switched on at a crime scene. 66 00:03:35.080 --> 00:03:36.759 Turning it off might seem logical. 67 00:03:36.919 --> 00:03:39.639 But but if it's locked or encrypted, you might lose 68 00:03:39.639 --> 00:03:40.439 access forever. 69 00:03:40.840 --> 00:03:44.759 Exactly so, examiners often try, if possible, to quickly enable 70 00:03:44.759 --> 00:03:48.960 flight mode first, cut off commutations right there. Then immediately 71 00:03:49.000 --> 00:03:50.400 it goes into a Faraday bag. 72 00:03:50.520 --> 00:03:53.240 A Faraday bag that's the metallic looking pouch. 73 00:03:53.360 --> 00:03:56.319 Uh huh. It's a special shielded container that blocks all 74 00:03:56.439 --> 00:04:01.439 radio signals, Wi Fi, cellular, Bluetooth, GPS, isolates it completely. 75 00:04:01.520 --> 00:04:02.680 Why is that so critical? 76 00:04:02.919 --> 00:04:06.240 Well, it prevents remote wipes. For one, someone could try 77 00:04:06.240 --> 00:04:09.159 to erase the phone remotely. It also stops any new 78 00:04:09.240 --> 00:04:13.560 data coming in like texts or notifications, which could overwrite older, 79 00:04:13.560 --> 00:04:18.199 potentially crucial evidence, and helps preserve battery life. 80 00:04:18.279 --> 00:04:22.639 Gotcha, So the immediate priority is basically to freeze the 81 00:04:22.680 --> 00:04:26.439 device in time, create a kind of digital bubble around it, 82 00:04:26.759 --> 00:04:29.920 preventing a remote wipe. That's something you might not immediately 83 00:04:29.920 --> 00:04:30.199 think of. 84 00:04:30.279 --> 00:04:34.199 Precisely, it's a major concern. And beyond just that initial seizure, 85 00:04:34.319 --> 00:04:37.839 the mobile landscape itself is a moving target. Think about it, 86 00:04:37.879 --> 00:04:42.360 the rapid evolution different manufactures, all the OS versions, constantly 87 00:04:42.439 --> 00:04:43.759 updated security features. 88 00:04:43.839 --> 00:04:45.879 Yeah, my phone updates constant right. 89 00:04:45.839 --> 00:04:49.879 So there's no single one size fits all tool or process. 90 00:04:50.240 --> 00:04:53.600 Examiners need really specialized knowledge and they have to constantly 91 00:04:53.639 --> 00:04:56.480 adapt their skills just to keep up. It's a continuous 92 00:04:56.560 --> 00:04:57.240 learning curve, a. 93 00:04:57.279 --> 00:04:59.560 Constant arms race. Basically, you could say that. 94 00:04:59.560 --> 00:05:01.319 Makes it one one of the most dynamic feels in 95 00:05:01.360 --> 00:05:02.800 digital forensics for sure. 96 00:05:02.879 --> 00:05:05.199 And it's not just digital stuff, right. The guide mentions 97 00:05:05.240 --> 00:05:07.959 phones can also hold traditional forensic evidence like. 98 00:05:07.920 --> 00:05:12.959 Fingerprints, absolutely, fingerprints, maybe DNA other trace evidence, so those 99 00:05:13.000 --> 00:05:16.480 need to be collected before any digital examination starts to 100 00:05:16.560 --> 00:05:21.199 avoid contamination. Standard procedure gloves are an absolute must. 101 00:05:21.360 --> 00:05:24.560 Okay, So device seized physical evidence collected, it's in the 102 00:05:24.560 --> 00:05:29.439 Faraday bag. Now the monumental task, Yeah, getting the data out. 103 00:05:29.519 --> 00:05:31.959 What are the main strategies these levels of extraction you 104 00:05:32.040 --> 00:05:32.720 mentioned right. 105 00:05:32.639 --> 00:05:35.879 The acquisition phase. There are several practical approaches and they're 106 00:05:35.879 --> 00:05:40.439 often categorized into tool leveling systems. Think of it as 107 00:05:40.439 --> 00:05:42.560 going from least intrusive to most extreme. 108 00:05:42.680 --> 00:05:43.680 Okay, Level one. 109 00:05:43.920 --> 00:05:46.720 First, you've got manual extraction. This is the most basic 110 00:05:47.079 --> 00:05:49.839 literally just browsing the device if you can unlock it, 111 00:05:49.879 --> 00:05:54.519 taking screenshots, photographing visible data. It's limited, obviously, but sometimes 112 00:05:54.560 --> 00:05:56.279 maybe with the damaged phone, it's all you can do. 113 00:05:56.480 --> 00:05:56.959 Makes sense. 114 00:05:58.040 --> 00:06:01.879 Next next up is logical analysis. This means extracting the 115 00:06:01.920 --> 00:06:05.879 accessible data using standard ways the phone communicates. Often this 116 00:06:05.920 --> 00:06:09.399 involves creating or analyzing device backups, the kind your phone 117 00:06:09.839 --> 00:06:11.560 might make automatically or that you make. 118 00:06:11.439 --> 00:06:13.360 Yourself, like an iTunes backup or something. 119 00:06:13.240 --> 00:06:16.800 Yeah that's exactly, or an Android backup. This method relies 120 00:06:16.800 --> 00:06:20.600 on the device being somewhat cooperative, you know, unlocked or unlockable. 121 00:06:20.639 --> 00:06:23.439 And the final level, the big one. 122 00:06:23.240 --> 00:06:26.680 That's physical acquisition. This is often seen as the holy 123 00:06:26.759 --> 00:06:29.759 grail for forensics. The goal here is to create a 124 00:06:29.800 --> 00:06:32.879 bit by bit raw image of the entire memory. 125 00:06:32.800 --> 00:06:34.839 Everything including deleted stuff. 126 00:06:35.040 --> 00:06:39.519 Potentially. Yes, it includes not just the currently accessible data, 127 00:06:39.560 --> 00:06:43.680 but also data in unallocated space, basically where deleted files 128 00:06:43.759 --> 00:06:46.879 might still reside before the space gets overwritten. That's where 129 00:06:46.879 --> 00:06:47.839 the real digging happens. 130 00:06:47.879 --> 00:06:51.399 Okay, physical acquisition, that's the ideal, But the guide mentioned 131 00:06:51.439 --> 00:06:55.519 some really advanced, almost sci fi methods, chip off and 132 00:06:55.600 --> 00:06:58.319 micro read. What are those about? When do you pull 133 00:06:58.360 --> 00:06:58.759 those out? 134 00:06:58.839 --> 00:07:01.560 Right? So this brings up the question what happens when 135 00:07:01.600 --> 00:07:05.720 a device is say, severely damaged, crushed, water logged, or 136 00:07:05.879 --> 00:07:09.519 it's locked solid and standard software methods just fail. Yeah, 137 00:07:09.560 --> 00:07:13.319 then what that's where these more hardware focused techniques come in. 138 00:07:13.439 --> 00:07:15.759 Chip office. Pretty much what it sounds like. You physically 139 00:07:15.800 --> 00:07:18.959 remove the memory chip, desorder it from the phone circuit board. 140 00:07:19.279 --> 00:07:22.720 Then that tiny chip is placed into a specialized chip 141 00:07:22.759 --> 00:07:26.720 reader or sometimes even onto another compatible phone board to 142 00:07:26.839 --> 00:07:28.879 extract the raw data directly. 143 00:07:29.199 --> 00:07:32.319 That sounds incredibly delicate and destructive. 144 00:07:32.600 --> 00:07:37.600 It is extremely technically challenging, needs serious hardware skills, and yeah, 145 00:07:37.600 --> 00:07:40.639 it destroys the original device in the process. So it's 146 00:07:40.759 --> 00:07:43.360 always a last resort, only used when the data is 147 00:07:43.439 --> 00:07:45.439 critical and other methods are exhausted. 148 00:07:45.639 --> 00:07:47.639 And there was another one, Chase. 149 00:07:47.439 --> 00:07:52.480 Something ah JTAG Joint Test Action Group that's slightly different. 150 00:07:52.720 --> 00:07:55.319 It uses standard test ports already built onto the circuit 151 00:07:55.319 --> 00:07:59.199 board for debugging during manufacturing. Investigators can sometimes connect to 152 00:07:59.240 --> 00:08:01.680 these ports to directly interact with the processor and try 153 00:08:01.720 --> 00:08:04.360 to dump the memory. It's less destructive than chip off, 154 00:08:04.519 --> 00:08:07.959 but still requires hardware access and isn't always possible, especially 155 00:08:08.000 --> 00:08:09.560 on newer and more secure devices. 156 00:08:09.680 --> 00:08:12.560 Okay, so chip off is physically removing it, JTAG is 157 00:08:12.560 --> 00:08:15.360 connecting to existing ports. Still sounds pretty hardcore. 158 00:08:15.560 --> 00:08:18.720 They are. And then there's the absolute extreme micro. 159 00:08:18.560 --> 00:08:21.240 Read micro read that sounds intense it is. 160 00:08:21.720 --> 00:08:25.839 Imagine using an electron microscope to manually view the physical gaits, 161 00:08:25.920 --> 00:08:28.879 the tiny on off switches on the memory chip itself, 162 00:08:29.519 --> 00:08:34.799 then painstakingly translating their status, their physical state into binary 163 00:08:34.879 --> 00:08:40.240 cone zero's and ones. You're kidding manually Manually It's unbelievably 164 00:08:40.279 --> 00:08:45.320 time consuming, incredibly expensive, and needs well unique expertise in 165 00:08:45.360 --> 00:08:49.360 both microscopy and memory architecture. You won't find commercial tools 166 00:08:49.360 --> 00:08:52.919 for this. It's reserved for like major national security cases, 167 00:08:53.240 --> 00:08:56.480 things where cost is no object and the data is paramount. 168 00:08:56.600 --> 00:09:00.000 Manually translating binary from looking at microscopic. 169 00:08:59.399 --> 00:09:02.600 Gates, which, wow, that puts into perspective the lengths investigators 170 00:09:02.679 --> 00:09:03.080 might go to. 171 00:09:03.279 --> 00:09:05.480 It really does. But look, regardless of the method, whether 172 00:09:05.519 --> 00:09:09.159 it's simple logical extraction or micro read, good forensic practice 173 00:09:09.399 --> 00:09:12.919 is absolutely critical, meaning securing the evidence, preserving its state, 174 00:09:13.000 --> 00:09:17.759 meticulously documenting everything, chain of custody, steps taken, tools use 175 00:09:18.039 --> 00:09:20.519 even down to calculating hash values to prove the data 176 00:09:20.519 --> 00:09:21.320 hasn't been altered. 177 00:09:21.360 --> 00:09:24.840 Hash values like a digital fingerprint for the data exactly 178 00:09:24.919 --> 00:09:28.399 and thorough reporting. The entire process has to be reproducible, 179 00:09:28.440 --> 00:09:30.559 step by step so it can stand up in court. 180 00:09:30.759 --> 00:09:34.759 Any changes, even tiny ones, must be documented and justified. 181 00:09:34.879 --> 00:09:39.639 Okay, that makes sense. Let's switch gears a bit. Apple iPhones, iPads, 182 00:09:41.120 --> 00:09:44.039 billions of them out there, Investigators must run into them constantly. 183 00:09:44.559 --> 00:09:47.799 What's unique about iOS forensics? How does it differ from say, 184 00:09:48.240 --> 00:09:50.639 Android or even older systems. 185 00:09:50.759 --> 00:09:53.360 Right, iOS is a huge part of the landscape. The 186 00:09:53.480 --> 00:09:56.480 key thing to understand is that Apple builds its devices 187 00:09:56.519 --> 00:09:59.240 with layers of security baked in from the start. A 188 00:09:59.320 --> 00:10:02.080 major turning point was iOS four. From then on, the 189 00:10:02.279 --> 00:10:05.440 entire file system is encrypted by default, using a unique 190 00:10:05.480 --> 00:10:07.639 hardware key build into the device's process. 191 00:10:07.759 --> 00:10:10.279 The entire filesystem encrypted with the hardware key. 192 00:10:10.399 --> 00:10:13.720 Yes, and this is critical. It fundamentally changes the forensic 193 00:10:13.759 --> 00:10:16.960 approach for these newer iOS devices, that holy grail of 194 00:10:17.039 --> 00:10:20.759 physical acquisition, like chip off. It's largely useless if you 195 00:10:20.799 --> 00:10:23.159 have the chip, because even if you successfully pull the 196 00:10:23.240 --> 00:10:26.480 raw data off the chip, it's still encrypted and the 197 00:10:26.559 --> 00:10:28.960 key needed to decrypt. It is tied to the phone's 198 00:10:28.960 --> 00:10:33.840 specific hardware, particularly the secure Enclave processor. Without that key, 199 00:10:33.919 --> 00:10:36.840 the data dump is just an unreadable jumble of bits. 200 00:10:37.120 --> 00:10:40.200 So if my iPhone, anything from the four onwards is encrypted, 201 00:10:40.399 --> 00:10:43.559 physically removing the chip doesn't actually get you readable data. 202 00:10:43.679 --> 00:10:47.639 That's that's a really strong security measure, almost like an 203 00:10:47.639 --> 00:10:49.879 impenetrable wall for physical attacks. 204 00:10:49.960 --> 00:10:52.960 It's a very strong wall. Yes, it forces investigators away 205 00:10:53.000 --> 00:10:56.679 from pure hardware attacks and more towards software vulnerabilities or 206 00:10:56.720 --> 00:11:00.039 methods that require logical access like getting the pass code. 207 00:11:00.120 --> 00:11:03.240 Okay, and Apple has other security layers too, right, passcodes, 208 00:11:03.279 --> 00:11:03.960 face ID. 209 00:11:04.080 --> 00:11:07.799 Exactly, data protection, the passcode system touch I face ID, 210 00:11:08.200 --> 00:11:11.679 and also activation lock that's the feature requiring your Apple 211 00:11:11.720 --> 00:11:15.120 ID and password to erase or reactivate a device if 212 00:11:15.159 --> 00:11:18.240 it's wiped. These all add significant hurdles. And what about 213 00:11:18.279 --> 00:11:22.720 deleting data ah another key point. The erase all Content 214 00:11:22.759 --> 00:11:26.159 and Settings option on iOS doesn't just mark files for 215 00:11:26.840 --> 00:11:30.679 deletion like on some systems, It actually destroys the encryption 216 00:11:30.840 --> 00:11:32.759 keys used for that data, so the. 217 00:11:32.759 --> 00:11:36.000 Data becomes cryptographically unrecoverable. 218 00:11:35.320 --> 00:11:39.360 Precisely for forensic investigators. That means the data is effectively gone. 219 00:11:39.559 --> 00:11:42.519 It's a very different mechanism than just deleting a file pointer. 220 00:11:42.840 --> 00:11:47.240 Wow, that's a powerful and pretty final action for a user. 221 00:11:47.320 --> 00:11:50.840 It is now one important workaround investigator Sometimes used, though 222 00:11:50.840 --> 00:11:53.120 it comes with big caveats, is jail braking. 223 00:11:53.360 --> 00:11:55.960 Jail braking I've heard that. Isn't that like hacking your 224 00:11:55.960 --> 00:11:56.480 own phone? 225 00:11:56.639 --> 00:12:00.799 Sort of? It removes Apple software restrictions, allows running sign code, 226 00:12:00.799 --> 00:12:05.240 and crucially can grant root access. That's administrative level privilege 227 00:12:05.360 --> 00:12:08.120 essential for getting a full image of the file system. 228 00:12:08.080 --> 00:12:09.960 So it bypasses some of Apple's locks. 229 00:12:09.960 --> 00:12:12.600 It can, yes, but and this is a big butt, 230 00:12:12.799 --> 00:12:15.480 avoids the warranty. It can make the phone unstable, and 231 00:12:15.519 --> 00:12:19.759 there's always a risk of bricking the device, rendering it completely. 232 00:12:19.279 --> 00:12:22.000 Unusable, breaking it yikes. Yeah. 233 00:12:22.039 --> 00:12:24.840 Plus, the act of jail breaking itself significantly alters the 234 00:12:24.879 --> 00:12:29.360 devices software, which raises potential issues for evidence integrity in court, 235 00:12:29.960 --> 00:12:33.080 and specific jail breaks only work on specific iOS versions 236 00:12:33.080 --> 00:12:35.840 and devices, so it's a constant cat and mouse game 237 00:12:35.879 --> 00:12:39.559 between Apple patching vulnerabilities and the jail break community find 238 00:12:39.600 --> 00:12:40.159 in new ones. 239 00:12:40.279 --> 00:12:44.000 So it's a really high stakes gamble for investigators. More 240 00:12:44.080 --> 00:12:47.399 access maybe, but huge risks definitely. 241 00:12:47.840 --> 00:12:51.360 That's why a critical and much safer alternative source of 242 00:12:51.399 --> 00:12:54.000 evidence is often iOS backups. 243 00:12:53.679 --> 00:12:56.120 The ones made with iTunes or iCloud. 244 00:12:56.000 --> 00:12:59.600 Exactly, both iTunes backups save to a computer and iCloud 245 00:12:59.600 --> 00:13:04.519 backups stored online can be incredibly rich sources of information. Contacts, messages, 246 00:13:04.600 --> 00:13:07.519 call logs, app data, photos, lots of stuff. 247 00:13:07.639 --> 00:13:08.679 Is one better than the other. 248 00:13:09.039 --> 00:13:12.759 Encrypted iTunes backups often contain more sensitive data than standard 249 00:13:12.960 --> 00:13:17.000 iCloud backups, things like saved passwords, Wi Fi settings, health data, 250 00:13:17.039 --> 00:13:19.960 and call history. So if investigators can get access to 251 00:13:20.000 --> 00:13:22.399 the computer the phone was backed up to and potentially 252 00:13:22.399 --> 00:13:23.480 crack the backup. 253 00:13:23.120 --> 00:13:24.720 Passwords, crack the password well. 254 00:13:24.759 --> 00:13:28.080 The guide mentions tools like elkom ceft phone breaker. These 255 00:13:28.159 --> 00:13:31.679 can perform brute force attacks trying every possible combination or 256 00:13:31.720 --> 00:13:35.240 dictionary attacks using lists of common words and passwords. 257 00:13:35.320 --> 00:13:36.840 But I bet Apple makes that hard too. 258 00:13:37.120 --> 00:13:40.120 Increasingly so, the guide notes that from iOS ten point 259 00:13:40.120 --> 00:13:43.320 two onwards, the encryption used for backups involves something like 260 00:13:43.480 --> 00:13:45.799 ten million computation iterations to. 261 00:13:45.799 --> 00:13:47.759 Derive the key ten million. Wow. 262 00:13:47.879 --> 00:13:51.279 Yeah, it makes cracking those passwords exponentially harder and slower 263 00:13:51.320 --> 00:13:54.759 compared to older versions. It really highlights that ongoing arms 264 00:13:54.840 --> 00:13:57.960 race between security and forensic access definitely. 265 00:13:58.200 --> 00:14:02.039 So when analysts get this data backups or otherwise, what 266 00:14:02.120 --> 00:14:02.840 are they looking at? 267 00:14:03.000 --> 00:14:05.399 Well, they need to deal with different timestamp formats. First, 268 00:14:05.440 --> 00:14:09.559 You've got UNIX, epoch time, MAC absolute time, even WebKit 269 00:14:09.639 --> 00:14:12.000 time used by the browsers. They all measure time differently. 270 00:14:12.039 --> 00:14:14.600 Okay, timestamps and the actual data. 271 00:14:14.639 --> 00:14:17.600 A lot of the critical user data contacts, SMS messages, 272 00:14:17.639 --> 00:14:20.799 call history, safari, web history notes is stored in school 273 00:14:20.840 --> 00:14:25.039 light databases. These are basically lightweight relational databases very common 274 00:14:25.039 --> 00:14:25.720 in mobile apps. 275 00:14:25.840 --> 00:14:27.519 Poll aake donaically like a database. 276 00:14:27.279 --> 00:14:31.279 File exactly, and also property lists files or dot blist files. 277 00:14:31.399 --> 00:14:34.960 These are structured XML or binary files Apple uses to 278 00:14:35.039 --> 00:14:39.840 store settings and data. Commercial forensic tools like Celebrate EDED 279 00:14:39.960 --> 00:14:43.879 or magnet exiome are specifically designed to find, parse and 280 00:14:43.960 --> 00:14:47.519 present data from these skillet and PLST files, even recovering 281 00:14:47.559 --> 00:14:50.279 deleted records from within the databases where possible. 282 00:14:50.480 --> 00:14:52.960 Got it. Okay, let's move over to the other giant Android. 283 00:14:53.720 --> 00:14:58.200 It powers most smartphones globally, known for its open, customizable nature. 284 00:14:59.000 --> 00:15:03.200 How does that open affect forensic investigations? Compared to Apple's 285 00:15:03.320 --> 00:15:04.080 walled garden. 286 00:15:04.399 --> 00:15:08.120 That openness is the defining factor. Really. Android is Linux based, 287 00:15:08.320 --> 00:15:10.759 developed by a consortion led by Google and used by 288 00:15:10.840 --> 00:15:13.559 hundreds of manufacturers. This means you have a huge variety 289 00:15:13.559 --> 00:15:17.320 of devices, hardware components, customized versions of Android, different filesystems, 290 00:15:17.399 --> 00:15:19.960 varying security implementations. 291 00:15:19.320 --> 00:15:21.559 So way less standardized than iOS. 292 00:15:21.320 --> 00:15:24.720 Much less. This creates both challenges. Investigators need tools and 293 00:15:24.759 --> 00:15:27.799 techniques that work across this massive diversity and opportunities, and 294 00:15:27.919 --> 00:15:31.080 sometimes that openness can provide different avenues for access compared 295 00:15:31.080 --> 00:15:32.519 to the more locked down iOS. 296 00:15:32.840 --> 00:15:35.639 Right and Android versions used to have those fun dessert names, 297 00:15:35.639 --> 00:15:38.559 but now it's just numbers. But the guide says security 298 00:15:38.600 --> 00:15:41.679 has ramped up significantly with each version, things like FD 299 00:15:42.120 --> 00:15:43.039 and c Linux. 300 00:15:43.120 --> 00:15:47.360 Absolutely early Android versions were less secure, but modern Android 301 00:15:47.399 --> 00:15:52.279 has robust security features. FD stands for full disc encryption, 302 00:15:52.639 --> 00:15:56.360 which encrypts the entire user data partition, similar in concept 303 00:15:56.360 --> 00:15:59.960 to iOS, but implemented differently, and see Linux Security enhancem 304 00:16:00.159 --> 00:16:01.080 Linux is a. 305 00:16:01.279 --> 00:16:03.879 Major edition See Linux. What does that do? 306 00:16:04.240 --> 00:16:08.559 It implements something called mandatory access control or MSEEC. Think 307 00:16:08.600 --> 00:16:11.799 of it like this. By default, everything is denied. Access 308 00:16:11.840 --> 00:16:14.399 is only granted if there's an explicit rule allowing it. 309 00:16:14.799 --> 00:16:18.480 This provides really strong isolation between apps and system processes, 310 00:16:18.720 --> 00:16:21.720 making it much harder for malware to gain elevated privileges 311 00:16:21.840 --> 00:16:23.200 or access data it shouldn't. 312 00:16:23.360 --> 00:16:25.879 So even if you install a bad app, SELinux tries 313 00:16:25.879 --> 00:16:27.799 to keep it contained in its own little sandbox. 314 00:16:28.039 --> 00:16:32.240 That's the goal. Yes, it significantly hardens the system against 315 00:16:32.240 --> 00:16:36.919 privileged escalation attacks. Android also uses an application sandbox where 316 00:16:36.919 --> 00:16:39.840 each app runs as its own user, secure ways for 317 00:16:39.840 --> 00:16:43.279 apps to communicate IPC, and requires all apps to be 318 00:16:43.399 --> 00:16:44.279 digitally signed. 319 00:16:44.320 --> 00:16:47.120 Okay, so Android is also pretty locked down. How do 320 00:16:47.240 --> 00:16:51.159 investigators get deeper access? Then? You mentioned jail breaking for iOS. 321 00:16:51.720 --> 00:16:53.000 Is there an Android equivalent? 322 00:16:53.240 --> 00:16:57.240 Yes? The equivalent concept is rooting the device. Rooting grant's 323 00:16:57.360 --> 00:17:00.879 super user or root privileges the high level of access 324 00:17:00.879 --> 00:17:03.919 in a Linux based system. This allows access to everything, 325 00:17:04.000 --> 00:17:07.359 including protected system files and directories like data data, where 326 00:17:07.359 --> 00:17:09.440 most private user and application data lives. 327 00:17:09.559 --> 00:17:11.599 But like jail breaking, rooting must have. 328 00:17:11.640 --> 00:17:15.960 Risks, right huge risks. First, rooting fundamentally alters the device's 329 00:17:15.960 --> 00:17:20.119 system software, which again raises evidence integrity questions. Second, the 330 00:17:20.119 --> 00:17:23.039 process itself can vary wildly depending on the device model 331 00:17:23.079 --> 00:17:26.240 and Android version, and critically on some devices like Google 332 00:17:26.319 --> 00:17:29.359 Zone Nexus or Pixel phones. Unlocking the bootloader often a 333 00:17:29.400 --> 00:17:32.759 prerequisite for routing automatically triggers a factory reset, wiping all 334 00:17:32.839 --> 00:17:33.559 user data. 335 00:17:33.599 --> 00:17:37.079 It wipes the data just to allow rooting. That's counterproductive 336 00:17:37.079 --> 00:17:38.400 for forensics. 337 00:17:37.880 --> 00:17:40.880 Exactly, it could destroy the very evidence you're trying to recover, 338 00:17:40.960 --> 00:17:44.440 So investigators have to be incredibly careful, know the specific 339 00:17:44.480 --> 00:17:48.359 device behavior, get proper authorization, and usually test the exact 340 00:17:48.400 --> 00:17:52.000 procedure on an identical, non evidentiary device. 341 00:17:52.079 --> 00:17:54.839 First. Wow, that sounds like walking a tightrope. 342 00:17:55.039 --> 00:17:58.160 It can be, and for newer devices using FBE file 343 00:17:58.200 --> 00:18:01.720 based encryption common since and seven point zero, a permanent 344 00:18:01.799 --> 00:18:04.720 root method often isn't even feasible for acquisition while the 345 00:18:04.759 --> 00:18:07.960 device is running normally. Investigators might have to rely on 346 00:18:08.000 --> 00:18:10.839 custom recovery environments or temporary root methods. 347 00:18:10.880 --> 00:18:14.200 Okay, so, assuming they can get some level access, what 348 00:18:14.319 --> 00:18:15.200 tools do they use? 349 00:18:15.319 --> 00:18:18.319 Fundamental tool is the Android the bug bridge or ADB. 350 00:18:18.839 --> 00:18:21.480 It's a command line utility that allows communication with an 351 00:18:21.480 --> 00:18:25.079 Android device. It's used for installing apps, copying files, running 352 00:18:25.119 --> 00:18:25.839 shell commands. 353 00:18:26.599 --> 00:18:30.079 Very powerful, but doesn't that require developer settings to be enabled. 354 00:18:30.400 --> 00:18:32.759 Yes, USB debugging needs to be turned on in the 355 00:18:32.759 --> 00:18:35.839 device's settings, and since Android four point two point two, 356 00:18:35.960 --> 00:18:39.920 there's secure USB debugging. When you connect an ADB enabled 357 00:18:39.920 --> 00:18:42.359 device to a new computer, the phone pops up a 358 00:18:42.400 --> 00:18:46.359 prompt asking you to authorize that computer. Without that authorization, 359 00:18:46.640 --> 00:18:48.240 ADB commands won't work. 360 00:18:48.200 --> 00:18:49.759 On another security layer. 361 00:18:50.000 --> 00:18:52.960 Right. But if USB debugging is enabled and the connecting 362 00:18:53.000 --> 00:18:57.119 computer is authorized or authorization can be bypassed, ADB can 363 00:18:57.160 --> 00:19:00.559 be used to pull data, sometimes even entire partitions, off 364 00:19:00.599 --> 00:19:04.720 the device. Forensic suites like autopsy can then analyze these 365 00:19:04.759 --> 00:19:06.759 acquired images or file dumps. 366 00:19:06.960 --> 00:19:11.039 The guy detailed some wild screenlock bypass techniques for Android two. 367 00:19:11.440 --> 00:19:14.119 Using ADB to delete the gesture file something called a 368 00:19:14.200 --> 00:19:14.880 smudge attack. 369 00:19:15.039 --> 00:19:17.680 Huh, Yes, the smuge attack. That's literally looking for the 370 00:19:17.720 --> 00:19:20.279 oily resnue patterns left on a touchscreen to try and 371 00:19:20.319 --> 00:19:24.440 guess the unlock pattern. Low tech but sometimes effective. 372 00:19:24.160 --> 00:19:27.480 Amazing and crashing the lock screen UI on older versions, 373 00:19:27.480 --> 00:19:29.519 pulling ADB keys from a suspects computer. 374 00:19:29.920 --> 00:19:33.480 Yeah, there are numerous techniques, some highly technical, some exploiting 375 00:19:33.519 --> 00:19:37.119 specific bugs in older Android versions. If investigators can find 376 00:19:37.119 --> 00:19:40.359 the adbkey dot pub file on a suspects computer that 377 00:19:40.440 --> 00:19:43.640 was previously authorized to debug the phone. They can sometimes 378 00:19:43.720 --> 00:19:46.680 use that key to authorize their own forensic workstation and 379 00:19:46.799 --> 00:19:49.720 bypass the secure USB debugging. 380 00:19:49.240 --> 00:19:51.319 Prompt, like stealing the keys to the Kingdom. 381 00:19:51.359 --> 00:19:54.240 In a digital sense, yes, it highlights the creative problem 382 00:19:54.279 --> 00:19:55.319 solving often needed. 383 00:19:55.559 --> 00:19:58.359 What about storage on Android? Is it different from iOS? 384 00:19:58.640 --> 00:20:02.279 It can be. Android devices often use standard file systems. 385 00:20:02.680 --> 00:20:06.400 External sd cards commonly use FAT thirty two or xat 386 00:20:06.880 --> 00:20:10.200 the internal memory, partitions like system and user data typically 387 00:20:10.279 --> 00:20:14.119 use Linux filesystems like ext four. Older devices might have 388 00:20:14.240 --> 00:20:15.559 used YFFS two. 389 00:20:15.720 --> 00:20:18.279 Is recovering deleted data easier then Sometimes? 390 00:20:18.400 --> 00:20:21.920 Recovering deleted files from an SD card using standard filecarving 391 00:20:22.000 --> 00:20:25.519 techniques is often more straightforward than from internal memory. Internal 392 00:20:25.519 --> 00:20:31.119 memory might use proprietary filesystem extensions or encryption. FDFP complicates 393 00:20:31.119 --> 00:20:35.119 things significantly. Also, how the phone connects to a computer matters. 394 00:20:35.240 --> 00:20:39.400 If it uses MTP Media Transfer Protocol or PTP Picture 395 00:20:39.400 --> 00:20:42.480 Transfer Protocol instead of presenting itself as a standard USB 396 00:20:42.640 --> 00:20:45.559 mass storage drive, you can't just mount it and run 397 00:20:45.640 --> 00:20:47.160 standard recovery tools directly. 398 00:20:47.359 --> 00:20:51.799 MTPPTP that's usually the default now right for transferring photos. 399 00:20:51.480 --> 00:20:53.839 Yes, it's more common now and more restrictive from a 400 00:20:53.880 --> 00:20:54.759 forensic standpoint. 401 00:20:54.839 --> 00:20:59.440