Speaker 1: Imagine just for a second that you are a digital detective.
Speaker 2: Oh, I love a good hypothetical.
Speaker 1: Right, So you're sitting at your desk and you've just
Speaker 1: intercepted this highly suspicious mobile app. On the surface, it
Speaker 1: looks completely benign, like a flashlight app, maybe exactly a
Speaker 1: flashlight app, or a simple puzzle game or a PDF reader.
Speaker 1: But your telemetry, you know, maybe some alarming network alerts,
Speaker 1: is telling you it's actually malware. It's a digital trojan horse, which.
Speaker 2: Is always a fun moment for an analyst.
Speaker 1: Yeah, a real great start to the day. So here's
Speaker 1: the immediate problem. How do you pull this thing apart
Speaker 1: to see what it's really doing without accidentally triggering.
Speaker 2: It, Because if you just run it, you're in trouble.
Speaker 1: Exactly if you run it, if you execute that code,
Speaker 1: you might unleash the exact peload you are trying to study.
Speaker 2: Yeah, it's basically the cybersecurity equivalent of examining like an
Speaker 2: unexploded piece of ordinance.
Speaker 1: Oh, that's a good way to put it, right.
Speaker 2: Because you can't just start snipping wires or applying electric
Speaker 2: current to see what happens. You have to X ray
Speaker 2: the casing swab the outside for chemical signatures and map
Speaker 2: out the firing circuits entirely from the outside looking in.
Speaker 1: You have to understand the architecture of the threat before
Speaker 1: you ever let it execute.
Speaker 2: Exactly.
Speaker 1: Okay, let's unpack this because that is exactly our mission
Speaker 1: for this deep dive. We are exploring the foundational methodologies
Speaker 1: of basic static analysis for mogule malware.
Speaker 2: The foundational stuff, right, We're.
Speaker 1: Going to walk you through how to examine both iOS
Speaker 1: and Android architectures. You know, the structural files that act
Speaker 1: as their blueprints, and we'll get into the precise tools
Speaker 1: used to decode their capabilities, all while the code remains
Speaker 1: entirely at rest in a secure environment.
Speaker 2: And you know that concept of the code being at rest,
Speaker 2: that's really the defining characteristic of static.
Speaker 1: Analysis, right as opposed to dynamic analysis.
Speaker 2: Exactly. We are not observing behavior in a sandbox. We
Speaker 2: are analyzing the underlying structure, the dependencies, and the logic
Speaker 2: that's actually banked into the binary itself.
Speaker 1: We're dissecting the anatomy of the app to understand the
Speaker 1: author's intent spot on.
Speaker 2: We want to see what they were planning before they
Speaker 2: even get to do it.
Speaker 1: But we need to talk about strategy before tactics always
Speaker 1: because my instinct, and I think the instinct of a
Speaker 1: lot of people, especially students or self taught learners, when
Speaker 1: they first get a suspicious file would be to just
Speaker 1: immediately throw it into a disassembler or a decompiler.
Speaker 2: Oh yeah, just dive right in, right, just start.
Speaker 1: Tearing through the long first engineering. The assembly code is
Speaker 1: using trap, isn't it.
Speaker 2: It is an incredibly common trap, and honestly, it's a
Speaker 2: massive drain on your resources. How So, well, if you
Speaker 2: dive straight into raw hexadecimal data or assembly instructions without
Speaker 2: any broader context, you will almost certainly lose the forest
Speaker 2: for the trees. It's just too much data, way too much.
Speaker 2: The overall static analysis process requires strict operational discipline. Before
Speaker 2: you even look at a specific files internal code, you
Speaker 2: need to execute step one, which is identifying and searching
Speaker 2: the application through cryptographic hashing.
Speaker 1: Hashing. Okay, so instead of looking at the code itself,
Speaker 1: we are running the entire file through a mathematical algorithm,
Speaker 1: right like SAHA two fifty six or MD five right
Speaker 1: to generate a fixed length string of characters. It's like
Speaker 1: a unique digital fingerprint. For that exact file.
Speaker 2: Precisely, you generate that hash, and then you consult global
Speaker 2: threat intelligence resources and databases before you ever touch a
Speaker 2: specialized local analysis.
Speaker 1: Tool like virus Total or other malware repositories.
Speaker 2: Exactly, you are checking to see if the broader cybersecurity
Speaker 2: community has already encountered, analyzed, and mapped out this specific fingerprint.
Speaker 1: But uh, let me push back on that process for
Speaker 1: a second. Sure, if we have the malicious app right
Speaker 1: in front of us, isn't looking up the hash online
Speaker 1: essentially just while outsourcing the work? Yeah, Like it feels
Speaker 1: a bit like reading the summary instead of the book.
Speaker 1: Shouldn't we just reverse engineer at ourselves to guarantee we
Speaker 1: really understand it?
Speaker 2: I mean, that's a fair question, but it fundamentally misunderstands
Speaker 2: the economy of time in incident response and malware.
Speaker 1: Analysis, because time is money.
Speaker 2: Time is your most precious commodity. Researching a hash isn't outsourcing,
Speaker 2: It is vital triage. I mean, if a global intelligence
Speaker 2: database tells you that this specific SAHA two five six
Speaker 2: hash belongs to a known, well documented banking trojan, well
Speaker 2: you've just saved yourself potentially days of reverse engineering.
Speaker 1: Right, because knowledge is most valuable when it's applied efficiently.
Speaker 1: You don't get bonus points for rediscovering a wheel that
Speaker 1: someone documented three years ago.
Speaker 2: Exactly. Redoing work that the community has already mapped out
Speaker 2: actively slows down your ability to protect your environment. And
Speaker 2: this leads to the most crucial part of the entire
Speaker 2: analysis process, which is setting firm objectives based on that
Speaker 2: initial intelligence.
Speaker 1: Okay, so narrowing the scope, right.
Speaker 2: If the hash tells you it is a known SMS
Speaker 2: stealing trojan, your objective is shifts. You weren't trying to
Speaker 2: answer what is this anymore?
Speaker 1: Your objective becomes highly targeted exactly.
Speaker 2: It becomes what command and control servers is this specific
Speaker 2: variant waking out to and how is it persisting on
Speaker 2: my network? Having those firm objectives prevents you from just
Speaker 2: drowning in a sea of irrelevant data.
Speaker 1: That makes perfect sense. The hash dictates the mission. But uh,
Speaker 1: let's look at the alternative scenario, A fun scenario, right.
Speaker 1: We run the hash, we query the databases, and we
Speaker 1: get zero hits.
Speaker 2: Nothing.
Speaker 1: It's a completely novel threat. The Internet has no idea
Speaker 1: what this file is. We're flying blind, which means we
Speaker 1: have to do the heavy lifting ourselves. So let's start
Speaker 1: with the Apple ecosystem.
Speaker 2: Okay, iOS, Right.
Speaker 1: We are looking at a suspected malicious iOS application. So
Speaker 1: picture you open your terminal or your file explorer. Where
Speaker 1: do we even begin looking?
Speaker 2: Well, the very first thing you need to realize is
Speaker 2: that an iOS app isn't just one monolithic file whatch
Speaker 2: you download from the app store, you know, an IPA file.
Speaker 2: It's essentially just a specialized zip the archive.
Speaker 1: So it's a container.
Speaker 2: Yeah, it's a package. It's a bundle of different resources, images,
Speaker 2: configuration files, and of course compiled code. Our very first
Speaker 2: objective is to find the actual engine of the app,
Speaker 2: the core executable file.
Speaker 1: So if I just unzip that archive, I'm going to
Speaker 1: see a directory structure in front of me. And I
Speaker 1: know one of the main folders inside an iOS app
Speaker 1: bundle is called the payload directory.
Speaker 2: Yep, the payload directory.
Speaker 1: And naturally payloads sounds exactly like what a maur analyst
Speaker 1: would want to look at. Is the executable just sitting
Speaker 1: right in there?
Speaker 2: I mean, it is inside that directory structure eventually, but
Speaker 2: you have to know exactly what you are looking for.
Speaker 2: The payload directory contains the application wrapper, but it is
Speaker 2: not the executable itself.
Speaker 1: Okay, so where do people go wrong here?
Speaker 2: You'll see people guessing At this stage. They start poking
Speaker 2: around looking for configuration files to point them in the
Speaker 2: right direction. They might look for a file called, say,
Speaker 2: settings dot plist or application dot plists, assuming those have
Speaker 2: the architecture map, but they don't. Usually those files don't
Speaker 2: even exist, or if they do, they definitely don't contain
Speaker 2: the core metadata we actually need.
Speaker 1: So it's like wandering around a cargo ship just looking
Speaker 1: into random crates. We need a document that tells us
Speaker 1: exactly what is on board.
Speaker 2: That is a perfect analogy, and for an iOS app,
Speaker 2: that authoritative document, the ship's manifest is a file called infodt.
Speaker 1: Plist infodot plist. Okay, so this is a property list file,
Speaker 1: an XML based file that Apple uses to store configuration data.
Speaker 2: Correct. The infodot plist is the foundational map of the application.
Speaker 2: It declares the app's bundle identifier, its version number, the
Speaker 2: permissions it requires, and the executable And most importantly for
Speaker 2: our purposes, yes, it contains the exact literal name of
Speaker 2: the core executable binary. It removes all the guesswork completely.
Speaker 1: Okay, So we check the infodoplist our ship's manifest and
Speaker 1: we find the exact name of the core Maco binary file,
Speaker 1: you know, the actual compiled engine of the app.
Speaker 2: Right.
Speaker 1: Once we isolate that binary, how do we look inside
Speaker 1: it without actually running it? Because we need to extract
Speaker 1: its structural blueprint?
Speaker 2: Right, yes, we want to see how the developer organize
Speaker 2: the code itself. Now, in the Apple ecosystem, apps are
Speaker 2: historically written in Objective C or Swift, okay, and because
Speaker 2: of how these languages operate, particularly Objective C, a massive
Speaker 2: amount of structural metadata is actually left behind inside the
Speaker 2: compiled binary.
Speaker 1: Like what kind of metadata?
Speaker 2: The names of the classes, the properties, the methods. And
Speaker 2: we can extract all this metadata by dumping the iOS classes.
Speaker 1: So we are essentially looking at the nouns and verbs
Speaker 1: the developer used to build the app exactly. So if
Speaker 1: we see a class named I don't know, data exfiltrator
Speaker 1: or a method called upload contacts.
Speaker 2: To server, then that is a massive red flag.
Speaker 1: Right, So what tools do we actually use to extract
Speaker 1: those blueprints?
Speaker 2: We rely on highly specific command line tools designed to
Speaker 2: parse the Maco binary format. The standard tools for this
Speaker 2: job are class dump, a variant called class dump Z,
Speaker 2: and a remarkably utility built into the Mac os environment
Speaker 2: called O tool.
Speaker 1: Class dump and O tool. And I assume because we
Speaker 1: are working in the command line, we're dealing with a
Speaker 1: fairly unforgiving environment.
Speaker 2: Oh, incredibly unforgiving. The command line only executes exactly what
Speaker 2: you instruct it to.
Speaker 1: No ring for typos, none.
Speaker 2: You have to know the precise tools that actually exist.
Speaker 2: For instance, you might hear rumors on forums about a
Speaker 2: tool called class dump pro sounds fancy, it sounds like
Speaker 2: a premium, highly effective utility, right, but it does not exist.
Speaker 1: Wait, really, it's just a myth, just a myth.
Speaker 2: There's a legacy tool called class dump, say, but for modern,
Speaker 2: reliable static analysis standard class dump and O tool are
Speaker 2: the primary instruments you will use to pull those class structures.
Speaker 1: Okay, here is where it gets really interesting to me.
Speaker 1: We've mapped out the internal structures, you know, the classes
Speaker 1: and methods. But apps don't operate in a vacuum.
Speaker 2: No they don't.
Speaker 1: A malicious app needs to connect to the internet, it
Speaker 1: needs to access the file system. Maybe it needs to
Speaker 1: read the devices cryptography libraries. How do we see what
Speaker 1: external resources the app is reaching out to.
Speaker 2: To understand an app's true capabilities, we have to examine
Speaker 2: its dynamic libraries.
Speaker 1: The libraries right.
Speaker 2: Libraries are pre written foundational chunks of code provided by Apple.
Speaker 2: So an app doesn't write its own code from scratch
Speaker 2: to turn on the camera, it just links to Apple's
Speaker 2: existing camera librarries.
Speaker 1: Okay, so if we are analyzing, say a simple offline
Speaker 1: calculator app.
Speaker 2: And we discover it is linking to networking libraries, cryptography frameworks,
Speaker 2: and contact list APIs.
Speaker 1: Then we immediately know its capabilities do not match its
Speaker 1: disguise purpose. It's a fake calculator exactly. So how do
Speaker 1: we actually expose those library connections? Are they just listed
Speaker 1: in a plain text file somewhere.
Speaker 2: No, They're not that obvious. They are embedded within the
Speaker 2: load commands of the MACO binary header.
Speaker 1: Okay.
Speaker 2: When the Apple operating system launches an app, the loader
Speaker 2: reads these specific commands to know which dynamic libraries it
Speaker 2: needs to pull into memory. Read these load commands ourselves.
Speaker 2: We use otool again, but we must use a very
Speaker 2: specific flag, which is a capital L. The exact command
Speaker 2: you type in is o tool space dash capital.
Speaker 1: L ownual dash capital L, and I imagine the capitalization
Speaker 1: is non negotiable.
Speaker 2: Absolutely non negotiable. This is where understanding the mechanism of
Speaker 2: the tool is vital.
Speaker 1: What happens if you get it wrong?
Speaker 2: If you type a lowercase L, the tool doesn't even
Speaker 2: recognize the command. If you use a lowercase A, you
Speaker 2: are instructing O tool to look at a completely different
Speaker 2: data section within the binary.
Speaker 1: And what if you forget the flag completely.
Speaker 2: If you just run a tool without specifying the library flag,
Speaker 2: you might end up dumping the raw simple table that
Speaker 2: will just flood your terminal with a massive, unintelligible wall
Speaker 2: of text that tells you absolutely nothing about the app's
Speaker 2: high level capabilities. Wow, okay, yeah, you specifically want to
Speaker 2: parse the load commands for dynamic libraries, you need O
Speaker 2: tool dash capital L.
Speaker 1: So if I'm visualizing this entire iOS process step by step,
Speaker 1: the infodop plist is the ship's manifest that tells us
Speaker 1: exactly which container holds the core binary, and running O
Speaker 1: tool dash capital L is like swabbing that container for
Speaker 1: chemical residue, revealing all the invisible connections it has to
Speaker 1: the outside world. Based on the tools packed inside.
Speaker 2: That is an excellent way to conceptualize it. You are
Speaker 2: letting the architecture betray the app's true intentions.
Speaker 1: Right, So we have cracked open the Apple ecosystem, but
Speaker 1: mobile malware is a multi front war. What happens when
Speaker 1: our digital suspect is an Android.
Speaker 2: App a whole different ballgame.
Speaker 1: Because Apple uses a tightly controlled, compiled C family architecture,
Speaker 1: but Android is a completely different paradigm. It's fundamentally built
Speaker 1: on Java and operates in a much more open ecosystem.
Speaker 1: I assume our analytical approach has to shift entirely.
Speaker 2: Entirely the underlying architecture dictates the tools. Android apps don't
Speaker 2: use plust files and they definitely don't use Moco binaries.
Speaker 2: An Android app is packaged as an EPKA file.
Speaker 1: An Android package file, which, much like the IOSIPA, is
Speaker 1: basically just to specialize ZP archive.
Speaker 2: Exactly. It is a ZP or archive containing the apps, resources, certificates,
Speaker 2: and the compiled code. But here's the critical difference. If
Speaker 2: you just natively unzip an APK using standard archive software,
Speaker 2: you cannot read the context. Why, because the core code
Speaker 2: is compiled into delvic executable format. A dox file. Furthermore,
Speaker 2: the essential configuration files, which look like standard XML, are
Speaker 2: actually compiled into a binary XML format to save space,
Speaker 2: so if you open them in a text editor, it
Speaker 2: just looks like complete gibberish.
Speaker 1: So we can't just unzip it. We have to actively
Speaker 1: decode it back into a human readable state. How do
Speaker 1: we reverse that process?
Speaker 2: We use a dedicated, powerful utility called app tool.
Speaker 1: App tool.
Speaker 2: Yes, apptool is specifically designed to parse those delvic executable
Speaker 2: files and translate them into smally, which is a human
Speaker 2: readable assembly like syntax.
Speaker 1: Okay, that sounds super useful.
Speaker 2: It is, and more importantly, for our initial triage, it
Speaker 2: decodes those binary XML files back into standard READABLEXML.
Speaker 1: So aptool essentially rebuilds the original project directory exactly as
Speaker 1: the developer saw it on their screen exactly. How do
Speaker 1: we invoke that? In the command line?
Speaker 2: The precise instruction to decode and APK is aptool space
Speaker 2: D followed by another space, and then the name of
Speaker 2: your file. The adult simply stands for decode.
Speaker 1: Ap tool dfile. It sounds simple enough, but given what
Speaker 1: we know about command line syntax, I'm guessing there's a
Speaker 1: nuance here that trips people up. Usually, when we pass
Speaker 1: a flag to a command line tool, like we did
Speaker 1: with otool dash L, we use.
Speaker 2: A dash and that is exactly where the analytical friction occurs.
Speaker 2: I knew it because standard POSEX syntax conditions us to
Speaker 2: use dashes. Analysts instinctively want to type aptool space dash
Speaker 2: d space.
Speaker 1: File right muscle memory exactly.
Speaker 2: Or they might think they need to list the contents
Speaker 2: first and try a non existent flag like dash L.
Speaker 2: But aptool operates differently. If you include that dash before
Speaker 2: or the d the tool will fail. It just won't run,
Speaker 2: It won't decode Dalvic bytcode, and won't rebuild the XML.
Speaker 2: Your analysis stops cold. It requires deliberate exactness. It's just
Speaker 2: apptool space, D space the file name, no dashes.
Speaker 1: It is a stark reminder that we are interacting with
Speaker 1: raw programmatic logic, not a user friendly graphical interface for sure. Okay,
Speaker 1: so we've been precise. We successfully typed app tool D,
Speaker 1: the APKs decoded, the Dalvik bytecode is translated, and the
Speaker 1: binary XML is now readable text. Where is our target?
Speaker 1: What is the Android equivalent to apple'sinfo dot plust.
Speaker 2: Your primary target? The absolute gold mine for Android static
Speaker 2: analysis is a file called the Android Manifest dot XXML.
Speaker 1: The Android manifest, it sounds authoritative.
Speaker 2: It is the master control document for the application. Because
Speaker 2: Android operates on a sandbox model where apps are isolated
Speaker 2: from each other, and app must explicitly declare its required
Speaker 2: permissions and its internal components to the operating system. Okay,
Speaker 2: so if an app wants to access the Internet, read
Speaker 2: your contacts, or sent text messages, it must be stated
Speaker 2: in the manifest.
Speaker 1: So we open Theanroid manifest dot xml and we start
Speaker 1: hunting for malicious behavior. What exactly does a malicious capability
Speaker 1: look like in this file?
Speaker 2: To understand that, you have to understand how Android apps communicate.
Speaker 2: They use an inner process communication system. Basically, if an
Speaker 2: app wants to do something, or if it wants to
Speaker 2: react to a system event, it uses an object called
Speaker 2: an intent.
Speaker 1: And intent So rather than directly hooking into the phone's
Speaker 1: SMS database and app essentially yells into the operating systems room,
Speaker 1: I intend to send a message or who has a
Speaker 1: new text message?
Speaker 2: That is exactly how it works, and to listen for
Speaker 2: those specific announcements, the app declares a specific field in
Speaker 2: the manifest called an intent filter. The intent filter tells
Speaker 2: the Android OS, hey, wake my app up when this
Speaker 2: specific event happens.
Speaker 1: So, let's say our initial hash research suggested this malware
Speaker 1: was a premium SMS toll fraud.
Speaker 2: Trojan uh, the kind that silently sent text messages to
Speaker 2: premium numbers to join your bank account.
Speaker 1: Exactly. So we decode the APK, we open the Android
Speaker 1: manifest dot XML, and we start scanning.
Speaker 2: And if you scan that manifest and find an intent
Speaker 2: filter configured to listen for say Android dot Provider, dot
Speaker 2: telepany dot SMS underscore received.
Speaker 1: Then you have just verified a core capability of the malware.
Speaker 2: You are looking at an intent shelter designed to intercept
Speaker 2: incoming text messages. If you are analyzing a simple offline
Speaker 2: notepad app and its manifest contains an intent filter aggressively
Speaker 2: monitoring your SMS traffic, well you have found the smoking gun.
Speaker 1: The structural fingerprint matches the suspected crime, and we proved
Speaker 1: it without ever executing a single line of malicious code.
Speaker 2: That's the beauty of it.
Speaker 1: We just looked at the app's own stated intentions inside
Speaker 1: its manifest and caught it red handed.
Speaker 2: That is the true power of basic static analysis. You
Speaker 2: are reading the thread actor's architectural blueprint.
Speaker 1: Let's take a breath and connect all these dots. Because
Speaker 1: we have covered a tremendous amount of ground across two
Speaker 1: entirely different operating systems, we definitely have. We started with
Speaker 1: the vital strategic phase, you know, using cryptographic hashes to
Speaker 1: querry global intelligence databases. We establish what we are dealing
Speaker 1: with before we ever touch a tool, allowing us to
Speaker 1: set highly targeted analytical objectives.
Speaker 2: Because context is everything in malware analysis exactly.
Speaker 1: Then we tackled the closed ecosystem of Apple. We learned
Speaker 1: that bypassing the generic payload directory and zeroing in on
Speaker 1: the info dot plist the ship's manifest is how we
Speaker 1: find the true name of the muco executable. We explored
Speaker 1: how dumping classes reveals the internal logic, and how parsing
Speaker 1: the load commands with O tool dash capital l exposes
Speaker 1: the dynamic libraries the app relies on.
Speaker 2: And then we shifted paradigms to Android's Java based architecture.
Speaker 1: Right we discuss why you can't just natively unzipin APK,
Speaker 1: but must decode the dolvic bytecode and binary XML using
Speaker 1: app toold relying on precise syntax with no dashes.
Speaker 2: Crucial point.
Speaker 1: We explored how the Android manifest dot xml serves as
Speaker 1: the master controlled document where malicious capabilities are openly declared
Speaker 1: through interprocess communication mechanisms, specifically the intent filters.
Speaker 2: It is a robust foundational methodology. If you grasp the
Speaker 2: mechanics behind these specific files and these specific tools, you
Speaker 2: possess the structural keys to demystify the vast majority of
Speaker 2: mobile malware.
Speaker 1: And I want you to think about how you would
Speaker 1: approach a brand new, highly suspicious file landing on your
Speaker 1: desk right now. Let's do a quick mental check. Oh
Speaker 1: pop quiz, just a quick review exercise to lock this in.
Speaker 1: If you have an iOS app and an Android app
Speaker 1: in front of you, and you need to find the
Speaker 1: iOS executable's name and the Android app's messaging actions, which
Speaker 1: specific file do you check for Apple and which specific
Speaker 1: field do you look for an Android?
Speaker 2: Give them a sake to think about it. Got it?
Speaker 1: For Apple you open the info dot plist and for
Speaker 1: Android you scan the manifest for the intent filter. You
Speaker 1: wouldn't just blindly throw the app into a decompiler and
Speaker 1: drown an assembly code. You now have a systematic process
Speaker 1: for tearing down a digital threat from the outside in.
Speaker 2: It is a critical capability. But as we conclude this
Speaker 2: deep dive, I'm going to leave you with a final
Speaker 2: thought to mull over.
Speaker 1: Oh lay it on us.
Speaker 2: We have just explored how basic static analysis relies on
Speaker 2: reading these structural blueprints, the plists, the libraries, the manifest.
Speaker 2: We can see all this clearly because the operating systems
Speaker 2: require these files to function. But cybersecurity is a perpetual
Speaker 2: arms race. Thread actors know exactly how otool and apt
Speaker 2: tool work. Of course they do so if they know
Speaker 2: we are scanning their manifests and library dependencies. What kinds
Speaker 2: of complex obfuscation and dynamic packing architectures are they actively
Speaker 2: inventing right now? How do you statically analyze a malicious
Speaker 2: payload that heavily encrypts its own manifest, only decrypting its
Speaker 2: true intent the precise millisecond it is executed in memory.
Speaker 1: Oh wow, that is a fascinating and terrifying question. The
Speaker 1: blueprints we rely on are constantly being written in disappearing
Speaker 1: ink pretty much. It just proves why. Understanding the fundamental architecture,
Speaker 1: you know the why and the how is so much
Speaker 1: more important than just memorizing a list of command line tools.
Speaker 1: The tools will evolve, but the logical methodology remains. Stay curious,
Speaker 1: keep analyzing, and we will catch you on the next
Speaker 1: deep dive.