This might be a complete "no-no," but I was wondering if it is at all possible to make an application debuggable after it has been signed and compiled into apk.
I'd like to be able to generate a random key on my server and then use this key to put an application I've published into a debuggable state.
//Build a hidden back door to request the randomly generated key on my server
//Input this key into an edittext box of some sort.
//Check this key against the server
//If key validates, put application in debuggable state.
I realize the potential security risks in doing this, but I was just wondering if it is at all possible.
It's fairly straightforward to generate a debuggable APK from a non-debuggable one if you are willing to re-sign and re-install, but you cannot do so to the already installed instance.
Anything in your actual code which behaves differently based on debuggable/non-debuggable status could also look at something else as Brent suggests, but that's of limited use as most of the debug functionality is built into Android, rather than part of the application code.
You may be able to provide flag-contingent alternatives to debug functionality though. For example, you can provide something to copy private files out to public storage. If you really wanted to, you could bake in a server that would provide a shell running as the application UID. But getting an actual JDWP debugger going may require extreme, android-build-dependent hackery as you'd likely have to provide your own version of a lot of system code.
At the simple end, having your program change its behavior by logging a lot of usually suppressed internal detail would be quite simple.
Do spend some time thinking about the security implications for your users.
Looking through the dev site I see access to the flags via a call to getApplicationInfo().flags; from a given Context. flags is not final, so it appears the getApplicationInfo.flags |= FLAG_DEBUGGABLE; would allow you to enable debugging at runtime: reference to ApplicationInfo doc:http://developer.android.com/reference/android/content/pm/ApplicationInfo.html.
Note, I have not tested this(not by an android environment at the momemnt).
Related
Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):
Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
In the official website, they've written:
A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.
What is this warning? What is the backup feature, and how do I use it?
Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?
There are two concepts of backup for the manifest:
"android:allowBackup" allows to backup and restore via adb, as shown here:
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.
However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.
So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.
I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.
"android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:
The name of the class that implement's the application's backup agent,
a subclass of BackupAgent. The attribute value should be a fully
qualified class name (such as, "com.example.project.MyBackupAgent").
However, as a shorthand, if the first character of the name is a
period (for example, ".MyBackupAgent"), it is appended to the package
name specified in the element. There is no default. The
name must be specified.
This isn't a security issue.
For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.
If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.
By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.
This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.
Setting allowBackup="false" opts an application out of both backup and restore.
To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)
Click here for More information
Here is what backup in this sense really means:
Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
~Taken from http://developer.android.com/guide/topics/data/backup.html
You can register for this backup service as a developer here:
https://developer.android.com/google/backup/signup.html
The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.
UPDATE:
You can see this flag listed on BackupManager's api doc: BackupManager
This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).
http://developer.android.com/reference/android/R.attr.html#allowBackup
http://developer.android.com/reference/android/app/backup/BackupManager.html
http://developer.android.com/guide/topics/data/backup.html
It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.
Solution - use android:allowBackup="false" in the manifest file.
You can read this post to have more information:
Hacking Android Apps Using Backup Techniques
Here you can see android official doc
https://developer.android.com/reference/android/R.attr#allowBackup
I am currently writing an app (App A) that depends on another app's data (App B).
Being an Android noobie, I thought that the only way to enable that is to use a ContentProvider and doing a query.
As it stands, the current way of doing is problematic, because App B has another signature than the one we're using for App A. This means:
The only way we can get our apps to talk to each other is to send our apk on a signing server so that it is also signed with the same key used for App B
This process is not automated, so it is therefore time-inefficient (takes around 2 - 4 mins).
This also mean we can't set debug points, which causes us a lot of pain when trying to see what data exactly is being returned by the ContentProvider
I did some more research and got told by a colleague that instead of signing our apk every time we make a slight change, we could extract the apk of App B and sign it with our key only once.
It led me to then create a keystore and key for my team, which I used to re-sign App B's apk and reinstall it on our test device. I then set my Android Studio to automatically sign the debug versions of App A with that exact same key.
The problem is that didn't change anything unfortunately...
It always ends up with the following exception being thrown:
Failed to find provider info for com.App.B.provider
(basically the same error thrown when we are using the default App B apk withouth sending our App A apk to the signing server)
Just to point out, if you're wondering, sending App A's apk to the signing server and running that does work and we're getting the data from the ContentProvider
So yea, I'm not sure what to do anymore... Any ideas ?
Also, since I'm not sure I have a clue of what I'm doing, any explanation of how these things are supposed to go would be very welcome !
<provider> tag should be placed inside <application> tag.
Also, be careful not to put it inside an <activity> tag.
Also you can get it working specify full path in <authorities> tag in manifest file (see SearchableDictionary sample code in SDK).
<provider android:name=".DictionaryProvider"
android:authorities="com.example.android.searchabledict.DictionaryProvider">
Alternatively you can use external storage,create directories and access the data from there directly.
I inherited an android app that has some security-related code that seems to basically be a no-op and that I'd like to remove. However, I'm concerned that my assessment of it as a no-op may be incorrect. The app sub-classes Application and, in its onCreate() method, gets the serial number of the certificate that the app was signed with:
ByteArrayInputStream bais = new ByteArrayInputStream(context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures[0].toByteArray()));
X509Certificate cert = CertificateFactory.getInstance("X509").generateCertificate(bais);
BigInteger sn = cert.getSerialNumber();
It then computes a hash of this value and compares it to an expected value that's embedded in a Java class as a byte[]. If the hashes don't match it throws an exception, crashing the app.
What this seems to prevent is someone stealing our source code, building the app and signing it themselves, then trying to install and run it. However, if someone has the source, they can simply remove the check at app launch. (Or change the embedded hash value to match the serial number of their certificate).
Is that accurate? Or is there some reason I'm missing that this code is useful?
I don't think it's to protect people from stealing your source code. It's to prevent people from replacing all the assets, thereby rebranding the app as their own, then re-signing it and putting it in the play store as their own.
However, the program shouldn't be verifying the serial number, which is easily modified. It should be verifying the signature.
If someone goes to the trouble of decompiling the app, as you said, they can remove that security check.
It's just another hoop for a cracker to jump through. Consider keeping it, but be sure to check the signature, not just the serial number.
Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):
Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
In the official website, they've written:
A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.
What is this warning? What is the backup feature, and how do I use it?
Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?
There are two concepts of backup for the manifest:
"android:allowBackup" allows to backup and restore via adb, as shown here:
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.
However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.
So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.
I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.
"android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:
The name of the class that implement's the application's backup agent,
a subclass of BackupAgent. The attribute value should be a fully
qualified class name (such as, "com.example.project.MyBackupAgent").
However, as a shorthand, if the first character of the name is a
period (for example, ".MyBackupAgent"), it is appended to the package
name specified in the element. There is no default. The
name must be specified.
This isn't a security issue.
For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.
If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.
By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.
This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.
Setting allowBackup="false" opts an application out of both backup and restore.
To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)
Click here for More information
Here is what backup in this sense really means:
Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
~Taken from http://developer.android.com/guide/topics/data/backup.html
You can register for this backup service as a developer here:
https://developer.android.com/google/backup/signup.html
The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.
UPDATE:
You can see this flag listed on BackupManager's api doc: BackupManager
This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).
http://developer.android.com/reference/android/R.attr.html#allowBackup
http://developer.android.com/reference/android/app/backup/BackupManager.html
http://developer.android.com/guide/topics/data/backup.html
It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.
Solution - use android:allowBackup="false" in the manifest file.
You can read this post to have more information:
Hacking Android Apps Using Backup Techniques
Here you can see android official doc
https://developer.android.com/reference/android/R.attr#allowBackup
Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):
Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
In the official website, they've written:
A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.
What is this warning? What is the backup feature, and how do I use it?
Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?
There are two concepts of backup for the manifest:
"android:allowBackup" allows to backup and restore via adb, as shown here:
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.
However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.
So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.
I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.
"android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:
The name of the class that implement's the application's backup agent,
a subclass of BackupAgent. The attribute value should be a fully
qualified class name (such as, "com.example.project.MyBackupAgent").
However, as a shorthand, if the first character of the name is a
period (for example, ".MyBackupAgent"), it is appended to the package
name specified in the element. There is no default. The
name must be specified.
This isn't a security issue.
For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.
If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.
By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.
This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.
Setting allowBackup="false" opts an application out of both backup and restore.
To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)
Click here for More information
Here is what backup in this sense really means:
Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
~Taken from http://developer.android.com/guide/topics/data/backup.html
You can register for this backup service as a developer here:
https://developer.android.com/google/backup/signup.html
The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.
UPDATE:
You can see this flag listed on BackupManager's api doc: BackupManager
This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).
http://developer.android.com/reference/android/R.attr.html#allowBackup
http://developer.android.com/reference/android/app/backup/BackupManager.html
http://developer.android.com/guide/topics/data/backup.html
It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.
Solution - use android:allowBackup="false" in the manifest file.
You can read this post to have more information:
Hacking Android Apps Using Backup Techniques
Here you can see android official doc
https://developer.android.com/reference/android/R.attr#allowBackup