Course 42 - Mobile Malware Analysis Fundamentals | Episode 12: Dynamic Analysis Tools, Techniques, and Assessment

0:00So imagine just for a second that you have this highly suspect application sitting right there on your device. Oh, that's never a good feeling. Right. And you've already put in the grueling hours. You pulled apart its code, extract the APK, you know, sifted through all those hard coded strings. Yeah, you mapped out the whole static architecture. Exactly. But here is the inherent limitation of static analysis, right? Reading the code only really tells you what that application has the potential to do. It's basically just a theoretical threat model at that point. Yeah, exactly. The code is just sitting there dormant. What you really need is to see what that code actually executes when it wakes up, allocates memory and well, comes alive in a real environment. Because a static binary is basically, I mean, it's just a dormant blueprint until the operating system actually breathes life into it. Right. You can study a recipe all day long, but you don't really know how the ingredients will interact or, you know, if the baker secretly swaps sugar for salt until

1:00you actually bake the cake. That's a great way to put it. Yeah. When an app runs, it interacts with the system state. It pulls down dynamic configurations from remote servers. And it might even decrypt hidden payloads and memory that were just completely invisible during your static review, which brings us to the mission for today. Welcome to this deep dive into dynamic analysis for mobile security. Today, we want to give you a front row seat to the live execution of an app specifically. We're going deep into the Android ecosystem today. We are. We're going to map out exactly how to systematically poke, prod, manipulate and monitor a running application as if you're sitting right there inside the OS with it. It is honestly a non-negotiable skill for modern security research. I mean, static and dynamic analysis. There are really just two sides of the same analytical coin. Yeah. Your static analysis forms your initial hypothesis, right? You read the code and you think, hmm, I suspect this function leaks. User data and then you run the app dynamically to actually prove it. Or I guess the workflow could flip entirely.

2:02Oh, absolutely. You run the app. You observe this like suspicious network beacon reaching out to a command server and then you pivot back to your static tools to hunt down the exact cryptographic function that generated it. I always conceptualize static analysis as, you know, sitting at a desk, methodically reading a car's engineering schematic. Like, you know where the engine block is. You see how the fuel lines are routed, but dynamic analysis. That is jumping into the driver's seat, flooring the gas pedal and basically seeing if the wheels actually stay on the chassis. That captures the exact mindset perfectly. You're stress testing the environment. You want to force the app down execution paths. It maybe wasn't intended to go down for pads. The malware author really hoped you wouldn't find right. But to achieve that level of manipulation on Android, you can't just, you know, tap the screen with your finger. You need a dedicated framework that hooks directly into the operating system's internal communication channels, which introduces the cornerstone of our toolkit today, which is droser.

3:03Yeah, droser developed by MWR labs. It is arguably the premier framework for Android dynamic security testing. And why is it so ubiquitous? The reason researchers rely on it so heavily is because it operates as an interactive bridge. It doesn't just passively monitor stuff. It allows you to actively forge and inject Android interprocess communication messages or IPCs on the fly. Oh, wow. Yeah. So you can directly command an application's internal components to execute just completely bypassing the normal user interface. Okay. Let me stop you right there, though, and kind of challenge that concept. Because if we think about Android's core security model, it is entirely built around this concept of application sandbox. Yeah, absolutely. Every app gets its own unique user ID runs in its own virtual machine. And it's explicitly forbidden from touching the memory of another app. That's the design. So if Android is locking everything down by default, how does droser legally reach across that sandbox boundary to manipulate our target app?

4:05Like are we essentially exploiting a vulnerability in our own emulator just to get a foothold? That is a phenomenal question. And it really gets to the heart of how Android actually functions under the hood. Okay. No, we aren't burning a zero day exploit to break the sandbox. We're actually turning Android's own architectural design against itself. Wait, really? Well, Android applications aren't monolithic blocks of code. They are highly fragmented collections of loosely coupled components. Right. Activity services, all that exactly. And to make these components talk to each other, Android uses a message passing system called binder. Droser just operates on a client server architecture to exploit this exact system. Okay. So break that client server architecture down for us. What actually sits where in this setup? So you have a server component running on your specialized analysis machine. A common setup is running a Santoku Linux virtual machine, right? Which comes preloaded with all those mobile forensics tools. Exactly. That's your command center. Then you deploy the droser agent, which is really just a standard Android

5:08APK directly onto your target emulator or your physical test phone. Ah, so the droser agent installs itself just like any normal app. So it gets its own sandbox precisely. It plays by the rules. But once the droser agent is inside the system, it acts as a translation layer. Okay. When you type a command on your Santa Cervium, it sends that command over the network to the droser agent on the phone. The agent then crafts a perfectly formatted legitimate Android IPC message and basically hands it to the OS, asking it to deliver it to the target app. That's incredibly clever. We're literally just using the built in development and debugging pathways that Android inherently provides. Exactly. So since we know the suspect app is sitting there hiding its true behavior, we need this framework to force it to react. Let's walk through the actual mechanics of wiring this connection up for you listening at home. Oh, yeah. Let's visualize that you're sitting at your terminal. You have your Santoku VM spun up and your Android emulator is running. What's step one? The very first step is to wake up that listening post on the device.

6:10So you open the droser agent app on your emulator and just toggle the embedded server to on simple enough. Yeah. And when you do that, the agent opens a very specific network port to listen for incoming demands from your computer. That port is 31415 31415. So the first five digits of pi. Yeah. A nice little Easter egg from the developers there. It is. But here's the networking hurdle you run into. Your host computer's operating system cannot natively route traffic directly into the isolated virtual network stack of the Android emulator. Because it's walled off right. The emulator is essentially running behind its own internal net router. So if you just try to send a packet to port 31445 on your local machine, it'll just drop. We need to build a tunnel. Exactly. We need a tunnel through that virtual router. And this is where the Android debug bridge or you know, ADB steps in. ADB is essentially the wormhole between your host machine. And the emulators isolated environment. That's exactly what it is. You drop into your host terminal and you execute the command.

7:11Add forward TCO. That at 31415 TCP. Todd 31415. Let's dissect the syntax of that command for absolute clarity. Sure. So the ad pay forward directive tells the ADB demon to create a socket connection. By specifying TCP. 31415 as the first argument, you're opening port 31415 on your local computer's loop back interface. Then the second TCP. 0.31415 tells ADB to take any traffic it receives on that local port. Shove it through the USB or virtual connection and spit it out on port 31415 inside the emulators network stack. Now technically depending on your shell environment, I know you can sometimes omit the TCP protocol declaration. You can't. Yeah. But explicitly stating it is an industry best practice. It just prevents weird protocol mismatch errors down the line. Okay. So the wormhole is established. Our host machine and the droser agent are now successfully shaking hands. What's next from there? The final step is incredibly simple in your terminal. You just type droser console connect.

8:12That's it. That's it. The framework leverages that ADB tunnel we just built the moment you hit enter, your terminal prompt will actually change to DZ. That visual cue indicates your secure communications channel is locked in. You're now interactively driving the Android OS from your command line. We are officially in the system. But I mean, NMT emulators and giving up any secrets. We need to put our suspect application onto the chopping block. Right. And the standard deployment method is using ADB again. Okay. You use the command ab install followed by the file paths to your application package. So for example, my app.appk ADB pushes the binary across the tunnel and basically instructs the Android package manager to install it. Now once the app is installed, we run into this classic Android quirk, the constantly trips up analysts transitioning from desktop environment. Even the naming thing. Yes. The name you see on the emulators home screen, like the user friendly display names, a flashlight pro or whatever is entirely irrelevant to the operating

9:13system. Yeah. The display name is purely cosmetic. The Android system relies exclusively on the application's package name, which is structurally formatted like a reverse domain name. Right. Like calm.militius.flashlight. Exactly. And you cannot guess this internal system name based on the shiny icon on the screen. So if the display name is just a facade, how do we systematically hunt down the exact package name of the target we just installed? Well, droser handles this beautifully at your DZ prompt. You just execute run app dot package dot list. Okay. This command queries the Android package manager and dumps a comprehensive list of every single package currently installed and recognized by the system. You just parse that output until you identify the reverse domain name that correlates to your target APK. All right. So we have successfully identified our target package. The crosshairs are locked. What is our first real intelligence gathering move here? We want to pull down the application's entire profile as the system understands it. Makes sense. So you use the command run app, not package.info, a followed by your

10:14target package name. The switch is critical here. It stands for all. And what did that give us? It forces droser to return a massive or both dump of data. It includes the app's active permissions. It's assigned Linux user ID, data directory paths, and most importantly, the contents of its Android manifest. Okay. I'm going to push back on this step for a moment because if we're following a standard security methodology, we've already performed static analysis. Right? Sure. So that means we've already run tools, unpack the binary and read the Android manifest.xml file. Yeah. Why are we burning time pulling the manifest again while the app is live in memory? Isn't that redundant? It definitely feels redundant until you understand how the runtime environments actually process that file. Okay. Walk me through that during static analysis. The manifest you extract is a compiled compressed binary XML file. You have to rely on third party reverse engineering tools to decompile and reconstruct it. And those aren't perfect. Exactly. Sometimes those tools fail or the malware author intentionally corrupts

11:17the binary XML headers specifically to break your decompilers. Uh, I see where this is going. The operating system have to know how to read it to execute the app regardless of what tricks the author played. That is the crucial a hot moment right there. When you query the package info live through droser, you're bypassing the entire decompilation struggle. You're asking the Android OS to hand you the fully instantiated decoded manifest directly for memory. It's the absolute ground truth of what the application is actively claiming at runtime. So you see the exact permissions it currently holds. Yep. The specific shared libraries. It has loaded into memory. The network rules it's enforcing. You are analyzing the app's reality, not just its static blueprint. That distinction between the static blueprint and the runtime reality is massive. It means we have successfully mapped the perimeter with verified intel. Yes. We know exactly where the app lives. Yeah. And what privileges it holds. So now it's time to map out the attack surface. Right. And to make this incredibly concrete for everyone listening, let's pivot

12:20to a real world, highly complex target like Google Chrome. Okay. Its system package name is calm. Android. Chrome. Correct. Our objective is to identify every single exposed entry point where an external entity like our droser console or maybe a piece of malware residing on the same device can force Chrome to interact to use a physical analogy. We aren't just looking at the front door of a secure building. We're walking the entire perimeter, you know, cataloging every loading dock, every side window and every air vent that connects the inside of that building to the outside world. Exactly. And droser provides the exact command to automate that perimeter walk. It's run app dot package dot attack surface calm dot Android dot Chrome. Nice and intuitive. Yeah. When you fire that command, droser interrogates the Android operating systems routing tables and returns this highly structured breakdown. For a complex app like Chrome, the output will tell you what's identified. I would say nine activities, 11 broadcast receivers, three content providers and

13:20five services that are currently exported and listening. Now, if you're listening to this deep dive, you likely already understand what those core components are natively, but let's re contextualize them specifically through the lens of security and attack services. Yeah, we aren't looking at these as developer features anymore. We're looking at them as potential vulnerabilities. Right. Let's focus on the activities, which are typically the components that drive a user interface screen. In Android, you don't generally launch an activity by calling a function directly. You use the message passing system. Yes. You create an object called an intent and you hand it to the operating system. You know, I always explain intense like a restaurant ticketing system. Oh, I like that. Yeah. The customer, which is one app, doesn't walk into the kitchen and start cooking. The customer writes their order on a ticket, which is the intent. They hand that ticket to the waiter, which is the Android OS. The waiter reads the ticket, figures out which chef can cook the meal and hands the ticket to that specific chef, which would be the target activity.

14:22That is a brilliant way to conceptualize Android's intent routing mechanism. And here is where the attack surface comes into play. If a developer sets an activities exported flag to true in the manifest, they're essentially telling the waiter, I will accept a cooking ticket from literally anyone who walks into the restaurant. Wow. That activity becomes a completely public API endpoint. Any malicious app on the phone can generate an intent and force that activity to execute without any user interaction or permission. That is a massive security implication. Yeah. So we've identified that Chrome has what nine of these open doors. Let's start to in the door knobs. All right. To see the specific labels of those nine activities, we use the command run app.activity.info. It lists them all out. You'll almost always find an activity labeled main. That's the primary launch intent, right? The screen you see when you physically tap the Chrome icon, the absolute front door, the front door. And we can forcefully kick that door open from our terminal using run app.activity.start

15:23followed by the main activities fully qualified component name. And this is where dynamic analysis really feels like a magic trick. It really does. You're sitting at your host laptop. You execute that start command. And instantly on the emulator running on a different screen, the Chrome application just springs to life. You bypass the launcher completely and commanded the OS to spin up that process. It demonstrates absolute control over the execution flow. But launching the main activity is usually safe. Right. They expect people to use the front door. Exactly. We want to test the side windows. Let's say in our list of nine activities, we spot a deeply nested, really specific component. Maybe something named bookmark activity. Okay. So we generate a custom intent using droser and fire the run app.activity.start command aimed specifically at that bookmark activity. What's the expected outcome? Well, this is where dynamic analysis totally diverges from predictable static theory. You fire the command and you might watch the emulator screen do absolutely nothing.

16:24Okay. Or the application might immediately trigger a fatal exception and just crash right back to the home screen. But why the silent failure? Like if the door is unlocked and exported, why did it crash when we walked through it? Because of application state dependency. The developer likely assumed that the only way a user could ever reach that bookmark ad screen was by first loading a web page, parsing its metadata and then clicking the button, which would pass all that necessary context into memory. Exactly. But by using droser to forcefully jumpstart that specific activity out of thin air, the activity wakes up, looks for the web page metadata in memory, finds a null pointer instead and violently crashes, which proves exactly why dynamic analysis is inherently an exercise in trial, error and forced mutation. Yeah. We're deliberately prodding the application in unnatural out of sequence ways to expose unhandled exceptions and logical flaws. Absolutely. But this raises a fundamental problem regarding visibility. If we trigger an activity in droser in the app crashes or worse,

17:27if it silently modifies a system file, how do we actually capture the mechanics of what just happened? Like staring at the emulator screen isn't enough. No, the screen is just the presentation layer. The real action is happening deep inside the kernel and file system. Running the app is only, I'd say, 20% of dynamic analysis. The other 80% is meticulously setting your surveillance tracks before you ever touch the application. You need specialized telemetry tools running silently in the background. Let's unpack that surveillance toolbox. If we're setting traps, what are the primary domains we actually need to monitor? There are three critical domains. The first is file system monitoring. Applications are inherently noisy on the disk. They read configurations. They write cash data and critically, if they're malicious, they drop secondary payloads or expel trade local databases. Now, I know Android Studio has the device file explorer in some real time monitoring capabilities built right in. It does. And for standard app development, honestly, it's sufficient. But for deep programmatic security analysis,

18:29the Android Studio overhead can be really cumbersome to bulky. Yeah. So for analysts who live in the command line, the gold standard is a utility called FS. FS. Mon dedicated file system monitor. Yep. It's lightweight, incredibly fast and hooks directly into the kernels in out of five subsystem. You basically deploy FS. Mon into the emulators data directory. And you configure it to output its telemetry as structured JSON data, just piping it to a background file. Oh, that's smart. Yeah. So while you're using DROZER to rapidly trigger activities and broadcast receivers, FS. Mon is quietly generating this machine readable JSON log of every single read, write and permission, change the application attempts on the disk. I love that it outputs in JSON. It means you can ingest that log directly into a sum or write a quick Python script to parse out only this suspicious file modification. Exactly. All right. Our file system trap is set. What is the second domain network? Monitoring. This is the absolute lifeblood of modern threat analysis,

19:31whether it's a benign app updating its UI or a malicious app phoning home to a command and control server. The network traffic tells the true story, right? You might be analyzing an app and looking for very specific data, exfiltration techniques because you know, malware authors know we're watching the network. So they rarely just send stolen data and plain text anymore. Exactly. A super common evasion technique is encoding the stolen data before transmission. Analysts often hunt for what are colloquially termed hex scapes data payloads that have been encoded into hexadecimal escape sequences. Right. The malware does this to bypass simple string matching rules on intrusion detection systems. If you're just looking for the string password, you're going to completely miss it if it's sent as a hex encoded byte array. So if the app is attempting to smuggle data out via hex escapes, we need a packet capture trap capable of recording the raw byte streams at the interface level. And for that, we rely on the undisputed champion of network analysis, TCP dump the classic. It's pre compiled for Android environments, you SSH into the emulator,

20:34you bind TCP dump to the will and zero interface, which simulates the primary network adapter. And you just instruct it to dump the raw packet capture into a standard. Peacat file right there on the device. So we've got a highly orchestrated environment writing here. FSMON is actively tracking the file system, writing a JSON log. TCP dump is intercepting every network packet, writing a PC cap log. We spend an hour using droser to manipulate the attack surface. Once the dust settles, how do we actually extract the forensic evidence from the emulator? We leverage our ADB wormhole again. Of course. You execute the ad pull command to seamlessly drag those JSON and PC cap files off the Android devices storage and straight onto your secure host machine. Okay. And from there, you have home field advantage. You can load the PC cap into wire shark to reconstruct the network streams and hunt for those hex capes. And you can analyze the FSMon JSON in your preferred text editor. You're essentially sealing off the crime scene, collecting the security camera footage and bringing the tapes back to the lab

21:36for frame by frame analysis. Precisely. Now there is a third surveillance domain. And this is reserved for when you need granular instruction level of visibility into the execution flow. And that's debugging debugging. That's where we stop looking at the footprints, the app leaves behind and start looking at the actual neural pathways of the code as it executes in real time. Well said. And the debugging landscape on Android is bifurcated, depending entirely on the architecture of the code you're targeting. Okay. How so? If you're reverse engineering native code, meaning C or C++ libraries that have been compiled directly down to ARM machine instructions, you utilize GDB, the GNU project debugger, which is natively supported in the Android environments. And for you listeners who spend their days in the iOS ecosystem, using GDB on Android native libraries is the exact conceptual equivalent of attaching LLDB to an iOS binary. It's identical in philosophy. Yeah. You initialize a remote GDB server on the Android device, use ADB to forward a

22:37specific port. And the industry standard default is usually port 80 day date. And then you can attach your local GDB client. And then you have full control. Yeah. You can set memory break points, step through native assembly instructions, inspect CPU registers right as the code runs. But the vast majority of standard Android applications are actually compiled down to native machine code, right? They're written in Java or Kotlin, running inside the Dalvik or RTE virtual machines. GDB isn't really designed to debug managed Java by code. Correct. If you're hunting bugs or analyzing logic in the managed Java layer, your toolset has to shift for a robust graphical workflow, attaching the Android Studio Java debugger via the Java debug wire protocol is incredibly powerful. But if you hate IDEs, right, if your workflow is entirely CLI driven and you don't want the immense overhead of an IDE, there are specialized command line alternatives like Ann Bug, which allow you to attach to the Dalvik runtime and inspect Java objects directly from your terminal. Okay. We've covered a phenomenal amount of technical ground today.

23:39We moved from the static theory of a dormant binary to the dynamic reality of a live execution environment. It's journey. Yeah. We bridge the network gap using ADB, established command and control with DROZER mapped out the intent attack surface and layered on this really comprehensive surveillance net of file network and memory monitors. It's a rigorous, deeply technical methodology. And what's really vital to understand is that while the specific command line syntax we discussed today is unique to Android, the underlying philosophy of dynamic analysis is completely platform agnostic. It applies everywhere. Exactly. The tools adapt, but the mindset of isolating, manipulating and observing an application remains exactly the same, whether you're hunting malware on Android or iOS. Since you brought up cross platform methodologies, I actually want to pivot and put you the listener to the test. Oh, pop quiz. Let's do a rapid fire knowledge check. I'm going to ask a question synthesizing everything we just covered and I'll weave in a few iOS concepts to see how well you can translate these

24:39security philosophies across operating systems. Ready? I'll ask, give you a beat dancer in your head and our expert will confirm. Let's see how sharp they are. Question one for you listening, sticking with our Android networking setup. We just established that remote native debugging requires a tunnel. What is the exact ADB command you would type to forward your host traffic to the standard GB debugging port? If you visualize typing, add forward TCP or 8888, TCP dot 8888, you nailed the networking concept perfectly. Awesome. Question two, let's jump defense to the Apple ecosystem. When an iOS application is launched by the operating system, what is the absolute first function that gets called to initialize the apps life cycle? The core entry point for every iOS application is UI application main. That's where the entire execution thread begins. Spot on question three, staying deep in iOS architecture. We talked about Android app states crashing when forcefully launched. How many distinct execution states exist within an iOS applications life cycle? The iOS architecture defines exactly five states, not running in active,

25:42active background and suspended, understanding those states is critical for knowing when your tools can actually inject code. Exactly. Five states and the final question for you a bit of deep cut terminology trivia. In Android, we use droser to manipulate intense in iOS dynamic analysis. What is the highly specific slightly ridiculous industry term for intercepting and replacing objective C methods at runtime? Is it boozing, lounging, weaseling? It is certainly not weaseling. The definitive technique you rely on in iOS is called swizzling method swizzling. Heaven swizzling. It is a foundational technique for iOS runtime manipulation. Acting is the conceptual counterpart to how we leverage droser on Android and tying those cross platform concepts together leads to a crucial final thought. I want you to consider after this deep dive. Okay. Throughout this discussion, we've demonstrated the absolute terrifying control that frameworks like droser, ADB and GDB give you over an application. You can force hidden screens to open hijack network streams,

26:43rewrite execution flaws and memory. You essentially have total dominion over the operating system. We do because we're using these tools in a sterile lab environment for security research, but consider the implications in the wild. The Android architecture doesn't inherently distinguish between a legitimate security researcher sending an intent via droser to test and activity. Oh, wow. And a sophisticated piece of malware exploiting that exact same intent routing mechanism to silently harvest data in the background. The pathways are identical. That is a profoundly chilling realization. The exact structural mechanisms, you know, the IPC channels, the exported activities, the debugging protocols that developers rely on to build and test the ecosystem are the exact same mechanisms adversaries weaponized to dismantle it. The architecture itself is dual use. And that reality is precisely why mastering dynamic analysis is not optional. You cannot defend a system you do not know how to manipulate, which brings this full circle to our starting premise. You can analyze the static blueprint of an application all day long.

27:44You can memorize every line of code, but until you jump into the driver's seat, floor the gas pedal and dynamically force that code to execute an alive environment, you have absolutely no idea what machine is truly capable of. Never trust the static theory. Always force the application to prove itself against the dynamic runtime reality. Keep pulling apart the architecture. Keep questioning the execution flow and keep diving deep.