WEBVTT 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:29.820 MobSF supports both static and dynamic analysis. 00:29.820 --> 00:34.520 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:02.380 Let's take a look into the tool. 01:02.380 --> 01:09.040 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:20.440 Now you get a report that looks like this. 01:20.440 --> 01:29.040 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:45.480 So I'm taking this particular app. 01:45.640 --> 01:51.740 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:36.700 These are like the fundamental components of an Android application. 02:36.860 --> 02:40.160 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:03.720 So you need to be careful about that. 03:03.720 --> 03:08.660 This needs to be manually investigated and see if this is a possible security issue. 03:09.300 --> 03:16.000 Then comes the scan options, where you can actually do a rescan or you can perform dynamic analysis. 03:16.000 --> 03:17.440 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:29.040 So that's the decompiled Android manifest XML file. 03:29.260 --> 03:33.180 And then you can also go through the Java source code. 03:33.180 --> 03:35.500 The decompiled Java source code is listed. 03:35.500 --> 03:36.980 All the files are listed. 03:36.980 --> 03:41.720 If you want to search for something inside the file, you can find inside the file. 03:41.720 --> 03:45.720 Like in this case, the string SSL is present in these three different files. 03:46.280 --> 03:58.780 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:07.520 Similarly, you can even view the Smiley code corresponding to the binary. 04:07.520 --> 04:11.220 Mobisoft also convert the DEX code into Smiley. 04:11.220 --> 04:15.760 And if you're interested in looking into Smiley source code, you can look into this section. 04:15.920 --> 04:21.080 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:34.220 And then comes sign a certificate. 04:34.220 --> 04:48.000 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:06.220 So if it detects anything, it will actually show that in the certificate status section with a small description. 05:06.220 --> 05:12.440 So that's actually quite handy when you're analyzing production-ready Android applications. 05:13.820 --> 05:16.720 The next section will list out permissions. 05:16.720 --> 05:22.620 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:35.040 Then again, it strengthens the point of least privilege model. 05:35.040 --> 05:38.240 So you should always have an application with the least permissions. 05:38.240 --> 05:41.600 So use only the permissions that are actually required. 05:41.600 --> 05:46.060 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 --> 05:57.220 The reason why you see dangerous here is that this is one feature that can be abused. 05:57.220 --> 06:03.380 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:18.300 So some of the permissions are actually considered dangerous. 06:18.300 --> 06:20.920 It does not mean that the permission is dangerous. 06:20.920 --> 06:22.180 It depends upon the context. 06:22.180 --> 06:27.320 Like if it's a malicious app, then it might be a dangerous permission that the app is actually requesting. 06:27.320 --> 06:32.980 The next section is shared library binary analysis. 06:33.220 --> 06:47.040 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:50.800 So we do binary analysis on the shared objects. 06:50.800 --> 06:56.880 We check and see if there are some misconfigurations while it's actually being compiled or built. 06:57.320 --> 06:57.900 Things like that. 06:57.900 --> 07:03.600 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:44.120 The scheme is a good place to start fuzzing the application. 07:44.180 --> 07:48.040 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 --> 07:58.640 After that comes security analysis. 07:58.640 --> 08:08.840 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:16.900 And then moving on, you have the code analysis section. 08:16.900 --> 08:22.860 So this is a section where mobiles have performed a static analysis on all the decompiled Java files. 08:22.860 --> 08:26.100 And if it finds any issues, it will list out the issues. 08:26.200 --> 08:30.380 So it's not just issues, it will also list out informational issues. 08:30.380 --> 08:33.940 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 --> 08:56.820 After that you have the file analysis section. 08:56.820 --> 09:03.100 This section will actually list out all the sensitive files like certificates that are hard-coded in the application. 09:03.100 --> 09:10.240 It will also help you to identify any accidentally hard-coded certificates like private keys and things like that. 09:10.240 --> 09:12.370 So that's the file analysis section. 09:13.120 --> 09:16.060 After that we have malware analysis. 09:16.720 --> 09:20.060 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:49.960 And after that we have a section called domain malware check. 09:49.960 --> 09:59.760 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:18.140 And based on that you have a status that tells if this particular domain is good or bad. 10:18.140 --> 10:22.700 And we also do geolocation on all the domains that's available inside the app. 10:22.700 --> 10:29.460 So you can even plot that to Google Map to see what's the location of the particular IP address. 10:30.340 --> 10:34.060 Alright, now comes the reconnaissance section. 10:34.440 --> 10:40.260 Here, Mobilesoft will actually list out all the URLs extracted from the different source code files. 10:40.280 --> 10:48.200 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:03.160 And after that comes trackers. 11:03.160 --> 11:12.620 Trackers are possible SDKs or add-ons that actually do telemetry collection on the application's behalf. 11:12.620 --> 11:18.700 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:25.800 And there's a URL that actually explains what kind of trackers and some analytics with respect to the tracker. 11:25.860 --> 11:29.360 So that's also available from Mobilesoft. 11:32.420 --> 11:35.120 And finally, in this section, we have strings. 11:35.120 --> 11:42.000 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 --> 11:58.780 After that, we have the components, which is nothing but the different components of the application. 11:58.780 --> 12:06.140 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:15.580 And after that, you have the PDF report section. 12:15.580 --> 12:19.660 So this allows you to generate a nice and beautiful PDF report. 12:19.660 --> 12:23.920 So let me generate a PDF report. 12:23.920 --> 12:27.740 And that's the Mobilesoft Static Analysis PDF report. 12:27.740 --> 12:33.440 It gives a PDF report with high-level information about the different findings. 12:33.660 --> 12:42.600 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:06.000 It's up to you. 13:06.000 --> 13:08.380 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:51.860 So here, there's an option called Show Screen, which will cast the device screen to the web interface. 13:51.860 --> 13:55.720 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:27.780 And finally, you have a button called Generate Report. 15:27.780 --> 15:33.640 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:19.680 You can see the activity log in here. 16:19.760 --> 16:23.480 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:35.720 We have API monitoring script. 16:35.720 --> 16:39.360 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:47.960 Then there is a root detection bypass script. 16:47.960 --> 16:51.660 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:04.280 If you do not want any of them, you can uncheck them. 17:04.280 --> 17:07.360 Otherwise, you can have them by default. 17:08.720 --> 17:11.740 And after that comes the auxiliary section. 17:11.740 --> 17:13.280 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:34.300 If you look into the console, you can see the application has spawned. 17:34.300 --> 17:39.960 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:31.040 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. 19:31.040 --> 19:32.100 Quite useful. 19:32.220 --> 19:36.460 From the Dynamic Analyzer, you have access to Frida Code Editor. 19:36.500 --> 19:41.720 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:46.620 You also have a set of pre-built scripts that comes with MobileSub. 19:46.620 --> 19:48.300 These are some helper scripts. 19:48.380 --> 19:51.680 So if you want to load a script, you can click on that and click on Load. 19:51.680 --> 19:53.960 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:04.140 Now we will talk about auxiliary scripts. 20:04.140 --> 20:11.100 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:13.780 Let's start with Enamorate Loaded Classes. 20:13.780 --> 20:19.080 As the name suggests, it will enamorate all the classes loaded at runtime. 20:19.080 --> 20:21.440 So let's click on Start Instrumentation. 20:23.960 --> 20:25.780 Our app is loaded. 20:25.880 --> 20:31.740 Now if you look into Frida Livelogs, you can see the classes that are loaded at runtime. 20:31.740 --> 20:38.780 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:40.200 Okay. 20:40.200 --> 20:44.680 Similarly, there is another auxiliary script called Capture Strings. 20:44.680 --> 20:48.580 What it does is it tries to capture all the strings at runtime. 20:48.580 --> 20:50.680 So let me start instrumentation. 20:52.920 --> 20:54.680 My app is running. 20:54.680 --> 21:00.500 Let me go through different flows so that there are possible strings in here. 21:05.490 --> 21:06.730 Yep. 21:06.730 --> 21:09.630 Now let me look into the Frida Logs. 21:09.950 --> 21:15.940 And you'll see that there are a couple of strings being caught by this auxiliary script. 21:18.580 --> 21:20.650 Now let's see Capture String Comparison. 21:20.650 --> 21:26.910 So this is a useful auxiliary script that will capture all the string equal comparisons. 21:26.990 --> 21:29.070 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:50.380 Now if I click on Frida Livelogs, you can see all the string comparisons that happened at runtime. 21:50.400 --> 21:57.500 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:07.480 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. 22:07.480 --> 22:09.040 So it's quite useful. 22:09.160 --> 22:13.540 Now we have an auxiliary script called Enumerate Class Methods. 22:13.540 --> 22:16.460 Like the name suggests, it will enumerate all the methods of a class. 22:16.460 --> 22:22.460 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:36.330 And if you look at Frida Livelogs, you can see the different methods supported by the class. 22:36.330 --> 22:41.330 So it will get all the methods and implementations of the class java.io.file. 22:41.330 --> 22:50.190 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. 22:50.190 --> 22:56.970 So you can easily, you know, obtain all the methods and implementations of third-party classes. 22:58.450 --> 23:00.910 Now we have Search Class Pattern. 23:00.910 --> 23:06.850 So this feature allows you to search for a particular class at runtime using pattern. 23:06.950 --> 23:13.070 Like for example, you are actually analyzing an Android application and it has a custom SSL pinning code. 23:13.070 --> 23:18.610 And the default SSL pinning bypass that comes with mobile stuff is not detecting it. 23:18.610 --> 23:24.710 You might want to investigate and find out what is the custom code responsible for SSL pinning. 23:24.710 --> 23:28.230 So for that, you can use the class pattern search. 23:28.230 --> 23:32.150 Like you can search for class names that have SSL in it. 23:32.150 --> 23:34.910 So if I just instrument the app. 23:38.950 --> 23:44.270 And check the logs, I can see that pattern matches found. 23:44.270 --> 23:47.250 So these are the classes which are string SSL in it. 23:47.250 --> 23:52.570 So with this auxiliary script, you can easily find and filter out classes based on a particular pattern. 23:55.030 --> 23:58.790 And finally, we have something called Trace Class Methods. 23:58.790 --> 24:03.970 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:15.910 Similar to that of API monitor. 24:15.910 --> 24:25.030 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. 24:25.110 --> 24:26.430 Let's put a class. 24:26.430 --> 24:34.670 So let's use Java.lang.string 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 --> 25:02.220 And you can see that class tracing all the method implementation of Java.lang.string There was this method called hashCode. 25:02.220 --> 25:06.520 This was the argument and that's the return value. 25:07.440 --> 25:14.840 Similarly, it also called equals and that was the argument and that's the return value. 25:14.840 --> 25:17.460 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:11.380 And you have startHttpTools. 26:11.380 --> 26:12.880 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:28.320 You can see the raw HTTPS traffic. 26:28.320 --> 26:32.220 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:31.730 Also, I would like to thank all the major contributors who had helped us with the various product features, like Netguru team who helped us with the iOS SIFT support, Dominic, Amrita, Shanil, Maxim, Abhinav, Shuksan and Ekstaban. 30:32.150 --> 30:35.730 If you have any questions, you can contact me over email or Twitter. 30:35.730 --> 30:36.690 Thank you.