All right, guys, welcome back.
In this video, we want to do some practical exercises regarding to broadcast receiver.
So this will be pretty amazing.
We want to identify them in the Android application.
We also want to see what they are doing in the receiver method and most importantly, we also want to
exploit them.
Alrighty.
So therefore I would suggest let's dive into this one.
Okay.
Here we are back in the ubuntu VM and I have prepared two applications for you within apps broadcast
receiver.
I've got the following two and I have attached them to the section over here so you can simply download
them.
We've got an Android SDK 25 version and an Android SDK 26 version.
So this would show the difference between those those two major versions.
This one is Android 7.1 and this one is Android 8.0.
So this means the intent folder in the Android manifest XML will work in this version, but not in this
anymore.
And this is something we will figure out by doing some practical exercises regarding to this one.
Okay.
So I mean, both versions are identical regarding to the code or the Android manifest example XML,
that's no difference between SDK 25 and SDK 26.
The only difference is that this one has an in-built version for 25 and this has the build version for
Android eight and higher.
That's the only difference.
The source code or the Android manifest is absolute identical.
Okay, so let's have look into Android SDK 25, this one over here.
Now we're having a little bit of a problem because we do not know how to reconstruct or decode this
application right now.
I mean, with the APK tool.
Yes, but we have learned smoothly so far and we also didn't learn something about reverse engineering
those APK files right now in case if you want to perform this, there's some video within the reversing
section so you can have a look into the shady x dash going video and then you will be able to reconstruct
the code, the Java code out of this application.
Also the code regarding to the Android manifest.
So this is like having the source code next to you.
I mean, it's not exactly the same source code because this is not possible, it's just an interpretation
of the original code.
But this is pretty close.
I guess it's about 90% or maybe even higher.
So you can definitely work with the reconstructed code out of this.
Okay.
All right.
For all of us, you do not have to do this.
Of course.
I mean, you do not have to jump ten meters ahead to perform this task right now.
I have also attached the source code to this section.
And yeah, I mean, it's simply just a text file you can have and look into those text files and then
you will be also able to figure out what's going on over there.
Alrighty.
Okay.
And this is something we are doing right now, so I've got it already included in my Android studio,
which is over here, and I will show you how you can do this tool.
Okay.
So I guess it has been finished loading and here we have now the whole ID regarding to this one.
If you want to also include it in this way, what you can do is because I have now already included
it, but you can go into file new and then simply import project and then you can select the source
code directory and you would end ups and you would end up in the same structure over here.
Okay.
So the first thing I like to do when I reverse engineer an Android application is having a look in the
Android manifest example because there's a lot of interesting stuff.
And also here, first of all, we are using in permission and we are using the receive PWD completed
permission.
All right.
We already keep this in mind because this is maybe most of the time or all the time being used in combination
with the broadcast receiver.
So then we've got this application tag we can see allow backup through a lot of unnecessary stuff.
But then we've got this receiver tag and this means we are now having our first broadcast receiver.
The name of this one is Safe Data.
It's being enabled and we've got export.
It equals true, which is pretty interesting because underneath we're having an intent folder.
So this one would already set this this class to be exported.
So this content filter is performing an implicit export for this class over here.
This is the Java class, by the way, the Android name.
This is the code for this for this broadcast receiver.
Okay.
Now it's the question why we having exported through and this intent folder and the answer for this
one is compatibility.
So therefore, we as an attacker do not take care about this one.
The developer has to take care about this one.
All righty.
Perfect.
So now we've got this intense filter.
So our application is listening to an event.
Which event?
This is defined in this action tag we can see Android intent action battery low.
So when the battery is running low, this application will be informed about this event and this application
is going into the safe data class and reacts to this event.
So let's have a look what's inside safe data.
So if we go into this one.
Here we can see we've got safe data extends broadcast receiver and here's our well famous on receiver
method so this application is listening to this intent to this battery low intent and if it receives
it it's executing the code inside here, which is absolutely lame.
This code.
I mean it's simply just and print out to the to the logcat output simply just safe data, nothing more.
But this is perfectly fine because first we want to have an overview about this whole system, about
this construct over here.
And then later on I have prepared another broadcast receiver which is performing some actions.
So this is now looking a little bit lame, but later on it will be super interestingly amazing.
All righty.
Okay.
So far, so good.
So this is simply just printing out text to the ADB locked console.
All right.
Back to this one.
What else do we have?
Yes, this is all about this receiver.
So our receiver is named Safe Data.
This is the Java class and we are listening for battery low event.
Okay, then we've got another receiver reset system enabled export, etc., true intent folder.
And this intent filter is listening to those two though those two actions.
First one is boot completed, which requires this permission.
So if we are listening to this event but we wouldn't have this permission, then the application wouldn't
work so it would crash or simply not not working within the receiver tech over here.
So therefore this intent filter is being tied to this permission.
So now we're listening to boot completed and in lock boot completed.
So we are only having two actions right now because I will run this on the Nexus device and therefore
I guess I would only need this part in the slides we have seen we have three actions, but I mean we
do not need to have a huge compatibility if we are running this only on a Nexus device.
OC OC So and that's all about this one over here and let's have a look what this code is doing.
It's in a class reset system.
So over here reset system.
Oh well I am that lazy.
Another System.out.println.
Yes, I am.
Because as already mentioned here, we want to learn how to trigger those broadcast events.
And later on, I have a really nice example for you.
Okay.
All right.
So here we can see if this broadcast will be received by this application.
It's simply printing out system reset.
Nothing more so far OC.
Back to this one.
And then we've got an activity which is in screen content and this is also the entry point of our application.
We can see main and launcher.
All right, so far so good.
We can see we are having to broadcast receivers so far, safe data reset system one is reacting to battery
low, one is reacting to boot complete.
And now I would suggest let's simply inside this application and see how we can trigger those events.
Let's see how we can actively trigger battery low and would complete it.
So let's go.
Okay.
To install this application, we first need a device and I recommend using the emulator because there
we can play around with yeah.
With the battery level pretty easily.
So I go into my AVD manager over here.
And I have prepared an extra six wise.
I can highly recommend using this device, this device type, because it doesn't require that many resources.
Therefore it's faster than the other one and it also has root access.
So this is a pretty neat device over here.
So let's start it.
Okay.
It's being started and we already get this morning emulators running using nested virtualization.
So they have to share those resources right now.
This is in virtual machine and this is also running in a virtual machine, which is not a good approach,
but it will work for this Nexus device over here.
So this is this is working probably fine.
All right, so now we've got our device.
Let's enable it.
Okay, here we have it.
And we can see these are all applications right now.
Okay, let's install our app.
So we go into this directory and I'm using the SDK 25 version first.
So open a new terminal and then ADB install alarm system apk.
Back to the emulator.
Here we have now this amazing icon.
I mean, we've gotten APK name alarm system.
We've got this alarm icon.
So let's see what this application might be.
And.
There we have it.
We simply just got an icon and some text over here which claims this alarm system has been disarmed.
So the whole functionality of this application is beside having those two lane broadcast receivers.
We are having another one and more hidden one in this application code and this one is receiving and
broadcast event and triggers an arm and disarm.
For an alarm system.
This could be 100% and real world applications in the Iot business.
Okay.
But before we come to this, this amazing part, let's first play around with those broadcast receivers
with those two.
So let's see how we can trigger this event battery low within the emulator.
This can be easily done and this is why I really recommend using the emulator because this is yeah,
it's super amazing if you are opening this one within those three dots.
We've got this battery tab over here and here we can set the battery level of this device.
So if we slide this down a little bit.
And then you can see this battery level is being drained.
By doing this, we can easily simulate and device running low on battery.
I mean, we also got states like battery health felt good and things like this.
So yeah, this emulator has a lot of nice, nice features.
If you are running this now on any device, you might have to wait until your battery level drains slow
or until we reach the point where we actively trigger this this event, which is in just a few minutes.
But for now, let's keep it this way.
Okay, so let's let's put this over here.
And here we're using now the logcat output to observe this whole behaviour.
So maybe let's have a quick look once again into the application source code.
So here we have to look at output.
And we are now triggering this battery low event, which means our application is listening to this
event with this intense filter.
And if it receives this event, it goes into the safe data class and prints out this text on our ITB
Lochhead console.
This is all.
All right, let's do this.
So maybe let's make this a bit smaller.
Yes, I guess this overview is nice.
So we are draining the battery and I'm not 100% sure when this event is being triggered.
We can see there's a lot of output already on the logcat.
So this might be regarding to broadcast receivers or could be simply some other output right now.
Okay.
15, 40, 30, I guess.
20 10% something here.
Let's see.
20.
No.
Okay.
Let's go further.
15.
Yes, 15.
Battery may run out soon, so we get this notification and perfect.
Over here we see this.
Nice.
So this is freaking awesome, right?
The smartphone is running low on battery and is sending this event out there to all these applications.
And here we can see we react to this event.
We are going into our safe data class and we react to this one by printing out two safe loss data.
I mean, we are not saving this data as a developer right now, but we print them out so we can see
we have application code reacting to an event occurring on the smartphone.
Super awesome.
All right.
Now.
This is pretty cool.
We can see we can supercharge our smartphone.
There we go.
And let's trigger it once again.
We you.
There.
We have triggered it once again.
That's the trigger.
Sorry that it gets triggered underneath a certain level.
Hmm.
Doesn't seem like.
But if we are reaching this level, so if we are charging our smartphone and if we go back once again,
then we can see it's getting triggered again.
This battery low gets triggered and battery volume or battery charge of 15%.
Okay, cool.
Now let's have a look into the other broadcast receiver.
But we have it in this one reset system and to be having now a little bit of a problem triggering and
battery low.
Absolutely no problem in the emulator.
But simulating and boot completed.
This might be a little bit tricky but complete it means after the smartphone has been finished booting
this event will be sent.
Okay, we could simply restart this emulator, but then it's not guaranteed that we are attaching at
the right moment with our ADB locked so this event could be already gone.
Therefore, we need to know how to trigger this on our own.
And this is super easy in the ADB shell.
So let's have a look.
Okay, let me put this on.
Let's let's highlight this first new window.
ADB shell.
So our friend over here is the activity manager.
And if we go to the top.
Yes.
We've got this broadcast event and here we can now see if we're using and broadcast.
We can send a broadcast intent.
Options are useful.
We can apply and use ID.
We can apply all or we can say current.
And now there is I guess there's some error in here because the description claims and specify which
user to send to.
So it means we can send this broadcast event to a dedicated user, this user ID for example.
Our applications all have user IDs so we can simply find them out and send and broadcast event to an
single application based on this description.
But I guess this is a little bit faulty, so I will show you later on what I mean.
Okay.
If we are not specifying anything, then it's sending to all users this event and this is perfectly
fine.
We as an attacker, we do not take care if we are sending an broadcast event to many applications out
there.
All we take care about this that our our event will be fetched by this application, which we want to
target, so we can easily send this to all users out there.
That's absolutely no problem.
All right.
So let's see now the question.
How can we send this event?
Because there's no here's no action defined.
And yes, the action is being defined in the intent here.
And this is a little bit annoying.
But once you are familiar with this one, it's it's no problem anymore.
So we now know and broadcast we send and broadcast to all applications.
If you are applying all of these or if you apply nothing, then this is the default value.
The intent options are at the end.
Over here.
Oh, uh, a little bit higher.
There we have it.
And specifications include these flecks, and we can see here we have our action flick.
Nice.
We also get our data, URI and our category.
So these are those.
Those three main blocks we could also apply and component name regarding to activities we have seen
we can trigger and single activity in our application.
We provide the package name so dash n package name slash and then the activity name.
This is how we can apply in certain component.
We could also do this over here.
Maybe regarding to.
This one safe data, for example.
But I mean, we do not have to target an in certain component name.
It also does mean, I guess, that it's being sent to in single application out there.
And therefore, we we do not get an advantage right now.
We could make a mistake regarding to this name and therefore, we simply we are not applying this in
our command.
Okay.
So what we need to do is make it a little bit smaller.
It's.
Yeah, it was really large.
All right, so let's get our puzzle together.
What we need to do is we need to call and broadcast, and then our action.
Dash eight.
What's the action name?
Well, let's see.
Over here.
Let's call this part.
Complete.
Completed.
So within this action tech, we've got this name and we simply copied this part.
All right, now let's open the locket on the right
and let's see.
We should see right now.
Sorry for the jumping, but we need to figure out what we are looking for.
So within our application, we are looking for this event.
And if this occurs, we go into the reset system and within the reset system we go into the on receive
and then we are printing out some lame text.
Perfect.
Let's see.
I'm executing this in 3 to 1 and we're getting an arrow.
What's the arrow?
Permission denied.
Not allowed to send broadcast and word intent.
Action boot completed from pit and the UUID to 1000.
If you're performing an ID, we can see we are having the user ID 2000, which is the option and the
ADB shell is not allowed to send and would complete completed broadcast.
All right.
This is unfortunate, but we've gotten a workaround so we simply type in Sue and then we are having
privileges and the root user will be definitely able to send this command.
So let's see.
And broadcast that a this action.
I'm hitting this in three, two, one.
And let's have a close look to the locket.
3 to 1.
All right.
There's a lot of stuff going on.
And like, I would have like I would have made it in this way.
Our system reset is on top of it.
So pretty nice, right?
Absolutely.
So we can see we are triggering this event actively right now.
We do not have to wait until the smartphone reports.
We are triggering this event.
Android intent action would complete it.
So those applications think right now that the system has been rebooted and this could be a little bit
messy because those applications are reacting to this event and they might think, okay, the smartphone
has now finished booting.
I have to start a lot of stuff which we can see over here.
There's a lot of things going on and it might be not wise to do this on real smartphones.
I guess you do not break something.
But yes, I mean, in an emulator, we are probably safe.
Okay, let's see how often we can do this until something crashes.
No, maybe not.
But I mean, we could simply repeat the step now over and over again.
And we can see our application is reacting to this one like shown over here.
So this is how we can actively send and broadcast.
And so far so good.
All we need to do is we need to use AM broadcast, dash A and then the action.
Then we can find the action name in the Android manifest eczema over here.
Okay.
Perfect.
Now, let me show you what I mean with this user type.
So let's make this larger.
Let's leave the root context and let's use AM one second.
Okay.
If we go upwards to broadcast, where do we have it?
Over here.
So the description claims that we can use and broadcast with a user dash, dash, user and user ID and
it claims that it specify which user to send to if not specified and then sent to all users.
Okay.
So based on this description, if I read it correctly, we would send this broadcast event only to the
single user, to the single application with this user ID.
How can we find out the user ID of our application?
Well, this is super easy.
If we go back into this one and using PM the package manager and then going upwards, there is something
like PM list packages and here we've got this option dash capital.
You also show the package ID.
So if you are performing PM list packages dash you, then we are listing all those applications with
the given user ID and let's do this PM next list, pick up channels, dash you.
Nice.
So here we have now all apps and we've got the corresponding user ID at the end.
Now I do not want to search through all of them, so I'm simply grabbing for app hacking because this
is why we are here.
And here we have our app hacking broadcast receiver with the user ID 10,124.
Let's verify this.
If we are getting root privileges and if we go into data data and if you are performing ls dash some
options on packing.
So we are grabbing app checking.
Then we can see we've got our application and this one has the user ID a 124 this a can be replaced
with ten because it's being 10,000 from the user ID where our applications start counting from this
ID, which means we are having the user ID 10,124, which aligns with this one.
Perfect.
So now we've got everything together.
Let's try sending this broadcast event to this user ID.
So we are using a broadcast dash dash user 10,124.
And then our action, the action we are getting from here.
And this is the whole command.
Let me.
Okay.
Well, maybe.
Let's do it this way.
All right, so let's restart the lockout.
And this means we are now sending this action to this user application.
This is our user application.
So the alarm system application, which means we should only see this log output over here.
Reset, sys.
System reset.
This is the only log output we should see on our on our terminal.
Right.
At least this is my interpretation of this whole of this whole stuff.
So let me show you what happens.
We can see skipping broadcast intent a user.
This one and parent are stored.
This one is hanging right now, which I have no explanation for this one.
But the we cannot see any output.
So the broadcast seems not to be successful right now.
And to be honest, this dash dash user command is being used also in in other commands, but in a different
way if we are typing in the activity manager once again.
And if we go upwards.
Oh, let's see over here, for example, in the stat activity.
Specify which user to run as.
And I guess we read this quite often.
And this is also my interpretation of this one.
So I guess the description over here is simply false.
And so what I have observed so far is if we apply this dash, dash user, this is the user that executes
this this broadcast command.
Let me show you this.
I mean, this is not required right now, but in case if you try to send this to a dedicated application
and you you are relying on this one, then you you might spend quite a lot of time with this.
Okay.
So if you're using and broadcast dash, dash use on 10,124, I guess this was the user ID.
Let's see.
Yes.
That's the user ID that A and this is our command.
If you are now executing this, we are getting in the same behavior.
So we are not even getting that the the current user has not the permission to do this.
But now to show you that this one might be the current user ID, they are simply using the user ID zero.
So that's not a dedicated application user ID.
We try to execute this as user zero, which is root, and we're not having the permission, of course,
to do this.
So let's see.
Yes, we're getting an permission denied because we're not allowed to send this broadcast from the user
ID to 1000 as the user zero.
Last but not least, let's do this once again.
But this time with root privileges.
And this time we are not claiming to send this to this application.
We are claiming that we are sending it as the user ID zero, which is maybe let's do this once again
here we can see this is our user ID.
So in this command over here and now let's observe the at output 3 to 1.
Oh, interesting.
Right.
So here we can see we've got the system reset or the other broadcast events related to this one.
But yeah, I guess this is simply just an error in the description.
So please do not spend some time sending it to a dedicated application based on this one over here.
Simply go for the try hard approach, send it to all applications.
The only thing we are interested in right now is that our application fetches this event.
All right.
This is the only important thing.
If you're sending out this event to other applications, we simply do not care about this one.
This application needs to receive this broadcast event.
Alrighty.
So far so good.
We have seen two absolutely lame broadcast receivers.
Let's have a look back.
And here this is all we have in the Android manifest example we can see Android Build Version SDK 25.
So Android build version seven one, we can use those receiver in the Android manifest OC in this application
code, there's now another broadcast receiver and this might be missed by automatic tools right now.
So automatic tools might rely on the Android manifest XML to identify those broadcast receiver and they
might miss the following one.
We only are having this this one class main activity left because these are all our three classes we
have seen reset system safe data.
So now let's have look into the main activity.
And.
Oh, well, what do we have here?
Let's see.
Register receiver.
So this is not the Java code approach regarding to broadcast receiver, which is required for Android
eight and higher.
It will also work for Android seven of course, but it won't work vice versa.
So this approach doesn't work anymore in newer versions, and this one will work in all.
And this is why we are also talking about this one, because you need to be prepared for things like
this.
Okay.
It isn't that hard.
I mean, it's simply just an transformation of our code.
So here we can see within the on create method of our main activity, we are having this registered
receiver.
This is now our receiver.
We want to register.
So this is our name of the receiver, alarm system receiver.
Then we are having in parameter new intent folder and this one is now the action.
So this is equivalent to this one.
Over here and also this one.
Over here.
Okay.
We get an error because that's not in class right now.
But this is the equivalent if we are having this in our Android manifest.
All right.
Okay.
Let's undo this really quick.
There we go.
So now we are registering the alarm system receiver and we are listening for this action.
This is now in custom action.
We can see this on the package name already and let's see what this custom action is doing.
All we need to do is we need to look into the on receive method and ask the question where is this on
receive method?
Because we cannot see it anyway.
And this is regarding to this ID.
I do not know why, but if we click on this one as it working, then yes, then we get this whole context.
So I was also searching quite a while until I figured out, well, it just have been overlapped over
here.
Okay.
So now we've got the all receive method and then we've got everything together.
We've got our broadcast receiver name, we've got the action and he is the on receiver method.
So let's see what's, what's being doing.
So let's have a look what's happening over here.
Okay, we've got this time in variable name, so no system out and then leaving.
This time we are having an variable name and now it's getting spicy.
This variable name will be assigned with the things we add to our broadcast.
So our broadcast is taking some additional information in an intent so we can apply and string to our
broadcast event.
And the string is being based on a key value pair.
This one over here is the key.
So we have to apply an intent with the key status.
And then this that shows this value of the status will be stored in the alarm state.
In the line underneath we can see this alarm state will be will be compared against.
So if the string is so this means our key value pair needs to look the following.
We need to apply and key status with the string arm and then we would end up in this if statement over
here.
All right.
Don't worry.
We will do this afterwards.
And you will see this is super easy to do.
Okay.
So within here, we can see we are setting this text, we are setting another image resource and we
are printing out some text.
So here we put the alarm system right now based on a broadcast event, which is absolutely amazing.
What else do we have if this state is not armed?
If the state is disarmed, then we are performing in this arm of the alarm system.
All right.
And in case if everything is unclear, because we are neither having armed nor disarm, then we have
instead is unknown.
So here we can see.
We can execute or trigger certain paths in our application code based on the things we provide to this
intent.
This intent can be triggered by any application right now because it's not using a certain permission.
There isn't any permission defined in the Android manifest example regarding to this one, and there's
also no certain permission defined over here.
So an attacker could write its own malicious application and trigger this event from the attacking application
so we can arm and disarm in system as we have seen so far.
The only downside for this one is the application needs to run.
Why?
Because if the application gets started, we are we are starting the main activity and this is our entry
point.
And this one over here and this main activity is calling the on create method.
And this on create method is calling or registering this intent folder.
If the application is not running, we are not having an intent filter being registered, which means
we cannot interact with this broadcast receiver because it simply doesn't listen to our events.
This is the only downside right now, but imagine having an alarm system application which could be
armed and disarmed by a malicious application.
Absolutely amazing, right?
Absolutely.
So let's do this over here.
Okay.
Let's see how we can apply certain certain information to our intent.
Okay.
So therefore, we need to have normal privileges.
We do not require privileges anymore.
And then within the ATM, in the ATM, we've got this intent section over here.
We have already seen this dash A and here we have now all these extra key, extra string values.
So here we can see extra key, extra string, extra boolean, extra int extra long.
All we need to do is apply dash dash is and then we can append our, our information into this broadcast
event.
So we can simply say a broadcast dash a the action name.
We fetched us out of here.
Right.
And then dash.
Dash s status.
This is our key.
Key can be fetched out of this one.
Over here in tent.
Get string extra.
So this is something you definitely need to look for.
If you're having an on received method and there's something like intent, get string integer boolean
then have a look into this one.
What happens with the with this date and then we can apply a value.
For example, hacked.
Okay, let's open the ADB logcat.
Also the emulator.
And now let's execute this.
And here we go.
Status unknown.
Nice.
Maybe a little bit larger.
Yes.
Here we have an alarm.
State status unknown.
So we have now triggered this code path based on our broadcast event.
Freaking awesome.
So we need to analyze the application code.
What happens with our input?
Because this is when vulnerability cannot cure.
Unfortunately, we cannot simply tell that having a broadcast receiver and providing some information
to this one is in vulnerability.
We have to see what could be trigger.
In this case, it seems to be pretty spicy because we have things like arm in this arm.
But first, let me show you some other stuff.
If we go back to our our smartphone and if you're repeating this command and if you are not providing
any intent, so we are simply just calling this this broadcast event, then let's see what happens.
A 3 to 1.
Oh, and there we go.
The application has been crashed and we can also observe this in the ADB logcat output.
So let's scroll up and here we have it.
Broadcast receiver alarm said Yes, this sounds like us right now.
So we have to we have crashed this application and the problem is none point no exception attempt to
invoke virtual method boolean on and java string equal.
So let's see.
All right.
So what we are doing over here is we are fetching the value from our status.
So in this case, we are not having anything in here because we did not provide this intent.
We are fetching this value into alarm state and this is now being assigned to null.
So it's not even assigned.
It's it's simply having a knowledge state and then we are performing an alarm state equals so we are
performing null equals which would cause an exception because I mean we are not having something like
null equals based on the, on the smiley code.
We would have some registers which, which are being compared and those register one of them is being
null which, which will throw an exception because this cannot be correct anymore.
All right.
This means if we're dealing with broadcast events, I mean, we also have to take care of what we are
inserting and that we are being compliant with the code.
Otherwise we could crash the application, which might be also an absolute valid use case to crash in
certain application.
But right now we we do not want to crash this.
We want to interact with this application and now it's getting spicy.
So let's try to arm in this omni system based on a broadcast event.
Are you ready for this one?
Let's do this.
Okay.
We start with, um, so we have our status, our key status, and we want to apply this string.
Let's do this.
Uh, and let me give me some more space over here.
Look at us running.
Smartphone is.
We need to restart this application first.
Otherwise, it wouldn't react to our event.
Okay and now am broadcast that a ah state.
Dash dash s status.
I'm not sure if we need those quotes.
It might work also without them.
Okay.
Our key status and our values are let's do this in 3 to 1.
Nice.
We have armed this alarm system based on broadcast event.
Pretty amazing.
Let's disarm this alarm system.
So instead of aam let's call this aam 3 to 1 oh well now we have this aam the system so this is how
we can tamper around with broadcast events we can also see this notification alarm system disarmed.
All we need to do is we need to have a look into the Android manifest XML or the Java code.
It depends on the the build SDK version and then figuring out what's what's the action name and what
happens in the on receive method.
These are our steps to play around with broadcast receivers and this is pretty nice because developers
often underestimate the functionalities or the trouble and broadcast receiver can cause in the application.
They are most of the time, barely all the time being exported to the outside world.
And as an attacker we simply have to take a look into the on receipt method.
This is all we need to do.
And yeah, to figure out what we can tamper with this broadcast event.
Alrighty.
Okay.
Last but not least, let's have a quick look.
What happens if we try to trigger this broadcast event, which has been defined in the Android manifest
XML, but the Android build version is Android eight and higher.
So let's see what kind of error message we get, because then we know what we need to look for is something
is not working anymore.
So therefore let's go into the Android SDK 26.
The code is identical.
So just the the target version has been changed.
OC.
And no.
Let's start this one.
Let's open the at.
Maybe let's clear the lock and output, but I guess it will be.
Yeah, it will be full anyway.
So here we have now this application.
I mean, this approach still works because this is being defined in the Java code.
This is compatible to newer and also older versions.
This is absolutely fine, this one over here.
But if we now want to trigger, for example, the boot completed command, let's see.
I am broadcast.
There's a.
So over here.
This one.
And let's see what kind of arrow we get.
Or maybe.
And maybe let's do this with the battery first.
Yes.
Okay, let's.
Let's charge our phone up, Ben.
There we go.
And now let's lower the battery.
Okay.
So now let's take a careful look on this one.
All right.
We cannot see our text anymore.
Let's let's enlarge this.
So there's no system out regarding to the batteries being low.
And we can see.
Yes.
Background execution, not allowed.
Receiving intent within safe data.
So this one is not working anymore.
So if you encounter things like this background execution not allowed, it's not a problem regarding
to a setup or the actions you try to trigger.
This is regarding to the the that the Android version is too high right now.
So the developer has not updated the code in the in the Android manifest regarding to this one.
And to be honest, this is something that can easily happen.
But now, you know, if you if you see this, then you do not have to search for and back in your code
or in your setup.
It is regarding to the application itself.
Alrighty.
Maybe one last proof.
Let's trigger this boot.
Complete action with root privileges.
First, let's.
Let's charge the phone.
It would be nice if this would work in real time so it'd be locked and broadcast as a and then.
Yes, I still got it.
Okay, three, two, one.
All right.
We can see the other applications are reacting to this event, but in between those lock messages.
Yes.
This is.
This is something we have to do it differently.
We are searching for a pecking.
That.
Whoops.
There we go.
Yes.
Let's trigger this one second.
Yes.
Here we can see.
Background execution not allowed.
So the Android manifest approach doesn't work anymore?
Absolutely.
No problem.
Then we know we have to look into the Java code for those additional broadcast receivers like this one.
I mean, either way, we definitely have to look into the Java source code for and look for those on
receive methods.
So now we know how to deal with this and this is why we are here.
Right.
So if we are having tools that cannot perform this task, absolutely no problem.
We know exactly what's going on.
We've got the background information regarding to this one.
And if we have to identify broadcast receiver, at least after the reversing section, we will be able
to do this by ourself and then we do not miss anything in this application.
Alrighty.
So this is all regarding to broadcast receiver.
Have a look into the android manifest.
Also take a look into the java source code.
If we have talked about this one in the on receive method and then I mean, it depends on the code that's
being stored in there.
In this case we can trigger an arm and this command based on broadcast event which is absolutely dangerous.
Sometimes you have some really nice things inside here and sometimes, yeah, even by triggering them,
it's not a big deal like those two lane functions.
Alrighty.
Okay.
So in case if you have any questions, please drop them in the comment section.
Under this video, I will definitely answer them.
Otherwise, I hope you had a lot of fun and I'm really looking forward to see you in the next video.