[GUIDE] Application for Analysis of the Programs Installed on Android - General Topics

Author: Apriorit (Device Team)
Permanent link: www(dot)apriorit(dot)com/dev-blog/304-android-package-analyzer
In this article, I will tell you about the process of my research and the results I’ve obtained. I will describe PackageAnalyzer program created as a supplemental tool that displays various data on applications installed in the system. The following is a short summary of its functionality and basic elements implementation.
Research Process. Results
First of all we need to obtain the Android OS source code. The official web-site provides the detailed instruction on downloading the source code from the repository. Following this instruction, I set up the program environment and began the download. At that moment 4.1 was the latest version of the source code available for download. That process took a while, as the overall size of the data received was nearly 15Gb.
What should we begin with? How to find a way to analyze such a volume of data under tight schedule…
It is a well known fact that programmers are rather lazy, which prompts them to optimize their work process in various ways, and I wasn’t an exception to the rule. I came up with an idea how to ease this process a little bit by creating a program that would scan all installed packages and display the information I need, namely activities, services, broadcastservices. What’s the point in it? Firstly, it provides arranged information on packages, which allows to outline those that are of a particular interest to me. But you cannot always define the activity purpose by its name. That’s why I modified the program by adding a function that allows you to run a separate activity from the acquired list.
As the result I outlined the list of Android system applications that might be of a special interest:
• com.android.browser
• com.android.contacts
• com.android.development
• com.android.email
• com.android.mms
• com.android.phone
• com.android.settings
• com.android.packageinstaller
The next step was the research itself.
What should I look for and pay special attention to? As we know, activity is launched with the help of Intent. To do this, we need to call the startActivity(Intent) or startActivityForResult(Intent,int) method, if we expect to obtain certain result, and pass to it the Intent we’ve already created. Intent is a kind of a package, which a sender fills with various data and sends to the recipient (activity) for analysis. Therefore I was tasked with identifying the activities capable of executing the instructions set in Intent, which are not described in the Android manual.
Activity life cycle begins with onCreate() method. In most cases, exactly this method extracts the data included into Intent. The getIntent() method is used for this purpose. Hence, equipped with Far, I started searching for classes with included getIntent() with further research of what happens inside of each class, what data is extracted from Intent, and for what purpose it is used. Using this algorithm, I went through each system package, which was planned to be researched.
Unfortunately, I couldn’t find any hidden possibilities in the system packages of Android OS. Perhaps, it happened due to shallow application research, for which I didn’t have much time, that didn’t allow me to go deep into the features of each application. But negative result is a result after all. I am sure that Google programmers did a great work to eliminate system vulnerabilities by the release of new Android OS – all loopholes, which I was trying to find, were covered.
Program Part. Package Analyzer
As I mentioned earlier, I created the PackageAnalyzer Android application that was mainly tasked with collecting and displaying various information on installed applications. Besides, additional service that checks the requested permissions in newly installed applications and warns about the potential danger was added to the program functionality.
Functionality
• Acquiring the list of installed applications;
• Acquiring the list of Activities, Services, Broadcast Receivers, Permissions;
• Launching a separate activity from the list;
• Notifying about potentially dangerous permissions used by the application;
• Service. Tracking the applications being installed and checking the permissions they request.
Appearance
The user interface consists of two activities.
When launched, the program acquires the list of all installed packages and displays it in the main activity. After a package from the list is selected, the second activity is launched. It displays the detailed information on the internal package components (activities, services, receivers, permissions).
In the “Activities” section, you can initiate the launch of any component from the list by clicking it. In this case, an attempt to launch it with the help of Intent will be made. If everything goes smoothly, the selected activity is displayed on the screen. But not all activities can be launched this way, as an attempt to acquire certain data from Intent that initiated the launched is made in many of them, in onCreate() method, and if some data is not actual or wasn’t found, the activity cannot be launched.
Any Android application requires a permission to perform an action. The list of requested permissions is displayed to a user before each installation. That means that in theory it allows a user to make himself secure against malicious software getting into a phone. But practice shows different results: most users simply do not pay attention to this list. This gives malicious software the opportunity to get into the phone and use the user means as it wants.
That is why the ScannService service was added to PackageAnalyzer program. Its main task is to check the permissions requested by new applications and to inform a user in case any potentially dangerous permissions are detected. Such permissions would include: sending and receiving SMS, making paid phone calls, access to your location, access to personal data (contacts, emails), and so on.
The permissions are checked for new applications, as well as for already installed ones. This check is performed at the PackageAnalyzer launch. Depending on the permissions requested, the indicators in are displayed in the main activity and in the Permissions section in one of three states.
Risk level:
- high;
- middle;
- low.
If a user allowed malicious software to be installed, ScannService shows the corresponding notifications and plays a sound signal.
By clicking the notification, you launch the activity with detailed information on the package. You can start/stop this service by clicking the button on the main activity.
The ScannService registers two BroadcastReceivers at launch. The first one gets the notifications on newly installed applications and initiates the check, and the second one starts the service in case of a mobile device restart.
Implementation
Information on installed applications is located in PackageManager, which can be acquired from the context:
Code:
1 PackageManagerpackageManager = context.getPackageManager();
We acquire the list of installed packages:
Code:
public List<String> getInstalledPackagesList()
{
List<String> list = new ArrayList<String>();
List<PackageInfo> packageInfoList = packageManager.getInstalledPackages(
PackageManager.GET_ACTIVITIES );
for( PackageInfo packageInfo : packageInfoList )
{
list.add( packageInfo.packageName );
}
return list;
}
We acquire the list of activities located in the indicated package:
Code:
public List<String> getActivities( String packageName )
{
List<String> list = new ArrayList<String>();
try
{
PackageInfo info = packageManager.getPackageInfo( packageName,
PackageManager.GET_ACTIVITIES );
for( ActivityInfo activityInfo : info.activities )
{
list.add( activityInfo.name );
}
}
catch( Exception ex )
{
ex.printStackTrace();
}
return list;
}
We acquire the list of services, receivers, and permissions the same way by passing the corresponding parameter to:
Code:
getPackageInfo(): GET_SERVICES, GET_RECEIVERS, GET_PERMISSIONS
BroadcastReceivers are declared with android: enabled="false" parameter in AndroidManifest.xml file, as by default the service is stopped. The receivers are inactive until a user launches the service. The components activity state is changed in the following way:
Code:
publicintonStartCommand( Intentintent, intflags, intstartId )
{
setComponentEnabled(true, PackageInstalledReceiver.class );
setComponentEnabled(true, OnBootDeviceReceiver.class );
...
}
publicvoid onDestroy()
{
setComponentEnabled(false, PackageInstalledReceiver.class );
setComponentEnabled(false, OnBootDeviceReceiver.class );
...
}
privatevoid setComponentEnabled(boolean enabled, Class<?> clazz)
{
int state = enabled ? PackageManager.COMPONENT_ENABLED_STATE_ENABLED
: PackageManager.COMPONENT_ENABLED_STATE_DISABLED;
getApplicationContext().getPackageManager().setComponentEnabledSetting(
new ComponentName( getApplicationContext(), clazz ), state,
PackageManager.DONT_KILL_APP );
}
It is necessary to check the activity of the service at program launch. To do this, you need to acquire the list of all started services and perform a search in it:
Code:
publicstaticboolean isServiceRunning( Context context, String serviceClassName )
{
ActivityManager activityManager = (ActivityManager) context.getSystemService(
Context.ACTIVITY_SERVICE );
List<RunningServiceInfo> services = activityManager.getRunningServices(
Integer.MAX_VALUE );
for( RunningServiceInfo runningServiceInfo : services )
{
if ( runningServiceInfo.service.getClassName().equals( serviceClassName ) )
{
returntrue;
}
}
returnfalse;
}
Summary
In conclusion, I would like to note that although I didn’t obtain any results after searching for hidden possibilities of Android system applications, I created an application for analysis of programs installed on a mobile device, which can be used in the future. The functionality of the program can be extended to obtain more detailed information on applications, as well as to provide security (detection of malicious software and so on).
All articles, code pieces, example project sources and other materials are the intellectual property of Apriorit Inc. and their authors.
All materials are distributed under the Creative Commons BY-NC License.

Related

[Q] sharing information between main app and audioplayeragent

The sample for background audio playback does not show how the main app and the background agent can share information. Furthermore, BackgroundAudioPlayer only supports setting the Track property for the current track. There needs to be a more flexible api to allow passing more information. There can be other things that are relevant, such as user account information, that needs to be passed to the AudioPlayerAgent so that it can play audio, especially if other server calls are required to get all the relevant information for playback. The current api seems to assume that all playback is done from local files in isolated storage.
I've tried to use application settings to provide this, but the same app settings cannot be accessed from the AudioPlayerAgent. This could be for something simple like a bool to indicate if shuffle is on or off. If shuffle is toggled in the main app, then the AudioPlayerAgent needs to be told so it can alter which track to select when SkipNext is called. And if shuffle is toggled in the main app, it is not clear how the AudioPlayerAgent would know. The only solution would be to write the value to a file in isolated storage or to the database, which the AudioPlayerAgent would have to read every time before going to the next track.
Question Sample
AudioPlayer.cs(AudioPlayerAgent project):
public static List<AudioTrack> trackList = new List<AudioTrack>();
public static void GetMusicListByHttp(string url)
{
if(url==null) url="XXXX/app/music?getlist";
WebHttpRequest request=....
....
trackList =result;
}
MainPage.xaml.cs(UI project):
private void ListNextPageButton_Click(object sender, RoutedEventArgs e)
{
AudioPlayer.GetMusicListByHttp("XXX/app/music?getlist&page=2");
BackgroundAudioPlayer.Instance.Play();
}
GetMusicListByHttp Working not

Modify/Remove Existing Intents

What I would like to have happen in an end result is when I select "Share" from an image in Gallery, I would only like certain apps to be listed. As it currently stands, every app that has an intent that can handle an image is listed.
Is there any way to modify which apps are actually shown in that list? Also, would it be possible to apply to any number of scenarios? music/image/text
Well with 150 views and no replies i can assume one of two things.
One, no one knows how to do this or it cant be done.
Two, no one will give input due to lack of code.
I can fix number two. When calling blah() as shown below, it will log all apps that have registered intents. What do I have to do to have an effective "putPackageManager()". Or is there a file that I can modify in order to get the desired output?
Code:
public void blah() {
final PackageManager pm = getPackageManager();
//get a list of installed apps.
List<ApplicationInfo> packages = pm
.getInstalledApplications(PackageManager.GET_META_DATA);
for (ApplicationInfo packageInfo : packages) {
if(pm.getLaunchIntentForPackage(packageInfo.packageName) != null) {
Log.d("MyAppInfo", "Installed package :" + packageInfo.packageName);
Log.d("MyAppInfo", "Launch Activity :"+ pm.getLaunchIntentForPackage(packageInfo.packageName));
}
}
}
As far as I know, the intents an application listens for are part of its manifest and can't be modified by other apps. If you want to make it so that a certain app doesn't show up in, say, the share list, you'll need to either uninstall the app or bust it open and try to modify its manifest to exclude the intent filter.
Think about the possibilities if it was possible to programmatically change the intent filters of other apps: You could replace the default email intent (one that presents a draft email and requires the user to click a send button) with one that sends 100 text messages without any user feedback.
Anyways, hope this helps clarify things.
- chris
cttttt said:
As far as I know, the intents an application listens for are part of its manifest and can't be modified by other apps. If you want to make it so that a certain app doesn't show up in, say, the share list, you'll need to either uninstall the app or bust it open and try to modify its manifest to exclude the intent filter.
Think about the possibilities if it was possible to programmatically change the intent filters of other apps: You could replace the default email intent (one that presents a draft email and requires the user to click a send button) with one that sends 100 text messages without any user feedback.
Anyways, hope this helps clarify things.
- chris
Click to expand...
Click to collapse
It seems a little odd that the android OS would reference each apk installed to check its manifest when you click share. I was hoping that there was a central location that it would reference and update as apps were installed/removed.
eldoon said:
It seems a little odd that the android OS would reference each apk installed to check its manifest when you click share. I was hoping that there was a central location that it would reference and update as apps were installed/removed.
Click to expand...
Click to collapse
Android most likely uses a data structure sitting in memory that allows quick association between each registered intent name and the list of activities or services listening for it. But for all we know it could change into a Leprechaun sitting inside your phone with a Rolodex. Heck...this could be one of the changes in ICS.
This structure isn't something you have direct access to. You only have access to add to these lists by installing apps with intent filters and to remove from these lists by deinstalling apps.
Of course this assumes you're planning on using supported APIs. If you plan on modifying the OS, the sky's the limit...although for reasons explained above, you may not have a whole lot of people lining up to use it for fear of not knowing what anything might do at any time.
- chris

Intent mechanism and security

Hi all,
I have a question to share with you about the Intent mechanism and I hope to start an interesting discussion.
As you (may) know through the use of "Intent" an app can send data to another app of an operation to be performed. For example, from my app I can send an Intent to the browser app in order to open a specific url. But the Intent mechanism seems (correct me if I am wrong) to not apply any security mechanism. Suppose I want to steal the contacts from a device and send them to a web server, if I want to perform these two operations I need the following permissions:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.INTERNET"/>
the former to read the contacts and the latter to send the data to the web server, but this is not true. In fact, I developed a simple app (named myApp) with the following permission:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
Basically myApp reads the contacts (it holds the permission) and builds a string like the following:
Code:
String request = "http://ww.example.com/stealContacts?"
request += nameContact1=number1&nameContact2=number2&...
Finally, I put the request in the intent (see below), this means that I want to perform a "get request" to the web app http://ww.example.com/stealContacts and send as parameters all the contacts with the phone number.
Code:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setData(Uri.parse(request));
startActivity(i);
In order to test this, I developed a web app that when triggered save all the parameters in the request and show an advertising page.
From my point of view this is very strange, because I can steal the contacts easily.
what do you think? is it a security breach?
You have the permission to read contacts and use the internet. You read the contacts and uploaded them to the internet. I don't see any exploit here, besides unethical behavior.
Hi iBotPeaches, thank you to join the discussion.
I don't give to myApp the permission to use internet, I only give it the READ_CONTACTS, but through the Intent I can send the contacts to internet. I cannot directly open an HTTP connection in myApp.
Yes, this is a fairly well "known" attack - you can use the web browser intent to "leak" information via GET variables.
I am not certain it's a "breach" in the true sense, since Android seems to be an over-trusting platform. I suggest taking a look at XPrivacy on XDA, since its "view" permission for websites will prevent this attack from working unless the user chooses to trust the app (by default it doesn't trust anything).
This is not a security-break. You can only use this permissions you gave. Ist almost impossible gaining permissions without declearing them.. There is a GPS Exploit around which enables GPS without permissions and user confirmation but i think ist fixed in android 3.0+
I second the XPrivacy recommendation and would add OpenPDroid. Both allow you to prevent apps from launching URLs in native Android Browser. XPrivacy allows you to choose which of your accounts and which of your contacts (if any) to allow apps to access.
@simone.mutti - you may be the perfect candidate for this given your interest and ability to develop Android apps:
What the community really needs is a "proof of concept" app that requests all permissions necessary to display all identifying data available/entrusted to Android core services. The app would request the absolute minimum permissions needed to access every bit of data "protected" (aka denied) or "obscured" (aka falsified) by things like XPrivacy and OpenPDroid.
The propose of the app would be twofold:
1) allow users to verify the effectiveness of privacy apps. Currently, XPrivacy's developer recommends NetInfo 2 for the purposes of verifying the efficacy of his app's different privacy features. But the picture is incomplete as NI2 wasn't developed for this purpose.
2) demonstrate the ease with which users can unwittingly supply an app with an inordinate amount of identifying data with the tap of the "install" button. This would serve a similar benefit as pen testing tools by highlighting to non-developers (aka lay people) the various pitfalls of current Android framework. The most excellent, poignant finishing touch would be to allow it to read all intents/permissions of installed Android apps and present the various data each app is allowed to access + the various methods through which it could "legitimately" send that data to some undeclared outside server with/without encryption. Not the easiest task but certainly transformative in terms of clue-ing casual users into the true cost of their "free"and paid apps.
Check out the latest flavor of Angry Birds for a poster-perfect example of data sucking apps at their worst.

[TOOL] Free time / location / whatever tracking API

I was in need of a simple way to automatically track the hours that I spent at the office. There are a ton of time tracking tools out there, but I didn't want to trigger a button every time I start or stop working. That's why I created this simple JSON API.
You can find the API on GitHub: https://github.com/Steppschuh/PlaceTracking
I used IFTTT to automatically send requests to the API whenever I connect or disconnect the office WiFi. I've set up some public recipes that you can use here.
The API only serves 3 endpoints:
Users, representing the one who is using the API (e.g. you)
Topics, representing whatever you want to track (e.g. a project or location)
Actions, representing tracking events (e.g. starting or stopping to work)
which are documented in the GitHub repo. Basically, all you have to do is firing 2 requests for setting up a user and a topic:
Code:
http://placetracking.appspot.com/api/users/add/?name=John%20Doe
http://placetracking.appspot.com/api/topics/add/?name=Work
And that's it. Now you can add some events whenever you start or stop working:
Code:
http://placetracking.appspot.com/api/actions/add/?name=start&userId=123&topicId=456
http://placetracking.appspot.com/api/actions/add/?name=stop&userId=123&topicId=456
When you want to analyse what you tracked so far, simply call:
Code:
http://placetracking.appspot.com/api/actions/get/?userId=123
Please let me know what you think and if you have suggestions!

Google rejecting app due to expressed user experience not matching core functionality

Hello,
I hope someone can help me navigate why our app is being rejected by Google. We have asked what the conflict is in the declarations but we have not yet gotten an answer. Our app automates deletes of various items including SMS, our code will briefly take default handler control of SMS to make the deletions but then releases it. We declare the application as automation and call out the requirement for default handler during deletion. So we arent doing anything the users cant do, we just automate it.
1. Also, how do we update the declaration form without uploading a new version?
2. Any thoughts on how we should fill out the the expressed user experience and the core functionality forms?
3. Is there another way to delete SMS without taking default handler while you are making the deletion?
Thanks for the help / suggestions.
Greg
Below is googles rejection message:
---------------------------------------------------------------------------------------------------------------------------
I’ve reviewed your appeal request and found that your app, does not qualify for use of [READ_SMS, SEND_SMS, WRITE_CALL_LOG] for the following reasons:
The declared functionality [Device Automation] is determined to be unnecessary or not aligned with the core functionality of your app.
Your app has default handler capability, which was not disclosed in the declaration form. Please remove unnecessary capability and / or submit a revised declaration form.
You need to ensure that your app no longer uses [READ_SMS, SEND_SMS, WRITE_CALL_LOG]; failure to do so could result in the removal of your app and may impact your developer account.
Permission requests should make sense to users. You may only request permissions that are necessary to implement critical current features or services in your application. You may not use permissions that give access to user or device data for undisclosed, unimplemented, or disallowed features or purposes. For additional guidance, please review the Permissions policy and this Play Console Help Center article.
------------------------------------------------------------------------------------------------------------------------------------

Categories

Resources