- Hi, my name's Rion Carter,
and today I'll be presenting
on why my security camera screams like a banshee.
The talking on signal analysis and reverse engineering
of an audio and coding protocol.
A little bit about myself,
I'm a software developer, a security engineer.
I love to code, love to automate, love to solve problems.
I like to employ the hacker mindset.
Like to break things in cool and unexpected ways
to learn more about the system
and hopefully drive an improvement
that makes it better for everybody.
I love food.
Love cooking, love baking.
Recipe hacking is a passion of mine,
and when I can get a delicious result,
that really makes my day.
And then of course the standard disclaimer applies here.
All opinions are my own.
Don't reflect positions or thoughts of anybody else
or any current or previous employers.
So, let's get to it.
Got a few different sections to cover.
We're going to touch on what it is
that we're actually doing here.
The signal analysis piece, application analysis,
hacking the signal, and, if all goes well,
we'll get to a demo.
So, what are we doing here?
And why are we talking about wireless security cameras?
So, my original goal, before I even had the idea
to submit a Defcon talk was to use
an inexpensive wireless camera to monitor my garden.
And this is the inexpensive camera I selected.
It's got an antenna suitable for outdoor use.
This one's kind of interesting in that it has a microphone
and a speaker, so you could have two-way communication
if you wanted it.
The nice thing about this is that it was cheap.
So, and it seemed like it would do the job.
This sounds fairly easy and straight forward,
so what's the catch here?
I discovered after purchasing the camera,
unboxing it and examining it, that it requires
a cloud application in order to enable and pair the camera.
There's no way to self set up the camera.
There's no ad hoc wireless network.
It doesn't show up with a Bluetooth connection.
There's, when you plug in the USB cable,
there's no signals there whatsoever.
Also, there's no documentation online about this camera
to any real technical depth.
Not that I was expecting much from a $30 camera.
And then of course, what brings us here today
is the bespoke protocol that it uses to,
well that the vendor application uses to communicate
and configure the wireless camera.
So take a listen to this.
This is what really peaked my interest and sent me down
the path of trying to do a Defcon presentation.
(electronic noise)
So that's the sound that this vendor application makes
to interface with the camera and configure
it to connect to a wireless network.
I have to say I was not expecting that.
That's not usually how you configure things
like security cameras.
So, my new goal after finding out that it uses
a sound wave signal to configure the camera,
was to find out what was going on in the camera set up,
and see if I can't hack on it and replicate it,
and if possible, cast off the shackles
of the proprietary cloud enabled app
that the vendor supplies.
So, let's investigate.
First thing you want to investigate is the hardware.
And as I mentioned before, it does have a USB cable.
This connector though only supplies power.
When I trace the leads,
there's no activity on the data pins.
Other investigative angles, of course, check for Bluetooth,
check for ad hoc wifi.
And unfortunately, after many hours of trying all sorts
of different permutations of things,
pressing the reset button, holding the reset button,
scanning with wireless scanners, et cetera.
Nothing was advertising.
So that left me to investigate the software
in a little bit more detail.
This is the vendor application that comes with the camera.
It's called JAWA.
And it's used to configure the cloud camera.
However, like I mentioned before, I wasn't really a fan
of having to use this proprietary cloud locked application.
JAWA requires an internet connection.
It also requires a username and password to be configured
with this cloud set up.
So that made me a little frustrated,
and incentivized me to poke around some more.
Now, in order to analyze the vendor application,
I needed a test device.
I didn't want to run this on my primary phone
just being a security paranoid person that I am.
I don't really have a trust for applications that come
from from dubious sources, like the manufacturer
of a $30 cloud enabled camera.
And as I searched online for information either
about the camera or the application,
probably not too surprised to hear
that there wasn't very many, if any results that were found.
I did uncover a few other camera models that seemed
to use the sound audio wave signal approach
to configure the camera for Wi-Fi network.
I don't have any of those though,
and I just more list them here as an interesting aside.
There are some cheap cameras though which leverage,
in my opinion, a far superior approach to pairing
the camera to a wireless network.
And that's having the app show a QR code
that you then scan with the camera.
I mean the camera has, well a camera,
and scanning a QR code is a fairly straightforward thing
to do in 2021.
So I doubt, or I should say, I wonder if there'll be many,
if any, more cameras out there,
which leverage this audio coded approach.
So, now that we've taken a quick pass at the hardware
and the software, let's think about this signal
a little bit more.
See what we can identify and figure out.
And along the way, let's think about what are some things
that we can think about
or look for as we analyze the signal.
Of course, the first thing is we'll want
to capture and visualize the signal.
We'll be looking for things like repetition,
the variation in replay.
And if possible, we'll try to fuzz and simulate
the signal in a way that can hopefully track
with a valid coding.
This is the raw view of the signal as captured by Audacity,
and visualized in the spectrographic view.
Just taking a quick look at this.
It's pretty clear that there are distinct tones,
and there appears to be steps.
This isn't a continuous wave form that gets transmitted.
There's individual tones, which are given certain slices
of time, that are transmitted for a certain amount of time,
and then other tones are played after that.
Taking a look, it seems like a lot of the signals
are centering at least here around 3,500 Hertz
with a few outliers on the low end of the frequency range,
and the high end as well.
So that is something worth noting
as we go about analyzing the signal.
Now, let's see.
One thing that I thought as I was looking at the signal is,
is this similar to a modem signal?
It's been an awful long time since I've heard a modem,
and obviously modems encode their,
transmit information using an audio signal.
So I did a quick comparison against a recording
of 56K dial-up modem establishing a connection.
And just by looking at these wave forms,
it's pretty apparent that it's not a 56K modem.
The spectrographs are substantially different.
And this protocol, this audio protocol that they're using
to configure the camera it's bespoke in the sense
that you can't find information about it easily,
and it doesn't track with other common audio protocols
that you might think of like modem or fax.
So, looking a little closer at this with our eyes.
I marked out a few sections that appeared interesting,
just really highlighting the signals that appear
that are extraneous, or that don't really track
with what the rest of the signal offers.
And on the left of this slide here,
I put together, I guess what I'm calling
a collapsed spectrograph view,
where I basically took all of the tones
and I slid them all over to my left,
and just lined them up to see which tones
and frequencies were represented.
And you can see that it does center around 3,500 Hertz.
There's a small gap above 4,000 Hertz.
And then there appeared to be some things at the higher end,
at the higher register range.
Now, a picture is nice, and it helps us understand
maybe how the signal is structured.
But a picture can only take us so far.
We'd like to get more precise and better understand
what is actually encoded in this signal,
and kind of what the protocol is for actually encoding data
into the signal.
With a manual approach, we can keep using a tool
such as Audacity or other audio editing tools
that are out there.
With Audacity, though, you can use
this functionality called labeling.
You position the cursor over each one
of those sections where there appears to be a distinct tone.
You press Control + B and it will cause Audacity
to label that time slice, and mark the frequency
that's detected at that point in time.
And so you can see just in the signal in this picture here,
it might be a little smaller.
A little hard to see, but I've got a bunch of labels
on each one of these tones.
This next view here is the Audacity view where you can view
the labels that you've taken.
You can go to edit labels, edit labels,
and you can export them to a text file,
which you could run through some other type
of automated analysis, or plug it into a spreadsheet,
or what have you.
Let's take a little closer look at this.
And you can see that Audacity is mapping a low
and a high frequency that it detects at that time slice.
These frequencies are a little variable.
So to me it looks like this puts us in the ballpark
for what each of the target tones are.
I don't imagine the vendor application
is really putting out 5,101.89 Hertz.
It's probably something a bit more round.
We'll figure out more about that as we go along
in this process.
What do we know now from doing our quick manual analysis?
We can see that there is encoding going on.
There's a digitized signal.
But the signal isn't binary,
it's not like it's just two tones, one and zero.
There's a range of frequencies represented here.
So there's some type of digital encoding going on.
The frequencies seem to be centered in the three
to five kilohertz range.
And my suspicion is that the signals
that are outliers at the top of bottom
are control signals, and that they warrant a closer look
for investigating how the signal is put together.
And we see that there's repetition.
I noticed that in my analysis of the vendor application
and the pairing tones that it produces.
The complete sequence repeats itself multiple times,
at least three times.
So, and then finally,
we can see that this is not a 56K modem or fax signal.
The spectral analysis just do not match.
So at this point, we have to ask ourselves,
is there really much further that we can go in manual mode?
And the answer there is yes, but with a set of caveats.
There's variability whenever you play back the audio signal.
I found that each time I played back,
even the same signal from the vendor application,
that Audacity would slightly vary,
that the Audacity analysis would slightly vary in terms
of which frequencies
it shows when you do the labeling process.
And of course, manually going through the process
of playing a signal from an application,
recording it into an audio editor,
and doing that over and over again.
It's very time consuming.
Since again, the app repeats the same signal multiple times.
So even after you get a complete signal captured,
you have to wait for the app to finish its full cycle
before you can kick off another test permutation.
And, just to be clear,
the only options we have to configure
in this vendor application are the SSID and the passphrase
for the wireless network.
So there's not a whole lot of things
that you can vary for the input.
Then, one thing I noticed
is that there's no readily apparent API
to leverage the frequency detection portion of Audacity.
There's no CLI option.
There's no readily available API option.
And while I could have dug deeper
into the Audacity code base to better understand
how that's put together and hook into it,
that really wasn't what I was trying to go for.
That would be more of an aside as opposed to helping me
on my main journey to reverse engineer
and better understand this audio signal.
So with manual mode,
we can do black box signal reversing.
We can try to brute force reproduce the tones.
We can attempt to match generated tones
with spectrographic views.
And then of course, just fuzzing generating permutations
until we find a match.
This is a very tedious and a time consuming process though.
So I was looking for a better way to leverage what I have
and what I know in order to improve this process.
So really the next step here is to do an analysis
of the Android application,
since the Android application is what generates
the audio signals.
And, let's take a closer look at this vendor application.
So.
How do we go about analysis of a software artifact?
We could do things like executing it and logging the results
in a sandbox or a test environment.
We can decompile the package.
We can look for strings,
anything that might relate to the audio or sound
or SSIDs and passwords, things of that nature.
We can do a key method search since Android uses
a higher level language, or at least I should say this,
this APK is written to a higher level language.
And even though vendors can obfuscate their code,
it's a lot harder to obfuscate
the underlying library functions that you use as a vendor.
So you could do a search for Android system calls
or Android libraries that provide methods
that you might need when dealing with audio
and audio and coding.
Once we figured out these code paths,
we can attempt to do high speed fuzzing.
And then of course, if we identify something
that has been obfuscated,
we can try to go and deobfuscate it
and attribute the classes, the methods, the properties,
some other identifiers, which makes more sense to humans.
And it helps us better reason about the code
to really figure out how this all works.
Now, let's talk a little bit about preparation.
You'll need to prepare your computer to pull the APK off
of your test device.
If you've done any of this,
if you've worked with Android before,
you're probably already familiar with this.
And you need to make sure your developer mode is enabled,
that you've allowed USB debugging.
Make sure that you have Android Studio installed,
and that version of ADB is correctly placed in your path.
So that way you can leverage it for the purposes of this.
You'll want to extract the Android package.
And here I show a few commands that you can use
if you want to follow along afterwards and try this.
You'll want to make sure that you take the output
of each step and feed it into the next step.
Since what I have here is really only applicable
to a Blackberry priv, 'cause this is the test device
that I had lying around after all these years
to do this analysis on.
Once you have the APK, you can use a tool to decompile it.
I leveraged jadx, you can go to the GitHub page,
pull the latest release, and then it's very simple
to decompile the code.
Just a quick one liner.
You will probably note that it'll show finished with errors.
I found that the errors did not negatively impact
my analysis of the package.
And I was not impeded in my journey.
Once you have the decompiled sources,
you'll want to open up a new Android Studio project.
Open the decompiled sources from jadx,
and then click a little button
in the lower right-hand corner that says configure
the Android framework.
By configuring the Android framework,
it enables you to do things like find usages
and go to definition.
Just all the goodness that you'd expect
from a modern IDE.
Once it's loaded, you'll see a bunch of classes on the side.
The one that I have highlighted there is a U.ALI,
which is clearly obfuscated.
As you drill into there,
there's a bunch of obfuscated classes and methods.
Now, quick note on obfuscated code.
What is obfuscation?
Sometimes software makers
want to hide their implementations.
They want to impede you from figuring out how they work,
and from reverse engineering it to better understand
what the underlying mechanisms of its operation are.
With higher level languages,
you get a terse randomly generated identifiers.
You might have a class named lowercase A.
You might have a method named F999,
or just whatever the case may be.
It's harder to obfuscate the use of system libraries
in a higher level language.
Since those decompile cleanly back to base libraries, so.
Why do we use Android Studio?
Or I should say, what's the advantage
of using Android Studio
is in your manual deobfuscation process.
It's a very slick IDE, it's free, it's readily available.
It receives a lot of support, a lot of people use it.
And then of course you get
all the classic IDE functionality like find usages,
go to declarations, things like that.
With Android in particular,
you get a LogCats instance or LogCat window,
which lets you search.
You can also target specific applications that are running
on a phone to reduce the verbosity of the messages
that you see, and better help you tailor your analysis.
Let's take a look at what we can do with this application.
So live log analysis.
This is one of the first things I try
because being a developer myself,
I know that oftentimes the debug logs will contain
a wealth of information.
And as a regular user of the phone or the service
of the application, I regularly user's not going to see
the debug output.
So if you're rushing a release out the door,
and you don't disable your debug output,
somebody like me is gonna come along
and hook up the Android phone to LogCat
and investigate for messages if we're curious
about what's going on.
Now, let's take a look at what logs we get
as we start this application.
Here's the login screen.
Here's a little capture from LogCat.
And we can see that there's some interesting information
in there, there appears to be some kind
of an encoded payload.
There's some interesting strings in there.
And we appear to be getting both informational
and debug output.
So, there's a URL that ap.jawalife.net.
Go JAWAs!
And then as we kind of continue scrolling
through the screen
that there's a lot more messages like this.
When you try the camera pairing process,
you have to enter in the SSID and the password.
And at this stage, we see that there's log output
which logs the SSID, the password,
and then what appears to be some kind
of a randomly generated token.
And in this log output, I know it's really hard to see here,
but there's a class that we can start to investigate.
And then there's what appears to be an HTTP helper class,
which is what helps us send and receive messages back
from the cloud server.
Let's try to pair to a camera and see what we get.
So there's a button that says click to send the sound wave.
Just to love it, it makes me smile when I see that.
And when we send the sound wave,
we get some additional information.
And it may not look like much,
but there are a few strings here which can help
in the analysis.
We found, just to recap what we've found so far.
We found a distinctive characters.
We found URLs.
We found a class to investigate
this bind device new activity.
That sounds particularly fitting given
that we are trying to enable
and configure a new camera device.
So, what does this lead us?
We can continue our search by taking those strings
that we found in the log outputs,
and searching for them within Android Studio.
And as I searched through the decompile output,
I found a few things.
It looks like the number one is used to delimit fields.
They call the random generated code,
they call it a SmartCode.
Then, there's a string one that's appended at the end
of this little message block.
And even though Android Studio is calling
this message DB notify reached,
I kind of wonder if this isn't a decompilation artifact
of some kind, because it really is just the string
of the character one.
So, what is the SmartCode thing?
I noticed that each time I tried to pair via the camera
to the cloud app, this SmartCode would change.
It would be different every time.
And I could see by looking at this boot up code,
that yes, every time that you attempt to pair the camera,
you get characters and numbers for six characters,
and that constitutes the SmartCode.
But the question still remains, like, what is this thing?
And just after having gone
through this entire analysis process,
and seen it change with every single time
that I attempt to pair,
and noticing that whenever I paired the camera,
a message was sent from the application
up to the cloud server that included the random code.
I can only presume that the backend cloud service uses
this random code to tie this camera
to my user account in the cloud.
Since, how else is the camera going to identify
that it belongs to my account?
So that's the best case that I have
for what this code is used for.
As we continue looking through the strings,
we can see other strings which guide us to processes,
sorry, to functions,
methods that warrant further investigation like run
and play voice.
Both of those sound, they sound good.
Let's take a closer look and do an extractive analysis.
At this point, we've uncovered a lot of functions,
a lot of methods, static constants in the code base.
And we want to take the key sections
out of the vendor application, put them in a clean project
so that way we can perform an analysis.
Just a couple of notes on setting up the clean application.
If you're looking at another application,
which like this application here,
leverages native libraries,
you'll need to manually create a jniLibs folder,
put all those compiled libraries in the jniLibs directory,
and then you'll need to make the JAWA class that matches,
the package structure has to be the same.
So this thing is called like calm.ithink.voice
in the vendor application.
I can't call it calm.test.reverseengineer,
I have to name the package structure the same.
Because the way that JNI works,
it requires those two things to match up.
And once you have your sample test project set up,
you're able to perform black box analysis
of the code that's used to generate the signal.
And along this way, one of the questions that I had was,
well, what are the exact tones that are being generated
by the application to pair and bind with the camera?
Well, there's a class called VCodeTable.
And as I ran it in this extracted project,
it produced a mapping of all of the tones.
All the tones along with the characters that they map to.
So this is what the characters map to.
We have from zero to 4875 Hertz.
And there are 16 states, so this is a hexadecimal style
and coding here.
Now, looking at what else we found here,
there's a lot of findings.
We know that Android uses AudioTrack,
we know that the application uses AudioTrack
to play a signal.
We've identified how it creates the payload,
as far as the SSID, the password, the random code,
and then the delimiters between those fields.
We've identified control tones,
like a frequency begin and frequency ends
that are just static constants.
There's also a space tone, which is used for
when two tones play back to back the same tone.
There's a little space tone that pops in,
and that'll be better visualized in a later slide.
There's methods which play the characters,
there's the use of a CRC values to help the camera
know if it's received a complete signal or not.
So, there's a been a wealth of information
that we've uncovered through this process.
So, what do we know now?
We can reconstruct all of section one and section two
of the signal.
'Cause each signal consists of three sections.
And now that we can reconstruct section one and section two,
really that just leaves section three.
And I've highlighted in this image the part of the code
which is, sorry, the part of the signal
which is elusive at this stage in the analysis.
This tone appears to be some type of error correction code.
It doesn't exactly track what the CRC process
that the rest of the code base uses though,
which left me wondering.
And since this is generated by code
that's in a native library,
it means that I need binary analysis
to dig deeper and try to figure out what's going on here.
My tool of choice is Ghidra.
I don't know how to pronounce that.
It's a free tool.
It's very capable.
And it does the job here.
So to get set up with Ghidra,
you'll want to visit their GitHub page.
Pull the latest release for your platform,
and then follow the installation guide.
Once you have Ghidra installed, create a new project,
fill out all the wizard boxes.
I just took basically all the defaults
and gave it a project name.
Click the dragon icon.
Import the native library that you want to analyze.
In my case, I just went with the x8664 library
since I am a little bit more comfortable with x86
than I am with arm library at the moment.
When you click the yes button,
it'll go through and it'll do an analysis
of this compiled library,
which you can then navigate in the UI.
So, reverse engineering with Ghidra.
We need to know what we're looking at here.
So, you want to go to your Android Studio project,
make sure that you identify which functions,
which methods in the higher level language map to functions
in the compiled library.
Once you know that, you can look in the symbol tree,
and you can see here that there's a number
of a JAWA com interrupts.
So JNI interfaces here in this native library.
The methods that we're looking
for are the get voise structures that are listed towards
the bottom of the screen.
And here's a closer view on what you would see in Ghidra
as you do this analysis.
So, now we just need to pick one of the functions
and dig in.
I focused on this intuitively named function
called "getVoiseStructGoke2."
So I love the spelling of voice,
and I don't know what Goke2 means.
This is the function though that generates the section two
and section three output for the audio signal.
One thing that I noticed as I was doing this analysis
is that on the JAWA side, you pass in eight parameters
to this native function.
Yet on the compiled side,
when we look at the function signature in Ghidra,
there were 10 parameters here.
So, it seems a little odd,
but then doing a little bit of reading I found
that JNI call in conventions add two parameters.
There is a, yeah, let's talk about the note on JNI.
There's a JNI environment pointer,
and then there's an object pointer.
And these two parameters are front loaded
to the function signature.
So those first two are just the environment and the object.
So this top picture is the raw decompiled view.
Just with all the generated identifiers
that don't really make a lot of sense.
The bottom picture shows it refactored in Ghidra,
to indicate that the first two parameters are JNI related.
Now let's continue the analysis.
Okay, so inside of Ghidra,
there's a function decompiler window.
And the nice thing about Ghidra, it's like most other IDEs
that I've worked with.
You can right click on an identifier, you can rename it,
you can highlight it.
You can do things that'll help you analyze
the flow of how a particular parameter
is used and manipulated.
So, this function, this getVoiseStructGoke2.
It calls another function that leverages the inputs
that are passed into this function.
What I do when I do this type of analysis
is for each screen that I'm on,
I try to rename and refactor the parameters and the methods,
the functions, to names that actually
make some degree of human sense.
So that's what I'll be doing here.
This is the cleaned up view.
And I know it's small, but the picture shows
that each of those parameters are named to reflect
what value they represent from the Android side.
And then, I go from there, I check the usages.
Since this is decompiled, there can be a lot of,
sometimes it doesn't exactly make the most sense.
Like I noticed that input parameters
are copied to local variables,
and then those local variables are then used elsewhere.
So, in the analysis,
just keep in mind what you're looking at,
track the flow through any type of intermediate steps
that it goes through,
to see where it winds up being manipulated.
Now, this is the raw view of that nested function.
Fortunately for me, and almost conveniently
so for this demo, this is a very small function.
There's only about 58.
Yeah, actually about 56 lines long.
So it makes it pretty easy to analyze.
Again, since the identifiers are all terse
and auto-generated, I need to refactor those into something
that I can use.
So, start with what you know, find a good starting point.
Even if you can't get all the names
to something human readable, just to do what you know,
and as you reason through the code,
you'll find that the rest of the pieces
can fall into place sometimes if you enter what you know.
As I went through this and did all of the renaming,
I found that the critical section,
the critical operation that I needed to apply
in my reverse engineering project to replicate
the signal three, it just came down to a shift.
So, this is the line.
It takes the CRC SSID, and then it shifts it to the right.
So, that's a very simple operation for me to perform
in my replicated Android project.
It is not something that I was able to figure out
just by reasoning through the JAWA,
or by passing in inputs to the library function
and fuzzing the output.
I think probably with enough time,
I probably would have figured it out,
but I get a little impatient,
and when I can go explore a little deeper
and a more fully understand how something works,
I'll take that opportunity.
So, a shift, that's all I got to do
to replicate section three.
Now, let's think about hacking the signal.
How can we recreate this and manipulate
it to serve our purposes?
So, let's look again at what we know.
This is the spectrographic wave form
of a complete pairing cycle.
The wave form is comprised of three sections
of hexified data.
Each section is prefixed and suffixed by control codes
and section identifiers.
We know that when two sequential tones are used,
there's a space tone that shows up in between it to help
the camera better differentiate
and identify distinct signals.
The duration of each tone that I found
is about 50 to 60 milliseconds.
And we know the structure of each wave form section.
Let's look at section one.
This one's a long one.
It's got frequency begin.
It's got delimited, SSID, passphrase and random code digits.
It has a CRCs of a bunch of data put together.
And then it's got end tones.
Section two is incredibly simple by comparison.
All it's about is the SmartCode,
and just making sure that there's
a proper error correction on that randomly generated code.
So that's very terse, very short,
very easy to reason through.
Section three.
Yeah, this one's a little bit longer as well.
We have some CRC codes in there.
We have another kind of like mutilated version
of the SmartCode.
There's a passphrase by itself, another CRC,
and then this thing wraps up.
So, we can reproduce the signal now.
We know every aspect of every part of the signal,
and we are able to recreate it as a result.
So, that's where the demo comes into play here.
I created an application which can be used to pair
this wireless camera to a wireless network
without having to use the cloud application.
This enables the camera to be further analyzed
using more traditional
but network style of investigation techniques.
So with that, let's go ahead
and let's take a look at the demo.
In this demo, we'll be pairing the wireless camera
with a wireless network
that's hosted on this laptop running host APD,
advertising a Defcon 29 SSID.
To do the pairing, we will leverage
the reverse engineered application that I created
as part of this kind of reverse engineering process.
Where I've configured the SSID and passphrase.
Now, to get this camera to pair,
we need to wait for it to get into setup mode.
After I plug it in,
we'll want to wait for the flashing light.
And at that point,
the camera should be susceptible to our suggestion
that it paired to a specific network.
So, I'll plug the camera into the power bank,
and start it up.
On boot the camera shows a solid green light
to indicate that it has power.
After it goes through its set up sequence,
whatever that entails,
I haven't been able to really probe that.
It'll go into a flashing light mode
where we can pass it along our message.
So, let's give this a try.
(electronic noise)
All right.
With that tone, it should indicate
that the camera has received our pairing message.
And in the Wireshark capture,
you will see that the camera is communicating
with the network, and that it's paired.
So that is looking good.
Let's take another look at the pairing,
this time from the screen recording
that shows the Wireshark output of our packet capture.
As the camera goes through its visualization sequence,
receives our pairing code,
it should show up requesting an address.
Which in this case,
I've targeted to be a specific one in advance.
You can see here that it receives an IP address
on the local demo network,
and it proceeds to query back home
and attempt to call home and do the cloud configuration bit.
We're going to try connecting to the camera's video now.
One thing I do want to note about this camera
is that the video connection can be a little bit iffy.
It doesn't always work
and can require three, four, sometimes upwards
of five different attempts to get the video signal to work.
Here I'm showing an attempt to connect
to the camera using VLC, and surprise surprise.
It fires right up.
So, go figure.
Let's go ahead and wrap this up now.
There are a few limitations that are worth noting.
It's not easy to discover
the device's administrative password.
It is six hexadecimal characters.
And the password changes each time the camera is reset.
It doesn't seem to be tied to macro serial number.
So just kind of brute forcing your way
through it might be one decent option.
The easiest option is just to have it pair once
to the cloud and pull the password off of that.
That is not the approach that I would prefer
if at all possible though.
So, it's not possible or not really very easy I should say
to decipher the camera to cloud communication,
based off of some of the code that I've seen
in the application and what I've intercepted
between the camera and the cloud servers.
The camera has a local RSA key pair that changes on reset
or potentially between each request.
The payloads are encrypted and sent over to the server.
So even though you can view the payloads by setting
up a self-signed demand in the middle server,
you can't really make sense of what the payloads are saying.
So, could be worth some additional investigation.
You also get what you pay for,
even if you know the password, it doesn't always connect.
VLC will sometimes connect and sometimes it will not.
So, just keep that in mind
if you want to economize and save a buck
or two on a cheap wireless camera.
So, thank you very much for attending my Defcon talk.
It's been a real pleasure to spend this time with you today.
So thanks.