I am actually studying mobile security and I am focusing on hardware protection, so, I wonder, if is it possible an app can access to mobile hardware resources, and dominate on them, so, no access to any hardware resource by other apps only if permission was given by the dominating app? (as a second level of hardware security).
At least for camera, I'm aware of using Android Device Administration with a policy to Disable camera: https://developer.android.com/guide/topics/admin/device-admin.html Typically using a Mobile Device Manager would be used on authorized devices by corporations/governments in sensitive locations. Other restrictions are probably available as the Device Manager software would be accessing Device Manufacturer APIs.
Another method to achieve your goal of 'wrapping' the hardware is to not let the Android app actually talk to Android framework methods. Basically the client app would be running a virtual container with the container mocking Android framework APIs.
See: How to execute APKs on a customized data directory?
And Commonsware's blog post for additional details: https://commonsware.com/blog/2017/01/17/droidception.html
This would allow you to add additional restrictions at the cost of having all of the apps go through the virtual container. Enforcing the user to always use the container isn't really possible unless you are building a custom ROM or perhaps rooted.
And if you are doing a custom ROM or rooted you might as well add any additional hardware restrictions through those methods.
Related
My goal is to write an application for Android (>= 9.0) which basically offers a device-owner-style control like Google's "Android Device Policy".
The following criteria have to be met:
Zero dependency on Google servers or any other 3rd party infrastructure like existing EMM solutions (MobileIron et cetera)
The user should not be able to remove or disable the app
Provisioning methods: QR-Code, NFC, URL, ADB, actually any "local" way ...
Has to work with stock androids on regular consumer devices
In short: I'd like to write an unremovable device manager (including a web-based management UI), put it on a device I own, give that device to someone else, and being able to fully control the device remotely.
Is such a project even possible with the current situation of Android?
No.
Has to work with stock androids on regular consumer devices
Mostly, this is your biggest hurdle to overcome.
What you are asking for is the description of a very powerful MalWare. An app that ca run on any version of Android, that can't be uninstalled, but can do what it wants to "fully control the device".
If you move away from the idea of "stock android on regular consumer device", towards a suite of devices you have some say in distributing:
Here is a list of Google Partners who offer an EMM solution: https://androidenterprisepartners.withgoogle.com/emm/
Here is Samsungs effort at device control:
https://www.samsungknox.com/en
Here is Googles device management:
https://developers.google.com/android/management
You could write your own ROM of Android and be able to control the things you want, but that would require .. building a ROM aka a whole phone OS forked from AOSP.
The user should not be able to remove or disable the app
This is only possible if you have a system app.
Or something extreme (which with any extreme, is always possible to have problems), like having two apps, and they monitor each other for uninstall, and programatically reinstall (vs 1 app that can't do much when it is being uninstalled).
I've always liked cheap smartphones ($ 50) because with little money I can have a powerful system with lots of sensors and things like that. So I wondered if it was possible to use the hardware without using the very limited android APIs, programming it at a low level then, of course with the root. In particular I wanted to see how the LTE module worked and experiment with this having full control, the Android API does not allow it to do much.
UPDATE: I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
The first layer of software for the phone is the bootloader. It tells the processor what partition to load into memory for executing the kernel. This is the level that is usually blocked by manufacturers because of greedy corporate reasons that are beyond the scope of this site.
The second layer of the phone is the linux kernel. Rooting is the process of gaining root user access to this layer. Root is the main administrator user account that has permission to do anything to the device. Accessing this layer is what most people refer to rooting. A large portion of the kernel is written in C, with other parts in c++. What happens at this level is where all the magic is. For most phone this is where the code for the modem resides. Talking to this can usually be done via at commands of serial. Sensors are also programmed at this level and communicate via drivers. Root access is not normally needed to read sensor data, its just a case of permissions usually.
The next level is the android operating system, the java instance runs on top of that, which in turn executes the android operating system. This is the portion that most users will see and is primarily written in java. In reality you can run any kind of user interface at this level.
A very brief view of android apps.
The android api provides a way for java developers to write "apps" that communicate with the kernel and access different parts of the phone's hardware. These apps can also be written using c++. Only until recently has google integrated c++ into android studio, but the most common and still most effective method of doing so is using the QT framework.
It's a bit problematic.
Hardware manufacturers do that actually.
Take into account that Android is Linux much like other distributions.
The manufacturers develop hardware and then compile a version Android that sits on top of it. Each Android compilation is specifically tailored to the hardware and equipped with drivers that enable the main OS access to the different hardware capabilities.
For example, some tables will tweak the Android OS to not support cellular communication because they decided to cut costs and deliver the tablet without a cellular module.
From here you have 2 options:
To hack a specific hardware and understand how the OS communicates with the hardware.
Find hardware manufacturers that release some/all of their Android OS code. This is a much simpler way as you can both learn and extend the Android OS for that specific device.
An example of the 2nd way is Sony who has AOSP that allows low-level access to some of the Sony devices.
Also, there is always the Android NDK which gives you a more low-level access to Android but you are still constrained by the KIT API so I'm not sure it will help you.
I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
I am working with WSO2's EMM (Enterprise Mobility Management) which is an open source MDM (Mobile Device Management) and MAM (Mobile App Management) solution. Specifically to implement a BYOD (Bring Your Own Device) program. I am unhappy with a few features.
One main feature I want to implement myself is strict control over which apps can be installed by the user.
1) By not allowing installation of apps from 'Unknown Sources'. That is to not allow the user to check the 'Allow Installation of Apps From Unknown Sources' option or at least to be able to flag it if they do.
2) Black-Listing only specific apps that can be downloaded from the Play Store.
3) Even better would be the ability to White-List apps that can be downloaded form the Play Store
4) And in a perfect world I would like the ability to mix both an Enterprise App Store and the above restrictions to Play Store app downloads. (The benefit to that would be the ability to push corporate software to users, and still allow a safe and user friendly experience through the Play Store.)
Android's Device Administration API does not explicitly allow for these controls. Yet paid enterprise MDM solutions such as AirWatch boast these features. Any help would be much appreciated.
After much research I have found a few things I would like to share:
The current Android Device Administration API is very limited the features included are:
Device password restrictions
Disable camera
Lock and wipe device
Device Encryption
Beyond that (as Victor Ronin described in the above answer) your app can only check for compliance but can not enforce it.
The only way to enforce policies beyond the scope of the Device
Administration API is to have system level permissions. The only way
to get these system level permissions is to have your app signed by
the OEM of the device running your software. This is exactly how
enterprise MDM solutions can enforce such rules, their apps are
actually signed by the OEM and then returned and distributed. Once
your UID is given the system permissions you can enforce most policies
needed to secure a device in the MDM scenario.
If interested watch this video it describes this scenario and a detailed system level exploit.
Most of the time support of such features are patchy. As example Samsung SAFE provides more API (which will allow to do what you want) and Motorolla had some additional enterprise API.
So, you can't implemented it on generic Android, but rather you can implement it on some devices.
Second approach is compliance. May be you can't prevent installation or remove apps, but you can detect them and do some actions associated with it (revoke credentials, turn off enterprise email and so on).
Usually, MDM solutions have some mix of these two things.
Does anyone know how to build a test app that plays well with Samsung Knox? What do I have to so differently to build an app for samsung devices that have Knox installed on them?
From KNOX 2.0, App wrapping is not required.
This is from the Samsung KNOX 2.0 whitepaper:
The KNOX 2.0 platform features major enhancements to the Application Container from the original KNOX platform. The most significant enhancement is the elimination of application wrapping. This is achieved by leveraging technology introduced by Google in Android 4.2 to support multiple users on tablet devices. This enables enterprises to easily deploy custom applications without requiring Samsung to wrap the applications. It also reduces the barrier to entry for independent software developers wishing to develop applications for the KNOX container.
Complete White paper can be found here: http://www.samsung.com/ca/business-images/resource/white-paper/2014/03/Samsung_KNOX_tech_whitepaper_Final_140220-0.pdf
Multiple user: (Complete Ref: http://developer.android.com/about/versions/android-4.2.html#MultipleUsers)
Android now allows multiple user spaces on shareable devices such as tablets. Each user on a device has his or her own set of accounts, apps, system settings, files, and any other user-associated data.
As an app developer, there’s nothing different you need to do in order for your app to work properly with multiple users on a single device. Regardless of how many users may exist on a device, the data your app saves for a given user is kept separate from the data your app saves for other users. The system keeps track of which user data belongs to the user process in which your app is running and provides your app access to only that user’s data and does not allow access to other users’ data.
Might want to take a look through here https://www.samsungknox.com/en/blog/what-app-wrapping and here https://www.samsungknox.com/en/resources.
Looks like you have to develop the app and then send it in to Samsung to have them 'wrap' it.
Personal data on Samsung devices is protected from mobile threats such as ransomware, malware, and unauthorized rooting, even while you’re using your device.
Secure Folder
Samsung Pay
Samsung Health
Samsung Pass
Empower enterprise mobility by leveraging Samsung Knox and ensure seamless device deployment with advance security, taking device management to next level.
There are many applications in google play that take snapshot, they work without device root.
Am new to Android development, so I dont know much of what can be done and what can not be and how it's done.
Following is the link on which you can find the list of applications working without device root :-
http://www.androidzoom.com/android_applications/screen+capture+no+root
If you read the descriptions of those products, you will see phrases like "Rooting will be required depending on model". That is because you are not supposed to be able to take screenshots programmatically, though rooted device users may be able to pull this off, at least for some devices.
Another technique, that at least one such app uses, is to involve a developer computer in the process, using the mechanisms in Android used by DDMS and such for taking screenshots. In reality, it is the computer, not the device, taking the screenshots.
For the devices that such apps work on without requiring root and without requiring a developer computer, the authors of those apps are exploiting security holes in individual devices, just like a malware author would.
Check this library.
Their page seems to suggest it can take screenshot without root.
Android Screenshot Library (ASL) enables to programmatically capture
screenshots from Android devices without requirement of having root
access privileges. Instead, ASL utilizes a native service running in
the background, started via the Android Debug Bridge (ADB) once per
device boot.
Edit:
there are quite a lot of posts SO regarding this
Programmatic screencapture on mobile device
Screen Capture in android