One thing we haven't talked about so far is men in the middle, in the emulator, and this might be
required for you right now.
So you do not need a device to to perform this course over here.
And therefore, you might want to know how you perform this setup for an emulator, because we've got
some tasks to do in our man in the middle setup or in our man in the middle challenges.
And therefore we need to know how to perform this.
Alrighty.
Okay.
The reason why we haven't talked about so far is I'm really not a big fan of the setup.
So if you want to analyze the mobile application, then take your device, set up your network connection
via the network manager, provide the HTTP and DNS automatically via the shared connection.
Hook it up to your access point and you're good to go.
You see everything the network package, the smart phone is making.
Regarding to the emulator.
We have to rely on software, which means we have to rely on certain operating systems regarding to
the virtualization and this can cause trouble.
So therefore, yeah, I'm not a big fan of the setup.
Nevertheless, you can do every single challenge in this course over here with the emulator.
Also, you do not need to buy every device.
You can do this all on the emulator.
There's absolutely no problem.
And also regarding to testing railroad applications, I would claim 90% of all applications can be can
be analyzed with the emulator in case if you are analyzing Iot stuff with Bluetooth, NFC or maybe other
strange protocols, then I really recommend using a real device OC.
But for now, let's say no real device available.
We have thrown it into the water.
All right.
How can we do this?
Let's have a look.
Let's switch back to the boom, boom, and let's figure this out.
Okay, so here we are back at the Ubuntu VM.
And the first thing I would like to show is the the emulator bug, which is still out there right now.
So I have already describe this in the tools.
And if you heard this now twice then sorry for this, but if people jump directly into this man in the
middle on topic over here without going through the installation part, then this might catch you right
now.
Okay, so what's the problem?
If we want to start our emulator, we've got, I guess, two options.
The first one is via the Android studio.
So let's have a look into what's been a solid Android studio then and then bash studio dot as this is
the approach I'm normally not taking because we are now starting Android studio to just that another
tool which could be directly started.
So why go this way?
But nevertheless, within the Android studio, the debug output is a little bit better than on the terminal
just for the emulator.
So sometimes it's handy within configure if you're not having any project selected.
We've got AVD Manager, which is the Android virtual device manager and I am having now a Nexus six
up 30, so it's Android 11, IP 30 and here we can see CPU architecture x 86.
The Android studio also has the ability to emulate ARM devices.
ARM is the CPU architecture for those smartphones, those native smartphones over here, not those fake
ones we are using right now.
So this one is a little bit slower.
It's not a little bit it's it's way slower because it needs to be emulated on an x86 architecture.
If we are emulating an x86 within an X 86, this is way faster.
But we could also run into problems on certain applications, which has been exclusively designed to
work on real devices.
If you want to know more about this topic, I have made an whole video about the difference between
x86 and ARM, why we are having this and how this all plays together right now.
Okay.
All right.
We can see the smartphone is requiring 8.1 gigabyte of disk space and we could simply start this emulator
via this button over here.
I highly recommend you using a Nexus six device because if you are using a pixel device, this is way
faster than the Nexus six and requires also more resources.
So within the emulator, we do not want to have in power device, we want to have an and really low
level device which acts just like an smartphone and does not have all these fancy features because,
because those fancy features require resources of our system and this smartphone would be terribly slow.
Okay.
So this is the that's how we can start this emulator via the Android studio.
But as already mentioned, there's an easier way and the easier way is using the emulator.
So if you type in emulator and then we are using the Android emulator, which comes with the SDK.
So if we are performing which emulator here be having now the binary that's being executed and this
binary has been also added to our path variable.
So this directory is tools directory.
Let's see.
There we have it.
This means if you're running emulator, the terminal is looking into all those directories and searching
for an emulator binary and executes it.
OC Okay, so now what's the problem?
Well, let's try starting our emulator and we have two options at with the name or dash ABD with the
with the name once again.
So I'm not sure what's the name of my emulator.
So I'm using emulator list evds and here we have it.
And now we can use emulator edge and then the name and now we're getting missing emulator engine program
for x86 CPU.
And the problem is that the emulator binary within the Android SDK has been placed into tools is outdated.
So we are having now two emulator binaries, one within tools and one within emulator.
And if we're having both in our path variable, we do not know which one gets picked.
And you know what?
It's always the wrong one.
So therefore what we need to do is we need to get rid of this emulator binary and then we have to include
it over here, the emulator directory in the path and then we are good to go.
So maybe let's do this a little bit graphically that you that you see what's going on because it's it's
not that easy to follow on a terminal.
Okay.
So here we heading tools the emulator binary.
We could delete this right now because that's the outdated version which shouldn't be used anymore.
But I'm not a fan of this, so let's rename this if we are renaming it to emulator dot back and also
this one, then if you are now using emulator, oh yeah, it would work because it has been added to
the path now.
Well, never mind if you rename this tool to back.
We are only having one emulator binary right now in our path variable and this one is within the emulator.
So the file structure has been changed in the last couple of years within the Android system and it
still gets messed up.
So this one is the emulator binary we need to execute and this one is located in Android SDK emulator.
They are named identical and both tools.
And also this emulator directory needs to be included into the path variable.
If we are throwing out the stooge directory, then we lose access to Android, make SD card monitor
and things like this.
Maybe these are also outdated binaries, but for now the only problem we are having is two binaries
in different versions with the exact same name.
So therefore let's get rid of one of them and then we are going to go.
All right, now let's see.
Yes.
If you are now simply running the same command once again, it should work because then it's going into
the path variable or yes, the path variable, it looks it up and sees, okay, within the SDK emulator,
I've got an emulator binary, I'm using this one.
Let's verify this.
Which emulator is the ultimate proof that I am.
Yeah.
A little bit silly and made this mistake over here but it doesn't matter.
It can still be executed.
So with an Android SDK emulator is now the emulator binary and here before it was within SDK tools emulator
because this was the first one which has been found.
I would like to fix this real quick and then we go to the man in the middle setup.
Yes.
And this error, it costs me quite a while to figure out and therefore I would like to include it in
an three minute break up over here that you do not have to search 15 to solve this right now.
Okay.
So now we can start our emulator finally.
Let's go.
Let's do this.
Yes.
Now we can see the emulator version 33.
And here we get the next warning in this case, running in between machine within another which a machine
is something we have also discovered or talked about in the installation path.
It's not a good idea.
If you are using and newer devices and pixel device, then the user experience would be absolutely horrible
in this case.
Right now it doesn't require that much resources.
So I'm not having an and full PowerPC.
I'm using eight gigabyte of RAM and I guess two CPU cores.
This is pretty standard nowadays, so therefore it should also work pretty smoothly.
I highly recommend you doing this all on your host system to get up and yeah, in separate laptop to
perform your penetration testing, reverse engineering and analyzing.
So within this setup on your host desktop, you you can run this emulator pretty fast.
So that's that's amazing.
So you do not see any any millisecond of lag in there right now.
We might have a little bit, but it's still good to go.
And this is something I would like to prove over here.
Okay.
So let's start this one.
Yes.
And B, there's still this old application the insecure bank opened.
Okay, so let's close this.
All right.
So now we're having this device and this device has an an wi fi access, maybe?
No, not now.
But it also claims to have a mobile network access.
And of course, those networks are virtualized.
So this this emulator does not have an SIM card with one phone number in there.
And it also has no no physical Wi-Fi access.
So these network connections are just virtualized and they are being taken from this system over here
where the emulator gets started from.
So now if you also want to forward Internet access to this device, we need to make sure that our host
system has Internet access.
So therefore I enabled it.
So let's make the connection.
Okay?
Now we've got Internet access on our virtual machine and then we will see Internet access appears in
in one or 2 minutes.
Also on our smartphone right now, I guess if you are now opening the web browser, it should be already
there.
So let's see.
Oh, that's nice.
There is no web browser on this device here.
That's interesting.
Well, okay then.
Let's choose webview so that people simply trust an application which performs in web view.
So we are having an a little in-app browser in there right now.
Okay.
So let's see, http example dot org.
Okay.
Yes, we can see it's working.
So I mean, we do not require an browser in there because all the network traffic we want to man in
the middle are regarding to our mobile applications.
So therefore we are absolutely fine with this low level device right now already.
Okay.
So performing this man in the middle set up right now, we have generally speaking, I would say to
options regarding to the emulator.
One is something I really cannot recommend, but I still want to show you why and how.
So the first one, which is always referenced, is using the Wi-Fi settings as a proxy if we go into
settings.
And then network and internet.
And WiFi.
So you can see it's a little bit laggy, but I guess it's still fine to work with this device.
Then we have to wait until our our emulated wifi apps.
By the way, we're having Internet connection, but still this X at this point right now.
So this is a perfect example because the emulator is now using the virtualized mobile connection instead
of the virtualized WiFi connection, which means if we're inserting in here in those settings our burp
suite proxy, this wouldn't do anything right now.
Let me show this to you.
So let's start our burp suite.
We have it.
And now we do not have to make a complex set up with IP table rules and things like this, because we
only insert the values of the burp suite as a proxy into this one over here.
So this is how many men in the middle setups are now being referenced.
And it's it's not a good idea.
And you will see now why.
So let's choose temporary project use burp defaults.
Okay.
And then within proxy.
Options.
So if you click edit.
Specific IP address or specific address, we can see we are not having our hour 1040 201 interface up
right now because we are not having a physical network interface where we want to connect to right now.
Therefore, the easiest way is using all of.
We could also simply just select this one over here because that's the interface of our Ubuntu VM network
account.
So this one.
The Smartphone can connect to this interface and we can forward the traffic from this interface into
the real world.
So you could select all or simply just your interface over here.
Regarding to request handling, we have to apply Invisible Proxy, and now we're good to go.
Okay, so now we want to insert it as a proxy.
Therefore we have to go to this pencil.
Wi-Fi options and TAB also have some confusing options treated as metered, treated as unmetered.
So yes, we already have decisions and decisions regarding to the network.
Traffic are always bad because if you do it this way, then we might miss the other part and vice versa.
Right.
Okay.
Let's say we treat it as unmetered and now proxy.
Many.
Well.
And now let's go.
The hostname is http 172 16 214 129.
It's exactly this one over here.
Yes.
And now the port is 80.
80.
We do not want to bypass and yeah, the HCP.
So why can we not save it right now?
Oh, we have to get rid of this one.
Okay.
Now we can save this.
And now let's see.
Okay, let's try it.
Our burps, we can man in the middle of this request because we are still talking about HTTP.
There should be no problem regarding to this world.
To be fair, this might have been already cached.
So therefore we are not using dot org.
We are using dot com.
Okay.
So I see nothing inside here right now.
And we can see the smart phone is browsing.
Maybe I have made a wrong configuration, so therefore let's go back.
Okay.
And let's switch to the other part.
So instead of treat it as unmetered, lets select metered.
Let's do this once again.
And now we can see we have lost the wi fi part.
So let's see.
H GDP example dot com.
Nothing here.
Let's do it.
For example, dot org.
Still nothing here.
Let's do it for Google.com.
Even if it's http, we should see some errors.
Nothing inside the burp suite.
Okay, so I guess it's not working in this way.
Last but not least, we've got this automatic option.
But I guess we get this point doing this in this way.
It's it's not really reliable to fetch anything.
Also, the problem is that some applications can detect proxy settings like this.
They can say if this if the smart phone is using certain proxy settings, then do not make this request.
So please do not use it in this way.
Let's get rid of this one right now.
So, well, we do not want to do this.
All right.
So we have seen it flips between wi fi and virtualized mobile connection, vice versa.
And sometimes it works.
Sometimes you miss some stuff.
Not a good idea.
What else can we do?
The easier option is using the global system proxy for this whole device, and we can find this within
the three dots.
So here we can see if we select menu proxy configuration.
And select our perps.
We then we can hit apply.
And now we're having a more global option.
I wouldn't rely on that.
This man in the middle setup is now fetching every single network packet.
So regarding to UDP or other stuff, it might be still tricky, but now we can already see this device
is making some requests.
So these requests are being forwarded into the burp suite.
So it will at least fetch all those those basic network packages, which is fair enough for 90% of all
applications.
All right.
But in this course, you have absolutely no bad experience or you do not miss anything if you are performing
it.
By this way, just keep in mind for real world applications, especially on Iot applications, please
use a real device like this one over here.
Alrighty.
Okay, cool.
So now we can see that's all we need to do.
Forget about the first part you have seen.
Why it's bad now.
It's flipping between those two connection types.
But we do not care because we are fetching the whole network traffic.
Not the whole maybe, but most of the network traffic.
Yeah, through our burp speed.
All right.
The only thing we need to do, because if you opening the Web view once again.
So let's go to to an HTTP page.
And let's also keep this history up here.
All right.
Okay.
So now over here, for example, let's see, http example dot org.
Yes.
Here we have now this example dot org page.
Perfect.
So we can see this whole network traffic for this application right now with our purpose fee OC.
That's the way better set up right now.
Cool.
The only problem we are having right now is regarding to https example dot com in case it has been cached.
Oh, let's see what's happening.
Let's clear this cash.
I mean, it can be done easily here.
And yes, we are getting some dashboard arrows over here.
So let's say there's an error and it claims.
That Examiner.com received photog certificate may be unknown.
Yes, it looks like.
Yes.
So the certificate is unknown.
We need to install the birth certificate also on this device right now on this one over here.
Is that a big deal?
Absolutely not.
So what we need to do is we go into proxy options, import export, see a certificate.
We select certificate the from what?
Then we select our home directory and we provide a name like emulator brb dot CRT this time.
So not the CRT.
Okay.
And then we are using ADB push on the.
What was it.
I don't know anymore.
Correct.
I CRT emulator work this way.
ADB push emulator work onto the sdcard and now we simply need to install it.
So if we go back, maybe we can close those applications.
Then we do not have to care about caching.
So settings.
And then let's see.
Security.
And the encryption and credentials.
Install a certificate.
See a certificate.
In style anyway.
OC the SD card is being loaded.
And let's see what you ve got.
Okay, then on those three lines.
And we have to select.
Yes.
If you select a SD card, we are only seeing those directories, not those files.
So we need to go back into Android SDK, build for x86 and now we are having also those files.
And here we can see we've gotten an emulator per CRT.
So we click on this and then there should be an success message, even if it's a little bit like it
right now.
See a certificate instead.
That's all we need to do.
We need to go into those settings.
We apply our burp suite within the burp suite.
We need to select the proxy settings on this interface.
88 invisible inside the certificate and we'll go to go.
Really?
Let's figure this out.
So within the HTTP history.
Yes, I mean, no, that's still Google.
Interesting.
So let's see, we are opening this amazing Web view test once again.
Okay.
And now we want to we want to go to an HTTPS site, so let's open.
HTTP as example dot com.
And perfect we can see hpe's example dot com here's the here's the network package and here we can see
it's working.
So the birth certificate has been trusted.
All right, this is how we can perform a man in the middle set up on an emulator.
Yes, it's way easier, but we are missing a little bit of packages regarding to strange or uncommon
protocols.
All righty.
Perfect.
Have some fun with this and then I'm looking forward to see you in the next video.