So on the previous lecture, we decompiled the APK file of the insecure bank application.
So that means in this section we will learn some approaches and the basics of analyzing an Android app
and what to look for in the source code.
So we'll start by analyzing the app's manifest Android manifest, not X amount.
So this is the binary form of the Android manifest on XML file.
Now, there is a decoded form of this file under the decoded resources.
And this file is an important part of the application because it provides data about the application
structure and metadata, so its components are here as well as the requirements.
Notice how it's segmented into different sections.
The first few lines will contain the different user permissions declared by the application.
These will always be variable and dependent on the app, but it's always good practice to make sure
the app isn't requesting more positions or permissions than it should have or or needs to use.
For example, we've seen many apps request location permissions without even having a feature that requires
the user location.
And of course, this usually ends up in some kind of user personal information being disclosed and in
most cases it's not even done intentionally by the developer.
To be honest, I'll show you some other important things to look out for in the manifest file are the
debugger bowl and the allowed back up flags.
So the first one refers to the app being in debug mode, meaning it's possible to attach a debugger
to the applications process and execute arbitrary code.
The second flag allowed back up defines whether application data can be backed up and restored by a
user who has enabled U.S. be debugging.
So this means that hackers connecting to a device via ADB can easily obtain any application data that
is stored on the device, including personal data on private storage.
As we look deeper into the insecure bank app, it has both of these flags enabled.
So the manifest may also include exported activities and content providers.
These allow external applications to access data in the application, which is why it's always important
to check for activities listed as true, because these can potentially leak user data to other applications.
These are the activities that are exportable.
Next thing you want to look for is hard coded credentials.
That is anything hard coded in an app such as passwords, username session, Tolkan, secret keys,
etc..
Attackers will often easily access this information, or at least they can here in this app, because
this is our example and it's designed to be vulnerable.
So, of course, it's no exception.
But I'll show you I'll search from all classes and I'll select strings as my search string type.
And first, let's search for password and username.
So by analyzing the source code, we can see the methods related to password and username, and that
way we'll get an idea.
How to bypass the login mechanism?
So now let's search for a secret, because it will likely reveal, well, secrets, but basically that
means sensitive values.
So we'll open this class.
Now, as you can see, it shows some valuable information here, including an initialization vector
for one of the utilized cryptography methods and the crypto key.
So if an application is importing Java, extract crypto cipher.
That indicates that the application will be performing some kind of cryptographic operation, right?
So you should also note that if you want to search a library, you should change the type of the search
string, otherwise you're not going to be able to find anything.
You can select X for this one.
Now, if we search the crypto library, the results are displayed here.
For example, by looking at the cyphers get instance function.
We can determine a cryptographic algorithm being used.
Now to find out if the application uses a secure connection on the Web, we can just search for SSL.
Now let's analyze Web views.
So Web views are an embeddable browser, so these browsers are embedded and that way native application
can use the embeddable browser to display Web content.
They might not be implemented in every application, but when they are, they certainly can provide
a risky attack vector.
And one of the important parameters to test on Web views is right in here, the clear cache method.
It clears the web, you caches from the client device so this can mitigate issues relating to sensitive
data stored on the local filesystem.