Mastering Android Security Research: A Guide for the Modern Security Researcher

[Music] all right if you're ready to get started say oh yeah oh yeah a it sounds like a Monday morning if you're ready to get started say oh yeah oh yeah excellent all right welcome today we will be presenting on mastering Android security research and we'll be presenting a guide for the modern security research you're probably wondering who are these people why should I talk to or listen to them uh I'm Hana Kan lonic I currently serve as the Director of security research for Dark Wolf Solutions I've been working in the defense industry for the past 18 years I've also served as a cyber security subject matter expert on uh Fox Business News ABC and other

National media Outlets I love participating in ctfs two of my proudest moments is last year our team tied in first place for the 2023 Defcon iot CF and in 2014 my team and I competed in the mainstage CTF event at Defcon placing in six and ranking the top 1.5% of ethical hackers worldwide I also hold several uh cyber security certifications including my cssp certified ethical hacker and I'm also a certified Android exploit developer uh lastly I have two pieces of paper a bachelor and Masters in computer engineering along with a mathematics minor and I'm joined with my co-presenter Jacob good morning everybody my name is Jacob soinski I'm currently a security researcher over at dark W Solutions working directly with

Hana um so my expertise is in quite a couple different areas uh specifically in reverse engineering binary exploitation vulnerability research now more specifically Android security and my I my background is heavily uh focused on pent testing so um I hold five different certifications including the Practical Network penetration Tester the e-learn junior penetration tester as well as the Security Plus and then I also have a hack the Box prabs certification also known as Dante prolabs um my background in schooling is I have a bachelor's in information systems with a focus in cyber security and I obtain that from Pittsburgh Technical College excellent now we're going to cover a lot in this 45 minute talk uh first we're

going to provide an introduction to Android if you're completely new to the topic raise your hand excellent uh and if you've been conducting Android security research or maybe doing uh Android pen testing uh we want to set the stage so that we're all on the same page then we're going to dive into our Android security research methodology and how to set up the proper lab to conduct this type of research then we'll go into each stage of the process first starting with reconnaissance of researching your target then performing static and dynamic analysis in order to discover vulnerabilities and how you can do that at scale using a technique called fuzzing once you have identified vulnerabilities in order to demonstrate

their severity first you need to bypass exploit mitigations and security protections so we'll talk about uh the different types that you'll need to consider as well as different types of cyber effects uh that you can demonstrate through exploiting those vulnerabilities so without further Ado let's dive into an introduction to Android which will be presented by Jacob thank you so let's get into the introduction of Androids so Android security greatly plays a major role within the world of cyber security which we know today I'd like to direct your attention to the two illustrations pictured in the middle of the screen uh so specifically we have 71% of the total mobile operating system market share is made up of the Android platform which is

just absolutely staggering next we have three billion Android devices actually populating the Earth which is unbelievable as well so given those staggering numbers as well as the div diversity and the fragmentation of the Android ecosystem being able to wrap your head around these types of vulnerabilities within the Android operating system has become more important than ever so with that said let's get into the architecture of Android Android is an open- sourced operating system that's based on the Linux based operating system and comes in a wide array of different types of form factors and different devices uh its documentation has been made conveniently open sourced and available through the AOSP or Android open source project and I I'd

like to direct your attention to the Android software stack specifically with the Linux kernel uh so with the Linux kernel this serves as a subsidiary and intermediary uh type of program that sits in between the operating system as well as the bare metal hardware and essentially the Linux konal allows us to gain access to those bare metal uh Hardware pieces next we have the native CN C++ libraries this allows us to implement native functional and Native implementations such as the lib SE Library within their applications and lastly the Java API framework this allows us to actually go in and manipulate our Android application as well as the ecosystem so really cool stuff there next we have we're going to

get into Android applications So currently Android applications are written in three different languages that those being Java C++ and cotlin um so Android also conveniently offers a SDK or a software development kit in order to be able to easily Implement all of your programs logic as well as any of the features and other audio audio files as well as imagery within your fun your program and that's all bundled into two different files known as the Android package kit or APK and you can actually bundle all of those together including your resources and that's known as the Android app bundle uh it's important to know that that after Android 9 plus and up um each and every single Android

application actually operates within its own sbox virtualized environment so that means that it only has access to the resources and the functionality that it needs uh next we're going to be getting into Android application components so what actually makes up these Android applications so this is split up in the four main parts uh first we have activities which represent the guey based interaction and the overall representation of uh basic functionality within the application and handles user interactions next we have Services Services actually perform background tasks and are utilized even when of the program is not in use next we have broadcasts this serves as a receiving and sending functionality for a series of broadcast messages that can be

relayed throughout the application uh that listen and respond to various different requests and broadcast m mesages as well as systemwide events lastly we have content providers which simply just manage and share data across a native application or thirdparty applications next we have Android intense so previously we talked about Android components well how do we actually use those Android components so we can use intents to actually call upon these Android components and as a result that's how we invoke those actual components so um in order so like intents serve as a communication mechanism and a sort of layer in between uh being able to call out components and actually being to specifically utilize them in specific use cases so more

specifically for activities and services the intent just simply defines the action to perform uh now for broadcast receivers the intent defines the actual broadcast message announcement in general next we have the APK or the Android package kit so I'd like to make it known that every single APK in the whole entire world includes a file known as the Android manifest.xml file this is arguably one of the most important files uh whenever it comes to Android applications and as a result if this file is not included in your binary it will not compile so definitely something to keep important keep track of uh so it's actually responsible for declaring everything that's necessary for the program's logic to be able to run

properly and it also includes various different resources like I mentioned earlier audio files and images but uh it's important to note that that is stored separately from the actual APK itself uh just in order to optimize overall usability and functionality within sharing uh application code just to simplify the process cool thanks Jacob uh so now now that you have an understanding of we'll say Android foundations uh let's talk about Android security specifically Android strives to provide the most secure software to their users and they do this in a variety of ways uh first they Implement several security features uh such as uh application sandboxing providing secure interprocess communication mechanisms uh as well as code signing or application signing to

verify the Integrity of the application that you're using they also provide a security bulletin where they're very transparent about the security vulnerabilities and weaknesses that have been reported along with additional remediation guidance Android provides very comprehensive security documentation about their security model of how they protect the app's data the users data as well as uh protecting the system resources on the device in addition we want to make you aware of the OAS mobile top 10 risks uh which provides uh details on uh existing and emerging threats to mobile application security I highly recommend becoming very familiar with these different resources documentations and features as it's going to greatly Aid your Android security research now you might be wondering well

how do I get started in performing Android security research as Jacob had mentioned earlier the Android ecosystem is very fragmented with several different operating system versions and device manufacturers in addition Android security tools that were once popular have now become either obsolete or they're no longer maintained therefore we created the Android security research Playbook as a getting started guide uh to Showcase how security researchers can conduct their research successfully against modern Android targets uh we have open- sourced the ASR on GitHub and we've also developed dedicated website don't worry you'll get access to these slides there's also a QR code at the end um and URL links if you don't trust QR codes but one thing we want to uh

clarify and make note of is that the ASR isn't all inclusive of every single tool or approach or method uh that is currently available however it provides several recommendations for each stage of the process so that you can continue making progress with your research so what is the ASR methodology it consists of seven stages as we mentioned earlier in the introduction first we'll describe uh reconnaissance of how to research your target then how to conduct static and dynamic analysis and the tools that are necessary to conduct uh these stages successfully the different types of classes of vulnerabilities that you can discover uh as well as different types of fuzzing tools that are available for use uh the

different classes of exploit mitigations and security protections that you need to bypass and the different types of cyber effects that you can demonstrate through exploitation but first and foremost you need to make sure that you have the right environment set up to do your Android security research we highly recommend using emulation software that allows you to create different types of emulated Android devices so whether it's a Samsung S9 or Google pixel 3 for example you can use Jenny motion which you can install on your laptop or desktop they also provide cloud images as well that you can deploy on AWS or gcp and um with that they do provide a a personal license or a free trial uh but

also a professional subscription for access to additional features there's also the Android Studio this is the IDE that's typically used When developing Android applications but it also comes with uh a free Emulator I love free I'm sure you do too um however it is a bit uh computationally intensive and a bit slow but hey it's free right you get what you pay for and then there's cilum uh they have been a game Cher um in this field uh they offer a SAS platform where you can emulate both Android and iOS devices and they provide a lot of advanced features for conducting uh your Android security Research In addition to creating emulated devices we highly recommend

using virtualization software um the last thing you want to do is examine a Target on your host machine and corrupt your your laptop right that sucks um instead use a uh virtualization soft software such as VMware Workstation Pro uh they again offer a free 30-day trial as well as a PID subscription where you get access to Advanced features such as snapshotting um but if you're on a budget or if you only like free like me uh you can use Virtual box uh which is also available in addition the ASR uh provides additional hardware and software recommendations so we highly recommend checking that out uh so that you can identify what's appropriate for your particular project so without further ado let's

talk about the first stage of reconnaissance thank you Hana so we're going to be getting into reconnaissance so this is split up into a category of five different plays uh so the first one being gather open source resources so why would the security researcher want to do that well in this play We Are tasking the security researcher to go out and perform osen or open source Intelligence on the particular Target that we are pursuing and just go out and gather documentation any blog posts that are regarding any exploitation as well as any documentation for that Target next we have contextualizing the history of the target this is done for a couple different reasons um the main reason is

to understand the overall motivation as to why the target exists in the first place this helps boost the overall understanding as to why we're performing Android research on this particular Target as well as why it's so valuable and why it's a Target in the first place next is discovering any known SE s this is arguably one of the most important plays within the reconnaissance section uh this is because often times or not uh whenever vulnerabilities are found within systems developers quickly want to get that patch and that mitigation rolled out as quickly as possible however that still leaves them open to attack from other attack surfaces and often times or not uh you can actually

still uh end up exploiting the original vulnerability just by tweaking the original uh proof of concept so definitely something to look out for if you hit a plateau and you need to make a pivot with it during your security research next we have creating a list of capabilities this this is pretty simple it allows us to understand exactly what the target is capable of what exactly its purpose is and what it can do lastly is finding sources for the APK so we want to find sources for the APK so we can actually obtain the file itself that we want to obtain we want to perform static and dynamic analysis on there's a couple different ways that we can

actually obtain uh the APK itself and that's through a primary method known uh just utilizing the Google Play Store and there's also thirdparty methods that utilize uh what's known as APK pure so with that said I'm going to pass it over to Hana to go into static analysis excellent all right once we have uh collected our Target uh we're now ready to perform static analysis where we're going going to examine our Target's code without actually executing it and we're going to utilize a variety of tools to help facilitate this process first we want to understand the apk's design and compiler using APK ID in this example we can see that uh this particular APK is

using anti- virtual machine checks we'll go into this a bit more in the presentation but essentially it's checking to see whether or not the APK is running in a virtual environment we can see that it was piled using DX or possibly Dex merge we also notice that it's using anti-debugging checks as well uh which can prevent us from conducting Dynamic analysis which we'll talk about uh shortly uh and we also see that it uses uh some anti- disassembly uh mechanisms as well which can help uh hinder the reverse engineering process so even though we haven't really executed um or dove into our Android application we've already learned a lot about its design and its compiler next

we want to decompress and decode the APK using APK tool in this example we can see that it's extracting its resources it's decoding the Android manifest file that Jacob talked about earlier it's also uh extracting its assets and libraries uh and in addition it's also extracting its classes.dex file this is actually the compiled B code that gets executed when you run your application next we want to decompile the APK using jotex who here has ever used the gidra decompiler right so the gidra decompiler essentially converts the disassembly of a program and converts it into a highlevel pseudo C like language this is very similar but instead of converting it um the compiled code to C or C++ is

compiling uh decompiling it to Java so rather than uh looking at the the uh bite code of the classes we can actually recover its corresponding Java code which is much more easier uh to to interpret to understand uh the functionality of the APK we can also export this project as a gdle project uh and import it into Android Studio in order to uh examine the file structure in a more uh we'll say robust IDE um and so here we can see that we have our Android manifest our Java packages its resources as well as the Gradle scripts that were used to build the APK next we want to analyze the apk's library files using the mobile security

framework or mob SF uh we can see in this example we have 17 activities as well as one provider for uh this APK we can also analyze its permissions to see which are present or which are absent we can also conduct additional U Mal analysis reconnaissance but what's great about mobsf is that we can specifically gain additional information about its shared libraries we can take it a step further and do some more low-level analysis by reverse engineering the library files using gidra in this example we can see that the main activity uh has a function called leak memory which is very interesting um and as we're analyzing this code I can see that it's utilizing the function called

SN printf uh which is actually a known insecure function so if I'm looking for vulnerabilities I probably want to spend a bit more time reverse engineering uh this particular function within this apk's uh shared library next we'll conduct Dynamic analysis where this time we're actually going to examine our Target while its code is executing and as you can see here we have a variety of tools that we'll be utilizing so first what we want to do is uh connect to our emulated device using the Android debug Bridge also known as ADB next we want to install the frea server this is going to enable us to perform Dynamic instrumentation um and gain greater introspection into our

Target once we've done that we're now ready to install our Target application uh in this example uh this is the dam insecure vulnerable app uh which is our Target once we've installed our application we can now examine its runtime Behavior Uh using objection in this example we're executing Android commands in order to hook into the main activity where we're searching for what list of methods uh does the main activity uh Encompass right so we can see here that this application is checking for a pen right usually we have a pen to access our phone or even our applications we can see that it's possibly uh performing some arith operations as there's a sum function so

just this listing alone uh we can gain a lot of information about our application and then we can also perform realtime monitoring uh using the runtime mobile security or RMS what I love about this tool is that I can actually interact with the application and in real time see what classes and methods are invoked right because I can take that information and then use that as a part of my reverse engineering uh process we can even debug our applications at a very low level uh using the ganu debugger or GDB along with its uh GDB server right so for example if I want to better understand uh the context of its register States what data is on its

stack in more I can perform that low-level analysis using GDB and this in this example in deploying an exploit I can see that I've overwritten the program counter which means that I can control the code flow or execution of my application so my exploit is working as intended and then uh if I am analyzing an Android app that is uh let's say it invokes a web page or it's communicating with a server I can monitor and intercept that web traffic um or even Network traffic using burp sweep proxy right so I can click on these different packets and sessions and see what data exactly was being transmitted from my source to my destination and vice

versa and so once you've conducted your static and dynamic analysis uh with the goal of finding vulnerabilities there's different types of classes that you can find so after all of your hard work from reconnaissance to static and dynamic analysis it's time for the fun part let's start breaking some code so getting into vulnerability Discovery uh the first vulnerability class that we have is a textbook standard buffer overflow simply put this is whenever the data of the allocated size of the buffer actually exceeds that buffer size uh while it was instantiated um and then ultimately from that uh that data begins to overflow past the buffer into other adjacent memory regions this can lead to a

multitude of different vulnerabilities uh such as remote code execution memory leaks Etc next we actually have a integer overflow uh this occurs whenever the operation of two arithmatic integers actually exceeds the data type that was instantiated for the variable type uh you can see in the illustration we actually have an odometer that is at 9 is rolling over from 999,000 miles to a million and where it should be a million it rolled over to zero so that's a perfect depiction of a integer overflow next we have a right what wear a right W wear condition is a condition that that could potentially be the presence of a buffer over the effect of a buffer overflow and essentially it just allows

an attacker to perform an arbitrary right to an arbitrarily attacker controlled memory location so in the C code snippet above you can actually see that we have a define global of buff size that is given 256 bytes and then you can see that it takes a argument a single argument for our binary uh there is then a call to a vulnerable stir copy that actually cop copies the contents of our first argument into buffer one lastly there is a call to free to free our second buffer that was created and if you actually inputed a string that was larger than 256 bytes uh what will happen is upon that freeing that second buffer the memory allocator will

actually leverage a uh linked list and as a result that linked list will become corrupted due to the pre-existing buffer overflow allowing the attacker to replace that link list with a um attacker controlled memory region as well as arbitrary data leading to remote code execution as soon as that pointer gets dereferenced next we have a use after free this is any attempt to access memory after it has been freed so this occurs constantly or this can occur whenever uh you are performing dynamic memory allocation so specifically you want to pay attention to two main functions that utilize dynamic memory such as Malik and free so anytime that you actually see a free call a Mal call

make sure that we're freeing the data after use or if you see a free call and that data is being referenced once more this could result in a use after free vulnerability next we have a format string bug this is personally one of my favorites uh it actually occurs due to developer error uh because the developer whenever he was here or she were creating the code itself uh they did not specifi specify a um format string specifier as an argument for the actual function itself such as print f or Sprint up for being able to print out data and strings so as a result uh the attacker can then Supply their own format string specifi such as percent n

and we can then write data to the stack uh dynamically and at will next we have an information leak uh this is just the just a generalized term for the unintended exposure to data and um it's also known as a memory leak um you can actually see in the illustration above uh this is a famous or infam rather Infamous depiction of the Heart Bleed vulnerability and you can see that the user is requesting data from the server and upon the server actually being exploited by the heart bleed vulnerability the server replies back with 65,000 bytes plus passed after the buffer which is not normal by any means next we have the shared Library uh this

involves mainly C and C++ native libraries uh this exponential expands the application's overall attack surface uh just by introducing native functionality in the implementations um and as a result uh it can actually like create a whole bunch of different vulnerabilities from that uh at the low level next we have input validation uh this is also du this also arises due to um user error and developer error um so it it is whenever a function actually fails to properly sanitize and validate data being inputed this can lead to a multitude of different critical vulnerabilities and next I'll be handling it over to Hana to go over fuzzing so vulnerability analysis can be a very timec consuming and laborious

process um and it can be manually intensive luckily there's a way that we can do this at scale in an automated fashion uh using fuzzing what we're doing is that we're sending crafted inputs to a Target and monitoring it for crashes and the application May crash for different reasons uh such as making incorrect assumptions about the user suppli data or not having the necessary functionality to handle that data properly there's different types of fuzzers and fuzzing techniques that are out there what we'll touch upon is running a mutational fuzzer such as AFL or AFL Plus+ a mutational fuzzer essentially takes an in file as uh it's called a seed and when it sends it to

the Target it's going to modify or mutate that data to see how the target then responds uh to that mutated form here's an example uh of running um AFL and AFL Plus+ against an Android application and uh within 19 seconds we had a unique crash and within 25 seconds we also had three total crashes that all uh demonstrated the same type of Crash so again check out the ASR for other types of fuzzing techniques and fuzzers uh that we recommend uh but usually uh using a mutational fuzzer like AFL or AFL Plus+ is a great starting point so now once you found your vulnerabilities uh you need to bypass all the Android security features that

have been implemented um and so Jacob's going to discuss how to do that so upon actually pinpointing a vulner ability that we can potentially exploit it's time to bypass some exploit mitigations so to start off we have the execute never SL no execute execute never is specific to the arm architecture whereas no execute is specific to the x86 Intel architecture so the NX bit is actually in charge of marking the stack as non-executable uh within your program upon compilation and as a result uh whenever the NX bit is implemented this means that the attacker can no longer inject Shell Code directly onto the stack expecting it to be executed so as a result uh when the NX bit is enabled

uh the attacker will then have to rely on a method known as roing or return oriented programming essentially this is whenever the attacker enumerates various different gadgets within the binary itself and can then manipulate the call stack as well as return addresses in order to bypass the NX bit to gain the functionality needed to carry out their mission next we have aslr or address based layout randomization uh this essentially randomizes the addresses uh within the virtualized address space uh for um all of the executed programs that are within the virtual address space It should be noted that aslr is actually a operating system function and it is not a binary function uh however it can be bypassed

with a information leak um pre existing to that uh before aslr was actually implemented um develop exploit developers were actually able to hardcode various addresses and other important information within their exploit scripts and because they didn't have to deal about aslr however since aslr is now randomizing addresses every time the binary is executed we have to rely on a pre-existing vulnerability that leverages a by a leak uh memory elak so that way uh we can obtain the Base address get an offset of that so we can recognize where we are within the code next we have anti-debugging mechanisms uh so this is just a generalized attempt to make Dynamic analysis more difficult you can actually

see by the two pictures that we have antia and anti-u debugger uh essentially these mechanisms will um persuade the researcher from not being able to utilize these tools because the application might invoke some function calls that will look for these uh various types of debugging tools and in an attempt to uh stop us from being able to perform debugging and if they are found uh then it can result in a premature termination of the application however we can utilize Dynamic instrumentation to bypass these fun these various anti-debugging functions and we can also utilize a couple tool tools to patch our binary um next we we have anti- reversing mechanisms uh this is just an attempt to make uh reverse reverse

engineering much more difficult for the attacker this is employed uh while the like within the source code itself for the original implementation uh this can be employed in a couple different ways such as encoding techniques such as polymorphism as well as encryption so uh we can actually leverage a couple tools within our Android security research tool belt and uh you like various de fisc techniques to get around that next we have anti-vm mechanisms this prevents the usage of virtualization technology while we're actively debugging and looking at our Target during um Dynamic analysis uh ultimately this can be bypassed by modifying a variety of checks as well as functions that are handling the anti-vm checks and we can

also do that utilizing Frida for dynamic instrumentation next we have root detection so root detection actually identifies if a device has been rooted or not so rooting is similar to jailbreaking on an iOS platform and why would somebody want to root their device well this is simply because this allows them to uh be able to unlock all of the restrictions on the device pretty much allowing them to do whatever they want with the device um so a couple ways that we can get around this is once again we can utilize Dynamic instrumentation via Frida or we can uh hook into various different uh functions as well as patching the APK itself so once you have bypassed these

exploit mitigations and security protections you can now proceed to uh attempt exploiting the vulnerability that you found uh there's different types of exploitation uh effects uh that you can perform we'll just touch upon a few of these but again uh we go into greater detail in uh the ASR uh so one of the common uh attacks uh that are observed are pen lock defeats again in order to access your uh device or an application it might ask you to enter in a four uh digit pen for example well we can actually bypass uh that check by either hooking into the function and uh changing the implementation of that check pin function uh we can also

perform brute forcing depending upon the length of the pen um or we can actually directly invoke activities within the application that don't have the pen protection in place right um so common it's most common uh where there's a lot of activities that aren't actually protected uh by the four-digit pen uh so I can quickly invoke it and get access to your photos videos or any other sensitive data uh we can also perform uh local privilege escalation so as a standard user user you usually have a a limited subset of permissions in order to read write or execute data um on that device with local privilege escalation uh you can elevate your privileges to root which has the highest

administrative access where essentially you own the system and you can read write and execute whatever you want uh we also have remote code execution so instead of having direct local physical access to the device or application uh based on the vulnerability I could potentially install an implant or uh execute a reverse shell which will communicate to a different device and now I can access my target remotely and execute arbitrary commands in addition there's an emerging trend of uh zero click exploitation where essentially an exploit an exploit can execute without the need for user interaction what that means is that essentially a user is unaware that their device or application is being exploited it's usually running uh very Ste

stealthily in the background uh without the users awareness for however long that attacker wants uh so again these are different types of uh I'll say cyber effects that you can demonstrate um in order to showcase the severity of the vulnerability that you've discovered now we have covered a lot in this talk but we've only scratched the surface right if you want to learn more uh definitely check out uh the ASR the Android security research Playbook again it's a getting started guide uh for conducting Android security research but also if you are a seasoned experienced Android security researcher I'm very confident there's going to be additional tips tools and techniques that you're going to learn in this um again you can

access it on GitHub via this QR code uh we also have a dedicated uh website for E of navigation and you can access them at these URLs again if you don't trust the QR codes so with that we're doing great on time uh any questions from the audience this is a packed room by the way this is amazing this is awesome this is

awesome seeing that more in scope on your pesting redeeming engagements utilizing those exploits for those Purp uh so we're seeing I would say increasing uh requirements in order to for the customer to understand what is the severity of these vulnerabilities and even if we do report a vulnerability they want proof right um and so by uh developing these proof of Concepts we can showcase um what is the risk if they do not uh patch or resolve that issue and of course for certain vulnerabilities um and certain targets we do go through a responsible disclosure process um as well y go ahead so you mentioned like o and historical resources at the beginning I understand that when it comes to like clients or

whatever but like I know for example like if I'm just a hobbyist I'm like oh this place has a bug b let me deile and look at I don't do research there can you speak more on the o and historical research maybe as perspective that's was picking up on yeah absolutely I'm going to pass this to Jacob because I want to say it's not client specific but actually a critical initial first step that you should do for any Target that you're looking at interesting yep okay yeah so overall whenever you're introducing and actively utilizing your hacking methodology no matter what your target actually is you want the first thing that you want to start off with is

reconnaissance this allows you to understand the overall implementations and allows you it like if you get stuck anywhere during your security research it allows you to have a soft spot that you can land back on if you need to Pivot if you get stuck anywhere so yeah there's a variety of reasons why you would want to definitely perform reconnaissance and learn more about the target uh prior to actually getting into the nitty-gritty and beginning to perform static and dynamic analysis and look for exploits so I'll I'll elaborate on that um so for example if you want to understand what's the the history of the app right has it been around for 10 years or has it been around like last

year with that and looking at like the release notes the change slugs yeah you can see how has this application evolved over time and in addition uh how many cves have been reported for this target over the years am I seeing more buffer overflows use after freeze are they implementing um newer security mechanisms that uh I need to take into consideration so there's a lot of Rich information in that history I see so in that case we're still talking about the target application itself corre or whatever correct you have the application itself because when I hear I usually think talking about looking up people or companies or whatever but this is about the application yeah so in this

case the target is the application not the person or company yeah yep so you you can actually utilize o for a multitude of different capabilities and purposes yep good um is there a playbook for um and debugging the Android on a current level Sy that is our next sequel yes so currently we are focused uh primarily at uh Android userland um but uh we do want to release a second version that dives deeper uh going into the Android kernel um but also for example if you're reverse engineering the shared libraries um if they're making any particular kernel calls right that can lead you down that path as well but more to come as far as playbooks

yeah uh go ahead and then I got you in the back good when you guys are doing vulnerability research which seems like to focus to your team you guys also kind of dabble in malare research and understanding what threat actors are doing with the vulnerabilities that you're coming across yeah so we actually uh take a hybrid approach and that's one the thing that's great about our cyber security practice area is that we will collaborate with uh red teamers um and uh also our our malare analysts as well so we're sharing our knowledge and if we encounter any blocker we'll reach out to the team saying hey this is what I'm seeing um and having that hybrid

approach allows us to essentially complete our analysis much more quickly and more thoroughly thank you yep I'm back um this is a question are we talking about attacking the application or the operating system or doesn't the operating system ability appliation great question um so we're focused on um exploiting any vulnerabilities in the application however as Jacob mentioned um during the exploit mitigation and security protection section there are um OS protections that are implemented that restrict what an application can do right so the um execute never for example or the no execute aslr Etc any of those OS uh security mechanisms we also have to take into account in order to successfully exploit our Android

application uh I wouldn't say that there actively trying to defeat them um but more of they're either not taking them into account or they're adding their own on top of it to make it even harder yeah uh we'll go here and then here um if you only have access to a production build of an application what are your best practices for off skting oh great question um so I mean it's going to vary based on what ausc uh techniques that they're utilizing uh but one I would say an initial first step is like within jotex um they have uh different types of officiation techniques that you can Implement um and then depending on the category of

officiation let's say for example white noise or anything um or even um we'll say function or variable renaming um there's additional techniques that we can take you want to elaborate on that well yes so by utilizing Jau we can actually load in that Target APK and there's an automated method similar to to G's approach to uh pre-analysis and we can actually leverage that to Auto decate that binary so yeah definitely something to look into yeah but in addition I would say based on the complexity of the ausc more likely than not you have to uh develop a custom solution to do the deoxidation yeah yeah and then we have this guy yeah have you seen anything

respon applic uh great question personally I have not uh perhaps on our red team they may encounter more of that uh but I would say that um as companies are embracing more of like BYOD or bring your own device um they are you know recognizing the need to have uh better uh detection response policies for mobile devices um also um if they're issuing work phones for example having some sort of um mobile device management software uh is also useful as well so um but again for for our research in our Focus area not necessarily um but great question cool got you and then I think you might have a question go ahead uh what's your opin on

work it works every time for us uh but again it's gonna it's going to vary depending upon the Target right um as well as just the um I say the age of the app of the the APK that you're analyzing um but again like it's not necessarily perfect uh but it definitely gets the job done at least 80% so anyone had a question over here I think maybe no all right oh go ahead sorry yeah the light's blinding sorry good I just wanted to know if um if any of the techniques you're using are impacted by Android Forks like gra Os or Kix or some of them does that change anything what doing so I would say with the ASR that we've

uh released uh has been I would say the most uh effective method across the fragmented Android ecosystem um however depend if they are using a different flavor of the Android OS um then we need to take more time to understand what those variations are and how they're reflected um in the uh say disassembly that we're we're reverse engineering right so um I would say it's not necessarily A one-size fits fits-all uh but it definitely gets you like 80% of the way there and then you just have to understand the nuances of your target to cover that remaining difference right time excellent Anna Jacob thank you guys very much thank you thank you [Music]

[Music]