[00:00.000 --> 00:05.000]  Hi everyone, I'm Ajin Abraham, a security researcher and creator of MobSF Project.
[00:05.040 --> 00:12.260]  This talk is about MobSF, a free and open source tool that helps you to perform security assessment of your mobile applications.
[00:12.280 --> 00:19.320]  To get started with the project, follow the documentation links and also feel free to join our Slack channel for support.
[00:19.840 --> 00:24.380]  Use these Docker commands to get a quick instance of MobSF up and running.
[00:25.980 --> 00:34.520]  MobSF supports both static and dynamic analysis. Under static analysis, we support Android, iOS and Windows binaries.
[00:34.520 --> 00:42.480]  We also support SIFT source code, so we support Java and Kotlin for Android and SIFT and Objective-C for iOS.
[00:42.640 --> 00:46.640]  For dynamic analysis, currently we only support Android binaries.
[00:46.640 --> 00:53.160]  You can perform dynamic analysis with a Genymotion Android VM or an Android Studio emulator.
[00:54.140 --> 00:59.960]  MobSF also has REST APIs for your CICD or DevSecOps use cases.
[01:00.320 --> 01:09.040]  Let's take a look into the tool. In this demo, I'll be talking about static and dynamic analysis of Android applications with MobSF.
[01:10.180 --> 01:18.060]  So let's take MobSF and let's drag and drop an Android APK, so that's a binary.
[01:18.060 --> 01:29.040]  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 time it will take for the scan to finish.
[01:30.360 --> 01:36.000]  And if you go to the recent section, it will actually show you the files that you have recently scanned.
[01:36.380 --> 01:42.780]  So let's do one thing, let's take one of the files so that I can give you a walkthrough of static analysis.
[01:42.780 --> 01:51.740]  So I'm taking this particular app. Let's take that and let's take a look into the report.
[01:52.480 --> 01:57.540]  The static analyzer report have different sections, so we will go through each of them quickly.
[01:57.860 --> 02:08.440]  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.
[02:08.440 --> 02:14.560]  Then we have the file information section that shows the name of the file, the size, the basic hashes of the file.
[02:14.780 --> 02:24.260]  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.
[02:24.380 --> 02:33.160]  And after that, you have a section that will actually show you the activities, services, receivers and providers, like the number of these components.
[02:33.160 --> 02:40.160]  These are like the fundamental components of an Android application. It will also list out what components are exported.
[02:40.400 --> 02:49.660]  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.
[02:50.140 --> 03:01.460]  So if you look at 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.
[03:01.460 --> 03:08.660]  So you need to be careful about that. This needs to be manually investigated and see if this is a possible security issue.
[03:09.300 --> 03:17.440]  Then comes the scan options, where you can actually do a rescan or you can perform dynamic analysis. We'll come to that later.
[03:17.580 --> 03:24.540]  Also, it shows you the decompiled code, where it actually shows you the decompiled Android manifest file.
[03:24.540 --> 03:41.720]  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.
[03:41.720 --> 03:58.780]  Like in this case, the string SSL is present in these three different files. Similarly, if you want to search for a particular file name, 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.
[04:01.660 --> 04:21.080]  Similarly, you can even view the Smiley code corresponding to the binary. Mobisoft 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.
[04:22.060 --> 04:30.920]  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.
[04:31.240 --> 04:48.000]  And then comes sign a 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.
[04:48.000 --> 05:00.060]  Also, Mobisoft does some checks on the signer certificate to see if there are any misconfigurations, like whether the app is signed with a debug certificate or if it's actually using a weak hash algorithm, things like that.
[05:00.060 --> 05:12.440]  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.
[05:13.820 --> 05:22.620]  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.
[05:22.720 --> 05:30.320]  So this is something that you can actually use to check and verify that the permissions used by the applications are actually necessary.
[05:30.320 --> 05:46.060]  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 permissions that are actually required. Do not provide permissions that are not required by the application.
[05:46.240 --> 05:51.740]  Also, if you note here, you can see the status as normal, dangerous, and signature or system.
[05:51.740 --> 06:03.380]  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.
[06:03.380 --> 06:15.220]  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.
[06:15.220 --> 06:27.320]  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.
[06:27.320 --> 06:47.040]  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 or you're using an SDK which has a native code, then you will have shared objects.
[06:47.140 --> 06:56.880]  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.
[06:57.320 --> 07:03.600]  Things like that. So if you identify any security issues on the shared object that will be listed under binary analysis.
[07:05.460 --> 07:12.880]  This section actually give you a quick idea about what this app is capable of doing from looking at the APIs that's actually being used.
[07:12.880 --> 07:27.020]  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 APIs.
[07:28.520 --> 07:31.300]  After that you have the browsable activities.
[07:31.760 --> 07:39.660]  So this section lists out all the browsable activities like all the activities that can be browsed by a particular scheme.
[07:39.960 --> 07:48.040]  The scheme is a good place to start fuzzing the application. You can take out the scheme and then append the first string and perform fuzzing.
[07:48.040 --> 07:54.700]  So you can see how the application or the particular activities behaving with your fuzzing input.
[07:56.080 --> 08:08.840]  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.
[08:08.840 --> 08:13.500]  So you can see the issue, the severity and the description corresponding to each issue.
[08:14.160 --> 08:22.860]  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.
[08:22.860 --> 08:33.940]  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.
[08:33.940 --> 08:47.660]  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.
[08:47.660 --> 08:54.280]  So you can see a classification identified corresponding to the issue and the files with the findings.
[08:54.380 --> 09:03.100]  After that you have the file analysis section. This section will actually list out all the sensitive files like certificates that are hard-coded in the application.
[09:03.100 --> 09:12.370]  It will also help you to identify any accidentally hard-coded certificates like private keys and things like that. So that's the file analysis section.
[09:13.120 --> 09:20.060]  After that we have malware analysis. Under that we have APK ID analysis.
[09:20.060 --> 09:39.380]  APK ID 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 does the DEX file has code that corresponds to anti-VM detection or anti-debugging checks, things like that.
[09:39.380 --> 09:45.500]  So it gives you a good idea about the behavior of the application from code perspective.
[09:46.260 --> 09:59.760]  And after that we have a section called domain malware check. So what it does is it actually extracts out all the domains from the binary and checks that against a non-list of rogue or bad domains or IPs.
[09:59.760 --> 10:12.580]  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.
[10:12.580 --> 10:29.460]  And based on that you have a status that tells if this particular domain is good or bad. And we also do geolocation 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.
[10:30.340 --> 10:48.200]  Alright, now comes the reconnaissance section. Here, Mobilesoft will actually list out all the URLs extracted from the different source code files. Similarly, if your application is having Firebase database, Mobilesoft will also extract all the Firebase database URL from the app.
[10:48.200 --> 10:52.840]  It also performs an additional check to see if the database is exposed to the internet.
[10:52.840 --> 11:00.960]  And in the next section, Emails, Mobilesoft will extract out all the emails that it found from the source code.
[11:00.960 --> 11:18.700]  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 list out all the trackers that's used inside the app.
[11:18.740 --> 11:29.360]  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 Mobilesoft.
[11:32.420 --> 11:42.000]  And finally, in this section, we have strings. So this will actually list out all the hard-coded strings in the binary, especially the ones from the string resource.
[11:42.000 --> 11:52.240]  So if there is any hard-coded sensitive API keys or any other secrets in the string section, that will be dumped and shown over here.
[11:52.240 --> 12:06.140]  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.
[12:07.200 --> 12:11.740]  Also, it will list out all the files inside the application binary.
[12:12.420 --> 12:19.660]  And after that, you have the PDF report section. So this allows you to generate a nice and beautiful PDF report.
[12:19.660 --> 12:27.740]  So let me generate a PDF report. And that's the Mobilesoft Static Analysis PDF report.
[12:27.740 --> 12:42.600]  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.
[12:44.680 --> 12:54.740]  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.
[12:54.740 --> 13:04.600]  Like, I can go to one of the Static Analysis reports, and from there, if I go to the Scan Options, I can perform Dynamic Analysis from there as well.
[13:04.600 --> 13:08.380]  It's up to you. So I'm clicking Start Dynamic Analysis.
[13:09.860 --> 13:22.900]  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.
[13:23.920 --> 13:32.840]  So Mobilesoft will automatically prepare the environment, connect to the VM, and then install the APK so that we can perform Dynamic Analysis.
[13:32.840 --> 13:42.680]  So since I have used Android version 7.0, we are actually seeing a lot of options which are related with Frida.
[13:43.480 --> 13:55.720]  So here, there's an option called Show 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.
[13:55.720 --> 14:00.300]  I can also do some basic operations like touches and clicks.
[14:04.860 --> 14:12.800]  Now you can remove the Mobilesoft Root CA, which is responsible for intercepting the traffic from the device if you want to.
[14:12.800 --> 14:18.120]  So that will remove the Root CA, and if you want to install that again, you can click on Install.
[14:19.040 --> 14:24.620]  The Exported Activity Tester allows you to dynamically test for exported activities.
[14:24.620 --> 14:31.720]  This helps you to create proof-of-concepts dynamically, and you can verify your findings from Static Analysis.
[14:31.720 --> 14:43.600]  So I'm clicking Start Exported Activity Tester, and if I take the VM, you can see that an activity is invoked, then closed, another activity is invoked, and closed.
[14:43.600 --> 14:51.880]  So what happens in the background is Mobilesoft will go through all the exported activities, open them, and take a screenshot of it, and then store it for you.
[14:52.000 --> 14:55.080]  So that's useful for proof-of-concept generation.
[14:55.080 --> 15:06.260]  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.
[15:07.300 --> 15:15.000]  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.
[15:16.580 --> 15:25.320]  Also, you can see the Logcat stream, so this is the Android Logcat stream from the device, so if you want to debug something, you can look here.
[15:25.380 --> 15:33.640]  And finally, you have a button called Generate Report. This is the option that tells Mobilesoft, let's stop all the analysis and generate a report.
[15:33.960 --> 15:37.100]  You have to press that when you're done with your analysis.
[15:37.100 --> 15:43.840]  Now, talking about dynamic analysis, Mobilesoft does not provide an option for automated dynamic analysis.
[15:43.840 --> 15:49.480]  It only provides an interactive environment for semi-automatic dynamic analysis.
[15:49.880 --> 15:55.140]  The reason being, Mobilesoft does not know what the business logic of your application is.
[15:55.140 --> 16:02.060]  It does not know about the username, the password fields, and how to fill them, and what other data it should provide.
[16:02.060 --> 16:11.500]  So in order to get the most out of Mobilesoft dynamic analysis, you need to manually go through the different business logic and flaws of the application.
[16:11.700 --> 16:17.280]  And in the background, Mobilesoft will perform security analysis on these different flaws.
[16:17.280 --> 16:23.480]  You can see the activity log in here. Also, if there is any errors, that will be listed under the Errors tab.
[16:24.500 --> 16:28.280]  Now below that, there is some Frida scripts related option.
[16:28.280 --> 16:34.020]  You will see a default section, which will actually show you the default Frida scripts that are loaded with Mobilesoft.
[16:34.020 --> 16:39.360]  We have API monitoring script. This script will monitor all the critical APIs at runtime.
[16:39.360 --> 16:45.060]  We have the SSL pinning bypass script, which is responsible for bypassing SSL pinning.
[16:45.380 --> 16:51.660]  Then there is a root detection bypass script. If your application is performing root detection, it will bypass that.
[16:51.660 --> 16:56.700]  Similarly, it will also bypass debugger checks using the debugger check bypass script.
[16:56.700 --> 17:01.980]  So these are some useful default scripts that loads with Mobilesoft by default.
[17:01.980 --> 17:07.360]  If you do not want any of them, you can uncheck them. Otherwise, you can have them by default.
[17:08.720 --> 17:13.280]  And after that comes the auxiliary section. We'll come to that later.
[17:13.480 --> 17:21.640]  So in order to start dynamic analysis, the first thing that you need to do is start instrumentation.
[17:21.640 --> 17:28.540]  You can see that your application will get loaded here and it will be instrumented by Mobilesoft.
[17:28.540 --> 17:39.960]  If you look into the console, you can see the application has spawned. We can see a couple of Frida scripts being loaded and some messages that are coming from the Frida scripts.
[17:40.720 --> 17:51.360]  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.
[17:51.640 --> 17:55.880]  Frida Live Logs will show all the output from the different Frida scripts.
[17:56.160 --> 18:03.660]  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.
[18:04.640 --> 18:09.720]  Once you click on Start Instrumentation, you should be navigating through the different floors of the app.
[18:09.840 --> 18:15.900]  I'm actually going through the different floors of the app so that Mobilesoft can actually perform security analysis in the background.
[18:27.780 --> 18:30.820]  Now you can see that I've done some operations in here.
[18:30.820 --> 18:38.360]  Okay, so one another thing that I want to show is that if you scroll up, you'll see a new field called Live API Monitor.
[18:38.420 --> 18:43.180]  So this button will be enabled only if you instrument the app.
[18:43.180 --> 18:51.460]  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.
[18:51.460 --> 19:15.120]  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.
[19:15.120 --> 19:20.660]  So this method was called from base64.java at line number 494.
[19:20.660 --> 19:32.100]  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.
[19:32.220 --> 19:41.720]  From the Dynamic Analyzer, you have access to Frida Code Editor. So if you want to write custom Frida scripts, you can write in here and you can just click on Start Instrumentation.
[19:41.720 --> 19:53.960]  You also have a set of pre-built scripts that comes with MobileSub. 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 contents in here.
[19:53.960 --> 20:01.380]  And once you have the contents in here, you can just click on Start Instrumentation, and that will instrument the app and load it with your custom script.
[20:02.060 --> 20:11.100]  Now we will talk about auxiliary scripts. So these are some very useful scripts that you can use while you are performing dynamic analysis of an Android application.
[20:11.100 --> 20:21.440]  Let's start with Enamorate Loaded Classes. As the name suggests, it will enamorate all the classes loaded at runtime. So let's click on Start Instrumentation.
[20:23.960 --> 20:38.780]  Our app is loaded. Now if you look into Frida Livelogs, 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.
[20:39.660 --> 20:50.680]  Okay. Similarly, there is another auxiliary script called Capture Strings. What it does is it tries to capture all the strings at runtime. So let me start instrumentation.
[20:52.920 --> 21:00.500]  My app is running. Let me go through different flows so that there are possible strings in here.
[21:05.490 --> 21:15.940]  Yep. 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.
[21:18.580 --> 21:29.070]  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.
[21:33.600 --> 21:39.840]  Then let's go through some flows, hoping that there are some string comparisons happening.
[21:42.320 --> 21:57.500]  Now if I click on Frida Livelogs, 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.
[21:57.500 --> 22:09.040]  So this is also one quite handy feature when you are playing CTFs where you actually want to capture the flag, where the flag is actually getting compared with the user input and things like that. So it's quite useful.
[22:09.160 --> 22:22.460]  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.
[22:23.440 --> 22:26.700]  And then let's click on Start Instrumentation.
[22:29.610 --> 22:41.330]  And if you look at Frida Livelogs, you can see the different methods supported by the class. So it will get all the methods and implementations of the class java.io.file.
[22:41.330 --> 22:56.970]  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.
[22:58.450 --> 23:13.070]  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 pinning code.
[23:13.070 --> 23:24.710]  And the default SSL pinning bypass that comes with mobile stuff is not detecting it. You might want to investigate and find out what is the custom code responsible for SSL pinning.
[23:24.710 --> 23:34.910]  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.
[23:38.950 --> 23:52.570]  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.
[23:55.030 --> 24:03.970]  And finally, we have something called Trace Class Methods. This is another useful and handy feature that allows you to trace class methods.
[24:03.970 --> 24:13.610]  Like for example, 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 the return value.
[24:13.610 --> 24:20.250]  Similar to that of API monitor. But if you want to do that on a custom method, you can actually provide
[24:20.990 --> 24:29.830]  The class name here so that it will trace all the class methods. Let's put a class. So let's use Java.lang.string
[24:31.050 --> 24:34.670]  And then let's instrument the class.
[24:41.520 --> 24:44.540]  Let's try to go through one of the flow.
[24:49.680 --> 24:52.480]  Let's look into the Frida Live logs.
[24:53.260 --> 24:57.780]  And you can see that class tracing all the method implementation of Java.lang.string
[24:59.160 --> 25:06.520]  There was this method called hashCode. This was the argument and that's the return value.
[25:07.440 --> 25:17.460]  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.
[25:17.460 --> 25:25.700]  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.
[25:26.180 --> 25:30.580]  What are the arguments being passed, what's the return value and things like that.
[25:30.580 --> 25:36.940]  Now that you have explored most of the features of Dynamic Analyzer, let's see how we can generate a report.
[25:36.940 --> 25:39.800]  For that, click on generate report.
[25:43.520 --> 25:49.280]  So this is a report generated after dynamic analysis of an Android application.
[25:49.280 --> 25:53.180]  Here under information section, we have API monitor view.
[25:53.340 --> 26:00.400]  You can see all the APIs that were captured at runtime, their arguments, return value, the caller function, etc.
[26:02.160 --> 26:06.720]  And you also have Frida logs view, which will show all the Frida logs.
[26:08.960 --> 26:12.880]  And you have startHttpTools. We'll come to that later.
[26:12.880 --> 26:17.880]  You can also see the raw Frida API monitor logs.
[26:18.140 --> 26:20.220]  That's a JSON log.
[26:21.080 --> 26:24.360]  Similarly, you can see the raw Frida logs.
[26:26.200 --> 26:32.220]  You can see the raw HTTPS traffic. So if there was any HTTPS traffic, that will be shown here.
[26:32.220 --> 26:35.780]  Since there was no traffic generated, there is nothing in here.
[26:36.300 --> 26:38.740]  Again, logcat logs.
[26:40.120 --> 26:42.300]  The dumpsys logs.
[26:43.040 --> 26:44.840]  And the application data.
[26:44.840 --> 26:47.740]  So if you click on that, it will ask you to download a file.
[26:47.740 --> 26:51.080]  And that file consists of the application data.
[26:51.080 --> 26:55.160]  That's the data that is created by the application inside the device.
[26:55.700 --> 27:06.280]  And then we have the Frida API monitor, where we will list out the different critical APIs or methods that were called at runtime.
[27:06.540 --> 27:11.240]  We have the class name, the method, the arguments, the caller activity, etc.
[27:11.240 --> 27:16.660]  So this is more of a nice representation of what you have seen in API monitor view already.
[27:17.000 --> 27:19.520]  And then you have the results from exported activity tester.
[27:19.520 --> 27:24.120]  So if you run the exported activity tester, that will invoke all the exported activities.
[27:24.120 --> 27:25.680]  Take a screenshot of that.
[27:25.680 --> 27:28.840]  So this is something that you can use in your proof of concept.
[27:28.840 --> 27:34.220]  In this particular case, you can see that this particular exported activity has some sensitive information.
[27:34.600 --> 27:39.140]  Also, if you have run activity tester, you will see similar results in here.
[27:39.140 --> 27:43.280]  And if you have taken any screenshot, that will be shown here.
[27:43.680 --> 27:47.600]  And then we have malware analysis, which has domain malware check.
[27:47.600 --> 27:50.260]  So these are the domains which were captured at runtime.
[27:50.800 --> 27:52.700]  And then there is clipboard dump.
[27:52.700 --> 27:57.160]  So if the application copies anything to the clipboard, that will be shown here.
[27:57.160 --> 27:59.960]  So we dump the device clipboard.
[28:00.500 --> 28:03.640]  Similarly, all the URLs, emails.
[28:03.920 --> 28:06.080]  And then we have file analysis.
[28:06.080 --> 28:10.860]  Here it will list out all the SQLite database created by the application inside the device.
[28:11.000 --> 28:16.420]  You can go through the database and it will dump the contents of the database.
[28:19.660 --> 28:26.260]  Similarly, you can read the XML files or the shared preference files created by the application inside the device.
[28:29.340 --> 28:31.740]  And there are other files as well.
[28:31.880 --> 28:34.140]  And finally, you can download or print the report.
[28:34.140 --> 28:38.640]  So that's a walkthrough of different sections of Android dynamic analysis report.
[28:43.830 --> 28:46.290]  And finally, you can use HTTP tools.
[28:46.290 --> 28:48.470]  Let's click on start HTTP tools.
[28:50.310 --> 28:54.270]  Now you can see that all the captured traffic is actually visualized here.
[28:54.270 --> 28:56.430]  So you can see the request response pair.
[28:56.430 --> 29:03.590]  Now if you want to repeat this request to a specialized security tool like Burpsuite, you can use the send to fuzzer option.
[29:03.890 --> 29:06.430]  So before doing that, let's run Burpsuite.
[29:13.810 --> 29:15.850]  Let's go to the proxy tab.
[29:16.030 --> 29:19.090]  And then obtain the proxy IP and port.
[29:19.090 --> 29:22.210]  So the proxy is on localhost 8080.
[29:22.570 --> 29:28.670]  So before repeating the traffic, just make sure that your proxy tool is not on intercepting mode.
[29:28.690 --> 29:32.110]  So let's go to intercept tab and turn off intercept.
[29:32.470 --> 29:41.530]  Now if I click on send to fuzzer, it will show this model with a field to enter the proxy IP and port.
[29:41.570 --> 29:45.570]  So in our case, the proxy IP is localhost 8080.
[29:45.750 --> 29:48.450]  So let's click on repeat request.
[29:49.470 --> 29:51.910]  So that will repeat the request.
[29:51.910 --> 29:54.110]  You can see the progress in the console.
[29:54.110 --> 29:57.550]  So you can see that a couple of requests are repeated here.
[29:57.550 --> 30:02.490]  And if you go to the proxy, you can see that the requests are populated over here.
[30:02.490 --> 30:10.150]  And from here, you can use the specialized tool like Burpsuite to perform web application or API specific security tests.
[30:10.370 --> 30:16.410]  I would like to give a shout out to our active collaborators, Maghafi, Mattan and Vincent.
[30:16.410 --> 30:22.630]  Also, I would like to thank all the major contributors who had helped us with the various product features,
[30:22.990 --> 30:31.730]  like Netguru team who helped us with the iOS SIFT support, Dominic, Amrita, Shanil, Maxim, Abhinav, Shuksan and Ekstaban.
[30:32.150 --> 30:36.690]  If you have any questions, you can contact me over email or Twitter. Thank you.