Welcome back.
So let's have a look into this one together right now.
In case if you could solve this, then this is pretty amazing.
And you can see those things we have learned so far.
They also apply on real world applications.
I mean, yes, this is a challenge.
And some of them has been configured in a really strange way.
But these are things you should definitely look for also in real world applications.
So they still exist there.
So let's have a look.
Okay.
We are within apps under lab server.
I've got the setup still ready and we can still not log in.
The first thing I like to do is using Chad's going to open this application.
Okay.
So here we have it.
And now within there, the first thing I like to do is having a look into the Android manifest.
So here we can see what's going on.
I mean, all those permissions, we have already seen them at the installation part, but yeah, right.
External storage, absolutely interesting.
And the rest might not be that interesting.
I mean, SMS, this is also something we should take a look into this.
Yeah.
Read external storage and things like this.
One thing I would like to mention over here is we are using just the Android system permissions.
So there are no custom permissions which could open some things right now.
So at least that's good for this application.
Okay, then we've got this application part and we can see it's debatable if you will learn or do this
later on in this course.
And we can also see allow backup has been set to true.
So within the with the ADB, we can so the Android type approach we can create in backup and then we
can have look into those files if there might be some sensitive information in there.
If this is enabled in an application, you should definitely do this to see what's inside there.
Then we've got our starting point within those intent folders, category launcher and Action Main,
which means this is the first activity that gets opened and this is something I definitely want to take
a look into.
Starting an application can be done in several ways, so if you click on this icon, this activity will
be lodged and there might be some interesting stuff.
For example, most of the application checks, if there is already some database, some database creation.
So if the database has been set up correctly, for example, most of the applications do some set up
first the database, share preferences, files, other stuff, and they have some checks.
Has this been already done?
If not, then do this.
And then we have a direct reference to yeah.
To something maybe interesting in there.
The other thing how an application could be started is, for example, by a broadcast receiver, this
would complete a broadcast receiver.
So after the system has been booted up, we can react to those events and then the application could
be also start.
Then we need to have look into the on receive method on this broadcast receiver.
So this is something I definitely want to do, figuring out all these entry points of an application
and have a look into there, what's happening there.
We can go down the rabbit hole.
I mean, we've got a bunch of stuff on the left, but at least we should have look into the starting
point of this app.
All right, then we've got activities and we've got a lot of activities.
Two, four, six, eight, nine.
Not sure about this one.
I'm not good at counting.
So here we can see we've got activities.
And yeah, I just look at those names to, to get the feeling of what's happening there.
Fireproof activity.
So something with files to log in post log in.
Interesting.
There are two separate activities for those log in process and even the launcher isn't logging activity.
Okay interesting.
Wrong log in.
Also interesting do transfer.
And this one we use statement.
What do we need to look for in those activities?
Of course, if they are exported because if they are exported, we can interact with them and we can
see exported set to true over here.
Oh there's a lot of stuff set to true we've got post in interesting do transfer even better.
So maybe we can simply open the transfer option and yeah, get some money from account A to account
B and things like this on real world applications, pretty unlikely, but in this challenge, maybe
then we've got provider and content provider.
So some com some form of database access track user content provider.
This sounds exactly like the challenge I have provided to you.
So.
So there might be some tracks about the things that the user does and maybe we can delete those tracks.
Then the user or the user, which is looking at this log file, doesn't realize that something happened
in there and we can see export etc..
True, amazing.
Then we've got the broadcast receiver, we've got more broadcast receiver, but this one here, super
generic name, nothing, no clue what's going on over here.
We can see that's the name, my broadcast receiver.
And the action is the broadcast.
We have to take a look into this one.
It's being exported and that's possible.
A text surface from outside.
So having a malicious application could trigger this one over here.
But we do not know what's happening inside here.
All right, then we've got additional activities change, password export into Drew.
Interesting.
Then this one over here, these are things which I skip in first view because here we can see the package
name.
It's com android insecure bank.
That's the package name over here.
So that's the that's the developer code and here we can see we are within com Google Android.
So these are core features of of Google and therefore they are just included into this application ad
activity.
So maybe some advertisement or things like this.
Yes, there could be flaws in there, but I would focus on the developer code itself.
It's most unlikely that we find something critical in here right now.
Maybe there are some critical flaw within the within the usage of them.
So this could be still messed up.
But if you have that much to do right now, I would recommend focusing on the developer code come android
insecure be to.
All right.
The rest is yes, the rest is Google stuff.
We skip this.
So now let's see, we we could start with the activities and I would recommend having a look at the
lock in activity at least.
Oh.
What catches directly in my eyes is my shared preferences.
Username password fields.
Okay, we have seen this and some base64 byte string.
All right.
So my shared preferences means we are having data being stored in an protected directory of this application.
We need root privileges to reach this.
And therefore, I wouldn't count this as as an security issue if there are some credentials inside there.
Nevertheless, it's pretty interesting.
Maybe there are some autofill credentials or things like this because we have seen this button and this
one autofill credentials.
So maybe they are some.
Yeah, some generic or global credentials inside there.
This is something this would be in an finding.
But having credentials, user credentials stored in a protected directory, I wouldn't count this one.
Nevertheless, it's interesting having a look into this one.
Okay.
And then we've got a bunch of Android app development, which we do not understand right now.
But that's not a problem because we we can look at those strings and maybe figure out what's going on.
We've got this on create method.
Okay.
We know on create that's being called when an activity is being created.
So this is the layout of this application in this method, which means this part over here, maybe let's
take color.
And this pot over here defines the view of our activity over here.
And this one.
Because this is our logging activity.
That's the entry point when we start this application and here we have this on create stuff.
Okay, so let's see, what do we have inside here?
Get resource string is admin equals know find view button set visibility.
Yes.
Sounds a little bit cryptic, but the things we get is admin.
No set visibility to this one.
So maybe there's some secret button inside there.
And if we are having admin privileges, we see this button.
And if you are not having admin privileges, we do not see this button.
This would be my generic interpretation of this code right now.
To be honest, I haven't looked into this one.
I have looked into other paths, but this one I haven't yet taken a deep look into.
But to be honest, this might sound absolutely interesting because if this is an intent that gets be
triggered, for example, if we click on this button and there's an intent happening, maybe we can
fire this intent from our own without having this button inside there so we could write, as we have
seen this in the past in the activities, they could start in the intent and provide additional parameters
to this intent.
And maybe we could create a user which has Yeah.
Privileges or things like this without even having access or credentials for this application.
Maybe.
I'm not sure about this one.
Maybe I will have look into this one later on.
Okay, then we've got some other stuff.
Logging, activity, perform, logging on, click.
I mean, if you click on a button, then we perform a log in.
This is something we should investigate later.
Here we have in create user.
Okay, the sounds also pretty interesting, but this might be the pattern which is.
Yes.
So I guess that's the button that's not visible right now.
Then we've got on Click Fail Data.
All right.
We've got a lot of exceptions over here and having many exceptions.
I mean, that's a good indicator to have some some complex stuff where things could go wrong.
This is often the case for cryptographic functionalities.
For example, invalid algorithms, parameter exception, invalid key exception.
No such algorithms exception bed padding.
This points toward cryptography.
So maybe there's some kind of encryption and decryption happening with those credentials via inserting
here.
This is just an educated guess.
Reverse engineering some some code is like, okay, we, we reverse engineer this, we make some guesses
and then we have to verify if our guesses are correct.
So we do not know if this is the case, but we have to start somewhere.
And yeah, this is my well educated guess for this one right now.
Okay, create use of functionality is still work in progress or okay, even if we can make an if we
can trigger this function, there's no code behind this one, so it's not worth taking a look into.
Maybe then we've got field data and we can see all those exception ones again and we can see username
and password, encrypted user name, super secure password.
So these are not this is not the username and password we have within the share preferences context.
So here, here we can see we are having shared preferences which is being referenced as settings and
now we have the method get string, get strings means the application is looking into the into the internal
file which is thought in the shared preferences and gets those strings into this application back again.
And we are now having some key value pair.
So this one is the key and this one is the value, which means in this file we are having a structure
which is encrypted username and super secure password and then there are some values inside there.
If you are not having values inside there, then we are defining these default values.
Now this is how this part works, which means we are going into an protected area of this application
and we check if there are some values inside there and we store them in username and password.
Okay.
So let's see if this username is not equals null and the password is not equals null.
Then we've got the username base64 byte string.
All right, so this is something we can understand.
So we have this username fetched from our shared preferences and we are simply just doing base64 decode.
The username is therefore definitely not encrypted as far as this goes directly into this function.
So this part is not encryption, this is just base64.
Okay, then let's see.
So this one is now containing our username and clear text.
This username base64 byte string because it's being decoded over here.
Okay.
So let's see.
Where is this being used?
It's being used over here.
Mm hmm.
So we can see this is now once again a little bit Android specific.
And this is why I recommend doing a little bit of Android app development.
Then it's easier to follow along with this because otherwise this might not be understandable right
now.
But let me try to explain this.
So here we are fetching the references to those two fields.
And this one here is an edited text and this one over here.
This one is also an edit text field.
And here we are fetching the references of this one and this one.
And then we are writing content into those fields and we are writing the content which has been previously
received from our shared preferences.
So we write in here our username and here the password, and the password is a decrypt string.
So the password is encrypted in the shared preferences, but here we write the plaintext.
So this would be absolutely readable for us if we hit out of our credentials and if there has been some,
some setup before.
So if we look in into this application, the share preferences file might, might be created which contains
the the last user name maybe.
And if we hit autofill, those credentials will be retrieved from this file.
The user name is only in base64 string and the password seems to be encrypted.
So these are the guesses right now.
We can we can conclude out of this one.
We do not know this.
That's just a guess.
Okay.
And then we can see if the username is null or the password is null.
No start credentials found.
And if the.
If both are null, then no stock credentials are also being found.
Okay, this is something we could we could test if he simply click out of her credentials because we
have in the method field credentials.
Sorry, full data.
Then we should get no Stott credentials found because username is null and password is null, which
is the case.
Let's see.
No star credentials found.
If you are inserting a username for example admin.
And if he hit out of credentials.
No Star Credentials fund.
I mean, it's amazing because both are identical.
But this one should be not this case because we have provided a username.
The username is not null, but the password has been set to nine.
So we should be in this case.
All right.
It doesn't bring us further.
Therefore let's move on.
Perform login here.
We can now see the EU.
Oh, yes, yes.
Okay.
Here we can now see we are fetching the text from this one.
This is this part.
And here we are, fetching the passport.
And then we are passing these to information via here we are passing them to those to information.
So to be more clear, the user will be here afterwards and the password will be here and we are passing
this to the dual lock in class.
So within the two lock in class those things are being compared and.
Yeah.
There's no check right now.
So this means our credentials are being checked in in the in the logging class.
It might be not the case or in the case if perform logging is not being triggered here.
So let's see.
Perform.
Lock in.
Okay.
We can see perform logging is being called over here and this one is the is the locking button, which
means we are definitely calling perform locking and afterwards they need some some check if we have
enter the correct credentials or not.
This means the check happens in the do lock in class.
Pretty, pretty likely right now.
All right.
And I guess that's all.
So there's there's a ton of stuff already happening in here.
I didn't mention to go that deep right now into this one, but yeah, nevertheless, we have done right
now.
And yeah, let's recap this real quick.
We're doing some stuff with the share preferences.
This might contain our username and encrypted password if we are successfully logging into this application
even once.
Because now if we start this out of a credentials, we are getting no credentials found because we can
see those needs to be fetched from those shared preferences.
And there are obviously no credentials inserted right now.
Okay, then we've got this this really strange admin button which appears if we are having admin privileges,
which is super interesting because we are still in the log in function over here.
So therefore we are not having any user context right now.
Interesting, but something we might want to investigate and then.
Yes, we've got the preferences, those things, and we can see the lock in class.
To lock in class is performing the credential stuff.
So a quick look maybe before we go to the activities.
Just just a quick look.
Let's see.
Okay.
Yes.
There's a lot of stuff happening there.
And this is something we might not want to check out.
So if you want to investigate this, okay.
But as far as I have seen this, this might be regarding to the to the Web configuration.
This would mean that those credentials might not be stored on on the application.
So we are having now in real world application this application.
Let me let me try to explain this differently.
Yes.
So this application is making a network request within the due log in class and the web server is checking
if the user admin is available or not.
This means those user information which can be used to log in and not stored on the device, at least
not them, which has been defined by the user.
There might be some other credentials stored inside there, so some generic credentials, service account
operator accounts, generally user accounts and things like this, but not those user credentials which
are normally used to log in.
And this is perfectly fine because this is like real world applications are handling this stuff.
So the server is managing those user credentials.
For example, if you register to in certain applications, if you provide some user name, email, address,
password and things like this, those information will be sent to the server and the servers handling
this.
In case if you want to log in, we need to have the the real credentials because we could patch this
in the application, but maybe then we will lose the access to the to the server part.
So those network requests might not take effect anymore.
We've covered this whole process, this the stuff in the man in the middle part when we talk about men
in the middle in a network connection, and then we will have a look into this part right now.
For now, we can skip this.
So if you want to bypass this, we have to figure out if there are some hardcoded credentials in this
application inside here which can be used to log in into this app.
Those hardcoded credentials might also appear on the server side.
Of course this can happen.
It's not that most likely, but this could be the case.
But this is something we definitely should take a look into.
All right.
So to bypass this path right now, I would go for the activity approach and therefore, let's do this
right now.
So let's clear this up, okay.
Let's see.
Okay.
We're having the locking activity.
We've got fireproof post locking, which has been set to export it through.
You know what?
Let's simply take this one and let's insert this into new research studio code file.
Okay.
And now we can we can select activity.
Then we can apply a regular expression.
And then we can say export.
That equals true.
Okay.
And then I hit all to enter and I copy them and paste them in here.
So now we've got all those those exported stuff.
There's some characters missing here.
Okay, so now these are the activities we can call.
We've got post locking glue, transfer view statement and change password.
Let let's try starting with post log in.
So can I set this on top.
No.
And then let's put this on the whoops.
Let's put this on the right.
And now let's see.
Let's put this.
Let's do it in this way.
Okay, ADB, we connect via ADB and then we are using the activity manager and we are using a AM for
activity manager and we are using start start activity and then we have to provide the component name.
So let's see.
Okay.
It's not mentioned here.
Then we might have it in the intent.
Options?
Yes.
Category.
Nothing we are interested in.
Component name.
There we go.
OC am start activity, dash dn and then we have to provide the package name.
The package name is this one?
And then we have to provide our activity name, which is this one, this post login.
Okay.
Let's start with this.
One, three, two, one.
Nice.
Och I didn't expect it that easy but it's, it's pretty nice.
And there's also this device is not routed option.
I'm not sure about this one.
Let's see.
Oh, well, well, for me, it looks like a router device.
Yes.
So can we.
Can we?
Yes.
This device is definitely being loaded.
So this routing detection is just bad.
I do not blame the developer.
Maybe it's it's designed to work in this way, but this routing detection is not it's not fetching our
routing option right now.
All right.
So now we we have locked in into this application and this routing detection is also not affecting our
device right here.
Pretty amazing.
Now, let's see what we can do.
Starting one activity gives us the opportunities to interact with the original activities because we
we are already in that in that sandbox context right now.
So what do we have here?
Okay.
These are just those general options transfer.
And let's see.
From account get accounts.
Yes.
This application seems to crash right now, I guess.
Let's see.
Yes.
Let's check this real quick.
Look at.
Okay.
Do we have?
Yes, I guess there wasn't a crash.
Let's see.
Mm hmm.
Here we have an crash.
Let's see if this is.
This is our crash.
So let's scroll down.
Transfer.
Everything is working fine.
Get accounts.
Okay, I read.
Now get accounts.
Yes, get accounts crashes over here.
The reason for this is if you look in, maybe we are having some kind of user context and if you are
now doing get accounts, this user context is not available and we might have an variable like NULL
in there or stuff like this.
Returning null when some string or some context is required might end up in this crash.
So even if it can take or start this activity, we are not having any real advantage right now.
Okay, let's try it once again and have a look at the other options use statement.
No, I do not see anything.
Maybe we see something in the lockout.
Well, let's just look at.
View statement.
Statement does not exist.
Okay, maybe I have missed this part over here.
So there's nothing in here and change password.
Okay.
Here we can see.
We cannot select the username.
This.
Okay.
This sounds like this looks like a flow.
The change password option only provides a password field over here.
New password.
So we do not have to know the original password, which is which is absolutely bad.
Unfortunately, right now we cannot select this username field, so we cannot provide which username
or which password we want to change.
But this might be something we could solve with those intents.
So here we have this change password activity.
We can see it on the title.
Let's see what's inside there.
So maybe we can start this change password.
We can apply our intents, our username, and then we can change this password.
So let's see if this generally would work.
If this works, then we still have to find out what are valid usernames because admin is not available
inside here.
Okay.
So let's see.
Okay.
Do we have change password over here.
Yes.
Here we have it.
Here is the activity.
So let's double click.
And we can see this might be also something with some HTTP request server IP server port get string.
Yes, yes.
Okay, nice.
Here we have it.
We've got get intent.
So if the change password activity is being called, we are having an intent and this intent has some
additional parameters which is you name, which might be the username.
And this username is in string.
So we need to call this change password activity and we need to provide our intent you name with a string
and then this activity will open.
We are having a username filled in here.
All right, so let's open a new terminal.
All right, ADB shell, amp start, activity dash.
And so our component name, our package name is this one over here.
And the.
The activity.
We want to start as this one.
And now was without us.
And now we need to provide this intent.
Let me check real quick.
Okay.
Therefore, I have to take a look into the AM.
Well, first.
So let's see.
How can we.
Oops.
Sorry.
So how can we provide the string in an intent?
Um.
Over here, it's simply just extra key.
Extra string.
Okay, we just need to use dash E or dash dash s for for extra string.
And then we we can apply it.
So let's keep this in the foreground, make this a little bit larger.
Okay.
Now we're calling this change password activity and we want to provide you name and we want to provide,
for example, admin.
I mean, it's not working right now because we do not know on username but this will start this activity
here.
That's.
Okay.
No, that's not working this way.
I'm sorry for this.
Okay.
Let's keep it in this way.
Okay.
This would start to change passport activity and we are providing this username intent.
How do we know that that it's you name?
Because within the activity itself and you change password activity we're having this get intent.
So this is some keyboard you definitely should look for.
If you reverse engineer activities or other stuff like services or broadcast receiver that you check
which data are being passed to this one and what happens with this data here we can see this is now
the username and this username set text.
Yeah, it's taking this username and inserting it here and if we click on on the button request change
password task it's being executed with for this username.
Okay.
So here we can see post data.
We are sending some network traffic, as already mentioned.
We will we will analyze this in the main, in the middle part.
For now, we we we are just reverse engineering this.
All right.
Let's see if this works.
We could also go back because this should work if we start this at the beginning.
So can we simply click restart?
Okay.
Now we are both in the lock in.
So let's open this one.
We can see change.
Password has extras and there we go.
Nice.
So now if you click change password.
Let's see.
Test.
It won't work because there is no username admin which we have already identified at the beginning.
Enter password is not complex enough.
Oh, that's also something we have to take care about.
And let's see.
The password things.
Yeah.
Here's the password pattern.
Okay.
What do we need?
Uh, maybe digits.
620 special character work.
We have to we have to choose really complex passwords.
Then let's do this.
So test.
One, two, three, four.
Exclamation mark.
That's the smirk.
Not what is missing.
6 to 20.
Oh, there's no exclamation mark allowed.
So then let's choose dollar.
So nothing happens.
But this is what we have expected.
Maybe.
Let's have a quick look at the server part.
I mean, as an attacker, we do not have access to this one.
But it will be interesting what's happening on this side.
So let's see.
Yes, we are getting a draw and see if we can see the password for the user admin.
But we are getting an error.
Yes.
Every time we click this we are getting an error.
So if we identify invalid username, we could use this one over here maybe to change the password for
this username, which is absolutely ridiculous, right?
Yes, it is.
But this is sometimes like the stuff works.
I mean, this is now a network request and we do not have to do this on the application side to call
this with this parameter, because after all this stuff, there is network request which is being sent
from this device to this device and those information are being stored in this network request.
So if we go into our man in the middle position and if we fetch this network request, then we can modify
those data and we can simply perform this without having a mobile application already mentioned.
We are doing this in demand in the middle part.
Okay, nice.
So this is how we can play around with those activities.
I mean, you could also have a look into this into this is something we have already seen.
I guess we have already seen all of them.
Yes.
And some of them might work and some of them don't.
Okay.
So for this beta right now, it's all we will move on with the solution, of course, but I will separate
them in case.
If you are just interested in exploiting content providers or broadcast receiver, you can directly
watch these separate parts.
All right.
So I'm looking forward to see you in the next video where we talk about content providers.
Let's go.