Speaker 1: Welcome to the dep dive Today. We're jumping straight into
Speaker 1: a topic that's relevant to pretty much everyone listening, the
Speaker 1: world of android malware. Think of it as those digital
Speaker 1: pests that can really mess with your smartphone experience. Yeah, definitely,
Speaker 1: why God is digging into this well, honestly, just a
Speaker 1: simple desire to be better informed, more secure as our
Speaker 1: lives get more and more digital. Makes sense, And when
Speaker 1: you actually pause to consider it, the sheer size of
Speaker 1: the Android universe is just staggering, billions of devices globally
Speaker 1: right managing everything from social media to bank accounts.
Speaker 2: Absolutely, that scale makes it a massive, very tempting target
Speaker 2: for cyber criminals. The widespread use that different things phones
Speaker 2: do now, it creates to prime environment for them exactly.
Speaker 1: And to help us make sense of this sometimes complicated area,
Speaker 1: we've got a fantastic resource, the Android Malware Handbook. Right now,
Speaker 1: This isn't some like dry textbook. It's a really comprehensive
Speaker 1: look put together by experts at Meta and Google. You know,
Speaker 1: the folks actively fighting.
Speaker 2: These threats, the ones on the front lines.
Speaker 1: Yeah, their aim with this handbook is basically to equip
Speaker 1: people with the know how to understand and spot Android malware.
Speaker 1: It's kind of like getting an insider's view.
Speaker 2: This is a significant piece of work, Yeah, connecting deep
Speaker 2: research with practical steps for better security.
Speaker 1: So our mission today and you're already part of it
Speaker 1: just by listening, is to pull out the most important
Speaker 1: insights from this handbook. We're going to explore how Android
Speaker 1: malware has, you know, changed over time devolution, right, what
Speaker 1: the common attack methods are, and really get a handle
Speaker 1: on this ongoing back and forth between the attackers and
Speaker 1: the security experts cat mouse game exactly. The goal is
Speaker 1: to give you useful knowledge so you can navigate the
Speaker 1: digital world more confidently without needing like a computer science degree. Okay,
Speaker 1: let's get into it.
Speaker 2: Okay, So the handbook points out that the first identified
Speaker 2: piece of Android malware appeared relatively soon after the platform launched.
Speaker 2: We're talking around twenty eleven.
Speaker 1: Wow, that's surprisingly fast. You'd think it would take a
Speaker 1: bit longer for people to figure out how to exploit
Speaker 1: a new system.
Speaker 2: Well, what's really interesting is the driving force behind it
Speaker 2: right from the start, Unlike say early PC malware, where
Speaker 2: there was maybe this element of technical curiosity like what
Speaker 2: can we do?
Speaker 1: Yeah, exploring the limits.
Speaker 2: Pretty much all known Android malware right from the beginning
Speaker 2: seems to have been primarily motivated.
Speaker 1: By profit, So less digital graffiti and more straight up
Speaker 1: trying to make money. That fundamental difference that tells you a.
Speaker 2: Lot precisely, And as Google's Android security team started, you know,
Speaker 2: putting up safeguards to keep the official Google Play store secure,
Speaker 2: the malware creators adapted pretty quickly. They didn't just give up, No,
Speaker 2: they shifted strategies. It's that constant cycle, you know, reaction
Speaker 2: and counter reaction.
Speaker 1: Right, So how did they try to get around Google's
Speaker 1: protections then? What were the main ways?
Speaker 2: Well, several key approaches popped up. One was developing methods
Speaker 2: specifically designed to evade Google Play's own malware detection systems,
Speaker 2: getting sneakier about hiding code or delaying when it runs.
Speaker 2: Another big route was distributing apps through third party app
Speaker 2: stores websites, what we often call side.
Speaker 1: Loading, right installing outside the official channel exactly.
Speaker 2: That needed different tactics, more focus on tricking users into
Speaker 2: installing from those sources, and maybe the most disturbing, there
Speaker 2: were efforts to get malware pre installed right onto devices
Speaker 2: during manufacturing.
Speaker 1: Pre installed malware. That sounds like a huge breach of trust.
Speaker 1: You buy a new phone, you expect it to be clean.
Speaker 2: It really highlights how far they were willing to go,
Speaker 2: even setting up like seemingly legitimate companies to fool the
Speaker 2: device manufacturers.
Speaker 1: Wow, Okay, that gives us a good overview of the
Speaker 1: early days. Now let's get into the specifics. What kinds
Speaker 1: of malware are we actually seeing on Android? How do
Speaker 1: they work? The handbook breaks down some common categories, right.
Speaker 2: Yes, it does. One of the earliest and still pretty
Speaker 2: common types is SMS fraud. Okay. This involves apps sending
Speaker 2: text messages to those premium short codes.
Speaker 1: Ah yeah, the ones that charge you extra for voting
Speaker 1: on TV shows or something exactly.
Speaker 2: Those but used for deceptive stuff like fake donations or
Speaker 2: unwanted subscriptions. And these apps often do it silently, how
Speaker 2: so they send messages in the background, maybe suppress the
Speaker 2: notifications so you, the user might not even know until
Speaker 2: you get your phone bill.
Speaker 1: That's incredibly sneaky. Did the handbook mention specific examples?
Speaker 2: It did. Cricket Land and Beekeeper were two early big
Speaker 2: SMS fraud families. Cricket Land mainly hit users in Vietnam.
Speaker 2: Beekeeper focused more on Russia, and interestingly, cricket Land wasn't
Speaker 2: really documented publicly before this handbook.
Speaker 1: So the handbook is even bringing some previously lesser known
Speaker 1: threats to light. What was cricketland doing well?
Speaker 2: It became known for SMS fraud, but its initial versions
Speaker 2: actually function more like spyware. Yeah, often hidden in normal
Speaker 2: looking apps. I only grab the user's contact list and
Speaker 2: send it off to a remote server, no permission asks.
Speaker 1: Wow.
Speaker 2: The Android security team actually named it after one of
Speaker 2: its internal software parts. So even early on you see
Speaker 2: this mixed deception for money but also data harvesting.
Speaker 1: Okay, so it shifted tactics. Speaking of spyware, that sounds
Speaker 1: even more invasive than just SMS fraud. What's the main
Speaker 1: goal there?
Speaker 2: Yeah, the main aim of spyware is just that secretly
Speaker 2: collecting sensitive user data without consent, without you knowing. For
Speaker 2: cricket Land, it started with contacts. The handbook also mentions
Speaker 2: doogle Leaker. Yeah, a spyware family with a narrower goal,
Speaker 2: apparently mapping social connections in Japan again by collecting contact lists.
Speaker 1: So less about instant cash, more about gathering intel.
Speaker 2: Maybe that seems to be the idea of their and
Speaker 2: the handbook makes a really interesting connection between this kind
Speaker 2: of data collection and the rise of what it calls
Speaker 2: financial anti fraud SDKs.
Speaker 1: SDK's software development kits like toolkits for.
Speaker 2: App developers, exactly things like loan spy, which got baked
Speaker 2: into lending apps, especially in Southeast Asia.
Speaker 1: Anti fraud SDKs. That sounds helpful on the surface, and
Speaker 1: that's the catch.
Speaker 2: While they look legit maybe supposed to prevent loan fraud,
Speaker 2: these SDKs often gather way way more data than needed,
Speaker 2: excessively so well. Loanspy, for instance, was found accessing WhatsApp messages.
Speaker 2: It did this by misusing Android's accessibility features.
Speaker 1: Hold on accessibility features, aren't those meant to help people
Speaker 1: with disabilities use their phones?
Speaker 2: They are, but they can be powerful, and in this case,
Speaker 2: they were exploited to basically snoop on private chats.
Speaker 1: Wow, accessing WhatsApp messages. That's a massive privacy violation, and
Speaker 1: loan spy was common.
Speaker 2: The handbook says its reach was comparable to actual malware networks,
Speaker 2: partly because of the high demand for loans in the
Speaker 2: region needing identity verification. It's a sobering example. Really, something
Speaker 2: looking like security turns into a huge privacy threat operating
Speaker 2: at scale.
Speaker 1: That is sobering. Okay, let's move on to another classic trojans.
Speaker 1: We all know the story The Wooden Horse. How does
Speaker 1: that play out on Android?
Speaker 2: Very similar concept. Android trojans look harmless, maybe they even
Speaker 2: clone of popular apps appearance, but they hide malicious functions inside.
Speaker 1: So they trick you into letting them in.
Speaker 2: Right, They have that innocent looking part to gain your
Speaker 2: trust while the bad stuff happens secretly in the background.
Speaker 1: Did the handbook mention common ways they get onto devices?
Speaker 2: Yes, A very effective trick is publishing a clean app. First,
Speaker 2: get it onto Google Play, pass the checks build up, some.
Speaker 1: Users establish legitimacy.
Speaker 2: Then later push an update that contains the malware. Users
Speaker 2: trust the app they already have.
Speaker 1: They hit update and boom. That's really sneaky building trust
Speaker 1: just to break it. Are there other kinds of crogan
Speaker 1: behavior highlighted absolutely?
Speaker 2: Some manipulate online reviews. They download fake positive reviews from
Speaker 2: a server and post them to boost app ratings artificially.
Speaker 2: Often involves managing lots of fake accounts. Huh, and the
Speaker 2: handbook also mentioned some proxy network apps behaving like trojans.
Speaker 1: Proxy networks like VPNs that make it look like you're
Speaker 1: browsing from somewhere else sort of.
Speaker 2: Yeah, some less than reputable VPN companies create these proxy
Speaker 2: SDKs those developer tools again and pay popular app developers.
Speaker 1: To include them, and the user has no idea.
Speaker 2: Often not. Their device then becomes an exit point for
Speaker 2: other people's Internet traffic, which could mean illegal stuff is
Speaker 2: getting routed through your phone without you knowing.
Speaker 1: Okay, so your phone could unknowingly be part of some
Speaker 1: shady network. That's another big risk. What about phishing? We
Speaker 1: hear about email phishing all the time. How does it
Speaker 1: work on Android?
Speaker 2: Well, messaging and communication apps are prime territory attackers and
Speaker 2: beid malicious links and messages, texts, whatever.
Speaker 1: And use social engineering to get you to.
Speaker 2: Click exactly psychological tricks. The links might go to fake
Speaker 2: login pages to steal your passwords, or to sites that
Speaker 2: trick you into downloading more malware.
Speaker 1: Simple but effective. Was there a more technical phishing example
Speaker 1: in the book?
Speaker 2: There was, Yeah, involving something called OMACP. It's basically a
Speaker 2: way for mobile carriers to send configuration settings to your phone.
Speaker 1: Remotely like network settings.
Speaker 2: Right, malware could steal your phone's unique ID, send it
Speaker 2: to a server, and that server could then send your
Speaker 2: phone especially crafted OMACP message. This message would insert a
Speaker 2: proxy setting to intercept your data like logging credentials.
Speaker 1: Wow, that's intricate, exploiting carrier level. So okay, let's talk
Speaker 1: privileged escalation. Sounds like apps trying to get more power
Speaker 1: than they should.
Speaker 2: That's exactly it. They try to disable security features like
Speaker 2: Google play Protect, maybe by exploiting system permissions like right
Speaker 2: secure settings, or they fiddle with system settings to weaken
Speaker 2: security overall.
Speaker 1: Wow.
Speaker 2: Some execute shell commands directly or manipulate settings like package
Speaker 2: verifying or onnable. That's the one controlling malware scanning, so.
Speaker 1: Actively trying to shut down the phone's defenses. The handbook
Speaker 1: mentioned upload Barnkennel two.
Speaker 2: Yes, that setting can trolls whether your device sends app
Speaker 2: samples back to Google play Protect to help find new malware.
Speaker 2: So attackers might try to turn that off to slow
Speaker 2: down their own detection.
Speaker 1: Makes sense. Hep Google in the dark longer.
Speaker 2: And it gets worse. Some malware even includes rooting tools.
Speaker 1: Rooting like gaining admin control over the.
Speaker 2: Whole system precisely, which basically blows security wide open. They
Speaker 2: might use that root access to make it easier for
Speaker 2: other malicious apps to steal really sensitive stuff like your
Speaker 2: Google account tokens.
Speaker 1: So it's like one piece of malware opens the door
Speaker 1: for others. Nasty. Now, ransomware, we hear about that constantly
Speaker 1: on PCs. Is it a big deal on Android too?
Speaker 2: It definitely exists on Android. Same goal, lock up your
Speaker 2: data or your whole device and demand money to get
Speaker 2: it back.
Speaker 1: Right.
Speaker 2: Handbook distinguishes between lockers they just lock your screen, and
Speaker 2: cryptors which actually encrypt your files, photos, everything, And sometimes
Speaker 2: you get crypto lockers that do both and.
Speaker 1: That encrypt xfiltrate leak strategy we see on PCs. Is
Speaker 1: that happening on Android.
Speaker 2: Yes, increase So the modern approach this el strategy. They
Speaker 2: encrypt your stuff and they steal a copy, and they
Speaker 2: threaten to release it publicly if you don't pay double distortion.
Speaker 2: The handbook mentioned simplocker as an early Android example. Apparently
Speaker 2: used a pretty basic encryption method, just incrementing byte values
Speaker 2: or something simple but still enough to cause panic.
Speaker 1: I bet simple but effective. Okay, denial of service DOS attacks.
Speaker 1: Usually we think of websites being taken down. Can Android
Speaker 1: phones be involved?
Speaker 2: Absolutely? Well, maybe not. The main goal for malware targeting individuals.
Speaker 2: Infected Android devices can be pulled into.
Speaker 1: Botnets networks of zombie devices.
Speaker 2: Exactly, and those botnets can then launch distributed denial of
Speaker 2: service d'd ass attacks against websites, online services, you name it.
Speaker 2: The handbook stresses the consequences can be serious financial losses,
Speaker 2: even public safety risks. If critical infrastructure is targeted.
Speaker 1: That's a disturbing thought. Your phone being an unwitting soldier
Speaker 1: in some digital attack. What about quieter form of abuse
Speaker 1: like AD fraud?
Speaker 2: Yeah, ad fraud is a huge money maker for malware authors.
Speaker 2: It's often invisible to the user, doesn't lock your device,
Speaker 2: doesn't necessarily steal your logins.
Speaker 1: Directly, So what does it do?
Speaker 2: Things like click fraud the app secretly clicks on ads
Speaker 2: in the background, generating tiny bits of revenue that add
Speaker 2: up or installation attribution fraud, falsely claiming credit for installing
Speaker 2: other apps to get referral bonuses.
Speaker 1: Sneaky background money making. Any examples.
Speaker 2: Handbook menches Turkish clicker, It used JavaScript inside app web
Speaker 2: components to do dedos attacks and click fraud, and the
Speaker 2: Cheetah mobile scandal which involves large scale installation attribution fraud.
Speaker 1: So even if your phone seems fine, it could be
Speaker 1: silently working for criminals. And those dodgyvpns came up again
Speaker 1: here too.
Speaker 2: Yes, related to the proxy behavior we discussed, some shady
Speaker 2: VPN outfits used those proxy sdgrays in popular apps, turning
Speaker 2: user devices into exit nodes without.
Speaker 1: Telling them right routing traffic.
Speaker 2: It's invisible runs in the background as long as the
Speaker 2: app is installed. Another easy monetization route.
Speaker 1: For the bad guys, a hidden network built on unsuspecting users. Okay,
Speaker 1: so these malware creators are clearly getting more sophisticated. How
Speaker 1: do they try to stay hidden both from users and
Speaker 1: from the security researchers trying to pick their code apart?
Speaker 2: Yes, staying hidden is key. Obviously they try to be
Speaker 2: invisible to the user. If an app is clearly messing
Speaker 2: things up, you'll uninstall it right sure, But they also
Speaker 2: use a lot of technical anti analysis techniques, specifically to
Speaker 2: thwart researchers. What kind of tricks The handbook talks about
Speaker 2: static anti analysis ways to make the app's code hard
Speaker 2: to examine without running it. Things like hiding tone, encrypting important.
Speaker 1: Parts you can't just read it easily exactly.
Speaker 2: Or loading the malicious code in later stages so it's
Speaker 2: not even there in the initial file you download. App
Speaker 2: backers are also huge, especially in places like China. They
Speaker 2: compress or encrypt the real app code. It's like trying
Speaker 2: to analyze the scrambled egg.
Speaker 1: Okay, makes sense. The book also mentioned reflection.
Speaker 2: What's that ah? Reflection is a common dynamic technique. Malware
Speaker 2: often breaks itself into pieces, like plugins. The first piece
Speaker 2: you install might be small, look.
Speaker 1: Harmless, the initial foothold right, and.
Speaker 2: It only downloads and runs the really malicious parts later,
Speaker 2: maybe after checking if it's running in an analysis environment.
Speaker 2: Java Reflection features Android's own code loading tools, like dex,
Speaker 2: class letter. They're used for this. Lately, they're even loading
Speaker 2: code directly from memory, not separate files, to leave fewer traces.
Speaker 1: It really is a constant game of cat and mouse.
Speaker 1: What about the programming languages? Does using different languages help
Speaker 1: them hide?
Speaker 2: Definitely? While Java's been the main language for Android, developers
Speaker 2: increasingly use others Flutter, Cotlin, React, Native, even Lua or Python.
Speaker 1: Sometimes Why does that make it harder?
Speaker 2: Because most security tools and researchers are more geared towards
Speaker 2: analyzing Java. Even if just the core malicious bid is
Speaker 2: written in say flutter, it can seriously complicate reverse engineering.
Speaker 1: So it's not just scrambling the code but using a
Speaker 1: less common language for it. The handbook also mentioned name mangling.
Speaker 2: Yeah, that's a basic obfuscation trick, giving things like classes
Speaker 2: and functions really short, meaningless names like ABC. It makes
Speaker 2: the code incredibly hard to read and understand for a
Speaker 2: human analyst. Reverse engineers have to spend ages renaming things
Speaker 2: just to make sense of it.
Speaker 1: Just deliberately making it confusing and slow to analyze. Okay,
Speaker 1: let's shift gears a bit supply chain compromises. That sounds
Speaker 1: much bigger, potentially more impactful it is.
Speaker 2: Yeah, it's about malware getting into the ecosystem at a
Speaker 2: deeper level through trusted players like the companies making the phones,
Speaker 2: or more commonly, the providers of over the year software updates.
Speaker 1: The OTAs you updates, your phone gets automatically.
Speaker 2: Exactly if malware gets into that system, it can potentially
Speaker 2: hit a massive number of devices all at once.
Speaker 1: Oh wow, were there specific examples.
Speaker 2: In the handbook, several worrying ones g Moby and OTA
Speaker 2: provider was found collecting user data showing unwanted ads and
Speaker 2: even silently the installing apps like ghost Push on millions
Speaker 2: of devices no consent. Then there was ad Ops. Their
Speaker 2: Ota software was basically spyware, collecting texts, contacts, call logs
Speaker 2: and could also install other apps. Adops was significant enough
Speaker 2: to get into the mitre att and CK framework which
Speaker 2: tracks adversary techniques.
Speaker 1: So it's recognized as a serious threat vector.
Speaker 2: Absolutely ritz on, Sunshine Digitime, other OTA providers mentioned with
Speaker 2: security or privacy.
Speaker 1: Problems, So companies meant to secure devices becoming the vulnerability.
Speaker 1: That's a huge trust issue and not just updates. Right
Speaker 1: component suppliers too.
Speaker 2: Yes, the Eagerfonts incident by compromising just one company supplying
Speaker 2: a software component, malware got onto devices from over one
Speaker 2: hundred different manufacturers shows the ripple effect massive scale from
Speaker 2: one compromise, and the handbook points out a common tactic
Speaker 2: malware authors setting up fake, legitimate looking companies. They offer
Speaker 2: apps or SDKs to manufacturers, but with hidden back doors
Speaker 2: built in.
Speaker 1: Just infiltrating the trusted pathways sounds incredible hard to defend against. Okay,
Speaker 1: let's put to the defense side machine learning. The handbook
Speaker 1: says it's increasingly important for detection. How does that work well?
Speaker 2: Given the sheer volume of new apps every day and
Speaker 2: how complex malware is, getting mL is pretty crucial now
Speaker 2: for detection at scale makes sense.
Speaker 1: You can't manually check everything exactly.
Speaker 2: The basic idea is to train algorithms to tell the
Speaker 2: difference between good apps, goodwaar and malicious apps malware by
Speaker 2: looking for patterns and their characteristics.
Speaker 1: Characteristics like what kind of things? What does the algorithm
Speaker 1: look at?
Speaker 2: These are called features. It could be the permissions and
Speaker 2: app asks for the specific android functions or APIs. It
Speaker 2: uses the structure of its code, even how it behaves
Speaker 2: when you run it in the safe controlled environment.
Speaker 1: Okay.
Speaker 2: These features get turned into numerical data. Then you feed
Speaker 2: the algorithm tons of labeled examples, known good apps, known
Speaker 2: bad apps, and it learns to spot the differences the patterns.
Speaker 1: And once it's trained, it can look at a new.
Speaker 2: App, preciselyzes the new apps features and makes a prediction
Speaker 2: likely safe or likely malicious based on what it learned.
Speaker 2: Classification algorithms are really good at this.
Speaker 1: Did it give an example like a decision tree.
Speaker 2: Yeah, decision trees are one type. They build rules like
Speaker 2: if ab asks for send ams permission, and it makes
Speaker 2: very few other system calls, then it's highly likely SMS fraud.
Speaker 2: Simple example. The Janini score mentioned is just a way
Speaker 2: to measure how well a feature splits the data into
Speaker 2: good versus bad.
Speaker 1: So it finds the most telling signs. But ma, our
Speaker 1: authors try to froo these features, right, So the book
Speaker 1: mentioned more advanced techniques.
Speaker 2: It did because attackers do learn how detection works and
Speaker 2: try to evade it, So researchers are always developing new
Speaker 2: or more robust features, things harder to manipulate, techniques like
Speaker 2: TSG landmark based features FACCG. They try to capture more
Speaker 2: complex patterns TSG tank based s Insbision grouping looks at
Speaker 2: sequences of API calls, how data flows, assigned suspicion scores
Speaker 2: groups them basically trying to understand the intent behind the action,
Speaker 2: not just the actions themselves, but looking deeper than just permissions.
Speaker 1: Sounds like a constant arms race to stay ahead. Okay, finally,
Speaker 1: looking ahead, what does the handbook see coming down the pike?
Speaker 1: For Android malware well, it.
Speaker 2: Draws parallels with Windows malware history. As platform security gets better,
Speaker 2: attacks have to get smarter, more sophisticated. Android head security
Speaker 2: in mind earlier on being always connected, but friends are
Speaker 2: still likely. We'll probably see more malware using those plug
Speaker 2: in architectures, adapting dynamically to the device.
Speaker 1: Environment, becoming more chameleon like, right, and.
Speaker 2: More use of less common programming languages to hinder analysis.
Speaker 2: That will likely continue. And unfortunately, supply chain attacks probably
Speaker 2: aren't going away either.
Speaker 1: And social engineering tricking the user that seems timeless. The
Speaker 1: handbook mentioned FluBot.
Speaker 2: Yeah, Flubot's success in twenty twenty one mainly tricking people
Speaker 2: into sideloading banking crojans really showed how effective good social
Speaker 2: engineering still is. Others will copy playbook. The handbook also
Speaker 2: suggests a potential shift towards more subtle background stuff, ad fraud,
Speaker 2: renting out devices and botnets. Maybe crypto mining harder for
Speaker 2: you to notice, but let's attackers build up large scale
Speaker 2: operations quietly.
Speaker 1: So less noisy ransomware, more quiet exploitation. It really does
Speaker 1: feel like the battle for Android security is far from over.
Speaker 1: Constant adaptation needed on both sides.
Speaker 2: Indeed, it's a constantly evolving landscape requires ongoing vigilance, continuous research.
Speaker 1: Well, this has been a truly deep dive into the
Speaker 1: world of Android malware, all thanks to the insights from
Speaker 1: the Android Malware Handbook. We've covered a lot early days,
Speaker 1: SMS frauds, spyware, trojan, supply chain attacks, evasion detection with MU,
Speaker 1: the whole gamut. Yeah, the key takeaway, it really seems,
Speaker 1: is that staying informed and just having a healthy dose
Speaker 1: of caution is absolutely essential for navigating the digital world
Speaker 1: more safely.
Speaker 2: Understanding the threats even generally helps you make better choices
Speaker 2: what apps you install, what links you click.
Speaker 1: Absolutely So here's a final thought for you, tomull Over.
Speaker 1: Given this constant cycle malware adapting, defenses adapting, what do
Speaker 1: you think the next major battleground in Android security will be.
Speaker 1: Is it going to be AI powered defense, shoring up
Speaker 1: that incredibly complex supply chain, or maybe finding better ways
Speaker 1: to counter the psychology of social engineering?
Speaker 2: Hmm, interesting question.
Speaker 1: Definitely something to think about, and if you want to
Speaker 1: dig deeper, the handbook itself or resources like Google's Android
Speaker 1: Security Year and review reports are great places to look.
Speaker 1: Thanks for joining us on this deep dive