All right, let's have look into the four key components of an Android application.
I mean, half of the vulnerability relies on the network traffic regarding to HTTPS or other TCP connections,
and the other half is within those four components.
So let's start with activities.
And now the question what is an activity if we start our application?
So if we click on the icon on our smartphone like this one, then a screen appears on our screen.
And like this one, the screen is now showing some username and password and lock in this screen is
an activity.
So this is some kind of screen content.
In our case, it's logging activity if we now perform our log in.
So if we enter the correct credentials and click log in, then another screen appears.
In this case, its profile.
Profile once again is another activity.
So it's another screen content.
If you now click the pattern settings, then another activity starts, which is the absolutely correct
these settings activity.
So settings or the settings activity is just another screen content.
And last but not least, we've got this code button which starts our last activity, which is decode
activity in our application over here.
All right.
Okay.
So here we have now all of our activities, but it has to be in one way.
For example, the code activity could also launch other activities, which has been seen before.
In this case, it's a profile activity.
So if we click within the code activity, the profile button, then the profile screen appears, which
is simply just a profile activity.
All right.
So it has to be in one way we can also interact between those activities.
All right.
To sum this up, right now, activities are simply just screens.
That's what an activity is.
So we've got an screen layout structured in an XML.
And yeah, this structure is being opened when we open such an activity.
So we, we simply just open another screen opening.
Certain screens can be dangerous.
I mean, they have been protected by a username and password, for example, to opening the profile
or the settings activity.
We need to insert those credentials to, to get into this application.
Of course.
Yes, this is why we have this password protection and therefore we've got the square around all of
them, which means those activities are within or are protected by the application context, which means
only the the current user, the user ID, which we have seen in those permissions or some really high
system applications can interact with this one.
For example, if we have fruit, yes, we can simply start whatever we like.
But another malicious application like this one over here cannot access them.
So we can start the logging activity with our malicious application.
Yes, that's correct.
Because that's the that's the activity that has been defined as the launch activity.
But all other activities are being protected.
So we cannot simply access them, which would be.
Yeah, which would be a huge security risk, of course.
All right.
So now the question, where's the problem?
Right.
So everything looks fine.
We've gotten username and password.
We need to enter them to enter the other activities or to enter the context of this application.
So everything is fine, right?
Yes.
Until we've gotten a certain case in this case could be the following.
Let's assume our code activity is something like a QR code or some other secret code which can be scanned
by an camera application like this one over here.
So if this camera application now scans in secret code and we want to open our application, this is
not working right now because if this this camera scans this code, it tries to open this activity.
But this has been protected with the application context.
So the camera application cannot simply launch this activity right now and therefore it doesn't open.
And here our app wouldn't work.
Now, as a developer, we've got this use case.
I mean, we've gotten secret code and we want to scan this with a camera application and then we want
to open our app.
So that's that's an absolute valid use case, right?
Absolutely.
And therefore, we've got the solution for this one.
And the solution is exported so we can export certain activities, which means they are now reachable
from the outside world, which means this camera application can now start this activity, but only
this activity, not the other one, for example, those profile or settings, because this would be
this would be dangerous.
Right now, the way it's working right now is based on intents.
And we will have a look into intense in the next couple of videos.
So that's that's a pretty amazing system.
All right.
But so far, I would suggest everything looks good at the first view.
I mean, we can interact with our application by scanning in secret code and the other ones are still
being protected.
For example, we can only reach the settings activity which can change our password.
If we log in into this application, click on the settings button in the profile activity and then we
can interact with this one, right?
And fortunately not because in code activity there was something wasn't there a certain button.
Oh yes.
Within the code.
Activity.
We are able to start the profile activity and this is how those vulnerabilities can be created as in
developer right now.
So we've gotten certain use case.
We want to start this code activity which is absolutely it's well valid file, but we have to think
this to the end.
If this activity can also start other activities on for example, the profile activity, then we are
having a huge problem right now.
The profile activity is within the secure application context.
Yes, this activity has not been exported to the outside world.
Yes.
But once we have reached this internal security context via decode activity, and if we have the ability
to start this within our code activity, then we can once again interact with everything else in the
secure context, which means we can start this profile activity from this code activity which has been
exported to the outside world.
And this means we can all start these settings activity, because once we have reached this internal
context, we are within this user context of this application.
So we have the permissions or the rights to interact with all the other components in there, which
means if those activities are interconnected, then we can also start other activities from one which
has been exported to the outside world.
All right.
Yes, this sounds now a little bit confusing, but don't worry, we will we will do some exercises regarding
to this one and then it will be crystal clear.
All right.
How we can exploit this right now.
The exploitation could be done, for example, by a malicious application.
We can use an malicious application to start the code activity.
Once we have started decode activity because this one has been exported, we can reach the profile activity
and then jump to the settings activity and we could, for example, change the user password.
Sometimes these approaches works and sometimes they don't.
The reason why they are not working could be the following.
Let's say our user credentials are being encrypted, and if we lock in into this application, those
user credentials will be decrypted.
Now, if we're using some functionalities, the application assumes that everything has been decrypted
because this is the case when we log in into this application, if we now try to interact with certain
things, for example, and password change or things like this, the application could crash because
we have yeah, we have cheated a little bit.
We have cheated a lot to get to a certain state and this application might have to set up certain states
before.
So it doesn't mean just if we can launch an and password change activity that this one functions correctly,
this is something we have to verify.
Nevertheless, if we can interact with all those activities, there's at least one function that could
cause trouble in an application most of the time.
Okay, so this is something we need to look for.
Now, the question, how can we identify this vulnerability?
And so where do we have to search to to get this information if an activity has been exported or not?
And the answer for this is in the Android manifest.
So this configuration file has all these information about our activities or otherwise.
If we are creating an activity, there will be an entry for this activity in the Android manifest XML.
Okay, so now we know where to look for, but what is the term we need to look for?
Well, there are two options.
We've got explicit export ID and implicit export and explicit export ID super easy because we simply
get this tech exported equal to.
If you find this in our application tech, then we know this activity has been exported.
All right.
The other one is implicit exported.
And we have already seen this implicit export.
It simply means everything that has an intent filter is automatically being exported to true.
So this is something that might not be that obviously right now, but that's the case.
So if we know this, then we are good to go.
These are the only things we need to look for.
If you want to know if an activity or another component has been set exported to true or not.
We have already seen this intent filter in our Android manifest XML in the launching activity and now
we can get our parcel together.
The launching activity has this intent filter, which means the launching activity is being set to export
it through.
So this activity is available from the outside world.
And of course, it has to be if you think about this.
So let's say our activities are within an insecure application context.
If you click on an app icon, we need to start at least one activity to launching activity.
Therefore, this activity needs to be reachable from the outside world.
Otherwise we couldn't even start our application because even the system service which is starting those
activities, has not the permission to interact in the secure context, of course.
Otherwise this would be absolutely dangerous because this service could also start in profile or in
settings activity in this case right now.
So how the system is working, I mean, it's pretty amazing.
We've got an activity, the launching activity, and this one is being exported to the outside world,
which means every application could start each other so we could make a malicious app which is constantly
starting other apps.
But that's not a real use case, right?
It's super annoying, but it's not dangerous.
Just annoying.
Okay, back to this one over here.
So now we've got our secure context and we've got one activity, the launching activity, which is being
exported to the outside world.
Once we have started this activity, we can also interact with the other components.
So we are then within a secure context and we can, for example, launch or open the profile activity
if we have provided the correct credentials.
So this is how it is.
This whole system works and this is the reason why we are having always this intent folder with our
launching activity.
All right.
Okay.
In our case right now, if you want to export this code activity, we can simply use exported equals
true.
And then this is this is available from the outside world and can be started by on camera application
or something else.
Alrighty.
Okay.
So now I have already spoiled it, but this whole exported scheme doesn't only affect activities, it
affects all of our key components, which means also broadcast receiver services and content providers.
And we have to look into every single component to search if there are some vulnerabilities regarding
to this one.
Okay.
So for now, it was a lot of theory and therefore I would suggest in the next video we will have and
look into a practical example how to identify those exported activities and how to interact with them.
How can we start another screen content and also searching for some kind of vulnerabilities inside there?
Alrighty.
Okay.
I'm looking forward to see you in the practical part.