Welcome back, guys.
This video will be absolutely wild.
I mean, you can see this already regarding to my hair.
But in this video, we want to do something which is not 100% related to Android app hacking, but I
mean, nevertheless, come on, let's have some fun over here and let's have a look how we can analyze.
And Bluetooth low energy connection.
Why is this important?
Because normally we've got our device in this one, for example, and this is making an HTTP or HTTPS
request, I hope it's https to and web server.
So this device is using the Wi-Fi connection or the mobile carrier network to perform this network request.
And this is something we can easily sniff.
We will have to look into this in the man in the middle section.
But nowadays we are not just dealing with apps and servers, we are also dealing with a lot of Iot components.
For example, this toothbrush over here, I mean, you can see I'm not using it very often, but it
would be important to use this.
So this toothbrush gets an app and they are communicating by a Bluetooth low energy.
The question is now, how can we analyze this connection?
I mean, this is not Web traffic right now.
This is Bluetooth, low energy.
And we cannot have look into this connection because these are radio waves.
An easy solution for this one would be locking the traffic that the application is receiving and sending
to this toothbrush on the device.
And this is exactly what we do in this video over here.
And then we can use this knowledge to also extend this to other devices, for example, to this one
over here, this super annoying, fluffy little Furby.
So are you ready for this then?
Let's have a look.
All right, back at Ubuntu VM.
The first thing we want to do is enabling the his new plug in the developer option and therefore we
need to have a real device.
I mean, not to enable this, but later on to communicate with a Bluetooth low energy device because
this is something we cannot use in an emulator.
The Bluetooth protocol cannot be emulated and sent out to any device.
That's not possible.
So in case if you want to play around with a real Bluetooth low energy device, I mean, you nevertheless
have to get an and smartphone, right?
Yes, absolutely.
Okay.
So let's do this.
I plug this in into the computer.
Right.
And then I can use the terminal to show you the screen on the smartphone.
So running screen copy there we have an oh, by the way, I did change the desktop background, so let's
put this on the left.
So the black background was not that nice to view regarding to the smartphone.
So therefore I have chosen it a little bit.
Yeah, a little bit brighter.
Okay.
So let's enable the high new block.
We go to settings and then within let's see the system.
Advanced developer options.
So here we have them.
And then I'm searching for Bluetooth.
HCI.
There we have it.
Bluetooth hits, new block.
Let's click on this and see.
We can see it's being disabled, so let's click on it.
And here we have now two options enabled filter.
But we do not want to have filter.
We want to have everything.
So we choose enabled.
All right.
And that's all.
The only thing we have to check is that Bluetooth has been enabled.
Yes.
So this is all we need to do to create this log file.
So now all this Bluetooth connection will be locked into a certain file, which we can then later pull
from this device and use it within Wireshark.
Awesome.
Right.
So let's see.
As already mentioned, I've got this toothbrush over here, and this one has an application.
And no, I'm not getting paid by Oral-b to show all of this, but I think having this toothbrush over
here illustrates this pretty nicely.
So this is, let's say, an Iot device, and this one is communicating with the real smartphone based
on Bluetooth low energy.
All righty.
Okay.
So if I open this application, let's see.
We are greeted and we can see connect to a toothbrush with this app and brush like a pro.
I mean, this sounds absolutely awesome.
Let's do this.
Let's click start first allow location services, of course.
But this is unfortunately something that comes with Bluetooth low energy.
So that's unfortunate and permission we have to use quite often regarding to this one.
Okay.
Only this time.
And connect your toothbrush.
All right, start.
And now all I need to do is pressing this power button.
However, so we can see this toothbrush has been now connected to this smartphone over here.
Amazing, right?
Okay.
So we can go ahead.
Oh, let's see.
Terms.
I'm at least 18 to brush my teeth.
All right, sounds.
Sounds pretty ridiculous.
Let's brush.
Okay, now, if I press this power button, then we can see this pop up appears, and it's super annoying.
Loud.
So we can see how a pause brushing session ends in something like this.
And we can also.
Let's see.
No, it has to be on.
Okay, so I'm re enabling this.
You can see reduce pressure.
I'm I'm brushing by two to a half my teeth right now.
All right.
So all of these information are being transferred via Bluetooth, low energy to this smartphone application
to this one over here.
And yes, now we want to analyze them.
So we have locked every single request right now.
And now we can yeah, we can pull those data from this device and analyze them in Wireshark.
Awesome.
Right.
So let's see.
Okay to do this, we need to get to his new block file from the device.
And unfortunately, this is sometimes a little bit ridiculous hot.
So it depends on the manufacturer, the device and also the version where this file is being stored.
But I've got an easy solution for you.
The easy solution would be creating a pack report.
And this pack report includes this file.
This pack report also contains a lot of other information which is not really necessary or relevant
for us right now.
And it costs a little bit more time generating this, but at the end, it's the easiest way to fetch
this file.
All right.
Okay, so let's see how we can do this.
Oh, I need to brush my teeth a little bit longer the next time.
But I'm I'm even glad that I'm using this device right now, so this application shouldn't complain.
All right, so let's open a new terminal, and then I'm using ATP Back Report and then I need to provide
an file name.
Let's call this brush, dot, sip or brush underscore report sip.
I mean, as already mentioned, this is not just the Bluetooth, his new block report right now.
This is everything.
It's also interesting to have look into this one.
But I guess right now let's focus only on Bluetooth.
All right, let's hit this.
And yes, I also got a little vibration on the device, but it automatically starts.
This might take a few minutes because a lot of information are now being gathered.
And I will fast forward this process that we do not have to wait that long.
All righty.
Okay.
So here we are back.
I guess it's it's finishing pretty soon, but don't get fooled by this by the status bar over here,
because it immediately jumped to 93% and then it got stuck for a few minutes right now.
Okay.
So let's see.
And this fight, by the way.
There we have it.
If we are using ATP Back Report and then the SEP name, this one is being executed from our host system.
So the ATP Command is connecting to this device, creating this report, and automatically fetching
it on our host system.
So wherever we have started this ATP Back report there should be now and file name the brush underscore
reports it and let's see.
Yes.
Here we have it so we can see it's five and be large.
Let's extract this.
Okay.
And we've got now tons of information.
So this is sometimes also useful for applications because we can we can find a lot of things.
We can see crashes, application states and much more.
Right now we want to focus on the his new blog and to be honest, I guess it's within PFS, but I'm
not sure where it is here.
So let's see prop by the way.
Yeah, that's the memory.
So every ID, it's the process ID and we will find memory information of this process.
So pretty awesome.
But back to this one.
So I'm now in the PFS directory and I'm simply searching for HCI and here we have it.
It is within data, misc, bluetooth logs.
So let's go into this directory maybe.
Oops, data, misc Bluetooth logs.
Yes.
So here we've got last and we've got this HCI log.
This is now on file which can be directly, directly opened with Wireshark.
So therefore, let's see, let's perform and right click open new terminal.
And now let's use Wireshark on this file in case if you do not have Wireshark installed, it's pretty
easy.
We can simply run sudo app, get install Wireshark and then it will be installed.
I guess the only question that you have to answer is if you want to allow capturing packages for root
users or also for normal users.
So normally I start Wireshark with root privileges and therefore I select and trust for root.
But running Wireshark as root can be also pretty dangerous.
Wireshark is in package parser and if you run this in a not trusted environment, it can be possible
that an attacker sends and crafted package and compromises your host based on Wireshark.
In the past there were some exploits which demonstrated this behavior.
But in my case, right now I'm running this on a virtual machine in my trusted environment.
So therefore, I'm pretty I'm pretty confident starting this route.
All right.
Okay.
So after installing Wireshark, we are now using Wireshark on this new block.
And here we have it.
Awesome.
So this is now the whole communication between this toothbrush over here and this mobile application.
So all these packages that has been exchanged between those two and now in front of us locked in this
file which can be opened in Wireshark.
Absolutely awesome.
Right.
So now we can investigate which data has been exchanged and we might be also able to manipulate or interfere
with them.
Let's have a look.
All right.
So if you're looking at this file, it looks a little bit strange because normally if you're opening
and file with Wireshark, we expect some IP addresses because this is where we normally use Wireshark
regarding to analyzing network connections.
But now we're not analyzing a network connection which has the source and destination IP address.
We are now looking at a radio protocol at Bluetooth low energy, but the good thing is that all these
bits and bytes which has been exchanged between those two devices can be interpreted by BioShock.
So Wireshark is fetching all these bits and bytes and passing them into those Bluetooth headers, which
makes the analysis a lot easier.
All right.
Maybe not, but nevertheless, let's have a quick look into this one.
So the good thing is everything between host and controller can be simply ignored.
Nice.
So we can we have to scroll down to find our connection and let's see.
Here we have it.
All right.
Let's scroll up a little bit to find the first package.
I guess it's this one.
And it's even more amazing because Wireshark is showing us that this one and this is now the source.
This is our pixel device.
How does Wireshark know this?
Well, we can see HTC and then we can see three bytes.
So the Mac address consists of six bytes.
The first three are regarding to the vendor ID, which means in this case HTC.
So Wireshark knows.
Okay, that's an HTK vendor and this one is its it's known for on pixel device.
The last three bytes are being shown over here.
So these are just the last three bytes of our Mac address and the same of course, for our toothbrush.
But now it's a little bit strange.
Why do we have Texas insert over here?
I mean, we can see those last three bytes, but what is this?
Once again, this is the vendor ID, which means this toothbrush has most likely and chipset in here
from Texas Instrument.
So Wireshark doesn't know that this one here is in toothbrush, but Wireshark knows.
Okay, the chip in here is from Texas Instrument.
So therefore it's displaying these information.
Also pretty awesome.
I mean, without opening this device, we now know that this one has an Texas Texas instrument chipset
in here.
All right.
So further investigation, we simply just replace in our mind Texas instrument with toothbrush OC OC.
But now it's getting a little bit rough.
I mean, this course over here is designed regarding to Android app hacking, finding and identifying
vulnerabilities in mobile applications.
We are now looking at the Bluetooth low energy connection, which is not 100% related to this course,
but nevertheless, Bluetooth low energy is all around us nowadays and it's often used in Iot devices,
and those Iot devices often also have mobile application.
So it could be the case that vulnerability within this mobile application can be exploited based on
a Bluetooth low energy connection.
And therefore, I would like to cover it in this video over here, but only on a high level.
So we do not dive too deep into this.
I just want you to enable to understand what's going on over here in this connection that you are able
to identify and also explore this on your own so that you can identify those vulnerabilities and send
them to the vendor so that they can be fixed.
Okay.
All right.
As already mentioned, Wireshark is able to pass these packages by.
We get all this information within this info tab, and this is absolutely nice.
And for example, over here we can see the source pixel device, destination, toothbrush, and this
one is type request.
So our smartphone is requesting something from the toothbrush.
We do not know what, but we know it's in type of request.
Then we can see we've got get primary service declaration and this is something I would like to discuss
on the graphic tablet in a little bit more detail because there I can explain it way better than here
right now.
For now, get simply stands for generic attribute profile and it's working in the following way.
If we are having a mobile application, this one, this mobile application is asking this device, hey,
what services or characteristics you offer?
Those services and characteristics are simply just information, for example, and the information how
long we are brushing the information.
If we are if we are brushing too hard the information, if we have switched the mode of our brushing
routine and things like this.
So these are just data which can be requested.
All right, then.
Let's have a look.
Everything between control and host can be ignored.
And this means here we are having now a source, the Texas Instruments.
So the toothbrush and this one is now responding to our request.
So this is the response regarding to our request.
And this one is now answering with all this information we have, we have asked before.
Okay, let's scroll down a little bit.
Because see, we can see those packages.
I mean, we've got the timeline on the left.
Those packages will be sent more frequently, which means this could be the routine where I have actively
used this as a brush.
So therefore.
Okay.
And this one, for example, sauce is the is the toothbrush.
This one is now sending in response.
And let's make this a bit larger.
Yes.
So here we have now a lot of things so we can see we've got something with get characteristic declaration.
We will have a look on through this one on the graphic tablet.
Then we can see properties right and right.
So we can write and read from this characteristics and then we've got this long uid and so if we understand
this package right now, I guess we, we have some good understanding about the Bluetooth low energy
and therefore I do not want to dive deeper into those packages.
We just take those information with us on the graphic tablet.
We can see we've gotten get characteristics.
This one has some properties right and read and we've got this long UUID.
We can also open this one but yes it's it's not providing any more information we can we can just find
and service you ID beside this characteristics your it all right okay and now let's switch to the graphic
tablet and now let's have a look what all of these information means right now.
So therefore, let's go back to the graphic tablet.
I really had to get rid of my sweater because now we are doing some hot stuff.
No, I'm not going to make this joke till the end.
All right.
So back at the graphic tablet now let's have a look at this this connection on the left.
We've got our Voltron smartphone, this one.
Smart phone and on the right.
I mean, could it be even more exact?
I give you this example.
Could it be even more exact than this one?
Absolutely not.
So no further label is being needed.
But nevertheless, let's also name this toothbrush.
It just took me, I guess, some 1000 attempts.
And we have to deal with this one right now.
Okay.
So the Bluetooth low energy connection consists of an server and a client.
The server.
This one is advertising its existence to the client, which is, in our case right now, the smartphone.
But during a connection, this could also change.
I mean, the server can also interact as a client in the same connection type.
So it doesn't mean to be that the server always stays the server.
But let's make this not more complex right now.
So the servers advertising its existence via three different channels and this is important.
OC Why is this now being important?
Well, if you're using a smartphone, it isn't.
But if they're using an external device, for example, this phone over here, this is new Bluetooth
and we can see it has a large antenna because the Bluetooth low energy is on 2.4 gigahertz.
So this device is capable of sniffing Bluetooth connections near around me right now.
So I could listen to those connections.
And if they are not being encrypted, then I can see all the data and also interfere with them.
The problem by using an external device is having those three advertisement channel because if we are
listening on the first one on this one with our Ubuntu.
That's an idea, by the way.
It's definitely an idea.
So if you're listening on the first one and the devices are using the second advertisement channel,
then we're not sniffing anything, which means we need to get three of them to make sure that we really
fetch this this communication between those devices.
What I did in the past, I did run 20 times the same task to make sure that at least one has been successfully
completed captured.
If we are using a real smartphone, we can completely ignore this.
This is just a hint.
If you're using an Uber to device and sniff and Bluetooth connection and wonder why is there no package
in here?
All right.
So luckily we are having a real device and therefore we do not need to take care about those three advertisement
channels.
By the way, besides these three advertisement channel, the Bluetooth low energy protocol is in total
using 40 channels.
Which means three are being used for the advertisement.
37 Quick math are left for data transfer.
Okay.
So right now, we do not need to take care about this one, but this information is super handy if you
if you want to sniff in connection with an external device.
All right, let's clean this.
Okay.
So now we have our smartphone and the toothbrush and the way the communication works on a high level
is as follow.
So if we turn on this toothbrush here, we can see it's being it's being pressed.
Then this one is advertising itself and telling everyone, I am here.
All right.
The smart smartphone, which is the client, needs to scan for those devices.
So the smartphone needs to look if a toothbrush is near around us, I mean, we can identify those toothbrushes
based on the vendor ID right now.
But it could be also the case that we are having a different device with in Texas instrument chipset
and it's not being in toothbrush and therefore we're getting this information within this mobile application.
If we are really connecting now to our toothbrush, it could be also a different device or another toothbrush.
So this this information over here.
Okay.
After connecting to this device, the smartphone is now requesting information from this toothbrush.
So the generic attribute profile and profile within the toothbrush, it's just an unknown set of information.
And for example, this toothbrush has some profile.
So this is the profile.
Within this profile, we are now dealing with services, services.
And within those services there's only one left.
Then we are done within those services.
We are now having characteristics.
Okay, so I hope you can still read this and characteristic is simply just in data type.
So it could be the information about the brushing time, the brushing mode, tip brushing pressure and
things like this.
Everything related to brushing could be summarized within a service.
So to make this a little bit easier on the right, let's, let's write this in the following way.
So let's clean it first.
Okay.
So we are now having several characteristics.
For example, one could be brush mode, one characteristic could be brushing time, and one characteristic
could be also the brush brush brushing pressure.
So brush brush.
Okay, so this one, it's it's pressure.
Okay?
All of them have something to do with brushing so they can be now categorized.
Well, let's say summarized within a service.
So in service can have many characteristics and uncharacteristic is just an set of data.
For example, brush time.
So these are now those characteristics.
If the smartphone is now requesting data from the toothbrush, for example, about the brushing time,
then it has to ask this characteristic and to ask this characteristic we are having this UID and this
UUID is this long identifier based on hexadecimal values, so and so on.
So this is just unique identifier for this characteristic.
And it also has to be unique so we can define our own custom characteristics, but they are not allowed
to interfere with existing ones.
So some of them are documented and defined as in standard and some of them can be also defined by your
self regarding to certain sensors and things like this.
So if we want to fetch data from a characteristic, we need to provide this.
UID So the smartphone is now simply telling, okay, I want to have this brush time and this brush time
has this uid so the smartphone is simply sending this request.
Okay, give me some data regarding to this brush time and then the toothbrush is answering.
With those information so we can have different type of access groups.
So for example, this characteristics can be only read.
This is just in read permission.
Okay.
Then we can also have.
Right.
This means the smartphone is able to change those data in this characteristic.
So within the toothbrush or we can have something like notify.
Not if I simply means the client has to be configured for this, but not if I simply means every time
a venue changes, the toothbrush is automatically sending this information to the client and the client
can fetch this.
This is quite popular regarding to certain sensors, or could be also the case regarding to brushing
time or things like this.
Okay.
All right.
Besides this, we have a lot of more options.
For example, we've got requests that require response requests that do not require and response and
other stuff.
But I guess for now it's okay to have a high level overview like this one right now.
So over here we have now summarized everything.
The smartphone is asking the toothbrush.
What services do you offer?
And the toothbrush is answering with the following.
For example, if you want to fetch data from a service, we have to address this by the UUID.
Addressing this UUID also requires certain permission.
For example, this read, write or this notify permission.
Okay, so this is Bluetooth low energy in a nutshell.
The key takeaways are if you're using an external device like this super tooth, then then you have
unfortunately to set it up 20 times to make sure that you definitely have fetch this connection.
But if you want to analyze the mobile connection, then you do not need to worry about this.
Regarding to our toothbrush, we do not know what those u ids means.
What is the UID for the brushing mode depressor and things like this?
To find this out, we have several possibilities.
The first one is simply searching online for those u u IDs.
So we'll simply just take the string and put this into the search engine of your choice.
Sometimes they have been documented in some sticks and things like this and you can find additional
information.
In our case, it is exactly this the case.
So already the end of this one is providing an Android SDK where developers can write applications to
communicate with this toothbrush.
And this SDK has additional information or let's even call it exact information about the characteristics
and their purpose.
So I will show you afterwards within the Wireshark dump that we can match them regarding to the to the
documentation online, in case if we cannot find any related information, we have to try harder.
So what we need to do then is we need to repeat certain actions over and over again and for example,
turning it on and switching between those modes.
And we have to do this quite often, really often, and then identify certain patterns.
Often just a single byte changes.
Or we we are requesting the same characteristic over and over again.
And then we can figure out, okay, this UUID is serving the following purpose, right?
OC Weaponized with this knowledge.
Right now we will have an look into the existing Wireshark dump, but then we will also start hacking
something.
And you think we are going to heck is this one, this fluffy, annoying little Furby.
So this one is also communicating via Bluetooth low energy.
And I will show you a really nice mobile application which is capable to fetch all these information,
these generic attribute profiles and those UUID characteristics and also gives us the possibility to
send data to them.
All right.
Okay.
So first, let's have some quick look onto this toothbrush and then on this Furby, let's go back to
the Ubuntu VM.
We now understand all of this a little bit better.
And for example, we can see we've got here in response and it's an attribute list.
Okay, this is something we do not know right now, but we can see.
Okay, we are returning the following service uuid.
This has the following characteristic uid and we can also see.
But we have it here.
We have it properties notify and read.
So we are not allowed to write to this service or characteristic right now.
We still have no clue what this one is doing.
So as already mentioned, we can figure this out by ourselves by repeating those actions over and over
again, or we can simply look them up online.
Oral-b is providing an SDK for Android developers.
Unfortunately, it's not available anymore.
So on developer or repeat dot com, we can see that the store is currently unavailable.
But if you take a look into the Internet Archive, which is some pretty good source regarding to things
like this, we will find out that in 2022, only one state has been saved.
And this is exactly what we are having here.
So if we go back a little bit, for example, in in 2018 and then we can see we've got a few saved states.
So let's have a look at this one.
Let's click on the snapshot.
And now the Internet Archive is showing the site which has been stored at this given date.
And there we go.
The web developer program will be shut down on 15 of April, so I guess it won't be available pretty
soon right now.
Sometimes we can also find some cached files.
For example, this SDK.
Unfortunately, this time we are not that lucky.
So if you open this link, we can see this all has not been archived.
The Web Archive itself, it's an amazing project and very helpful.
So I have encountered some lost firmwares in the past regarding to the help of the Internet Archive,
so you should definitely check this out if you're looking for something and the current link is not
available anymore.
All right.
Okay.
Back to the video.
Okay.
Without having the SDK, do we still have some chance to identify what the issue IDs are?
Yes, because if you're searching online for this, we can still find some references to them.
For example, this UUID.
So let's see, I do right click and then copy value here.
I already have downloaded such and reference and if you are now searching for this one.
Then we can see this one is now this service.
And this service summarizes several characteristics of, for example, this handle ID, but I mean,
we do not have an exact definition what this handler ID is really doing.
We do not have an in certain description.
I mean, just handle ID, but here we can now see all these utilities and the Yeah.
The things they are good for.
For example, this one if we read and value from this one and Smiley appears on our smartphone, this
is something we could trigger by ourselves with an external device like the Uber tooth, which has been
shown before.
Okay, nevertheless, let's see if we still can identify this by ourselves.
So within the introduction of this mobile application, I did brush my teeth very hard.
So there were a lot of warnings regarding to the pressure of this toothbrush.
So let's see if we can find this information in the Wireshark, the OC.
And therefore I guess we have to scroll down because these packages they should be sent quite often
if you turn on this device and brush our teeth.
So let's see.
We already have many, but I guess that's.
Yes, here we had quite a few.
Yes.
All right.
This looks good.
So we can see all of them are regarding to the following handle.
So this UUID and we can see we are sending the value c0c000.
All right.
Yes, zero.
And what was the other 105.
Is it the exact.
No, this is a different handle.
We need to be very careful regarding to this one so we can see C zero and yes.
So oops, sorry.
On the left so far, yes.
C zero and zero zero.
So these are the two values we are sending to these characteristics.
So let's see.
Oh, sorry, the service.
So let's see what this UID is good for.
OC copy and then value.
Let's look this up.
Let's go down.
Unfortunately, it's not regarding to this one.
Oh, yes.
Are those two the same?
I guess not.
Let's see.
Yes.
Sorry.
My bad.
We can see perfect pressure sensor.
This one is the service UUID.
And this one is the UUID.
We are.
We are sending those data.
And if we have a quick look onto this one, they look identical because this UUID they have an certain
prefix and everything also is pretty identical.
Most of the time just a single byte in there changes.
Let's see.
Copy volume.
I make a new one.
This was the first value and it's also compared with this value.
And Paul here?
Yes, I've got it.
This character.
Let's see.
Yes, just one single character instead of zero.
It's B, so we need to be very precise when we look at those information.
So here we can now see, yes, this is now the pressure sensor.
And by getting maybe the value zero, everything is fine.
And by getting C zero, we are brushing by too hard.
If you now want to attack this mobile application, we have to think in the following way.
We've got our smartphone, which is running the mobile application and we've got our device so we could
impersonate our device and then send arbitrary data to the smartphone.
Or we could have the device and we can pair with this device and sending arbitrary data to this device.
So we have to we have to analyze both endpoints regarding two vulnerabilities or exploits in there.
Okay.
All right.
In case if you have any questions regarding to this topic, please drop me a message underneath this
video.
And now I would suggest let's have some fun.
Let's hack this super annoying little Furby.
All right.
Okay.
Let's have a look into this one.