 Hi everyone, I'm Ajin Ubraham, a security researcher and creator of MobESF project. This talk is about MobESF, a free and open source tool that helps you to perform security assessment of your mobile applications. To get started with the project, follow the documentation links and also feel free to join our Slack channel for support. Use these Docker commands to get a quick instance of MobESF app and running. MobESF supports both static and dynamic analysis. Under static analysis, we support Android, iOS and Windows binaries. We also support SIFT source code, so we support Java and Kotlin for Android, and SIFT and Objective-C for iOS. For dynamic analysis, currently we only support Android binaries. You can perform dynamic analysis with a GiniMotion Android VM or an Android Studio emulator. MobESF also has REST APIs for your CICD or DevSecOps use cases. Let's take a look into the tool. In this demo, I'll be talking about static and dynamic analysis of Android applications with MobESF. So let's take MobESF and let's drag and drop an Android APK, so that's a binary. Now you get a report that looks like this. The scan time is directly proportional to the size of the binary, so the bigger the binary, the more the time it will take for the scan to finish. And if you go to the recent section, it will actually show you these files that you recently scanned. So let's do one thing. Let's take one of the files so that I can give you a walkthrough of static analysis. So I'm taking this particular app. Let's take that and let's take a look into the report. The static analyzer report have different sections, so we will go through each of them quickly. On the top, you have the information section where it will actually show you the app scores, the various app scores like average CVSs, the security score, the number of trackers identified from the app, etc. Then we have the file information section that shows the name of the file, the size, the basic hashes of the file. And the app information section shows different information about the app like the package name, the main activity, the version, so on and so forth. And after that, you have a section that will actually show you the activity, services, receivers and providers like the number of these components. These are like the fundamental components of an Android application. It will also list out what components are exported. When you talk about exported components, these are the components which can be invoked or called upon by a different app running inside the device. So if you look it from an application security perspective, there are certain cases when you do not want a third party application to access or invoke a particular activity or a service in your application. So you need to be careful about that. This needs to be manually investigated and see if this is a possible security issue. Then comes the scan options where you can actually do a rescan or you can perform dynamic analysis. We'll come to that later. Also, it shows you the decompiled code where it actually shows you the decompiled Android manifest file. So that's the decompiled Android manifest XML file. And then you can also go through the Java source code, the decompiled Java source code is listed. All the files are listed. If you want to search for something inside the file, you can find inside the file. Like in this case, the string is present in these three different files. Similarly, if you want to search for a particular filing, like if you want to search for activity, the files that contain the word activity, then you can search that here and it will list out all the files that contain the word activity. Similarly, you can even view the Smiley code corresponding to the binary. Mobeza also convert the DEX code into Smiley. And if you're interested in looking into Smiley source code, you can look into this section. Like Java source code, you can find inside the files or you can search for a specific file as well. And this section will also allow you to download the Java source code, the download the Smiley source code or even you can download the APK itself. And then comes signer certificate. So this section lists out the basic information about the code signing certificate, like the version of the signature, the hash algorithm used, the fingerprint, the issuer identification, so on and so forth. Also Mobeza does some checks on the signer certificate to see if there are any misconfigurations like whether the app is signed with the debug certificate or if it's actually using a weak hash algorithm, things like that. So if it detects anything, it will actually show that in the certificate status section with a small description. So that's actually quite handy when you're analyzing production ready Android applications. The next section will list out permissions. So you can see the table shows the permission that's used by the app status info and description. So this is something that you can actually use to check and verify that the permissions used by the applications are actually necessary. Then again, it strengthens the point of least privilege model. So you should always have an application with the least permissions. So use only the permission that are actually required, do not provide permissions that are not required by the application. Also, if you're not here, you can see the status as normal, dangerous and signature or system. The reason why you see dangerous here is that this is one feature that can be abused. Let's say this was a third party application, and you're doing a black box testing or you're doing a malware analysis, then this might be one permission that can be actually abused by the application like using the Bluetooth or like connecting to internet to exfiltrate data and things like that. So some of the permissions are actually considered dangerous. It does not mean that the permission is dangerous. It depends upon the context. Like if it's a malicious app, then it might be a dangerous permission that the app is actually requesting. Okay, the next section is shared library binary analysis. So what happens here is if your application is having any native code, for example, if you're using JNI and or you are using an SDK, which has a native code, then you will have shared objects. So we do binary analysis on the shared objects. We check and see if there are some misconfigurations while it's actually being compiled or built, things like that. So if you identify any security issues on the shared object, that will be listed under binary analysis. This section actually give you a quick idea about what this app is capable of doing from looking at the API that's actually being used. It's quite handy if you're doing malware analysis or you're doing, you know, black box pen testing on third party application, like it will give you an idea about what are the core functionalities of the app and then you can start your investigation from the critical API's. After that, you have the browsable activities. So this section lists out all the browsable activities like all the activities that can be browsed by a particular scheme. The scheme is a good place to start fussing the application. You can take out the scheme and then append the first string and perform fussing. So you can see how the application or the particular activities behaving with your fussing input. After that comes security analysis. In security analysis, we have manifest analysis where we actually perform a static analysis on the Android manifest files and pull out any insecure findings. So you can see the issue, the severity and the description corresponding to each issue. And then moving on, you have the code analysis section. So this is a section where mobiles have performed a static analysis on all the decompiled Java files. And if it finds any issues, it will list out the issues. So it's not just issues, it will also list out informational issues. It will also list out any good findings as well. So the table has the issue description, the severity, the CVSS score of the issue, the CW identifier and we also classify the different issue under OWASP top mobile risk. So you can see a classification identified corresponding to the issue and the files with the findings. After that, you have the file analysis section. This section will actually list out all the sensitive files like certificates that are hardcoded in the application. It will also help you to identify any accidentally hardcoded certificates like private keys and things like that. So that's the file analysis section. After that, we have malware analysis. Under that, we have APKID analysis. APKID looks into the DEX files and tells us the possible behavioral patterns like the kind of compiler being used if an obfuscator was used or just the DEX file has code that corresponds to anti-VM detection or anti-debugging checks, things like that. So it gives you a good idea about the behavior of the application from court perspective. And after that, we have a section called Domain Malware Check. So what it does is it actually extract out all the domains from the binary and check that against a non-list of rogue or bad domains or IPs. So we have a database of non-malware related IPs and domains and all the domains inside the binary is actually checked against those to see if it's actually present in that database. And based on that, you have a status that tells if that this particular domain is good or bad. And we also do geo-location on all the domains that's available inside the app. So you can even plot that to Google map to see what's the location of the particular IP address. All right, now comes the reconnaissance section. Here, mobile surf will actually start all the URLs extracted from the different source code files. Similarly, if your application is having Firebase database, mobile surf will also extract all the Firebase database URL from the app. It also performs an additional check to see if the database is exposed to the internet. And in the next section, emails mobile surf will extract out all the emails that it found from the source code. And after that comes trackers. Trackers are possible SDKs or add-ons that actually do telemetry collection on the application's behalf. Sometimes it can be a privacy concern. So it will start all the trackers that's used inside the app. And there's a URL that actually explains what kind of trackers and some analytics with respect to the tracker. So that's also available from mobile surf. And finally, in this section, we have strings. So this will actually start all the hard-coded strings in the binary, especially the ones from the string resource. So if there is any hard-coded sensitive API keys or any other secrets in the string section, that will be damped and shown over here. After that, we have the components, which is nothing but the different components of the application. It will list out all the activities, services, receivers, providers, and any libraries that's used by this particular application. Also, it will list out all the files inside the application binary. And after that, you have the PDF report section. So this allows you to generate a nice and beautiful PDF report. So let me generate the PDF report. And that's the Mobius of Static Analysis PDF report. It gives a PDF report with high-level information about the different findings. It's quite handy if you want to document your security analysis for audit or for getting mobile application security certifications, etc. So in order to start dynamic analysis, I can click on Start Dynamic Analysis from here, or I can actually perform dynamic analysis after static analysis. Like I can go to one of the static analysis report, and from there, if I go to the scan options, I can perform dynamic analysis from there as well. It's up to you. So I'm clicking Start Dynamic Analysis. And if I take the console, I can see that there are some operations happening like ADB restarted, waiting for two seconds, trying to connect to this device, so on and so forth. So Mobius will automatically prepare the environment, connect to the VM, and then install the APK so that we can perform dynamic analysis. So since I have used Android version 7.0, we are actually seeing a lot of options which are related with Frida. So here, there's an option called short screen, which will cast the device screen to the web interface. So if I enable that, I will be able to see my screen here. I can also do some basic operations like touches and clicks. Now you can remove the Mobius of root CA, which is responsible for intercepting the traffic from the device if you want to. So that will remove the root CA. And if you want to install that again, you can click on Install. The exported activity tester allows you to dynamically test for exported activities. This helps you to create proof of concepts dynamically, and you can verify your findings from static analysis. So I'm clicking Start exported activity tester. And if I take the VM, you can see that an activity is involved, then closed, another activity is involved, and closed. So what happens in the background is Mobius of will go through all the export activities, open them and take a screenshot of it and then store it for you. So that's useful for proof of concept generation. Similarly, if you want to brute force all the activities, you can perform start activity tester, which is a good way to brute force non exported activities forcefully. Also, you can take screenshots, like if you want to take screenshots of something, you can click on take screenshot, that will take a screenshot. Also, you can see the lock cat stream. So this is the Android lock cat stream from the device. So if you want to debug something, you can look here. And finally, you have a button called Generate Report. This is the option that tells Mobius of let's stop all the analysis and generate a report. You have to press that when you're done with your analysis. Now, talking about dynamic analysis, Mobius of does not provide an option for automated dynamic analysis, it only provides an interactive environment for semi automatic dynamic analysis. The reason being Mobius of does not know what the business logic of your application is, it does not know about the username, the password fields and how to fill them and what are the data it should provide. So in order to get the most out of Mobius of dynamic analysis, you need to manually go through the different business logic and flows of the application. And in the background, Mobius of will perform security analysis on these different flows. You can see the activity log in here. Also, if there is any errors, that will be listed under the Erase tab. Now below that there is some Frida scripts related option. You will see a default section which will actually show you the default Frida scripts that are loaded with Mobius of. We have API monitoring script. This script will monitor all the critical APIs at runtime. We have the SSL pending bypass script, which is responsible for bypassing SSL pending. Then there is a root detection bypass script. If your application is performing root detection, it will bypass that. Similarly, it will also bypass debugger checks using the debugger check bypass script. So these are some useful default scripts that loads with Mobius of by default. If you do not want any of them, you can inject them. Otherwise, you can have them by default. And after that comes the auxiliary section will come to that later. So in order to start dynamic analysis, the first thing that you need to do is start instrumentation. So if you click on start instrumentation, you can see that your application will get loaded here and it will be instrumented by Mobius of. If you look into the console, you can see the application has spawned. We can see couple of Frida script being loaded and some messages that are coming from the Frida scripts. So once you instrument the app with Frida, in order to see the output generated by these scripts, you can look into the console or the best place to look into is Frida live logs. So Frida live logs will show all the output from the different Frida scripts. So if you're running a custom Frida script or if you're writing a custom Frida script, and if you want to see the output, this is the place that you need to look into. Once you click on start instrumentation, you should be navigating through the different flows of the app. I'm actually going through the different flows of the app so that mobile stuff can actually perform security analysis in the background. Now you can see that I've done some operations in here. Okay, so one another thing that I wanted to show is that if you scroll up, you'll see a new field called live API monitor. So this button will be enabled only if you instrument the app. So once you instrument the app, you can see the live API monitor, which will capture all the API calls that are happening at runtime. Once inside the API monitor, you can see the API name, the class, the method that was called at runtime, the arguments passed to the method, the result, if there was any, the return value, if the method returns a value, and then called from, which actually shows from where that method was actually called. So this method was called from base64.java at line number 494. This is a helpful feature that allows you to identify the API calls which are made at runtime, what are the arguments being passed, from where are they being getting called, things like that. Quite useful. From the dynamic analyzer, you have access to Frida coordinator. So if you want to write custom Frida script, you can write in here and you can just click on start instrumentation. You also have a set of pre-built scripts that comes with mobile stuff. These are some helper scripts. So if you want to load a script, you can click on that and click on load that will load the script condensing here. And once you have the condensing here, you can just click on start instrumentation, and that will instrument the app and load it with your custom script. Now we will talk about auxiliary scripts. So these are some very useful scripts that you can use while you're performing dynamic analysis of an Android application. Let's start with enumerate loaded classes. As the name suggests, it will enumerate all the classes loaded at runtime. So let's click on start instrumentation. Our app is loaded. Now if you look into Frida live logs, you can see the classes that are loaded at runtime. So if you need to understand what are the classes loaded by the application at runtime, you can make use of this auxiliary script. Okay, similarly, there is another auxiliary script called capture strings. What it does is it tried to capture all the strings at runtime. So let me start instrumentation. My app is running. Let me go through different flows so that there are possible strings in here. Now let me look into the Frida logs. And you'll see that there are a couple of strings being caught by this auxiliary script. Now let's see capture string comparison. So this is a useful auxiliary script that will capture all the string equal comparisons. Let's instrument the app. Then let's go through some flows hoping that there are some string comparisons happening. Now if I click on Frida live logs, you can see all the string comparisons that happened at runtime. Like that's the first argument, that's the second argument and the comparison returns false because they are not equal. So this is also one quite handy feature when you're playing CTFs where you actually want to capture the flag where the flag is actually getting combined with user input and things like that. So it's quite useful. Now we have an auxiliary script called enumerate class methods, like the name suggests it will enumerate all the methods of a class. For example, if you have a class and you want to know what are the methods supported, you can give that here file. And then let's click on start instrumentation. And if you look at Frida live logs, you can see the different methods supported by the class. So it will get all the methods and implementations of the class Java dot IO dot file. Again, this is actually quite handy if you're trying to dig into third party classes where you do not have documentation available on what are the methods available. So you can easily, you know, obtain all the methods and implementations of third party classes. Now we have search class pattern. So this feature allows you to search for a particular class at runtime using pattern. Like for example, you are actually analyzing an Android application and it has a custom SSL pending code. And the default SSL pending bypass that comes with mobile surface not detecting it, you might want to investigate and find out what is the custom code responsible for SSL pinning. So for that, you can use the class pattern search like you can search for class names that have SSL in it. So if I just instrument the app and check the logs, I can see that pattern matches found. So these are the classes which are string SSL in it. So with this auxiliary script, you can easily find and filter out classes based on a particular pattern. And finally, we have something called trace class methods. This is another useful and handy feature that allows you to trace class methods. Like for example, you if you have a class and if you want to see what are the methods of the class that are invoked at runtime, what are the arguments passed, what's written value, similar to that of API monitor. But if you want to do that on a custom method, you can actually provide the class name here so that it will trace all the class methods. Let's put a class. So let's use Java dot lang dot string. And then let's instrument the class. Let's try to go through one of the flow. Let's look into the Frida live logs. And you can see that class tracing all the method implementation of Java dot lang dot string. There was this method called hash code. This was the argument. And that's the return value. Similarly, it also called equals. And that was the argument. And that's the return value. And you can see other methods in this particular class. And this helps you to isolate monitoring to a particular class, like what are the methods of a particular class that are being called at runtime, what are the arguments being passed, what's the return value, and things like that. Now that you have explored most of the features of dynamic analyzer, let's see how we can generate a report. For that, click on generate report. So this is a report generated after dynamic analysis of an Android application. Here under information section, we have API monitor view. You can see all the APIs that were captured at runtime, their arguments, return value, the color function, etc. And you also have Frida logs view, which will show all the Frida logs. And you have start HTTP tools. We'll come to that later. You can also see the raw Frida API monitor logs. That's a JSON log. Similarly, you can see the raw Frida logs. You can see the raw HTTP traffic. So if there was any HTTP traffic, that will be shown here. Since there was no traffic generator, there is nothing in here. Again, locad loads, the dumpsys loads, and the application data. So if you click on that, it will ask you to download a file. And that file consists of the application data. That's the data that is created by the application inside the device. And then we have the Frida API monitor, where we will list out the different critical APIs or methods that were called at runtime. We have the class name, the method, the arguments, the color activity, etc. So this is more of a nice representation of what you have seen in API monitor view already. And then you have the results from exported activity tester. So if you run the exported activity tester, that will invoke all the exported activities, take a screenshot of that. So this is something that you can use in your proof of concept. In this particular case, you can see that this particular exported activity has some sensitive information. Also, if you have run activity tester, you'll see similar results in here. And if you have taken any screenshot that will be shown here. And then we have malware analysis, which has domain malware check. So these are the domains which are captured at runtime. And then there is clipboard dump. So if the application copy anything to the clipboard, that will be shown here. So we dump the device clipboard. Similarly, all the URLs, emails, and then we have file analysis. Here it will list out all the SQLite database created by the application inside the device. You can go through the database and it will dump the contents of the database. Similarly, you can read the XML files or the shared preference files created by the application inside the device. And there are other files as well. And finally, you can download or print the report. So that's a walkthrough of different sections of Android dynamic analysis report. You can use HTTP tools. Let's click on start HTTP tools. Now you can see that all the capture traffic is actually visualized here. So you can see the request response pair. Now if you want to repeat this request to a specialized security tool like Burbsuit, you can use the send to first adoption. So before doing that, let's run Burbsuit. Let's go to the proxy tab. And then obtain the proxy IP and port. So the proxy is on localhost 8080. So before repeating the traffic, just make sure that your proxy tool is not on intercepting mode. Let's go to intercept tab and turn off intercept. Now, if I click on send to first, it will show this model with a field to enter the proxy IP and port. So in our case, the proxy IP is localhost 8080. So let's click on repeat request. So that will repeat the request. You can see the progress in the console. So you can see that couple of requests are repeated here. And if you go to the proxy, you can see that the requests are populated over here. And from here, you can use the specialized tool like Burbsuit to perform web application or API specific security test. I would like to give a shout out to our active collaborators, Magafi, Metin and Vincent. Also, I would like to thank all the major contributors who had helped us with the various product features like net guru team who helped us with iOS SIF support, Dominic, Amrita, Chanel, Maxime, Abhinav Shaksen and XTaban. If you have any questions, you can contact me or email or Twitter. Thank you.