Skip to content
TrackPodcasts
educationSep 4, 202621:15

Course 42 - Mobile Malware Analysis Fundamentals | Episode 8: Static Analysis of Android Banking Trojans

About this episode

CyberCode Academy is made possible by:


Android Basic Static Analysis — Advanced Study GuideThis episode demonstrates how to perform basic static analysis of Android applications, moving from initial malware triage to manifest analysis, code decompilation, and identification of suspicious functionality.1. Android Malware Analysis MethodologyAlthough Android and iOS have very different architectures, the fundamental malware-analysis methodology remains similar:Sample ↓ Identification ↓ Hashing ↓ Threat Intelligence ↓ Manifest Analysis ↓ Code Analysis ↓ Behavioral Hypothesis ↓ Dynamic Analysis The objective of static analysis is to understand as much as possible without executing the malware.2. Initial APK IdentificationThe first stage is to establish basic information about the APK.Useful checks include:
  • File type
  • File size
  • Cryptographic hashes
  • Existing antivirus detections
  • Known threat intelligence
For example:file "malware 2.apk" Hashing provides a stable identifier for the sample:md5sum "malware 2.apk" sha256sum "malware 2.apk" The resulting hashes can then be searched in authorized malware-intelligence services such as VirusTotal.Important principleA clean scan does not establish that an APK is safe. Static analysis should continue even when existing security engines report no detection.3. AndroidManifest.xml AnalysisThe AndroidManifest.xml is one of the most important artifacts in an Android investigation.An APK's manifest is normally stored in a compiled/binary representation, so tools such as apktool can be used to decode it into a human-readable form.For example:apktool d "malware 2.apk" -o malware_analysis The decoded project may contain:malware_analysis/ ├── AndroidManifest.xml ├── smali/ ├── res/ ├── assets/ └── ... The manifest can reveal:
  • Application components
  • Activities
  • Services
  • Broadcast receivers
  • Content providers
  • Intent filters
  • Requested permissions
  • Exported components
4. Permission AnalysisPermissions can provide an early indication of an application's intended capabilities.In this lab, the APK requests permissions associated with:
  • Reading SMS
  • Writing SMS
  • Receiving/intercepting SMS
  • Installing packages
  • Removing packages
This combination is particularly interesting for a purported banking application.However, permissions alone do not prove malicious behavior.A better analytical question is:Which parts of the code actually use these permissions, and for what purpose?That connects manifest analysis with code analysis.5. Identifying the Application's TargetThe investigation decodes the application's string resources and discovers that its name translates from Korean to "smart banking."This provides an important contextual clue.Combined with the SMS-related permissions, the analyst can begin developing a hypothesis:Korean Banking Theme + SMS Access + Device Information ↓ Potential Banking-Focused Malware The hypothesis should then be tested against the application's actual code and behavior.6. DEX AnalysisAndroid applications typically contain compiled code in DEX (Dalvik Executable) format.The primary file is often:classes.dex Static analysis can involve converting DEX bytecode into a more readable representation.A traditional workflow demonstrated in the episode is:classes.dex ↓ dex2jar ↓ JAR / Java representation ↓ JD-GUI / JEB / Procyon ↓ Pseudo-source code The resulting code is not necessarily identical to the original source code, but it can provide a useful approximation of the application's logic.7. Why Decompilation MattersManifest analysis tells you what the application declares.Decompilation helps determine what the application actually does.For example:Manifest: READ_SMS RECEIVE_SMS ↓ Code: SMSReceiver ↓ Extract SMS information ↓ Process information ↓ Potential network communication This correlation is much stronger evidence than simply observing a suspicious permission.8. SMSReceiver InvestigationOne of the most significant findings in the lab is the SMSReceiver class.A broadcast receiver associated with SMS functionality deserves particular attention because SMS can contain:
  • Authentication codes
  • Banking notifications
  • Account alerts
  • Password-reset messages
  • Two-factor authentication codes
The analyst therefore investigates what the receiver actually does with incoming messages.9. Device ProfilingThe SMSReceiver analysis also reveals functionality for collecting information about the device, including:
  • SIM-related information
  • Telephone information
  • Device characteristics
This creates a stronger behavioral picture:SMSReceiver │ ├── Access SMS │ ├── Gather SIM information │ ├── Gather telephone information │ └── Network communication This behavior is considerably more suspicious when combined with the application's banking theme.10. Suspicious Network InfrastructureThe analysis identifies a connection to:banking1.catcat.net This domain becomes an important indicator of compromise (IOC) and a potential focus for further investigation.At this stage, the analyst should avoid immediately concluding that the domain is definitively a C2 server.Instead, the appropriate hypothesis is:The application contains functionality that may communicate with external infrastructure associated with its banking-related behavior.Dynamic analysis can subsequently determine:
  • When the connection occurs
  • What data is transmitted
  • What responses are received
  • Whether SMS information is exfiltrated
  • Whether additional commands or configuration are retrieved
11. Building the Behavioral HypothesisThe evidence collected so far can be combined:EvidenceObservationApplication identity"Smart banking"TargetingKorean usersSMS permissionsRead/write/receive SMSComponentSMSReceiverDevice profilingSIM and telephone informationNetwork indicatorbanking1.catcat.netCode analysisSuspicious functionalityTogether, these findings support a strong hypothesis that the application may be banking-oriented malware capable of collecting sensitive device/SMS information and communicating with remote infrastructure.12. Static Analysis WorkflowThe complete workflow from this episode can be summarized as: APK │ ▼ File Identification │ ▼ Hashing │ ▼ Threat Intelligence │ ▼ apktool │ ┌───────┴────────┐ ▼ ▼ Manifest Resources │ │ ▼ ▼ Permissions App Identity │ ▼ classes.dex │ ▼ Decompile │ ▼ Java/Pseudo-code │ ▼ Interesting Classes │ ▼ SMSReceiver │ ┌────┼─────┐ ▼ ▼ ▼ SMS Device Network Data IOC │ │ └───┬───┘ ▼ Behavioral Hypothesis │ ▼ Dynamic Analysis Key Takeaways
  • APK analysis begins with identification and preservation, not execution.
  • Hashes provide useful sample identifiers for threat-intelligence searches.
  • AndroidManifest.xml provides an excellent overview of the application's declared capabilities.
  • Permissions should be correlated with actual code behavior rather than treated as proof of maliciousness.
  • apktool is useful for decoding APK resources and the manifest.
  • DEX decompilation provides visibility into application logic.
  • SMSReceiver is particularly important when investigating malware that may target banking or authentication workflows.
  • Device profiling combined with SMS access and suspicious network communication can provide strong evidence of malicious intent.
  • Static analysis ultimately produces a behavioral hypothesis, which should be validated through controlled dynamic analysis.
Golden ConceptThe strongest malware-analysis conclusions come from correlating multiple independent artifacts: what the application claims to need, what its code actually does, what data it accesses, and where it communicates.

You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy

Get every episode summarized

Each time CyberCode Academy publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.

Email me new episodes

Free for 3 shows. No card needed.

Hosts & guests

Transcript ready

728 searchable segments. Every word is indexed and playable.

Course 42 - Mobile Malware Analysis Fundamentals | Episode 8: Static Analysis of Android Banking Trojans

CyberCode Academy

0:00
21:15

Full transcript

CyberCode AcademyCourse 42 - Mobile Malware Analysis Fundamentals | Episode 8: Static Analysis of Android Banking Trojans. Machine-transcribed; use the interactive transcript above to jump the player to any line.

This is Ashley Akinetti from the almost famous podcast. You ever notice you and your spouse keep saying, we need to get away, but you never actually plan anything. That was us until we did something fun and spontaneous. We went to resort pass.com. There are hundreds of hotel resorts, pools and spots and private beaches that you can enjoy. You can spend the day at a luxury resort, pool, spa, massage, without booking an overnight stay. And listen, I may have only been like 15 minutes from home, but it felt like it was a whole different world. And I'm thinking, this is exactly what I needed. So just go to resort pass.com, choose your resort, choose your day, luxury, resort, day passes, start at just $1,500. Once you post your daycation, people are gonna ask where you are. Go to resort pass.com slash almost famous and use the promo code almost famous to get $20 off when you spend $100. That's code almost famous at resort pass.com slash almost famous.

Enjoy big savings with Red Hot deals at Vons and Albertsons. This week at Vons and Albertsons, baby back pork ribs are $2.99 per pound with membership where applicable limit three racks. And ballpark hot dogs or hamburger buns eight count are $2.99 with digital coupon. Plus personal seedless watermelons or canelope are $1.99 each with digital coupon. Enjoy fresh and delicious savings for every meal. Korean these deals won't last. Visit vons or Albertsons.com for more deals and ways to save. At Arizona State University, we're bringing world-class education from our globally acclaimed faculty to you. Earn your degree from the nation's most innovative university. Online, that's a degree better. Learn more at ASUOnline.asu.edu. You probably have like 50 or 60 apps on your phone right now, right? I mean, you trust them to play your music or track your workouts, maybe even act as a level for hanging a picture frame. You tap the icon, does the thing,

and you just go about your day. But what if one of those apps is silently waiting for you to go to sleep, just so it can wake up, read through your private text messages, and beam them to a server halfway across the world? And the scary part is on the surface, that app looks and behaves exactly like a harmless calculator or a weather widget. The malicious behavior is very deep in the architecture. Totally hidden from the average user. Exactly. It's completely hidden. Well, welcome to this deep diet. Today, we are putting you in the shoes of a cybersecurity analyst. Your objective is to learn how to literally tear apart a suspicious Android application and uncover its hidden secrets. Yeah, we are exploring the philosophy and really the nuts and bolts of what the industry calls basic static analysis. And I think when people hear phrases like reverse engineering malware, they tend to picture chaotic screens filled with scrolling green text. Like something out of a hacker movie. Exactly. Matrix style.

But the reality is much more accessible. It's an entirely logical, methodical process of just peeling back layers. It really is. We are basically looking at the blueprint of a house to see where the trap doors are, without actually having to step inside. Right. And for anyone who has looked at malware on other platforms like maybe you've studied how a desktop Trojan works or iOS phone or abilities that underlying philosophy here on Android is, I mean, it's fundamentally the same. Oh, for sure. The core concepts of infection, they don't really change when we switch platforms. The bad guys, they still rely on social engineering to trick you into downloading something you shouldn't. Right. The classic fishing tactics. Exactly. They still compromise third party app stores. Or they specifically target users who have, you know, remove the built in security protection and software devices, jail broken phones and stuff. Yeah, exactly. Our overarching goal as analysts remains constant here, which is to uncover the true functionality of the program. OK. So before we turn into the code itself, we have to secure our starting point.

We have to know exactly what we are holding, right? Yes, absolutely. So this is the very first layer of analysis identifying the APK file. Right. Because when you download an Android app, the file you are actually pulling onto your device is an APK, which stands for Android Package. OK. Now in spatic analysis, our absolute first item of business is to identify this specific APK without running it. We're strictly observing from a safe distance here. I would assume we can't just rely on the file name, though, right? Like a hacker isn't going to name their file steal your bank passwords.atk. Doesn't like not. The name is something innocuous. Like I don't know, angrybirds.ac or system update.ac. Yeah, file names are completely meaningless in malware analysis. You just can't trust them. So what do we do instead? Instead, we generate a unique digital fingerprint for the file using a process called hashing. Hashing, OK. Yeah. You take the entire contents of that APK file and you pass it through a mathematical algorithm. This algorithm basically crunches all the data

and spits out a fixed length string of letters and numbers. Meaning, if a malware author takes a known malicious app and changes absolutely nothing except the color of one pixel in the app icon, that minor tweak completely alters the resulting hash. Wow, just one pixel. Just one pixel, yeah. But if the file is truly identical, the hash will always be identical. OK, that makes sense. And once you generate that unique fingerprint, you can cross-reference it against massive global databases that track malicious software. It's basically similar to booking a suspect at a police precinct. That's a great way to think about it, yeah. Before you take them into an interrogation room and try to figure out their whole life story, you run their fingerprints. You want to see if the global cybersecurity community already has a rap sheet on this exact file. Exactly. If a thousand other security researchers have already flagged this exact fingerprint as a banking Trojan, well, your investigation just got incredibly focused. You already know what your deal meant. You know exactly what you're dealing with, yeah.

OK, so the fingerprint tells us if the community already knows this is a bad file. But what if it's like a brand new string? Right, a zero day or something. Yeah. What if the fingerprint comes back totally clean and there's no record of it anywhere? That is when we have to crack open the safe. We have to look at the app's ID and see what it's demanding from the phone. Which brings us to decoding the Android manifest. Right. And to understand the manifest, you really have to understand what an APK file actually is. It's not just a single magic file, right? No, not at all. It's essentially just a specialized zip file. It is a container holding a bunch of other folders, images, and code that basically make up the app. But I'm guessing you can't just unzip it like a normal folder on your desktop and start reading the instructions. I mean, you can unzip it, but you won't be able to read much. Because when the developer finished writing the app, they had to compile it. They translated it from human readable text into a binary format that a machine can process really fast.

So it basically becomes unreadable machine logic. Exactly. And sitting right inside that zip container is the absolute most critical file we need, which is called Android Manifest.xml. The manifest? Yeah. You can think of the manifest as the absolute rulebook for the application. But to read it, we have to run the APK through a specialized decoding tool. Because right now, it's just binary gibberish. So we use a simple command line tool, aptly called ATKTool, I believe, to essentially reverse that binary compilation. Yep. APKTool is the industry standard for this. We point the tool at the APK, and it translates that binary gibberish back into a plain readable text file. And then we can just open it up in any basic text editor, right? Exactly. And when you open that newly readable Android manifest, you are scanning for a few specific structural pillars. OK. What's the first one? The first is the manifest package element. This is the official Java name for the application. And it's usually styled backwards, like a flipped web domain. Oh, right.

So it might read something like com.google.android.youtube. Precisely. That's the app's formal government name, basically. But that's usually different from what the user sees on their screen, right? Very different. Yeah. The user sees the Android colon label that is the shiny, super cool flashlight title displayed on the home screen. Gotcha. So comparing the official package name to the public label is actually your first chance to spot a discrepancy. Oh, I see where this is going. Yeah. A package name that looks like randomized gibberish underneath a highly polished label is an immediate indicator that something is wrong. OK. So label and package name, what's next in the manifest? Then we move further down into something called intent filters. Intent filters. Yeah. These describe how the app interacts with other applications on the phone. They basically define the app's ability to send or receive messages from the system itself. So like if an app wants to be notified when the phone finishes booting up or when a text message arrives,

it uses an intent filter. Exactly. It has to register that intent. Wait, hold on. An intent filter. Yeah. If I'm building a highly malicious sneaky app, I'm definitely not going to openly declare my intentions to the operating system. You think so, right? Yeah. Like, why would a malware author out themselves like that? That feels like giving the police your itinerary before committing a crime. It does, but it comes down to the core philosophy of Android's security architecture. Android is heavily sandboxed. Sandbox, meaning isolated. Exactly. Unlike older desktop operating systems, where a program might have free-raying over the whole computer once it's running, Android draws strict isolated boundaries around every single app. Ah, so it's basically a structural hostage situation. That's a good way to put it. The malware physically cannot function outside of its sandbox unless it explicitly asks the operating system to open a specific door. Exactly. The operating system forces the app to declare those intents in the manifest.

If the app tries to intercept the text message without declaring the intent to do so, the Android system simply blocks the action. It just hits a wall. Yep. The malware author has absolutely no choice. They have to declare their intentions to make the app work at all, which provides us with a really clear trail of breadcrumbs, which perfectly sets up the absolute gold mine of the manifest, right? Not long. The uses permissions tags. Oh, yeah. The permissions are everything. Like when you install an app and your phone pops up a warning asking, allow this app to access your camera. That is the operating system reading the manifest permission demands. Exactly. And analyzing these permissions is where critical thinking becomes your best analytical tool. Context is everything here. How so? Give me an example. Well, let's say you are analyzing a video player application. If you see a permission tag requesting access to the internet, well, that aligns with its function. Right. It needs to stream video from a server. Exactly. But if you scroll down the manifest of that same video player,

and you see a permission tag demanding access to read your SMS text messages. Or a permission to silently record audio from my microphone. Yeah. Right. The alarm bells start ringing immediately. A video player has absolutely zero legitimate functional need to read your private texts. So you've spotted a massive anomaly just from the context. You have. And the beauty of this phasostatic analysis is that the manifest gives you that insight instantly. You haven't even looked at a single line of the app's internal logic yet. Not one line. But you already know it has malicious capabilities based purely on what it's asking permission to do. That is wild. OK. So the manifest gives us the demands. And tell us what the application wants to do. But to figure out exactly how it's utilizing those permissions, we have to look deeper. We do. We need to look at the actual brain in the app, which brings us to translating the blueprint moving from DX to Java. Right. Because knowing an app has the ability to read your text messages is vital context. But seeing the specific lines of code

that actually steal the text message, bundle it up, and email it to a hacker server, that is the definitive proof. And getting to that code requires understanding how Android apps are actually built. It does. I imagine a phone's processor doesn't really want to read bulky, human-written Java code. Like it's dealing with battery constraints, memory limits. It needs something stripped down and optimized. That is the exact reason for the compilation journey. A developer writes the app in standard Java source code. The system compiles that into Java bytecode. OK. But for Android specifically, it goes through a second compilation phase into what is called Delvik bytecode. Resulting in files with a .dex extension, which stands for Delvik executable. You got it. And these Zax files are hyper optimized for the physical constraints of a mobile device. They execute incredibly fast. But the trade-off for that speed is human readability. Exactly. If you try to open a .dex file in a text editor, it looks like raw, chaotic assembly language. It is virtually impossible to just sit down

and read Delvik bytecode to understand an app's complex logic. So we have the instructions, but they are written in a hyperfast, completely unreadable shorthand. Pretty much. We need a way to translate that shorthand back into something we can actually analyze. And because Delvik bytecode and Java bytecode share similar underlying structures, we can use translation tools to reverse that compilation process. So nice. Analysts frequently use a command line utility called Dex2jar. And just as the name implies, it takes that unreadable Delvik executable file and converts it back into a standard Java archive or a .jar file. So to trace this journey, the developer wrote the original book in English, meaning Java. The compilation process translated it into a super condensed shorthand, so the phone could read it instantly, which the Dex file. Exactly. And now we are using a tool to translate that shorthand back into English so we can actually read the plot. That is a perfect analogy. And from there, you open that converted Java file in a decompiler. A decompiler, like JDG UI.

Yeah, JDG UI is a classic widely used tool in the industry that displays this converted code. It gives you what we call Java pseudo source code. Sudo source code. Meaning it's not perfect. Right. It might not look exactly character for character, like what the developer typed on their keyboard, but the logic, the variables, and the flow. This is Ashley Akinati from the almost famous podcast. You ever notice you and your spouse keep saying, we need to get away, but you never actually plan anything. That was us until we did something fun and spontaneous. We went to resort pass.com. There are hundreds of hotel resorts, pools and spots and private beaches that you can enjoy. You can spend the day at a luxury resort, pool, spa, massage, without booking an overnight stay. And listen, I may have only been like 15 minutes from home, but it felt like it was a whole different world. And I'm thinking, this is exactly what I needed. So just go to resort pass.com, choose your resort, choose your day, luxury resort day passes,

start at just $1,500. Once you post your daycation, people are gonna ask where you are. Go to resort pass.com slash almost famous and use the promo code almost famous to get $20 off when you spend $100. That's code almost famous at resort pass.com slash almost famous. My name is Shannon Maldonado. I'm the founder of Yahweh, a gift shop from the lens of artists and handmade objects. I chose Shopify because when I was testing other platforms, it was definitely one of the most user friendly. It was important to me to think about where we would be in the future. All of the tools for reading your sales like planning inventory, they're just right there on your dashboard. For anyone starting a small business, the biggest thing I can tell you, it doesn't have to be perfect. Shopify can help you build upon it. Start your free trial on Shopify.com. Right now at Subway, try the $4.99 sub of the day. Get a different six inch sub every day for just $4.99 each. Like Meatball Marinera on Mondays, tuna on Tuesdays, and the BMT on Saturdays. It's a different six inch sub every day. Pat with protein and your choice of chopped veggies

for just $4.99 each. Or make it a meal with chips and a drink for just $2 more. But hurry, it's only for a limited time and only its subway. After participating restaurants, prices higher in Washington, Alaska, and Hawaii, and on third party delivery, add on taxes and fees for delivery additional. They're entirely readable. No, I know there are also premium professional grade decompilers out there that are so powerful they can interpret the DX files directly, skipping that conversion step entirely. Oh yeah. But regardless of the tool you use, you eventually get the code open on your screen. And I have to imagine this is where people just get totally overwhelmed. This can be overwhelming, yeah. Like you are suddenly staring at hundreds of different files, folders, and functions. Where do you even begin? Well, the secret is you never just start reading code from the top line downwards. You rely on a strategy called forward engineering. Forward engineering, how does that work? You go back to the Android manifest file, the rulebook we decoded earlier. Oh, you go back to find the starting line. Exactly. Yeah. The manifest explicitly tells the Android operating system

when the user taps the app icon on their screen, launch this specific class first. The main activity. Yes, the main activity. You find the name of that main activity in the manifest. Then you locate that exact class in your decompiled code. And then you just start reading from there. You start reading from that launch point, and you follow the logic forward. You track what methods it calls, what background services it triggers, and you just trace the execution path step by step. OK, let's move from theory into application here. To really solidify this knowledge, we need to put you, the listener, in the driver's seat for a hypothetical lab scenario. Let's dissect a real world threat. I love it. Let's do it. Imagine we boot up a secure isolated Linux environment. We are handed a suspicious file named malware2.app. Our intelligence briefing suggests this specific file has been targeting banking customers in Korea. OK, hi, SACE. Very. And we are going to tear it apart using only the basic static analysis tools we've just discussed. All right, so step one, we need to decode the manifest

to see what we are dealing with. We run our decoding tool on malware2.app, and we open the resulting Android manifest.xml file. And as we scan through that XML text, we are looking for the label, right? The public facing name of the app. Exactly. Scanning the intent filters, we find the main activity, and right above it is the label. What it just points to is string a text in the app's resource folder. Right, which is common. So we track that down. We find the Korean characters run them through a translator, and it translates to smart banking. Smart banking. OK, so the disguise is established. The user genuinely believes they are downloading a secure barking application. Which means we need to evaluate the threat level. So we scroll down to the permission section of that same manifest. And we immediately hit a wall of massive red flags. I'm guessing it's asking for a lot. Oh, yeah. This supposedly secure banking app is requesting the ability to read SMS messages, write SMS messages, receive them, and send them. Wow. It is also requesting permission to install and delete

other packages on the phone. That is huge. Taking a step back to look at the broader context, why would a banking app need the ability to completely hijack your text messaging system? It's hunting for two factor authentication codes, isn't it? Almost certainly. Like when your actual bank texts you a secure login code, this malware wants the ability to intercept that text, read the code, and hide the message so your phone never even buzzes. Exactly. You have deduced the malicious capability entirely from the manifest. But a deduction isn't proof. We need the smoking gun. Right. We need to find the specific code executing that interception. So looking back at the manifest, alongside the main activity, we spot another class declared with a highly suspicious name, death, SMS, receiver. That is our target right there. Yeah. So we take the optimized classes.dex file from the APK, run it through our converter to get a readable Java archive, and we open it up in our decompiler. And boom, we see the entire tree of the apps code.

We can bypass the main activity for now and click directly into the SMS receiver class we found in the manifest. And what reveals itself in that pseudosource code? It's all sitting right there in plain sight. We can actually read the methods using the phone's telephony manager to profile the device. It is actively pulling the SIM card number. It is hooking into the incoming SMS stream. And right in the middle of the interception logic, sitting there like a glowing neon sign, is a hard-coded web address. And there it is. You found the command and control server. The code is actively taking those intercepted text messages, packaging them up, and attempting to send them out over the internet to a URL banking1.catcat.net. Catcat.net? Yeah. Now, catcat.net does not sound like a secure, federally insured financial institution to me. No, it definitely does not. But it absolutely validates the suspicion we had during the permissions phase. It perfectly ties it together. The manifest showed us the demand. I want to read your texts. And the decompailed code revealed the true intention

to intercept two-factor authentication, profile your SIM card, and secretly upload your private data to a shady server. And the most amazing part, we uncovered all of that without ever risking the execution of the malware. We never let it run on a real phone. We never let it run. We never let it connect to the internet. We mapped out its primary attack vector and identified its command server solely by reading the blueprints. That is just incredible. It is a deeply empowering process once you understand the sequence of the tools. So synthesizing this entire journey for you, the listener, you start from a safe distance by generating a unique hash to see if the global community recognizes the threat. Right. Then, if you need to go deeper, you decode the binary Android manifest to read the apps rulebook, spotting dangerous permissions, and locating the main launch points. Exactly. And knowing what the app demands, you then trace the source code. You take the highly optimized, delvic executable files, translate them back into readable Java, and open them in a decompiler.

You just follow the breadcrumbs from the manifest directly into the code to uncover the smoking gun. It is a literal step-by-step road map for tearing apart malicious off work. It really is. Which brings us to a final review exercise for you, the listener. Let's test what you've learned today with a really quick scenario. All right. Imagine you are performing basic static analysis on a simple, everyday flashlight application. You decode the APK, you open the Android manifest file, and you scroll down to the permission section. Oh, OK. Based on the philosophy we discussed today, what is one specific permission that should immediately make you sound the alarm? Think about the context of the app. If you said the ability to read or send SMS messages or access your microphone or read your contacts, you are spot on. Absolutely. A flashlight just needs access to the camera flash hardware and maybe a basic wake lock to keep the screen on. Anything beyond that is a massive indicator of compromise. If you caught that, you were officially

thinking like a reverse engineer. Awesome. But we can't let you leave without a broader concept to chew on. Today, we saw how incredibly effective static analysis is when the code is cleanly translated and readable. Right. I mean, we literally found the SMMS receiver class because it was conveniently named SMMS receiver. Exactly. But the malware authors know we have these decomplation tools. They know we are reading their blueprints. So what happens when the attacker is intentionally scramble their code? Right. What happens when they use obfuscation techniques so that when you decompile the app, instead of seeing clearly named variables and logical flow, you just see meaningless, randomly generated characters that look like complete gibberish. Oh, wow. So the blueprint is essentially blurred out. You can't trace the logic because the words just don't make sense anymore. That is precisely where basic static analysis hits a brick wall. And when that happens, how do you figure out what the app does if you can't read this schematic? That sounds like a nightmare.

It is. And that is where analysts are forced to pivot into dynamic analysis. You have to create a heavily armored isolated environment and actually execute the malware to see what happens when it runs. You essentially have to let the malicious app wake up and start acting out its programming. Just so you can observe its behavior in real time. Exactly. It's a completely different ballgame. Man, it's a fascinating escalation in the cat and mouse game of cybersecurity. Well, keep your eyes open. Check the permissions on your own device and never ever trust a simple widget that demands to read your private messages. This is Ashley Akinati from the Almost Amos Podcast. You ever notice you and your spouse keep saying, we need to get away, but you never actually plan anything. That was us until we did something fun and spontaneous. We went to resortpass.com. There are hundreds of hotel resorts, pools and spots and private beaches that you can enjoy. You can spend the day at a luxury resort, pool, spa, massage, without booking an overnight stay. And listen, I may have only been like 15 minutes from home,

but it felt like it was a whole different world. And I'm thinking, this is exactly what I needed. So just go to resortpass.com, choose your resort, choose your day, luxury, resort, day passes, start at just $25. Once you post your daycation, people are gonna ask where you are. Go to resortpass.com, slash Almost Famous and use the promo code Almost Famous to get $20 off when you spend $100. That's code Almost Famous at ResortPass.com, slash Almost Famous. Toyota's easy choice sales event is on. Whether you're looking for the performance of a camera, the versatility of a rat for, the efficiency of a Corolla, or all electric driving in the BZ. There's a Toyota that's just right for you. And with great deals across the lineup, now's the time to find yours. But hurry, these deals won't last long. Toyota's easy choice sales event ends soon. We make it easy. Toyota, let's go places.

McDonald's is putting value back on the menu. Whether you're craving a big Mac, or nuggets, or sausage, egg, and cheese, McGrittle's, make it a meal, and save. Your favorite is now your wallet's favorite too. Extra value meals are back. Sun rises, prices fall. Get a sausage, McMuffin with egg, or sausage, egg, and cheese, McGrittle's, small hot coffee and hash frowns for just $6. Price and participation may vary. Promotion pricing may be lower than meal pricing. Ba-da-ba-ba-ba.

More episodes

More from CyberCode Academy

View all episodes →