WEBVTT 1 00:00:00.120 --> 00:00:03.759 Imagine just for a second that you are a digital detective. 2 00:00:03.919 --> 00:00:05.240 Oh, I love a good hypothetical. 3 00:00:05.440 --> 00:00:07.960 Right, So you're sitting at your desk and you've just 4 00:00:08.080 --> 00:00:12.480 intercepted this highly suspicious mobile app. On the surface, it 5 00:00:12.519 --> 00:00:15.800 looks completely benign, like a flashlight app, maybe exactly a 6 00:00:15.839 --> 00:00:19.320 flashlight app, or a simple puzzle game or a PDF reader. 7 00:00:19.760 --> 00:00:23.679 But your telemetry, you know, maybe some alarming network alerts, 8 00:00:24.239 --> 00:00:29.879 is telling you it's actually malware. It's a digital trojan horse, which. 9 00:00:29.719 --> 00:00:31.320 Is always a fun moment for an analyst. 10 00:00:31.519 --> 00:00:35.119 Yeah, a real great start to the day. So here's 11 00:00:35.159 --> 00:00:37.719 the immediate problem. How do you pull this thing apart 12 00:00:37.759 --> 00:00:41.000 to see what it's really doing without accidentally triggering. 13 00:00:40.520 --> 00:00:43.000 It, Because if you just run it, you're in trouble. 14 00:00:43.280 --> 00:00:45.759 Exactly if you run it, if you execute that code, 15 00:00:46.200 --> 00:00:49.399 you might unleash the exact peload you are trying to study. 16 00:00:49.640 --> 00:00:54.359 Yeah, it's basically the cybersecurity equivalent of examining like an 17 00:00:54.479 --> 00:00:55.799 unexploded piece of ordinance. 18 00:00:55.799 --> 00:00:57.479 Oh, that's a good way to put it, right. 19 00:00:57.399 --> 00:01:00.119 Because you can't just start snipping wires or applying electric 20 00:01:00.159 --> 00:01:02.359 current to see what happens. You have to X ray 21 00:01:02.399 --> 00:01:06.719 the casing swab the outside for chemical signatures and map 22 00:01:06.760 --> 00:01:09.480 out the firing circuits entirely from the outside looking in. 23 00:01:09.680 --> 00:01:12.239 You have to understand the architecture of the threat before 24 00:01:12.239 --> 00:01:13.480 you ever let it execute. 25 00:01:13.519 --> 00:01:14.079 Exactly. 26 00:01:14.120 --> 00:01:18.040 Okay, let's unpack this because that is exactly our mission 27 00:01:18.120 --> 00:01:22.599 for this deep dive. We are exploring the foundational methodologies 28 00:01:22.640 --> 00:01:26.000 of basic static analysis for mogule malware. 29 00:01:26.040 --> 00:01:28.079 The foundational stuff, right, We're. 30 00:01:27.920 --> 00:01:30.640 Going to walk you through how to examine both iOS 31 00:01:30.680 --> 00:01:33.439 and Android architectures. You know, the structural files that act 32 00:01:33.519 --> 00:01:36.599 as their blueprints, and we'll get into the precise tools 33 00:01:36.680 --> 00:01:40.280 used to decode their capabilities, all while the code remains 34 00:01:40.439 --> 00:01:42.480 entirely at rest in a secure environment. 35 00:01:42.760 --> 00:01:45.439 And you know that concept of the code being at rest, 36 00:01:45.799 --> 00:01:48.359 that's really the defining characteristic of static. 37 00:01:48.120 --> 00:01:51.000 Analysis, right as opposed to dynamic analysis. 38 00:01:51.079 --> 00:01:54.959 Exactly. We are not observing behavior in a sandbox. We 39 00:01:55.000 --> 00:01:59.439 are analyzing the underlying structure, the dependencies, and the logic 40 00:01:59.480 --> 00:02:02.040 that's actually banked into the binary itself. 41 00:02:02.239 --> 00:02:05.040 We're dissecting the anatomy of the app to understand the 42 00:02:05.079 --> 00:02:06.560 author's intent spot on. 43 00:02:06.840 --> 00:02:08.520 We want to see what they were planning before they 44 00:02:08.560 --> 00:02:09.280 even get to do it. 45 00:02:09.439 --> 00:02:13.000 But we need to talk about strategy before tactics always 46 00:02:13.120 --> 00:02:15.599 because my instinct, and I think the instinct of a 47 00:02:15.639 --> 00:02:18.479 lot of people, especially students or self taught learners, when 48 00:02:18.479 --> 00:02:21.319 they first get a suspicious file would be to just 49 00:02:21.759 --> 00:02:24.879 immediately throw it into a disassembler or a decompiler. 50 00:02:24.919 --> 00:02:27.039 Oh yeah, just dive right in, right, just start. 51 00:02:26.879 --> 00:02:33.360 Tearing through the long first engineering. The assembly code is 52 00:02:33.479 --> 00:02:34.879 using trap, isn't it. 53 00:02:34.879 --> 00:02:37.639 It is an incredibly common trap, and honestly, it's a 54 00:02:37.680 --> 00:02:40.759 massive drain on your resources. How So, well, if you 55 00:02:40.800 --> 00:02:45.159 dive straight into raw hexadecimal data or assembly instructions without 56 00:02:45.199 --> 00:02:49.439 any broader context, you will almost certainly lose the forest 57 00:02:49.479 --> 00:02:52.280 for the trees. It's just too much data, way too much. 58 00:02:52.719 --> 00:02:58.039 The overall static analysis process requires strict operational discipline. Before 59 00:02:58.080 --> 00:03:01.400 you even look at a specific files internal code, you 60 00:03:01.479 --> 00:03:05.240 need to execute step one, which is identifying and searching 61 00:03:05.240 --> 00:03:07.960 the application through cryptographic hashing. 62 00:03:08.080 --> 00:03:11.280 Hashing. Okay, so instead of looking at the code itself, 63 00:03:11.639 --> 00:03:15.120 we are running the entire file through a mathematical algorithm, 64 00:03:15.199 --> 00:03:17.680 right like SAHA two fifty six or MD five right 65 00:03:17.759 --> 00:03:20.000 to generate a fixed length string of characters. It's like 66 00:03:20.039 --> 00:03:22.879 a unique digital fingerprint. For that exact file. 67 00:03:23.000 --> 00:03:26.240 Precisely, you generate that hash, and then you consult global 68 00:03:26.280 --> 00:03:29.879 threat intelligence resources and databases before you ever touch a 69 00:03:29.919 --> 00:03:31.960 specialized local analysis. 70 00:03:31.400 --> 00:03:34.479 Tool like virus Total or other malware repositories. 71 00:03:34.520 --> 00:03:37.280 Exactly, you are checking to see if the broader cybersecurity 72 00:03:37.280 --> 00:03:42.159 community has already encountered, analyzed, and mapped out this specific fingerprint. 73 00:03:42.400 --> 00:03:44.680 But uh, let me push back on that process for 74 00:03:44.680 --> 00:03:46.759 a second. Sure, if we have the malicious app right 75 00:03:46.759 --> 00:03:49.240 in front of us, isn't looking up the hash online 76 00:03:49.400 --> 00:03:53.080 essentially just while outsourcing the work? Yeah, Like it feels 77 00:03:53.120 --> 00:03:55.240 a bit like reading the summary instead of the book. 78 00:03:55.719 --> 00:03:58.599 Shouldn't we just reverse engineer at ourselves to guarantee we 79 00:03:58.639 --> 00:03:59.479 really understand it? 80 00:03:59.520 --> 00:04:03.520 I mean, that's a fair question, but it fundamentally misunderstands 81 00:04:03.520 --> 00:04:08.360 the economy of time in incident response and malware. 82 00:04:08.000 --> 00:04:09.960 Analysis, because time is money. 83 00:04:10.240 --> 00:04:15.080 Time is your most precious commodity. Researching a hash isn't outsourcing, 84 00:04:15.199 --> 00:04:19.160 It is vital triage. I mean, if a global intelligence 85 00:04:19.240 --> 00:04:22.639 database tells you that this specific SAHA two five six 86 00:04:22.759 --> 00:04:27.079 hash belongs to a known, well documented banking trojan, well 87 00:04:27.079 --> 00:04:30.560 you've just saved yourself potentially days of reverse engineering. 88 00:04:30.160 --> 00:04:33.839 Right, because knowledge is most valuable when it's applied efficiently. 89 00:04:33.959 --> 00:04:36.720 You don't get bonus points for rediscovering a wheel that 90 00:04:36.800 --> 00:04:38.319 someone documented three years ago. 91 00:04:38.399 --> 00:04:41.600 Exactly. Redoing work that the community has already mapped out 92 00:04:42.040 --> 00:04:45.839 actively slows down your ability to protect your environment. And 93 00:04:45.879 --> 00:04:47.720 this leads to the most crucial part of the entire 94 00:04:47.759 --> 00:04:51.040 analysis process, which is setting firm objectives based on that 95 00:04:51.079 --> 00:04:52.040 initial intelligence. 96 00:04:52.120 --> 00:04:54.279 Okay, so narrowing the scope, right. 97 00:04:54.839 --> 00:04:57.519 If the hash tells you it is a known SMS 98 00:04:57.560 --> 00:05:01.680 stealing trojan, your objective is shifts. You weren't trying to 99 00:05:01.720 --> 00:05:03.720 answer what is this anymore? 100 00:05:03.800 --> 00:05:06.800 Your objective becomes highly targeted exactly. 101 00:05:06.399 --> 00:05:09.360 It becomes what command and control servers is this specific 102 00:05:09.439 --> 00:05:12.000 variant waking out to and how is it persisting on 103 00:05:12.040 --> 00:05:15.480 my network? Having those firm objectives prevents you from just 104 00:05:15.600 --> 00:05:17.720 drowning in a sea of irrelevant data. 105 00:05:17.920 --> 00:05:21.560 That makes perfect sense. The hash dictates the mission. But uh, 106 00:05:21.720 --> 00:05:24.480 let's look at the alternative scenario, A fun scenario, right. 107 00:05:24.519 --> 00:05:26.759 We run the hash, we query the databases, and we 108 00:05:26.800 --> 00:05:27.759 get zero hits. 109 00:05:27.959 --> 00:05:28.279 Nothing. 110 00:05:28.399 --> 00:05:31.279 It's a completely novel threat. The Internet has no idea 111 00:05:31.319 --> 00:05:33.879 what this file is. We're flying blind, which means we 112 00:05:33.959 --> 00:05:36.639 have to do the heavy lifting ourselves. So let's start 113 00:05:36.639 --> 00:05:38.120 with the Apple ecosystem. 114 00:05:38.319 --> 00:05:39.720 Okay, iOS, Right. 115 00:05:39.680 --> 00:05:43.839 We are looking at a suspected malicious iOS application. So 116 00:05:44.000 --> 00:05:47.639 picture you open your terminal or your file explorer. Where 117 00:05:47.680 --> 00:05:48.920 do we even begin looking? 118 00:05:49.040 --> 00:05:50.759 Well, the very first thing you need to realize is 119 00:05:50.839 --> 00:05:54.399 that an iOS app isn't just one monolithic file whatch 120 00:05:54.439 --> 00:05:57.279 you download from the app store, you know, an IPA file. 121 00:05:57.600 --> 00:06:00.800 It's essentially just a specialized zip the archive. 122 00:06:00.959 --> 00:06:01.839 So it's a container. 123 00:06:02.040 --> 00:06:05.680 Yeah, it's a package. It's a bundle of different resources, images, 124 00:06:06.000 --> 00:06:09.639 configuration files, and of course compiled code. Our very first 125 00:06:09.639 --> 00:06:13.279 objective is to find the actual engine of the app, 126 00:06:13.600 --> 00:06:15.040 the core executable file. 127 00:06:15.560 --> 00:06:18.600 So if I just unzip that archive, I'm going to 128 00:06:18.680 --> 00:06:21.319 see a directory structure in front of me. And I 129 00:06:21.360 --> 00:06:24.759 know one of the main folders inside an iOS app 130 00:06:24.759 --> 00:06:26.720 bundle is called the payload directory. 131 00:06:26.800 --> 00:06:28.360 Yep, the payload directory. 132 00:06:28.040 --> 00:06:31.120 And naturally payloads sounds exactly like what a maur analyst 133 00:06:31.199 --> 00:06:33.639 would want to look at. Is the executable just sitting 134 00:06:33.680 --> 00:06:34.199 right in there? 135 00:06:34.560 --> 00:06:37.240 I mean, it is inside that directory structure eventually, but 136 00:06:37.279 --> 00:06:39.800 you have to know exactly what you are looking for. 137 00:06:40.199 --> 00:06:43.519 The payload directory contains the application wrapper, but it is 138 00:06:43.600 --> 00:06:45.079 not the executable itself. 139 00:06:45.160 --> 00:06:47.240 Okay, so where do people go wrong here? 140 00:06:47.319 --> 00:06:49.680 You'll see people guessing At this stage. They start poking 141 00:06:49.720 --> 00:06:51.920 around looking for configuration files to point them in the 142 00:06:51.959 --> 00:06:54.399 right direction. They might look for a file called, say, 143 00:06:54.879 --> 00:06:57.759 settings dot plist or application dot plists, assuming those have 144 00:06:57.839 --> 00:07:00.839 the architecture map, but they don't. Usually those files don't 145 00:07:00.839 --> 00:07:03.680 even exist, or if they do, they definitely don't contain 146 00:07:04.120 --> 00:07:06.120 the core metadata we actually need. 147 00:07:06.240 --> 00:07:08.639 So it's like wandering around a cargo ship just looking 148 00:07:08.680 --> 00:07:11.680 into random crates. We need a document that tells us 149 00:07:11.759 --> 00:07:13.120 exactly what is on board. 150 00:07:13.279 --> 00:07:16.199 That is a perfect analogy, and for an iOS app, 151 00:07:16.560 --> 00:07:22.199 that authoritative document, the ship's manifest is a file called infodt. 152 00:07:21.519 --> 00:07:26.000 Plist infodot plist. Okay, so this is a property list file, 153 00:07:26.079 --> 00:07:30.040 an XML based file that Apple uses to store configuration data. 154 00:07:30.199 --> 00:07:33.959 Correct. The infodot plist is the foundational map of the application. 155 00:07:34.240 --> 00:07:37.399 It declares the app's bundle identifier, its version number, the 156 00:07:37.439 --> 00:07:41.160 permissions it requires, and the executable And most importantly for 157 00:07:41.240 --> 00:07:45.319 our purposes, yes, it contains the exact literal name of 158 00:07:45.399 --> 00:07:48.920 the core executable binary. It removes all the guesswork completely. 159 00:07:48.959 --> 00:07:52.000 Okay, So we check the infodoplist our ship's manifest and 160 00:07:52.040 --> 00:07:55.199 we find the exact name of the core Maco binary file, 161 00:07:55.279 --> 00:07:57.160 you know, the actual compiled engine of the app. 162 00:07:57.279 --> 00:07:57.480 Right. 163 00:07:57.639 --> 00:07:59.920 Once we isolate that binary, how do we look inside 164 00:07:59.920 --> 00:08:02.240 it without actually running it? Because we need to extract 165 00:08:02.279 --> 00:08:03.360 its structural blueprint? 166 00:08:03.480 --> 00:08:06.720 Right, yes, we want to see how the developer organize 167 00:08:06.720 --> 00:08:10.920 the code itself. Now, in the Apple ecosystem, apps are 168 00:08:11.000 --> 00:08:14.439 historically written in Objective C or Swift, okay, and because 169 00:08:14.439 --> 00:08:18.399 of how these languages operate, particularly Objective C, a massive 170 00:08:18.399 --> 00:08:22.800 amount of structural metadata is actually left behind inside the 171 00:08:22.800 --> 00:08:24.240 compiled binary. 172 00:08:23.959 --> 00:08:25.160 Like what kind of metadata? 173 00:08:25.199 --> 00:08:28.480 The names of the classes, the properties, the methods. And 174 00:08:28.560 --> 00:08:32.320 we can extract all this metadata by dumping the iOS classes. 175 00:08:32.600 --> 00:08:35.840 So we are essentially looking at the nouns and verbs 176 00:08:36.000 --> 00:08:38.440 the developer used to build the app exactly. So if 177 00:08:38.480 --> 00:08:41.200 we see a class named I don't know, data exfiltrator 178 00:08:41.360 --> 00:08:43.799 or a method called upload contacts. 179 00:08:43.399 --> 00:08:45.360 To server, then that is a massive red flag. 180 00:08:45.480 --> 00:08:48.120 Right, So what tools do we actually use to extract 181 00:08:48.120 --> 00:08:48.919 those blueprints? 182 00:08:49.000 --> 00:08:52.320 We rely on highly specific command line tools designed to 183 00:08:52.480 --> 00:08:55.679 parse the Maco binary format. The standard tools for this 184 00:08:55.799 --> 00:08:58.720 job are class dump, a variant called class dump Z, 185 00:08:59.039 --> 00:09:02.360 and a remarkably utility built into the Mac os environment 186 00:09:02.440 --> 00:09:03.120 called O tool. 187 00:09:03.200 --> 00:09:05.759 Class dump and O tool. And I assume because we 188 00:09:05.799 --> 00:09:07.679 are working in the command line, we're dealing with a 189 00:09:07.720 --> 00:09:09.159 fairly unforgiving environment. 190 00:09:09.480 --> 00:09:14.440 Oh, incredibly unforgiving. The command line only executes exactly what 191 00:09:14.480 --> 00:09:15.320 you instruct it to. 192 00:09:15.519 --> 00:09:17.240 No ring for typos, none. 193 00:09:17.720 --> 00:09:20.360 You have to know the precise tools that actually exist. 194 00:09:20.639 --> 00:09:24.000 For instance, you might hear rumors on forums about a 195 00:09:24.039 --> 00:09:27.720 tool called class dump pro sounds fancy, it sounds like 196 00:09:27.720 --> 00:09:32.000 a premium, highly effective utility, right, but it does not exist. 197 00:09:32.080 --> 00:09:34.200 Wait, really, it's just a myth, just a myth. 198 00:09:34.799 --> 00:09:38.279 There's a legacy tool called class dump, say, but for modern, 199 00:09:38.480 --> 00:09:42.720 reliable static analysis standard class dump and O tool are 200 00:09:42.720 --> 00:09:46.440 the primary instruments you will use to pull those class structures. 201 00:09:46.600 --> 00:09:48.720 Okay, here is where it gets really interesting to me. 202 00:09:48.879 --> 00:09:51.600 We've mapped out the internal structures, you know, the classes 203 00:09:51.639 --> 00:09:54.759 and methods. But apps don't operate in a vacuum. 204 00:09:54.840 --> 00:09:55.399 No they don't. 205 00:09:55.559 --> 00:09:57.919 A malicious app needs to connect to the internet, it 206 00:09:57.960 --> 00:10:00.639 needs to access the file system. Maybe it needs to 207 00:10:00.639 --> 00:10:03.840 read the devices cryptography libraries. How do we see what 208 00:10:03.879 --> 00:10:06.120 external resources the app is reaching out to. 209 00:10:06.120 --> 00:10:09.000 To understand an app's true capabilities, we have to examine 210 00:10:09.039 --> 00:10:10.399 its dynamic libraries. 211 00:10:10.600 --> 00:10:12.200 The libraries right. 212 00:10:12.440 --> 00:10:16.159 Libraries are pre written foundational chunks of code provided by Apple. 213 00:10:16.639 --> 00:10:18.879 So an app doesn't write its own code from scratch 214 00:10:18.919 --> 00:10:22.720 to turn on the camera, it just links to Apple's 215 00:10:22.759 --> 00:10:23.919 existing camera librarries. 216 00:10:23.960 --> 00:10:27.840 Okay, so if we are analyzing, say a simple offline 217 00:10:28.159 --> 00:10:29.480 calculator app. 218 00:10:29.360 --> 00:10:33.279 And we discover it is linking to networking libraries, cryptography frameworks, 219 00:10:33.600 --> 00:10:35.559 and contact list APIs. 220 00:10:35.240 --> 00:10:38.159 Then we immediately know its capabilities do not match its 221 00:10:38.200 --> 00:10:41.399 disguise purpose. It's a fake calculator exactly. So how do 222 00:10:41.480 --> 00:10:44.879 we actually expose those library connections? Are they just listed 223 00:10:44.879 --> 00:10:46.440 in a plain text file somewhere. 224 00:10:46.519 --> 00:10:49.080 No, They're not that obvious. They are embedded within the 225 00:10:49.159 --> 00:10:51.279 load commands of the MACO binary header. 226 00:10:51.399 --> 00:10:51.720 Okay. 227 00:10:51.799 --> 00:10:54.879 When the Apple operating system launches an app, the loader 228 00:10:54.919 --> 00:10:58.120 reads these specific commands to know which dynamic libraries it 229 00:10:58.159 --> 00:11:01.559 needs to pull into memory. Read these load commands ourselves. 230 00:11:01.879 --> 00:11:04.200 We use otool again, but we must use a very 231 00:11:04.200 --> 00:11:08.039 specific flag, which is a capital L. The exact command 232 00:11:08.039 --> 00:11:10.879 you type in is o tool space dash capital. 233 00:11:10.679 --> 00:11:13.639 L ownual dash capital L, and I imagine the capitalization 234 00:11:13.799 --> 00:11:15.320 is non negotiable. 235 00:11:15.000 --> 00:11:18.799 Absolutely non negotiable. This is where understanding the mechanism of 236 00:11:18.840 --> 00:11:20.360 the tool is vital. 237 00:11:20.519 --> 00:11:21.759 What happens if you get it wrong? 238 00:11:22.440 --> 00:11:25.600 If you type a lowercase L, the tool doesn't even 239 00:11:25.600 --> 00:11:29.360 recognize the command. If you use a lowercase A, you 240 00:11:29.440 --> 00:11:32.679 are instructing O tool to look at a completely different 241 00:11:32.720 --> 00:11:34.120 data section within the binary. 242 00:11:34.399 --> 00:11:36.480 And what if you forget the flag completely. 243 00:11:36.679 --> 00:11:39.559 If you just run a tool without specifying the library flag, 244 00:11:40.000 --> 00:11:42.279 you might end up dumping the raw simple table that 245 00:11:42.360 --> 00:11:45.519 will just flood your terminal with a massive, unintelligible wall 246 00:11:45.559 --> 00:11:48.759 of text that tells you absolutely nothing about the app's 247 00:11:48.799 --> 00:11:51.919 high level capabilities. Wow, okay, yeah, you specifically want to 248 00:11:51.919 --> 00:11:54.759 parse the load commands for dynamic libraries, you need O 249 00:11:54.840 --> 00:11:55.960 tool dash capital L. 250 00:11:56.360 --> 00:11:59.960 So if I'm visualizing this entire iOS process step by step, 251 00:12:00.480 --> 00:12:03.519 the infodop plist is the ship's manifest that tells us 252 00:12:03.559 --> 00:12:07.039 exactly which container holds the core binary, and running O 253 00:12:07.120 --> 00:12:09.759 tool dash capital L is like swabbing that container for 254 00:12:09.840 --> 00:12:12.759 chemical residue, revealing all the invisible connections it has to 255 00:12:12.759 --> 00:12:15.200 the outside world. Based on the tools packed inside. 256 00:12:15.320 --> 00:12:18.159 That is an excellent way to conceptualize it. You are 257 00:12:18.240 --> 00:12:21.240 letting the architecture betray the app's true intentions. 258 00:12:21.440 --> 00:12:25.320 Right, So we have cracked open the Apple ecosystem, but 259 00:12:25.600 --> 00:12:29.559 mobile malware is a multi front war. What happens when 260 00:12:29.720 --> 00:12:32.639 our digital suspect is an Android. 261 00:12:32.120 --> 00:12:34.080 App a whole different ballgame. 262 00:12:33.759 --> 00:12:38.159 Because Apple uses a tightly controlled, compiled C family architecture, 263 00:12:38.559 --> 00:12:42.919 but Android is a completely different paradigm. It's fundamentally built 264 00:12:42.919 --> 00:12:46.360 on Java and operates in a much more open ecosystem. 265 00:12:46.879 --> 00:12:49.720 I assume our analytical approach has to shift entirely. 266 00:12:50.000 --> 00:12:54.440 Entirely the underlying architecture dictates the tools. Android apps don't 267 00:12:54.519 --> 00:12:57.440 use plust files and they definitely don't use Moco binaries. 268 00:12:57.720 --> 00:13:00.240 An Android app is packaged as an EPKA file. 269 00:13:00.279 --> 00:13:03.879 An Android package file, which, much like the IOSIPA, is 270 00:13:03.960 --> 00:13:06.360 basically just to specialize ZP archive. 271 00:13:06.639 --> 00:13:10.399 Exactly. It is a ZP or archive containing the apps, resources, certificates, 272 00:13:10.399 --> 00:13:13.440 and the compiled code. But here's the critical difference. If 273 00:13:13.440 --> 00:13:16.840 you just natively unzip an APK using standard archive software, 274 00:13:17.120 --> 00:13:19.600 you cannot read the context. Why, because the core code 275 00:13:19.639 --> 00:13:24.919 is compiled into delvic executable format. A dox file. Furthermore, 276 00:13:24.919 --> 00:13:28.600 the essential configuration files, which look like standard XML, are 277 00:13:28.679 --> 00:13:31.759 actually compiled into a binary XML format to save space, 278 00:13:32.440 --> 00:13:34.039 so if you open them in a text editor, it 279 00:13:34.120 --> 00:13:35.519 just looks like complete gibberish. 280 00:13:35.639 --> 00:13:37.840 So we can't just unzip it. We have to actively 281 00:13:37.879 --> 00:13:40.480 decode it back into a human readable state. How do 282 00:13:40.519 --> 00:13:41.840 we reverse that process? 283 00:13:42.360 --> 00:13:45.399 We use a dedicated, powerful utility called app tool. 284 00:13:45.559 --> 00:13:46.200 App tool. 285 00:13:46.320 --> 00:13:50.159 Yes, apptool is specifically designed to parse those delvic executable 286 00:13:50.200 --> 00:13:53.440 files and translate them into smally, which is a human 287 00:13:53.440 --> 00:13:55.360 readable assembly like syntax. 288 00:13:55.440 --> 00:13:56.879 Okay, that sounds super useful. 289 00:13:57.000 --> 00:14:00.279 It is, and more importantly, for our initial triage, it 290 00:14:00.399 --> 00:14:04.440 decodes those binary XML files back into standard READABLEXML. 291 00:14:04.679 --> 00:14:08.919 So aptool essentially rebuilds the original project directory exactly as 292 00:14:08.919 --> 00:14:11.480 the developer saw it on their screen exactly. How do 293 00:14:11.519 --> 00:14:13.000 we invoke that? In the command line? 294 00:14:13.000 --> 00:14:16.279 The precise instruction to decode and APK is aptool space 295 00:14:16.360 --> 00:14:18.840 D followed by another space, and then the name of 296 00:14:18.879 --> 00:14:22.279 your file. The adult simply stands for decode. 297 00:14:21.919 --> 00:14:25.840 Ap tool dfile. It sounds simple enough, but given what 298 00:14:25.879 --> 00:14:28.759 we know about command line syntax, I'm guessing there's a 299 00:14:28.799 --> 00:14:31.879 nuance here that trips people up. Usually, when we pass 300 00:14:31.919 --> 00:14:34.120 a flag to a command line tool, like we did 301 00:14:34.240 --> 00:14:36.200 with otool dash L, we use. 302 00:14:36.080 --> 00:14:39.679 A dash and that is exactly where the analytical friction occurs. 303 00:14:39.759 --> 00:14:43.480 I knew it because standard POSEX syntax conditions us to 304 00:14:43.559 --> 00:14:48.000 use dashes. Analysts instinctively want to type aptool space dash 305 00:14:48.080 --> 00:14:48.919 d space. 306 00:14:48.720 --> 00:14:51.480 File right muscle memory exactly. 307 00:14:51.240 --> 00:14:53.600 Or they might think they need to list the contents 308 00:14:53.639 --> 00:14:56.159 first and try a non existent flag like dash L. 309 00:14:56.679 --> 00:15:00.000 But aptool operates differently. If you include that dash before 310 00:15:00.080 --> 00:15:02.759 or the d the tool will fail. It just won't run, 311 00:15:02.840 --> 00:15:05.360 It won't decode Dalvic bytcode, and won't rebuild the XML. 312 00:15:05.399 --> 00:15:09.200 Your analysis stops cold. It requires deliberate exactness. It's just 313 00:15:09.519 --> 00:15:13.960 apptool space, D space the file name, no dashes. 314 00:15:14.240 --> 00:15:16.600 It is a stark reminder that we are interacting with 315 00:15:16.840 --> 00:15:21.919 raw programmatic logic, not a user friendly graphical interface for sure. Okay, 316 00:15:22.000 --> 00:15:26.600 so we've been precise. We successfully typed app tool D, 317 00:15:27.519 --> 00:15:31.720 the APKs decoded, the Dalvik bytecode is translated, and the 318 00:15:31.759 --> 00:15:36.159 binary XML is now readable text. Where is our target? 319 00:15:36.480 --> 00:15:40.279 What is the Android equivalent to apple'sinfo dot plust. 320 00:15:40.080 --> 00:15:43.039 Your primary target? The absolute gold mine for Android static 321 00:15:43.080 --> 00:15:47.039 analysis is a file called the Android Manifest dot XXML. 322 00:15:47.200 --> 00:15:49.639 The Android manifest, it sounds authoritative. 323 00:15:49.840 --> 00:15:52.960 It is the master control document for the application. Because 324 00:15:53.000 --> 00:15:56.120 Android operates on a sandbox model where apps are isolated 325 00:15:56.120 --> 00:15:59.039 from each other, and app must explicitly declare its required 326 00:15:59.080 --> 00:16:02.159 permissions and its internal components to the operating system. Okay, 327 00:16:02.240 --> 00:16:03.960 so if an app wants to access the Internet, read 328 00:16:04.000 --> 00:16:06.679 your contacts, or sent text messages, it must be stated 329 00:16:06.720 --> 00:16:07.399 in the manifest. 330 00:16:07.480 --> 00:16:10.519 So we open Theanroid manifest dot xml and we start 331 00:16:10.600 --> 00:16:14.679 hunting for malicious behavior. What exactly does a malicious capability 332 00:16:14.720 --> 00:16:15.759 look like in this file? 333 00:16:16.080 --> 00:16:18.799 To understand that, you have to understand how Android apps communicate. 334 00:16:18.799 --> 00:16:21.240 They use an inner process communication system. Basically, if an 335 00:16:21.240 --> 00:16:22.840 app wants to do something, or if it wants to 336 00:16:22.879 --> 00:16:25.480 react to a system event, it uses an object called 337 00:16:25.480 --> 00:16:26.279 an intent. 338 00:16:26.360 --> 00:16:29.759 And intent So rather than directly hooking into the phone's 339 00:16:29.879 --> 00:16:33.840 SMS database and app essentially yells into the operating systems room, 340 00:16:34.080 --> 00:16:36.600 I intend to send a message or who has a 341 00:16:36.639 --> 00:16:37.679 new text message? 342 00:16:37.799 --> 00:16:40.440 That is exactly how it works, and to listen for 343 00:16:40.440 --> 00:16:43.960 those specific announcements, the app declares a specific field in 344 00:16:44.000 --> 00:16:47.840 the manifest called an intent filter. The intent filter tells 345 00:16:47.879 --> 00:16:51.120 the Android OS, hey, wake my app up when this 346 00:16:51.200 --> 00:16:52.320 specific event happens. 347 00:16:52.360 --> 00:16:55.159 So, let's say our initial hash research suggested this malware 348 00:16:55.279 --> 00:16:58.000 was a premium SMS toll fraud. 349 00:16:57.840 --> 00:17:00.960 Trojan uh, the kind that silently sent text messages to 350 00:17:01.000 --> 00:17:02.720 premium numbers to join your bank account. 351 00:17:02.759 --> 00:17:05.839 Exactly. So we decode the APK, we open the Android 352 00:17:05.880 --> 00:17:08.039 manifest dot XML, and we start scanning. 353 00:17:08.559 --> 00:17:11.000 And if you scan that manifest and find an intent 354 00:17:11.039 --> 00:17:14.400 filter configured to listen for say Android dot Provider, dot 355 00:17:14.440 --> 00:17:17.240 telepany dot SMS underscore received. 356 00:17:16.920 --> 00:17:19.839 Then you have just verified a core capability of the malware. 357 00:17:19.920 --> 00:17:22.400 You are looking at an intent shelter designed to intercept 358 00:17:22.480 --> 00:17:25.880 incoming text messages. If you are analyzing a simple offline 359 00:17:25.880 --> 00:17:29.519 notepad app and its manifest contains an intent filter aggressively 360 00:17:29.559 --> 00:17:32.799 monitoring your SMS traffic, well you have found the smoking gun. 361 00:17:33.039 --> 00:17:36.960 The structural fingerprint matches the suspected crime, and we proved 362 00:17:36.960 --> 00:17:39.960 it without ever executing a single line of malicious code. 363 00:17:40.160 --> 00:17:40.960 That's the beauty of it. 364 00:17:41.119 --> 00:17:44.279 We just looked at the app's own stated intentions inside 365 00:17:44.279 --> 00:17:46.440 its manifest and caught it red handed. 366 00:17:46.640 --> 00:17:50.400 That is the true power of basic static analysis. You 367 00:17:50.480 --> 00:17:52.960 are reading the thread actor's architectural blueprint. 368 00:17:53.160 --> 00:17:55.359 Let's take a breath and connect all these dots. Because 369 00:17:55.400 --> 00:17:58.559 we have covered a tremendous amount of ground across two 370 00:17:58.960 --> 00:18:02.880 entirely different operating systems, we definitely have. We started with 371 00:18:02.880 --> 00:18:07.039 the vital strategic phase, you know, using cryptographic hashes to 372 00:18:07.240 --> 00:18:11.519 querry global intelligence databases. We establish what we are dealing 373 00:18:11.599 --> 00:18:14.200 with before we ever touch a tool, allowing us to 374 00:18:14.279 --> 00:18:17.519 set highly targeted analytical objectives. 375 00:18:17.000 --> 00:18:19.759 Because context is everything in malware analysis exactly. 376 00:18:20.160 --> 00:18:23.559 Then we tackled the closed ecosystem of Apple. We learned 377 00:18:23.599 --> 00:18:27.119 that bypassing the generic payload directory and zeroing in on 378 00:18:27.160 --> 00:18:30.400 the info dot plist the ship's manifest is how we 379 00:18:30.480 --> 00:18:33.960 find the true name of the muco executable. We explored 380 00:18:33.960 --> 00:18:37.960 how dumping classes reveals the internal logic, and how parsing 381 00:18:38.000 --> 00:18:41.119 the load commands with O tool dash capital l exposes 382 00:18:41.200 --> 00:18:43.240 the dynamic libraries the app relies on. 383 00:18:43.519 --> 00:18:47.000 And then we shifted paradigms to Android's Java based architecture. 384 00:18:47.119 --> 00:18:50.480 Right we discuss why you can't just natively unzipin APK, 385 00:18:51.119 --> 00:18:54.720 but must decode the dolvic bytecode and binary XML using 386 00:18:54.799 --> 00:18:58.119 app toold relying on precise syntax with no dashes. 387 00:18:58.400 --> 00:18:59.200 Crucial point. 388 00:19:00.200 --> 00:19:03.319 We explored how the Android manifest dot xml serves as 389 00:19:03.319 --> 00:19:07.400 the master controlled document where malicious capabilities are openly declared 390 00:19:07.440 --> 00:19:11.359 through interprocess communication mechanisms, specifically the intent filters. 391 00:19:11.440 --> 00:19:15.279 It is a robust foundational methodology. If you grasp the 392 00:19:15.319 --> 00:19:18.680 mechanics behind these specific files and these specific tools, you 393 00:19:18.759 --> 00:19:22.319 possess the structural keys to demystify the vast majority of 394 00:19:22.400 --> 00:19:23.240 mobile malware. 395 00:19:23.400 --> 00:19:24.960 And I want you to think about how you would 396 00:19:24.960 --> 00:19:28.039 approach a brand new, highly suspicious file landing on your 397 00:19:28.039 --> 00:19:30.279 desk right now. Let's do a quick mental check. Oh 398 00:19:30.319 --> 00:19:33.039 pop quiz, just a quick review exercise to lock this in. 399 00:19:33.599 --> 00:19:36.119 If you have an iOS app and an Android app 400 00:19:36.119 --> 00:19:38.079 in front of you, and you need to find the 401 00:19:38.079 --> 00:19:43.240