BG - Introducing Android Security Evaluation Framework (ASEF) - Parth Patel

hello everyone uh thanks for hanging until this late and uh choosing to attend this talk uh they have been uh quite a fun talk so far and uh I hope this one is also going to be amazing one today I'm going to talk about ASF uh the story of it um ASF as I call it Android security evalution framework and uh uh we're going to cover like a lot of aspects of this framework and how the idea came into existence and uh what it has to offer to the Android security before I do that I'll briefly give you my introduction I I don't mean to flatter myself too much but uh uh I'll cut it really short um I work as a

vulnerability signature QA engineer at kalis and uh actually over there I get to enjoy my childhood hobby of breaking things as a profession uh but along with uh all the fun that I'm having I I also get to like uh learn how to build things how to how to automate things and when I get to build those automation tools I get like extra time to explore new things and that's how I actually started exploring Android security or last one year and combined with all those factors uh here is uh today's talk so let's find out what we're going to cover today uh initially I'll I'll give you like a brief overview about the the manual

research uh that I conducted all the tactics that I used um and I'll also talk about uh the limitations of of such tactics and uh what automation can make a difference and uh uh what ASF has to offer to it so we're going to cover the the detail design of ASF we're going to do the demo we're going to cover all the stats that I have collected uh it's going to be pretty interesting uh and once we are done uh uh explaining ASF we'll see what type of real life problems we can solve and if we can do that then we'll see what we conclude today so let's find out so I I'll I'll just start with a

very brief overview about my personal experience as a security engineer working on the Android OS platform uh as we all know Android is an open source operating system for the smartphone so that opens up a huge market for all the smartphone manufacturers uh uh to to add their own flavors to it and and create their own interpretation so we see like there are a lot of uh uh uh interpretation already out there in the market um which is actually a key strength of it uh of it being so prominent in the market however from the security engineer point of view the way I it is there are times when it's it's it's you have to be like very careful

about uh your requirements have to be very precise and you have to be very careful when you're trying to address any issue uh out of like the cluster of Androids out there at the same time there are times when you want to make a very generic uh statements you want to you want to be uh you want to consider all the possible iterations out there in the market so that makes it little bit hard as a security engineer however we're going to talk about the the the element that makes this platform very smart which is the apps and we're going to perform the security evaluation of these Android apps one of the place you can get this

app U is from the market as you can see that um initial version of these markets were a little bit relaxed so along with some uh genuine app from the developer there were malicious app were also injected uh into the into the market and um again user uh uh has to worry about like whether uh the app is you are malicious and in order to solve this problem later on we saw that some of the uh markets like Google Play came up with their own security service called bouncer in order to protect their uh markets um from being injected by an attacker uh via malitia app however um there are enough evidences out there that that shows that the even this uh uh

Security Services are not entirely bulletproof there are attackers who have still managed to bypass this and put the malicious app on the market so again the question for the user is uh what do they have to make that decision whether to install an application or not and again this is uh only a part of the picture where uh we are talking about the users who are religiously sticking to the uh uh downloading an application from the market um but talk about most of the users who are very more adventurous for them this is only a part of a problem because they want to uh root their device they want to install applications from different part of the internet and

uh if you consider the world inside these markets bit more regulated the world outside it is is quite Lawless so what's the gist of the story I mean um if if you are a user um what what is in your hand in know in order to make that judgment call in in order to make that final decision whether to install an app or not whether it's a genuine app or a malicious app well Google's answer to this is permissions well we all agree yeah permissions are out there in order for us to make that decision but the real question is how convenient are those I mean sometimes it feels like reading a software agreement uh uh and which is

very very inconvenient and most of the PE most of the users are inclined to ignore it at the same time there are times when the application is very uh uh very appealing or maybe I'm very tempted to try it out I might just ignore it uh uh in that case so that's that's somewhere uh the the starting point of my malual research started where I try to categorize all these application based on the permissions and what I realize is just relying purely based on the permission or in general the asset information that are associated with this Android application isn't isn't completely conclusive or not neither comprehensive so I I I dig a little bit further on the manual research where I

rather than focusing on the functionality aspect of the this application I wanted to focus more on the behavioral aspect of it in a sense that I I I don't just want to focus on what this app is telling me that it is going to do like it's a game app or a social networking app or or or utility app but I'm I'm I'm I'm more interested in about the the way it behaves when you install it or use it for example uh what type of server does it talk to uh what type of network activity does it uh conduct uh how much data does it consume uh does it have any security flaws is it

talking to any server which is already blacklisted by Google there are kind of questions uh around around this uh behavioral analysis uh that that I was interested in so I I just started uh thinking of creating U um a an environment for this behavioral analysis of an app so I can start with n number of tools in order to build this environment to to perform such type of Behavioral analysis but I thought of starting with the most basic utilities available out there um and once we build like a solid platform we can always go ahead and integrate more uh utilities and build upon it so one of the thing I was doing was just download an

application from an internet uh install it on a virtual device and you know just just for with it just uh just trigger certain behaviors while you're doing all this just collect the network traffic uh at the same time you also collect all the activity logs on the virtual device and try to make sense out of this data like what is happening behind the scene so Android uh uh SDK will provide you like uh emulator utility from which you can create the virtual device you can also uh get the uh Android debug Bridge which will allow you to talk to this uh virtual device also there is an Android asset packaging Tool uh which will let

you construct all these uh commands it will help you in constructing all these commands in order to uh talk to the virtual device again V Shar is a widely available packet capturing tool that you can use in order to re uh reconstruct the source source code you can start with the de2 jar uh convert the dvic executable file from the APK file and uh get it to the jar file and once you get into the jar file uh you have a whole uh a lot of options in order to De uh decompile the source code and then you can actually manually dig into the source code and you can use any ID in order to uh look at this uh source code

so these are like very basic uh fundamental utilities that I started with and uh I started uh doing this manual research for like uh large number of applications like I I download the application like I do all this behavioral analysis I I collect the data I go manually I I try to make sense out of it I try to interpret it and it seems like it it it's too overwhelming I mean imagine like it takes like hours and hours of work to do such thing for one application and the rate at which the new applications are coming up in the market it's just too hard to keep up at this rate doing the manual research so I

was looking for more uh solid answer to it and the one of the answer that I came up with is Automation in form of ASF so I'm in the next few slides I'm going to talk about the design aspect of ASF and we going to we going to start with the the the top level overview to the very fine uh uh design aspects of it so before we even go into further detail we just look into like if I give you an ASF right now this framework what you can possibly do with it imagine there are uh three different type of use cases that I consider while designing this framework first one is if user has just

downloaded an uh application from an internet and uh they want to know all the questions that we just ask um all they have to do is just point that uh APK file to the framework and it will give you all the all the results after performing all the behavioral analysis uh uh tactics that we talked about thoroughly automatically um But there again there there might be some researchers who might have like tons of applications they want to go through not just one application they might be interested in so in that case you can uh run this framework against the end number of application it will perform the same task one by one on each application and it will give you the uh

results uh once it's all done but here we are only considering the cases where you actually have the APK file the actual source file of the application on which uh which you can point it to the but most of the user might not uh have the APK file they might have just installed the application from the uh Market uh and in that case all they have is install applications on their devices so in if if they want to uh scan their device all they have to do is just connect their device with the framework with the machine running framework and it will give you all the results and they don't have to worry about uh

anything else well while I'm I'm saying that I just do want to make sure that at no point ASAP will run any uh pass or active test on the device itself and how we are achieving that uh we're going to go into uh much detail of the design so there are three different phases ASF is uh working um uh it's it design flow is Works in like three different phases first phase is a passive where it tries to collect all the data which is required to run all the test in the active phase it will actively run all the test on the virtual device and then once all the data is collected uh after running all the test

Cycles uh it will try to interpret this data in order to conclude some results so let's look at uh every phase one by one irrespective of your input uh the configurator module will uh start uh this is the initialization mode uh ASAP is trying to initialize and these are the modules uh that will be called one by one after one um again this is a automation framework so we don't want to have a uh user bit overwhelmed by uh entering like long nested arguments every single time so uh once you there is a configurator file uh once you configure with all the default uh parameters uh then the the framework is good to go for any number of uh test

that you want to run at the same time it will also help you in like creating the virtual device uh which will be also helpful in migrating this framework from one machine to another machine we'll also do the uh session cleanup before we start our uh test Cycles so uh ADB refresh module will take care of that there might be time where uh many devices might be connected to the machine which is running ASF so uh device detect will let you know that hey I have successfully de uh detected either the this virtual device or the this physical phone and uh this is the device ID of it but make sure when you connect your

device to the machine running ASF enable the USB debugging mode in order to uh talk to the device so once the SF is initialized uh it goes into the normalization mode where we talked initially that the first two category of the use cases are same where you actually have the APK file on the machine and you can just easily pointed to the framework but imagine when you have a uh when you have a device on which all these apps are installed the extractor module uh does its magic where it will extract all these application one by one on the local machine and uh once we get these applications uh it will create a list of

array where all these APK files are stored and how it does it the extractor module queries this device for the list of installed packages and once it finds the install packages it will iterate and try to find what are uh what are what at which location these applications are stored and while it's doing this iteration it will also try to find out whether these apps are system apps or the user install apps as such our Focus here at the in this framework is to test the user install application we going to we're going to filter out the user install application and only extract those ones uh at the local machine and once we get to that point uh we have a

list of area where all these uh APK files are stored on the local machine and again the importance of this uh uh mode is also because irrespective of what type of input you have if somehow you get to manage to get to this point rest of the functionality of the framework uh will be almost same and once the uh um the normalization mode has run uh we can just jump into the test cycle but we want to take a little bit more careful approach and what we're going to do is we're going to create uh uh a set of uh uh uh we're going to create a hash table in which for each and every application

we're going to extract all the asset information like package name uh version version number um uh when the application will be started and and stopped uh in the test cycle uh that that will help us organize all our our results uh later on as well and help us uh triggering all these commands while running the test cycle and in order to organize our data uh which we're going to collect in the test cycle we going to create a test result archive so the framework will create uh uh the directory is based on the time stamps and within those uh directories um at uh different uh directories will be created based on the name of the application and

within those uh directories there will be there will be lock files in which we'll be capturing all the data so once we have all this hierarchy created um we are good to go for uh uh go for the active mode which what we're going to do is first we're going to see uh whether the virtual device is running or not so if it's not be uh if it's not already running we're going to we're going to boot the virtual device we're going to uh actively check whether the uh device has been booted or not and all these default virtual devices they they they boot with the display being locked and in order to uh in order for user to

see what's happening on the virtual device we're going to unlock the device uh remotely but if the virtual device is already running there is no need to go through this entire boot process and we can just bypass it and then just go ahead with our test cycle so uh virtual device launcher will uh take care of these two uh uh possibilities but there might be some security researchers might question that hey um the the default virtual device has its own limitations and uh there are few things or maybe there might there might be some application might be smart enough to detect that hey this is a default settings on the virtual device and they might not be behave maliciously and we

might not able to uh cover those application in our coverage so in order to answer that question uh I have added one more option where you can just bypass this entire uh virtual device uh phase and you can just point this framework to run all the tests on the actual physical device where all these uh tests will be performed on the another physical device that you have connected uh and you'll get the more real life like data again now we are all set for running a test cycle we'll capture the time stamp uh we'll start two background processes uh one to collect the log on the device and another one to collect the network traffic and once you have

done that we going to go into the installation mode where we're going to point uh the application to the right device where we want to install it once we have successfully installed it we're going to automatically launch it uh and then the uh then it will try to send different gestures in order to trigger those behavior that we are interested in and collect the data uh and once it's all done it will uninstall it and uh it will capture the stop uh stop time stamps and it will close all the all the processes that were uh that we started for that particular application and again this cycle will be iterated for n number of applications that you have

provided till now it looks fine um however uh there is more to it which I call it an extensive mode where if the research is not only interested in the behavioral analysis as pect but the to find out more behavioral patterns uh they can also go ahead and collect the kernel lock memory dump and running services at the different stages of this test cycle and and that way you can actually cover uh that way you can in fact do some forensic analysis and and and find out some behavioral patterns uh out of this collected data however there is more to this it seems like a recipe that has all the ingredients but there is one Element

missing which I call it marination time which allows you to fine tune this test cycle in such a way that you can decide how long you want an application to spend inside the test cycle you can tune this time in such a way that the app can spend like uh you can you can construct the 3 minute or 5 minute or maybe 30 minute test cycle for each and every application so as to increase your coverage of the test once all the data is collected uh the interpet phase will try to pass this data analyze analyze it and uh generate some results so we talked about the capturing the network activity so this parser will try to parse all the URLs

and IP it will run it through the safe browsing API of Google and uh it will tell you like what Google safe browsing API has to talk about all those servers I mean if you are uh information is being sent to some server which is already blacklisted then uh you'll come to know right right here at the same time we'll also look into the access rate of this uh uh servers and we we'll try to find out what are the uh what what are the type of uh servers U which are actually uh serving the ads and if the accessity is too high then are those really an aggressive hardware for you and we'll look into it more in detail

when we look into the results uh the traffic analyzer will try to find out the amount of bandwidth uh that an app has consumed in that uh in the test cycle and it will tell you all the data user and bandwidth uh results uh for that particular test cycle uh if you are worried about your data being consumed uh then you might be interested in this type of Statistics as well the vulnerability detector is is is something that uh not part of the behavioral analysis but it's something that I uh I I I I went through all this uh security advisories for Android uh and found the most high priority uh uh High sity vulnerabilities and created

signatures um and then what we are doing here is uh we are running all these uh packages that we have extracted uh finding the versions and running it through the vulnerable versions that are already known and we are displaying the user that hey you are currently uh you have currently installed these many applications out of which these applications are vulnerable to some known security flaws and you might want to take some action to it again we talked about permissions a little bit and say uh and mention how uh the permissions um have limited scope in order to make the uh decision but again we don't want to completely ignore it um what the the the technique that I

have created is where rather than going through every single application and iterating every single permission just create a unique set of permissions out of all those application and see which uh permissions are being used by which application how this mapping makes sense we'll see in the charts uh when we talk about the results and uh again you can also recompile all these uh APK files if you want to do like further manual research um and you can get uh this you can get to the source code um and again the same tactic can be used by uh can be used to the API mapping as well blacklisting is something that is more like a community thing if we don't

have uh like all the once the app is gets blacklisted then it just disappears from the market so we want to make a list of all these uh packages which were uh of the of the application which were like blacklisted so uh that can help us uh learn more about them at the same time if the app is already blacklisted then we can just let user know right away seems like we talked a lot about this uh framework uh so let's just look at the demo and see how it works there are there are many ways I can give the demo but I'll pick the most obvious one which uh user might try like after they download the framework uh

what they might be most interested in just scanning their device so I have an Android device uh with me all I have to do is just connect it with the uh machine that is running the ASF and I'll walk you through the demo so once I'm

yes

I think

[Music] [Applause]

uhic closer to you so I have connected so I'm going to pick the device scan mode um and just going to give the option dashd and the framework is going to start and as you can see all the design uh slides that we talked about it will start with the configurator mode uh it will detect the device it shows you the ID of the device uh the extractor is running now it has extracted all these applications uh it is telling uh the the converter model is telling you all the asset information associated with these applications uh the test uh result High uh hierarchy module is is creating all these test directories uh for the current time

stamp and organizing all the data now we are going into the uh device launcher module where it hasn't detected any virtual device uh already launched so as you can see here the device got booted

and as we mentioned in the in the design slides that we don't want to uh we don't want to time it uh the the boot Pro boot time of this virtual device so we are actually actively tracking the boot process and once we get the signal whether the uh device has been booted uh properly we're going to movee uh with our uh test cycle so as you can see uh the device has come uh come online and now it's waiting for it to complete the boot process and I mentioned that all the default vir device they start with the lock mode so in a while we going to uh we're going to send the uh

remote swipe and unlock the device so it has unlocked the device and now uh one by one it will start installing application and run all the test and we already uh started the TCP uh dump and the ADB lock uh capture in order to collect all the behavioral data so has it has successfully installed the first application and you can see it will be launched uh and now we are sending all the different gestures I'm trying to keep this demo quick and short but when you run this framework it will be very extensive it will send uh a lot of uh lot of gestures and um you can collect lot more data um but we are going to

just run it through two two applications um but it can perform this task for and number of application now it's going to install the second application and once it finds it successful then it will go and start sending the different gestures to it so now it's going to launch the second application where we going to first with it and we're going to collect some data and behind the scene we are also collecting all this uh packet capturing and uh and the ad log on the virtual device and we going to uh go into the interpret mode where we're going to try to analyze this data so now it's done testing these two applications it is going to see as you

can see like what type of what type of uh URLs it has accessed

here you can see that this application is trying to send some user statistics to uh a website or like these are the type of uh servers it has talked to uh this is the number of uh bytes that it has uh uh exchanged uh during this test cycle and at the same time I talked about the vulnerability detection where uh this app was found to be vulnerable to this version and this is the CV ID that uh it is telling you and user can refer to it and decide whether to update the application or um uh what to do with the uh version of the application so these are the list of uh U behavioral

data that we come to know once we run the application again there are lot more features to it you can run it extensively but this is a brief demo uh which shows the functionality of this framework but I want to share a lot more about like the type of data that I have collected uh while running my own uh test using framework so let's move this to the

side so now you got an idea about how ASF Works uh we're going to look into all the statistics that I have collected over the period of time uh for different applications uh the one the one that I was most interested in in in if the applications are leaking any of my personal private or sensitive information so I took bunch of application uh like ad or so and I found out that out of them after run running a test through ASF six of them were leaking private data and we'll go through them one after one like here you can see that this application is sending your IMI which is a device ID number and your phone number uh to some server uh

uh somewhere uh again this is the default device ID of an emulator uh and the default phone number these are all the default settings of the ulator imagine if if you have downloaded this application on your device these numbers would have been yours so uh using ASAP I came to know that hey whether should should I install this application knowing that this is actually leaking my personal information uh at the same time there was one application which was actually sending the uh the serial number uh of the of the device uh to some server um the subscriber ID number which is an IM imsi number was also being leaked I was also interested in like knowing

how much bandwidth uh does an application consume so I I ran a I created I fine tuned the test cycle to be 3 minute and I collected all the data for the number of bytes it exchanged during the test cycle and I found out some of the applications were like uh uh creating very high Network traffic whereas some of the applications were not so again if I'm more interested in uh finding out uh more about the network activity and such I might start focusing as a researcher on this side of the graph and pick uh pick and choose my applications if I have to deal with like hundreds and thousands of application but again the B the data

uses was only like uh limited information I was more interested in finding the aggressive adware in order to do that I first had to find out the access rate at which these servers were talked to so this graph shows you that uh number of servers uh were accessed uh for each and every application and more interestingly at which rate these servers were talked to so in this graph you can see that uh there were different uh servers that uh were communicated and the the height of the the width shows that the number of servers and the height shows that the rate at which they were communicated and you can just set your own threshold saying that hey if

the server is talking to uh if the app is talking to some server which is known to be an uh an ad server and if it's like more than twice a second then you might call it as an aggressive adware um and here is one of the example where an application was trying to send a request at very high rate and maybe for me it might be an aggressive adware again the definition of the aggressive adware is bit more broader uh we are trying to look at it from the access rate of the uh the rate at which the ads are pushed at uh onto your device I talked about the permission mapping while talk going over the design

uh design slides where um I was more interested in um looking into what type of permissions are being used by the different category of apps so I took like thousand applications and I created the permission distribution in a sense that rather than going through every single application and find out which permissions I just created a set of unique permissions out of them and find out which permissions were most widely being used so the games g these thousand game apps were like using 25% of them were using like internet permission um so um that means that in order for that application was asking you to have an internet access in order to uh be installed um again but there are there

are certain uh permissions that I was actually very surprised to find in a sense that some of the application were even asking for like send SMS write SMS even write contacts or mount on Mount follow systems which you might have a hard time imagining uh why would a game app will ask you to do so so again this is still not yet uh U conclusive in a sense that this gives you enough lead in a sense uh if I'm interested in SMS Trojans and such I might start looking into these applications uh so it gives me enough leads about how to approach and how to reverse engineer the applications uh again vulnerability SC scanning as I

mentioned um I had like 75 applications uh installed on my device and I was interested in uh finding out how how how much uh how many number of vulner uh vulnerabilities are there in my application so I just took my phone and I I ran a scan with the ASF and and I was a little bit surprised that I found like 12 applications which were vulnerable for like severity 10 uh 10 and uh there was quite surprising but more surprising was some of them were I was like highly uh were very very highly used application like Adobe Flash Player or Mozilla Firefox so then at that time I realized that hey I I need to go ahead and update

my applications uh and get them all to the most recent version available from the market uh maybe I haven't updated them that's why I'm vulnerable um so I I did that and I updated all my 75 applications to the most recent version from the Google Market and I felt little bit safe well but not too long um cuz the next data that I found was not surprising but little bit shocking in a sense that um six of the applications uh even after updating all the application from the Google Market we're still vulnerable to some known security flaws and here is one of the example where um one application here is the most recent version from and this is the known

security flaw um and I guess developer hasn't taken much action in order to update or patch it so I I see like there are hundreds and thousands of people who are also download this application are currently vulnerable for uh this security flaws which can be exploited um so far we talked about the design um and and the statistics parts of it but imagine having this framework as an open source um we also want to talk about the ex uh extending the framework uh part of it uh what how how possibly you can uh take this framework to the next level So currently we are collecting uh the packet capture uh through TCB dump and activity lock through ADB lock uh but

imagine the the the the design is so simple you can add as many as uh command line tools as possible uh in order to increase the functionality of this uh um so there are a lot of functionality that can be added uh at this layer around the test cycle U but there is another place where we can uh also improve upon is uh the virtual device itself we want to increase the functionality of the of the virtual device or the physical device where it has an ability to to uh to to detect certain malicious activities uh which uh some smart malicious apps might be uh uh very smart enough to like overcome uh those type of platforms so

we want to we want to make the contribution in the platform as well uh so if we have those type of images on which we can uh do those type of analysis we can use that in order to expand the functionality of the framework so I think we have the framework now let's just try to solve uh some real life problems one of the idea that I had was like if I uh make this framework an open source framework there might be so many developers who might be interested in creating their own app stores and in order to protect and promote these type of app stores uh where people haven't yet gained enough uh trust uh this

framework can be easily integrated where uh it can give you the results of all these behavioral analysis that he has performed for all the applications that are there on the market and user can get to see before they download the application and say that hey these are the uh activities that they are doing these are the type of analysis that ASF has provided and whether to install an application or not so that makes a life a little bit more easier for the emerging uh markets and the uh user which are bit more adventurous and trying different markets however uh there is another uh uh place where uh I I think it's bit more challenging to

solve problem is for the applications which are already installed on the device so in that case imagine like if you have a large company where there are hundreds of uh Android uh users and you want to you want to you want to test all these applications uh regularly uh one one one simple solution you can come up with is give this framework to the it guys uh let them uh deploy this on a server and uh let them manage all these uh Android devices one by one and let them scan and collect the data and such but it's not only it it doesn't only sound unfair but it sounds very inconvenient not only for the it guys but also for the users where

they have to like even leave their phone for like few minutes in order to you know perform this test and who would want to do that I mean they have their whole life in these phones like email and contacts and calendars and everything so that doesn't seem like uh uh a reasonable approach uh and what I what I realized at that time even though I was happy about the functionality that ASF has to offer and what kind of things it could solve uh I still saw a limitation through a physical barrier where you have to connect the uh device in order to run a test uh on the machine and I wanted to unplug ASF by overcoming

that physical barrier and in order to do so I came up with my very first Android app which I call it night Fenix uh with the help of that uh ASF is now unplugged in a sense that all you have to do is user can just install this application and it will it will extract all these application uh installed on this on your devices it will send it to the uh uh ASF uh on the machine which is running the ASF and uh all the tests will be performed so how night Fenix and ASF will work together so you have installed this uh application on your device it will go ahead and iterate all these uh packages and try to find out uh

find out where these APK files are located on the device um just like the extractor module of an ASF except this time we are doing it locally on the device itself using the package manager Library it will create a zip file of this and store it on SD card and on the other side ASF will be listening on a predefined port uh to receive this uh ZIP file and once it receives it it will unzip it and it will create a list of array where all these APK files will be stored and as I mentioned that once you figure out a way to get through this point of a normalization mode rest of the functionality of ASF will always

remain sa so that's a beauty of the design and with the help of night Phoenix uh now ASF is unplugged that all you have to do is just click uh uh one application and your test tests are being run on the ASF server why do I keep calling it night Phoenix uh that's a good question so when I imagine uh this application to work with the uh ASF um I I thought of why you want uh make user to go through that hassle of clicking uh that application every time they want to run a scan so you can actually integrate the alarm manager library with this which will allow you to schedule all your scans so let's just say your user

activities uh at the least at the midnight so you can schedule your scans at nighttime and uh it will send all these files uh to ASF server and ASF will run all the tests and will let you know if anything is wrong it so again um after uh working on night Fenix I was a little bit happy that I I was able to uh unplug the ASF but uh at at one point it really stried me that uh who watches the Watchman because uh I was I I started talking about uh evaluating the security of the Android applications and uh doing all the behavioral analysis and running through through ASF and such but in order to

overcome the limitation of a physical barrier of ASF we ended up introducing our own app so I was more interested in knowing let's just find out how secure is my own app so what I did is I just I just took uh I I took uh my night Fenix application and I ran it through ASF uh at that time I didn't find anything wrong but I started digging much more into the into the uh functionality aspect of it what I realized is the way I'm uh achieving the uh function of night Fenix is by using two permissions one is the internet permission in order to send the zip file and to store that zip file on the SD card I'm using the

right external storage permission and while I was going through this code I I realized one interesting thing where there are ways you can actually bypass very easily the external storage uh uh permission where you can send all these application one by one rather than creating a zip file and sending it at one shot and this is something that you can play around or search on the internet how to bypass uh how to find a way to bypass the internet permission and once you get to that point imagine what do you have you have an Android application you have a piece of code which sends all your install application to somewhere um with or without your

permission and if you can get to this point uh and uh you might not want to call it a night night Phoenix and if you may please call it the dark Phoenix it seems like an end of an story here but is it actually it is just the beginning I'm more excited about also talking about the next generation of ASF in a sense that through the next gen through thinking about the next generation of ASF I have seen uh the future of Automation in the field of Android security where uh the the functionality of this framework can be increased by adding more scalability to this uh framework I'm currently developing the load B module which will

allow uh to to to run this test on large number of virtual device or physical devices the automated and custom signature generation can be easily achieved by creating all the feeds uh from various uh uh various uh security bulletins and we can actually create a realtime signature updates and such which will make user uh secure uh at any given time again there are times when I think about like having uh go through all these updates and uh updating my every single application if I'm if these updates are distinguished in a sense that if I know that hey there are some of the updates which are uh security uh which are the security fixes I might be

more focused uh on installing them U rather than worrying about some UI features being introduced in the fixes so these are the areas where uh uh I'm focusing on for further improvements and such uh there is lot more efforts need to be done in uh correlating all this data creating all these results and statistics through UI so it has better insight into what it's collecting to any uh uh any user and again uh this whole framework can be sitting in the cloud available for anybody to uh run a test um it seems bit ambitious in a sense that it will require a little bit of financial investment in infrastructure and such but to easily achieve this uh you can uh

uh create a central reposi somewhere on the internet where all the results are stored so maybe the functionality might not be available for you right away but you can just query all the results and uh see if you are happy with it if not then you you'll always have the framework on which you can run a test and uh there might be like some offline uh crowlers which will be uh looking for applications and we feed it to the ASF framework and it will collect all the data offline and it will have it ready way before uh you will actually um uh scan your uh application so you might have it might even have the results of

the application way before you have even given it to it so these are the type of areas where I'm trying to improve upon so what's the today's conclusion that ASF is an awesome framework and everybody should use it well not entirely uh today I told you the story of ASF and what it stands for uh well that's just the full form of it but I'm talking more about the the meaning behind it which actually comes from the the story that ASF has to tell uh when I was working on ACF what I realized is there is there is so much out there in the field of Android security to absorb process understand and interpret and uh the biggest

question at the end of the day was how how do I make sense of all these individual problems in much more comprehensive way and address them much more collectively on a larger scale and that's exactly where ASF comes in where uh uh I'm trying to take uh take things to the next level and provide a One-Stop solution for almost all of our security needs and when we get to that point this framework will still be called ASF but it will be Android security Evolution framework and I'm sure we'll definitely get to that point but by the time we get there feel free to use ASF here is the link where you can get the get the

code it's going open source today uh here is the blog where all the details are there about the design and all the uh all the stats and uh um how the how how ASF uh methodology and all so there is a white paper also present uh inside this short blog which you can go through it has more finer details of about ASF and you can follow me on Twitter uh or you can uh reach me at this email ID if you have more questions thank you everyone [Applause]