Okay.
So we are still working on this mobile application and we have already figured out quite a lot.
Now after activities and content providers, we want to have a look into the last component in this
application which is broadcast receiver.
So we are only having two of them where this one over here comes from some some Google APIs where we
do not want to have a look into.
But this one over here, this has been developed or coded by the developer and therefore there might
be some flaws inside here.
So let's see, it's being set to export the true and we also got the Android name in the broadcast.
So if you want to trigger this, we need to apply this this action name over here.
But first of all, let's have a look what's happening inside here.
Okay.
As already mentioned in the broadcast receiver part, if you want to analyze broadcast receiver, the
only thing we have to look for is the on receive method.
This is the only part that can be triggered by us right now.
And in this case, we only having this on receive method which is performing all the stuff, which is
amazing because we have full control over this method and all those parameters.
Once again, we've got intent get string extra.
So we are having two strings inside here, which means we've gotten phone number and the new pass.
All right.
This sounds this sounds interesting.
So here we can see if the phone number is not equal null.
So if we are having a phone number, we are triggering this part, this code.
Otherwise, we simply just get out of this one.
Okay?
This means we have to provide a phone number.
The phone number, it has to be a certain value.
No, the phone number is irrelevant.
Interesting.
But we we do not care about this phone number right now.
Okay.
So we can trigger this broadcast receiver.
And this is taking two to values, a phone number and new pass.
Okay.
And now let's see what's happening here.
If we provide a phone number, no big deal, we can do this.
Then we are going into the shared preferences settings.
So we have we are getting those.
Okay.
We're going into the share preferences, this user name basically for pilot string.
So we are getting this user name and this in this field oc decrypt password new crypto is decrypt string
super secure password.
Okay, we are fetching the decrypted password.
So this part right now is going into the shared press.
And taking the username and also the password out into those two variables.
Let's see what happens next.
Then we assign our phone number from here.
To here, which means this is now our phone number.
And then we are having a message.
Text update password from.
Oh, well, well, well.
So here we can see this is the decrypted password which gets fetched from the shared preferences.
So this is being returned back into this variable here.
And this decrypted password is now being used in this message.
Text message updated password from decrypted password.
So this text message is doing something with the decrypted password and it also claims that we are providing
a new password.
This one over here.
And then okay, now, now we are having the SMS manager and the SMS manager is sending out this this
text message, does it?
System.out.println for the change password.
Okay.
The ADB locate is also being involved in this ridiculous function, but it doesn't print out any sensitive
information beside the.
What's the.
What's the text phone number?
What's this one?
Okay.
Besides the phone number.
Oh, oh, oh, oh.
Okay.
And the text message.
Well, so within the it'd be locket if you change the password, the password is being printed out into
the locket because we, we have this directly here.
The decrypted password will be assigned to the text message or it will be included in the text message.
And here this text message is being printed out to the locker.
So this one is leaking the password in the locket output.
Och, this is something I haven't looked into, but realizing right now by looking at this amazing and
then as the manager sent text, then we are sending the text messages which contains the the old password.
But wait a minute.
All right.
Interesting.
This is why you shouldn't rely on on names that has been provided by the developer.
Do you recognize something interesting in here right now?
What happens with the new powers?
I will give you a moment to think about this.
Okay.
So we have seen the we can trigger this broadcast receiver and we can provide a phone number and a new
password.
The application takes the information out of the shared preferences.
The old password.
In this part over here.
Share preferences.
Then we've got this is it.
Get string.
Get string here.
Encrypted username and password.
The username, by the way, is also not encrypted.
We have already figured out that base64 do not rely on those on those themes.
Okay, so it's taking out this information and it's placing them at least the password into an ADB logcat
output and also within an text message via send via SMS.
Okay.
But the new passport is not being touched anywhere.
This means the passport just never gets updated in this whole construct.
And then we are returning out.
So if we trigger this broadcast receiver, the the update process by the broadcast receiver, we are
not updating the passport.
We've got an information leakage, which is absolutely ridiculous because we we can fetch the original
passport, which is also pretty fine because if we are not updating it, then the the old passport still
works, but we are not updating the passport.
This one here is not being used anywhere.
Only here within a text message string, but not within another function.
We have seen that the update process works.
So after applying a new passport and resetting this application, we have to enter the new passport.
But this has been separated from the broadcast receiver.
So the broadcast receiver is simply just in heavily information leakage.
If we can trigger this on our own, we cannot update the passport.
But we are we are still fine with this one because we fetch the old passport.
But yeah, this is why we shouldn't rely on labels like this one over here, this new pass label over
here.
We are not setting a new passport, at least not here.
It's being done, but not any broadcast receiver.
Okay.
Nevertheless, let's trigger this broadcast receiver, because I would like to to span the smartphone
full of SMS.
We are also sending a lot of text messages.
This could be in finding in its in itself.
So we are providing a phone number.
Yes.
We are providing a phone number where we send this message to.
Okay.
Now I realize this.
We can provide the ticket phone number and send us the old password for this application.
Oh, yes.
Okay.
Now I know how this works.
Oh, yes.
This would be a pretty nice finding.
So let's do this over here.
Okay.
What do we need to get within the Android manifest?
We need to have the.
The name of this broadcast receiver, and it's this one.
Okay, so let's see.
ADB, shell.
And then once again, the activity manager.
And here we have something like broadcast where we have it.
Here we have it broadcast so we can send it to a specific user ID to only one application, or we can
send this broadcast to every user application.
In our case right now, I mean, as an attacker, we are lazy, so therefore we simply send it to all
and then those applications can react to this one.
So you can receive an on receive method regarding to this broadcast event and then you can also react
to this event.
But yeah, this, this has been already defined in our application.
We want to hack, therefore we are good to go.
So yeah, that's all we, we simply, we simply called pro broadcast default is I guess all.
Yes specified to send to all users and then we have to apply our intents at the bottom.
Let's do this am broadcast then the package name.
The component name in the component name is our package name.
This one.
And then let's see.
I mean, we I guess we do not have to provide an component name, to be honest, because this broadcast
received or this broadcast will be sent any way to everything.
But let's try this out both ways.
I'm also not sure what's happening then.
Okay, so we've got component name and then let's see the name of this broadcast.
Is this one over here?
Okay.
And now here we have to define the action.
And the action is within the Android manifest.
It's named the broadcast.
Yes, the action should be enough because that's the action that gets sent out to every application
out there.
And then the application can react to this broadcast event.
All right.
But this doesn't hurt at all.
But it also might work without having the package name.
Okay.
And now let's see, what do we have to provide?
What intents do we need to deliver to this one?
An intense get spring we have in phone number and a new pass.
Alrighty.
So the phone number is in string.
So we're using this one extra key string value.
This is our string.
And the value is I guess we can we can add some quotes, but I guess this is also not required.
So the phone numbers, for example, one, three, three, seven, that's the phone number of the attacker.
I mean, the smart phone, I guess it's fetching all those SMS, even if it's not the original phone
number.
But yeah, it doesn't matter.
And the other part was the new pass, which is not really relevant.
Not relevant to be sure that that is that it is really not relevant.
Let's select an and one which also fits those requirements that we do not get trouble with this one.
All right.
This is how we can trigger this broadcast.
And now let's see if this works out.
So can I put this smartphone?
I guess I cannot keep it in foreground.
Unfortunately not.
So therefore, let's put this on the left.
Okay, so let's see.
Three, two, one.
Okay.
I cannot see something in here right now.
This might be all an old SMS.
So let's see if there's some SMS message regarding to this one.
Message us.
Yes.
Here we have it.
This is that's the phone number.
That's the phone number.
So this is confusing me a little bit.
We have to look up what SMS manager send text message.
If this is the phone number where it comes from or where it should send to.
So maybe let's look this up real quick.
Okay.
Now we've got send text message and here we have it.
Okay.
Yes.
Okay.
The the expectation was correct.
The first one is the destination address.
And if you are not sure, you shouldn't make guesses if there are official documentations out there.
So you can simply look it up and let's see source address.
Nevertheless, the the emulator is receiving all messages because it's an emulator and you might want
to test certain things.
So therefore this message would have been acquired at the attacker phone and now we can see the the
update for the for this user over here.
The password has been updated from hacked at 1 to $3 to work at 1 to $3.
And now we know we have changed this password to hack via our activity manager.
So yes, yes, we have changed this password, which is ridiculous.
Now we have an another way to interact with those passwords, but in this case, it might not been updated.
We can verify this because we know the user to this password is check.
So we need to figure out if works at 1 to $3 is not working with the with the user check.
So therefore sorry, we first need to restart this application to be sure that those those changes have
been updated.
And then let's see.
Check and let's see if the old passport simply works.
There's no history.
So the old passport is hacked at 1 to $3.
If this works, then the password has not been updated.
Yes, that's correct.
Because I need to insert text.
Oh, sorry.
It's input text.
One, two or three.
Now, I'm also a little bit excited right now, so let's see.
Yes.
As expected, the passport does not get updated.
This finding is an information leakage.
It's and pretty nice information leakage because you can define the the phone number of the attacker
to send the current password of the last lot in the user, which sounds amazing.
And yeah, this is how we can abuse this.
We have seen this broadcast receiver is leaking the password, so it's not updating your password,
but it's pretty heavily information leakage because we can send this to any number we want to have.
Nevertheless, even if we are not sending an and password inside here sending an SMS by a broadcast
receiver, absolutely ridiculous because we could we could send any phishing SMS or other stuff to other
people from this smartphone over here.
There could be also costs, of course, which which occurs on the user side.
So this whole example over here I find is pretty amazing.
And yeah, it's a little bit constructive regarding to this stuff, but you will definitely find things
like this out there.
Not exactly like this, but closely.
For example, once I had an application which triggered and really important event via an broadcast
receiver, so this broadcast receiver could be triggered by a malicious application.
And then this event did some, some crazy stuff where the developer didn't thought about that.
Also, other people can trigger this broadcast receiver.
Broadcast receiver is always worth taking a look into.
All right.
And this is how we can interact with them pretty easy, right?
Okay.
So that's all for those basic components.
In the next video, we take a look into the crypto functionality.
So we will have a look into those shared preferences and how we can easily decrypt this.
And we will also try to hunt for hardcoded credentials because this is something that can also occur,
especially on Iot mobile applications.
Alrighty.
Okay.
So I'm looking forward to see you in the next video.