- Our primary areas of focus for digging
into Android applications are listed here
data storage, logging, network, and platform communications
build settings, and finally reverse engineering.
So let's run through some of these.
For data storage on Android.
We have a few persistent data stores.
We have shared preferences, SQLite databases
and fire base, realtime databases.
So for shared preferences,
shared preferences are a, it's on disk, an XML file.
And there are methods exposed in the Android SDK
to write two shared preferences very easily
I have an example of this on the coming slides.
We talked about SQLite and fire base in the iOS section
the storage location for the SQLite databases
on Android is slightly different, of course
completely different operating system.
But in slash data slash data
the package name slash databases within there
you would have a SQLite file that you could then, provided,
You can get to that data, you can actually, you know
load it up into SQLite and see the data.
We also have internal storage,
so applications just like iOS, are sand-boxed,
containerized, segmented data store and inaccessible
to a general user.
In one of the coming screenshots,
we'll see that I get root in order to access data.
And that applies here. Your standard off the shelf
cell phone, running Android, non-rooted,
you wouldn't be able to access this.
You root the device, then you get access
to the full disc and you can access whatever data you want.
And then finally, external storage.
So Android, all Android devices have a concept
of external storage, whether or not it exists
or not is up to the actual manufacturer of the product.
However, the capability is there.
This might be removable.
It might be non-removable.
So if you have an SD card that you can extract
from your phone, that's removable, external storage.
That data store is world readable
and USB accessible, and plug it into a computer,
you can browse the data on that disc.
So if an application developer decides to write their data,
maybe on purpose, maybe by accident,
to this external storage location, and then it falls
into an SD card, again, on purpose or not, what sort
of information can you extract from that?
So an example of shared preferences exposure.
So I put together this very simple application.
This is not even really an application it's
got two text fields and some code in order to
store shared preferences.
So we create a shared preferences object.
We create an editor for that.
We put two strings into that
and we see right here, save username and password
is the function name.
Whenever the user taps, the login button
this function gets executed and it stores the username
and password to those shared preferences.
So that example I was talking about on the previous slide,
of being root to get access to this data.
If I root my phone, then I can get a shell
and actually navigate to the applications
containerized directory and extract data.
So shared preferences, as I mentioned, are stored
in an XML file, shared press dot XML, saved password
super secret password saved username john@doe.com.
So once I type that information in here, press login.
This function executes and stores it to shared preferences.
Shared preferences are commonly used to store information
for an application.
And as you can see very easy to implement.
ADB, Android debug bridge.
This is an application you can install on your computer.
It's available for Mac, Linux, Windows,
and it includes the log cat feature.
So Android is constantly logging under the covers.
Your phone is always logging stuff to itself.
You can get access to these logs.
If you turn on developer mode
on the phone and then turn on USB debugging or TCP
you can do this over the network as well.
Then you can do ADB log cat and get a bunch of information.
If the developer forgets to turn off the de-bugable flag
then it's possible to expose information
in these log messages. I have an example of that here.
Same application, I went ahead and added
a bank login header here.
So I have username and password.
You press the login button and what occurs?
So we have a debug message here. Log dot D.
So it is integrating the login library into the application.
It's built into the Android SDK
for logging it's to help developers.
Once you hit the package button,
so I mentioned this de-bugable flag.
So whenever you are debugging an application
then de-bugable is set to true.
Whenever you package it for release,
then if you're using Android studio
it'll turn that off for you,
as part of the release process.
if for whatever reason, the developer decided to mess
with that, or they change from debug to info.
So you'll notice log dot I versus log dot D.
Then we could expose information here.
So we have on create and we get the some handles
to these two text fields over here, you press go log in,
it executes this function right here.
And we see we create two strings and we log it, log dot I
so this is an informational log message that
is output in log cat output.
So we see here, go log in username and password
which is what I told it to output,
username and password.
So if you are investigating an Android application
turn on developer mode, turn on USB debugging
and just start watching log messages.
And it's a command line application.
So you pipe that to grip or whatever the case may be, and
look for unique strings that this application
may be accidentally logging.
When it comes to network communications
the same concepts we have looked at in previous lessons
as well as the iOS lesson apply.
So capturing traffic, sniffing traffic
and even proxying traffic. So we have burp suite as well
as the Zed Attack Proxy from OWASP to proxy HTTP traffic
as it's coming out of the device
and then better cap or etter cap to actually do machine
in the middle type capture of data.
Similar to iOS, Android has permissions.
These permissions will allow an application to
access platform capabilities.
We can see here in this screenshot access fine location,
access course location, get accounts, record audio.
Why does this application need to record audio?
That's a good question.
These requested permissions would then
be presented to the user.
Do you want to allow this application to record audio?
Hopefully the user's gonna say no.
However, there's a good chance, they're gonna say yes.
Regardless, understanding what permissions are requested
by an application is helpful.
These are called runtime permissions, as well,
they are called dangerous permissions
and that's quote on quote dangerous.
So in the documentation they're classified
as dangerous meaning they could expose some data
provided the user says yes this permission is approved.
Build settings. So I mentioned the de-bugable
in a previous slide here, so within the manifest dot XML
is Android de-bugable, true or false?
The build settings for either debug
or release should toggle this from true to false,
when you go to release it.
You can see the contents of manifest dot XML
using some applications such as jadx and drozer, or jadx,
also AP case signatures.
So in your build settings, whenever you are packaging it up
for distribution on the Android play platform
there's several different options available
for signing those particular application bundles.
So in version one, when they first release this stuff
they were doing Java archive signing, and now
they have APK signatures for two and three.
Based on the level of API, you are targeting
with your application.
I'm saying you as if you are the developer.
For reverse engineering of Android applications
there is a Dex to Java decompiler called jadx
or jadx. Bite code viewer can be used
as well to decompile these.
I have a screenshot to show you how jadx or jadx
works here in just a moment.
Also, if you have access to the actual distributable package
Android studio, which is the default IDE
for Android, can actually decompile it for you
into what is called Smali. Smali as is mentioned here
a similar and disassembler for Dex bite code
which is used by dalvik which was the
previous version of the virtual machine,
and now the Android runtime.
So here's an example of jadx compilation.
So this is that example application I was showing
in the previous slides. This is the original source.
And then this is the decompiled source.
And you'll notice that it is the same
from original to decompiled source.
So provided I can get access to that binary,
I can extract quite a bit of useful data.
The input to this decompilation was the actual
signed Android package that would be uploaded
to the Android play store.
Some other tools available to you for
decompiling Android applications, dex2jar, APKtool,
The developer studio, as I mentioned
is the default preferred integrated development environment
for Android applications.
IDA Pro can deal with this stuff as well.
There is a list of tools available from OWASP
for interacting with both iOS and Android applications.