Another coming class of security vulnerabilities on Android applications.
Are known as hard coding issues with hard coding issues.
They're mostly the the active hard coding information into our source code that is potentially exposing
information about how the application runs or maybe exposing something like a username or password or
some sort of sensitive data.
It's going to take a look at two types of hard coding issues in this video.
The first one is sort of the classic hard coding issue where we've hardcoded a password into some java
file and since we compile it WE FIGURE KNOWN it's going to be able to decode pile it and be able to
get to that password.
However that's not the case as we can see through these compiling and then the other one we'll be a
little bit more complex which will involve actually shared libraries and shared objects and discussing
how we can potentially extract passwords from those as well.
So you'll see in this we need to enter in some sort of vendor key in order to access this this section.
So if we try to access it we'll say access denied if we enter the wrong values.
So in order to extract the password for this we need to find first the activity that corresponds to
this log in page.
And in this case it would be hard code activity.
Now a lot of the times it might not be named exactly like this.
It might not be as easy to find the activity if you need to try to find this as well you can also take
a look at the log messages or the the displayed messages in the alerts.
So as you can see this one has that same access denied message.
So we know that we're probably in the right place now looking at this code we can see that we're taking
a look at the the each C key text field we're getting the text and rechecking if the string equals vendor
secret key says you can see we've hardcoded in the password and this means that it's very easy for someone
to D compile this application and figure out the password for this.
So now from here we can just type in vendor secret key and press access and as you can see access granted
in this case.
So this is one type of very common hardcoded activity problem where we heard code a password in plain
text rather than doing something like obscuring it or encrypting it or hashing it or you know putting
it on a server or something like that.
There's a whole lot of different things that we could be doing that aren't.
This primarily we would be wanting to potentially like hash the password in order to protect it.
But even then someone could get the hashed password and try to brute force it with like an off line
attack.
So that's not really the best way to do it.
Typically what we'd want to do here is sort of verify on server side or place it somewhere that someone
wouldn't be able to access it if they did compiler application.
So be the key idea.
So let's go ahead and discuss the other type of heart coding issue and this one is relatively similar
again we have to enter in a password if we get the wrong password it will give us the access denied
message that if we enter in the correct password let's say access granted when we look at the hard coded
activity which is hard code to activity you'll see that things are slightly different here.
You see it's grabbing D J and I got access.
So this is this is a method from the DIY are the D.J. and I object which is this one here.
So what we're going to do is we want to find this class to determine what the access method is actually
doing.
So if I go into this class here which I have here diva J and I you'll see that there's a static load
that happens so it's a learning a shared library and the S.O. name is diva J and I.
So as we discussed we can find shared objects in the under resources under library and you'll see that
it's compiled for every different type of processor.
But each of these shared objects are going to be the same.
The main difference being the assembly language that it's targeting.
So really any of these are going to be able to give us information.
So these shared object libraries as we discussed they can't really be compiled in the traditional sort
of way.
We can't go from a shared object to source code.
However what we can do is we can search these shared objects for strings.
So what I mean by this is that any sort of like statically text we're able to extract from these shared
object libraries.
There's a number of different ways to do it.
I like to use a utility called strings and what strings does is that essentially allows us to search
the whole library for these static strings so you can see here I've grabbed the copy of the library.
If you wanna grab a copy of the library what you can do is you can change this HBK to a zip folder and
then once you do this you can open up this app and then you can go into the libraries folder like before
and then extract the value from there.
So that would be the way that you would be able to extract it if you're looking to extract it onto your
device and then utilizing strings were able to search it for any sort of text that may exist.
So let's go ahead and open up command line.
I got to go out and see to this the rectory and then the way that it works is if you just go strings
die EMC and then we type in the name of the file that we want to search.
So it would be the live diva.
Jan I thought so.
And you can see here we get all the text strings that are existing inside of that dot so file.
Now from here we have to do a little bit of thinking to be able to extract out the ones that are important
to us.
You'll notice all these dot ones here.
If you have some familiarity with them with assembly languages you'll know that these dots will typically
correspond to labels or points to jump to.
So these dots don't like text files and are sorry like text to text data.
These are early as important to us because they're just like sort of like divisions of the file itself.
So we aren't really interested in those.
We could see that these genuine GCSE are probably telling us what this was compiled with.
So this information again isn't necessarily relevant or interesting.
The good one point one looks to me like a version number of something and we can see here and you called
hyphen version.
So this is probably just a version number.
So that's not necessarily important.
You can see these are other shared objects that are being used.
So again these aren't really particularly important.
These again are mostly of labels.
So it's indicate the end OBSS start the data.
So those aren't really something that's going to be interesting.
Similar with these here for the same reasons as to your copy is a C function that's likely being used
inside of here.
These appear to be just like information about the the actual library itself which will leave us with
these three pieces of information as well as this.
So when we're taking a look at these we sort of want to extract which ones are relevant to us so from
these we can we can sort of essentially just trial and error rhythm to see which one is the correct
inputs.
There are some other ways that we can sort of like look at these and be able to decode information from
them.
Usually when they have like the dollar sign character inside of them it means that there's some sort
of scripting thing related to them potentially could be like an argument and a bash script or something
like that.
A lot of the time these will correspond to like code lines for instance which means that this is probably
the only one that's just general text.
So if we think that this one is the right one then we can bring it over here and try to put it in and
see what will happen.
So all of us d f g h t semicolon LH We try to access you'll see that we get access granted.
So obviously this is the proper password for it.
So you can see from here that even though we can't necessarily Deacon pilotless shared objects we can
still search them for the strings that exist in them.
And if we have a hard coded string inside of there we're going to be able to extract that string and
potentially weak information such as the password.
So this video it gives you a bit of an idea behind how hard coded text is able to be utilized to potentially
expose data about Android applications.
So these sort of vulnerabilities do happen every so often and a lot of times the shared object ones
are maybe a bit more common because people are a bit less careful when they think that the thing can't
be compiled.
But also if they obscure the files at all if we can sort of like manage to an untapped skewer the code
or unencrypted code we can potentially figure out these passwords.
So not only are plaintext information necessarily a bad idea but also even just like putting hashes
into the code could be dangerous because then you can do like password based attacks to try to decrypt
them.
So this gives you a general idea of the sort of things that you can look out for for these types of
vulnerabilities so now you can take a look for these in any applications.