2.5 Android Basic Static Analysis Techniques

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

3 hours 58 minutes
Video Transcription
In her next section, we begin to examine Android applications. This is where things get a little bit easier now. Why do I say easier? Well, to this point, we've already covered a lot of the basic principles of strategy is related to Mao analysis. Now have we covered everything to make you super Ari's? No, of course not.
But now analysis process in theory doesn't change because we're examining a different platform.
So now all we need to do is apply the same basic principles we used during our basic static analysis of IOS to Android. As faras Android goes, we have many samples of Mauer to choose from when we want to practice our analysis. I could talk for hours about the history of campaigns in the latest samples.
But really, when all of sudden done, the malware threats and infection vectors are similar, if not the same toe. Iowa's.
Now, as with IOS, malware authors are trying hard to infect users by social engineering tactics and infecting third party application stores and targeting users who root their phone. So as Android Mauer tactics are similar, we can play the same malware objectives and analysis strategies to accomplish similar goal,
which is of course, to uncover the functionality of our malware program
with Android. Our basic static analysis strategy is the same. The first item of business, of course, is to identify the AP K file. Again, we can do this using our hashing program and file command, as we've done in the previous exercises.
Then we can also scan it with a V and or search the hash with virus total or another malware database. The next item two inspectors the Android Manifest file. This is where our steps start to deviate a little, but the strategy really is the same. Now in the manifest file, we want to inspect the file for different activities intense and permissions of the program.
This will give us an idea of what the program is doing. And really, these are the most important fields to look for when analyzing
android applications. Now because the manifest is in binary form meant we have to use the AP K tool to decode it, because if you remember simply unzipping, the package doesn't want to see the contents. But once we decode it, we can view it just is regular text.
Now, I like to look at this file using strings and grab, because only to look at the elements that are most important me.
But sometimes you really need to see them in context. To the first item to look for is the manifest package element. This is the job, a name for the application. The naming scheme is similar to that of a domain that's flipped the application element. This shows the application components like icons, permissions, processes, etcetera.
The activity elements detail our user interaction with the program. The Android labels. These show the name that the user will see when they're using the application in the Android colon names. These represent the implemented class. Names are intent Filter. This is the element that describes the messaging object
that can be used to request in action from another application.
If you remember, intense is that an object intends to do something. Lastly, we have the uses permissions, these elements of the ones we want to be watching out for. When we're looking for suspicious applications here, we can see the movie player is looking for the Internet permission, which is probably not a bad thing. But if it was a requesting, maybe SMS permissions.
Then we may start to get suspicious.
Okay, so let's go through the activity of simply decoding an A p k file and viewing the manifest file. So here we go. I've got my Santa Cuvee em all up and running, and we're gonna decode the client on a p K file that you see here. So let's go ahead and do that simply.
It's real simple. A peek a tool
D and the file name. Okay,
here we go.
Alrighty. Okay, It's all done. So now we can just go into this folder and simple way to view this. Just double click. It will load it right into a browser.
Okay, so now we can go ahead and browse the different elements. The 1st 1 will look for. Let's look for the package element. That's the job. A package for the applications. Let's do that.
We'll just search for it.
Yeah, Here it is, right at the top. Here. Okay, so we've got the application. A Java package name. Oops.
Okay. Next, we can take a look at the activity element. We could look at the activity element for the android label for them. The name of the application. Let's see if we could find it.
Okay, here it is. Who? This is called M name. Okay.
Yeah. I don't see your name here.
How many activities are there?
No. Okay, let's take a look at the intent filters.
We could see a few of them here already. That's going to search for all of them.
Okay, so it's gonna interact with the phone.
It's gonna interact the phone. We saw that. Okay. With the S M s
with the excess ability service.
Okay, All these different. Intense. All right, let's take a look at the main application and see if we can find where the application has a load from, maybe with it.
I don't see it. Here we go. Right here.
Okay. So here is the
main skull. Hope's gonna launch from Bright. They're so we've got that. Okay. And then next we can look at the user permissions. We saw a lot of those.
Oh, my gosh. His phone application can do everything vibrate, camera, wallpaper, SMS. So this can do a lot of stuff. This is a definitely a bit scary what this application could do. So those are definitely the things that we want to check out when reviewing this XML file.
So by looking at the manifest filed, we can get an idea of what the program has permission to d'oh
and what other applications it touches. Now we want to look at the android source code.
If you remember, once we build our application, the source code gets compiled to buy code a few times. First is the Java bite code, and then the second time is the machine or the decks by code. That's where we're here. The dad licked by code that gets compiled into these decks files, and then it gets run in the virtual machines.
Now Dex was invented to have a fast processing time.
But there aren't a lot of tools to interpret this format, So what we want to do is we want to get back to here. Fortunately, decks and java are very close and syntax, so we can easily convert the decks to job a bite code. But really, we can't stop there. We still have a little problem. Java by code is a bit like assembly, so we'll avoid looking at that code in this format.
But we have a lot of tools like JD Gooey Eclipse, Jeb
and others that can help us d compile the Java by code format. Allow us to look at Java pseudo source code to get our decks file into a format we can use. First, we must convert the decks file using a tool called Dexter Jar. This will produce the Java code, and then we can read it into a tool like J D gooey
Jeb, or maybe something even from the command prompt like pro style.
But before I go ahead and show you the conversion process, I want us to take note of the differences and steps we've taken to get here so far.
When reviewing the AB structure, weep simply unpacked the files using winds up. This gave us the APP directory structure along with the classes dot dex file. But the files were in binary format, and they weren't too much use to us at that time.
A few moments ago, we used a peek a tool. We decoded the binary formats and that allows us to view the files like we did the manifest file. So one process gives us decoded files and the other one does not. So usually we must perform both actions to get what we want with a few exceptions.
All right, so let's convert the classes that Dex file of our client dot i p k and see what kind of job classes we get. All right, so here is my VM.
Okay, We're in the android directory. Perfect. OK, so we should have ah,
classes dot text file, which we dok. So let's convert it D to J
text to jar. Right.
And we used the classes. Don Tex as the target.
We get our jar file.
Okay, so now we can just open this up with Janey. Gooey
Okay, so now we've got it open.
Okay, so we've got our name of our application here. We know that from before. Okay, so we have these classes now. So where do we begin? Well, that's a good question here, all the classes. So if we take a look at the android manifest from earlier this er decoded one,
what we want to do is locate the main activity, right? Because once we locate the main activity, then we can see which class it initiates first.
So if you remember the android Colon name. This'd is the class that gets loaded
at launch.
So it's m
so where we want to begin. We want to begin in our M class.
Okay, So see, Here you go. Here's our on create method. You've got all the methods and properties associated with this class as well as the other ones. If you want to go and look at them.
So what we can do is we can start here at our main
and we can move forward through the application to see what kind of functionality it has
so we can go through. And we look exactly
what this class does. This M class
we can scroll down. We can see that it intends to look at the accessibility settings
it uses. Some service is okay and look, So here's the problem with these tools. Sometimes
they get a lot of errors. Sometimes the conversion between decks to jar isn't amazing. So sometimes you need to run these through a few different tools
to get the output that you want.
But an alternative is using a piece of software called Jeb. Now Jeb is typically for reverse engineers. But if you're going to be doing a lot of android reverse engineering. Maybe it's worth $1000 but let me show you what I've got. The demo version installed. So let me just show you how that operates will shut that down. Real quick
case. I'll move to the
Jeb folder
and will launch its
now. The nice thing about Jeb
is you don't even need
to convert it to a jar. You can interpret the entire Dex file, which is really nice,
but it gives us the same type of output that JD Gooey gives us
so we can look at our M class
and we can start
looking at it and reverse engineering it from here.
The money thing we can do is well, is
de compile our code.
So go ahead and give us a decomp. I'll version exactly like JD Gooey did. The problem with that is this demo version does not de compile some methods. So again we might have to combine a couple of tools
to get the effect that we want to find out the functionality that we want.
But that's our main strategy is to
take the decks file converted to a jar if we have Thio and then go through the different methods and forward engineer the program to see what kind of functionality it has.
Up Next
Mobile Malware Analysis Fundamentals

In the Mobile Malware Analysis Fundamentals course, participants will obtain the knowledge and skills to perform basic malware analysis on mobile devices. Participants will perform these tasks by learning and implementing tools and techniques while examining malicious programs.

Instructed By