I would like to implement a fanotify (supported by kernel > 2.6.37 - shipped in Android 5+) interface for the Android x86 - at first for goldfish emulator. I like to use the tool fsmon to start the filesystem monitor (a C program with basic structure to use the fanotify syscalls fanotify_init(2) and fanotify_mark(2)). I extended the fsmon code by own access-permissions. This permissions should be able to edited later by an system app in Android. (For example: I can choose later, which file types are denied)
The problem is following:
"The other big drawback of fanotify is that it currently is root-only (CAP_SYS_ADMIN-only to be more specific). This means that only the root user can request to use the monitoring capabilities provided by fanotify [...]"
[source]
A rooted phone is a must have? But is there not another way to run on/after kernel boot the fsmon binary without rooting the device?
My first thought was to execute a file/service after every boot by init.d. But to use it, you need a rooted phone. Then I found this: init.d scripts support:
"If your device is rooted the scripts can be executed using superuser permissions, but normal users can do also."
But I cant't understand how this can work (I didn't test it yet) Could this be a possible solution? For running it on other devices (without installing this app), I need to understand how the app bypass the problem. And init.d gets executed in the user-space, is it even possible to run the monitor there as root?
Next thought was to run a crontab, but same story - rooted phone.
Now I go one level deeper - linking/execute the binary (or the c code) in the kernel boot sequence.. I have to be honest - I'm not a professional kernel developer. I know, that I need the execve systemcall to run a file in kernel. But is my approach right? If this could be the right way, how can I communicate later with the system app? Do I need to create a small "database" from where both sides can access? Which way is the best to access the provided data from the system app? (kernel-userspace-communication: Procfs, Sysfs, Configfs, ...) Where is the right place to start the monitor? (sure - after setting up the filesystem)
Or is it absolutely not possible to use fanotify without rooting the phone?
I would be very happy if someone can give me some tips...
You are trying to use a feature that requires a permission (CAP_SYS_ADMIN or root) that is withheld from user and application processes by design. You either need a phone that provides this capability to designated applications or you need to root the phone. I do not know of any phones phones providing this capability, because it would enable an app to subvert the security of the system.
Related
I am trying to develop a file communication system that interfaces between the respective file systems of a Windows PC and a connected Android device. I realize a better (or at least simpler) way to do this would probably involve using the adb push and pull commands, but I am gathering options/trying to avoid developing additional communications on the Windows side beyond its basic OS file access. I know it is possible to interact with the device's storage directly from Windows when the device is physically connected via USB - if I understand correctly, this is commonly done using MTP? However, I am also currently constrained to only being able to use an emulated Android device. The Android Emulator is a useful tool for a variety of development situations, but I am not sure it was ever intended to appear as an MTP device in Windows like its physical counterparts do.
So could anyone provide documentation or some other resource establishing either
an MTP, UMS, etc. Windows connection is indeed not possible with the default QEMU Android Emulator; or
it is, and how.
Judging by the answer provided here - https://stackoverflow.com/a/21633596/1399272 - it does not appear that accessing the Android file system using a mounted drive in the Windows file system is an option, regardless of whether it is emulated or physically connected. So my question becomes moot point.
I'm building a custom Android 10 firmware.
I want to prevent the user of the device from being able to copy the firmware code from the device via ADB.
It's a USER build variant.
The user must have ADB access and can't limit it to specific commands.
Currently to get the code he could just do, for example:
adb pull /system/framework/services.jar
How can I modify AOSP to limit this access? Preferably l would like to prevent access to any other way to get the code from a running device.
Note:
I know obfuscation is an option, rather have a stronger prevention.
The user is prevented from going into bootloader mode.
You can restrict shell process to which all partitions it can get access to. This can be achieved by making the changes in SELinux policy.
Reference:
https://source.android.com/security/selinux/customize
I have read all over the internet and get the single info whose summary is Runtime.getRuntime().exec(). But it didn't work.
How does the applications like King Root etc works? Are these apps written in C/C++ with NDK or no java is also used to create such apps. Any resuorce of information would be appreciated. Thanks!!!
Typically to root an Android device, the user needs to flash a custom recovery such a TWRP ((https://twrp.me/about/). Once that recovery is installed and booted into, the user can flash modifications such as root. This also requires an unlocked bootloader to flash that recovery.
Can you create an app that roots a device? Not unless there is a security flaw for that specific device and OS version.
How do I get root access in order to reboot the emulator? How do I kill all unwanted processes along with the child process?
You have already root access to your emulator. To kill a process and all childs just use the device view in eclipse, select the emulator theere and chose which process you want to kill.
I have no idea on how to restart from code if you are looking for that. Rebooting the device should be easy: just close it and than boot it up again.
(I have the feeling I don't really get what you want...)
Most su binaries for Android depend on SuperUser.apk (available for free through the market). The su binary uses this apk to ask the user if it's ok to do whatever is being requested (and the user can opt to remember the answer). If you're using such a su, you need to also have that apk.
Once the pieces are in place, your application can spawn a process with the right arguments... something like argv[0]="/path/to/su", argv[1]="-c", argv[2]="(whatever command you want to run)", argv[3...n]=arguments to your command.
To kill a process in the command line, simply issue the following command line on the shell:
kill-9 YOUR_PID
If you know the name of the process, but not the pid, use
kill -9 $(pidof NAME_OF_PROCESS)
You can also use it on your code:
Runtime.getRuntime().exec("kill-9 YOUR_PID");
Check the man page for more details: http://unixhelp.ed.ac.uk/CGI/man-cgi?kill
ps-after rebooting i also wanted to kill all unwanted process except my specific app and its child process alone to run in emulator.
If that is really what you want to do - repurpose an android build as a generic embedded linux, then the way to go about it is to regenerate a ramdisk image (which android packs onto the kernel) containing an init.rc which launches your application rather than the android native services and (java-esque dalvik) android runtime. Rebuilding the ramdisk requires a unix-like OS and that arcane cpio command line which you can find in web search. I'd be tempted to leave the startup of ADB in there so you can debug the various things which will go wrong.
For testing purposes simply typing "stop" from the adb shell will shut down the android runtime and give you a UI-less virtual pocket linux box. There will still be some native services running but they may be more help than harm. Ultimately you may need to set OOM killer values on the things you add, though without the runtime up that may not be an issue in the near term if you don't consume much memory.
Or if what you want to do is have a very locked down and limited UI built on top of the android runtime, you would instead develop a custom home screen , test this on an unmodified emulator, and then deploy it on a build customized to lack any means of installing other applications.
I am looking generally in to Android development.
I keep seeing information on root however I am unclear how this relates to general android app development.
I understand that there is an emulator however when I get to actually test the software on a phone does that phone have to be a rooted device or is this only required if you wish to edit the core features of the os?
Finally are there are any development disadvantages to rooting the device such as that is no longer behaves like other android phones I may deploy too?
Thank you
You don't need root to develop for Android.
The easiest setup is to run Eclipse with the Android Development Tools installed. Then, you can debug your application in the emulator, or register your phone with the SDK and debug directly on your phone. The only thing you need to do on your phone is check the development mode under Settings -> Applications
I can understand the allure of having a rooted device, but I can't really see a reason for changing the bootloader or os binaries. You can, however, change most of the default applications (including the Home application) with other applications available on the Market. For instance, OpenHome is about $5 and allows you to replace the home app, add themes, and replace many of the core apps (e.g. clock).
Rooting is only required, if you want to play around with advanced features or update your firmware, etc.
If you develop your software using the Android SDK you will be able to use it on your phone regularly (as long as you have the corresponding version). No rooting needed.
I have never heard of any problems according to your concerns. But I cannot deny that there are none. Though I personally don't expect that there are any problems with rooted phones.
On the Nexus S running Android 2.3, the /data folder is not visible in the DDMS File Explorer or the ADB shell, but it is visible in the emulator. This occurred with debug turned on in both the manifest and on the phone. I confirmed that debug mode was properly enabled by successfully stepping through the app using breakpoints and also by receiving messages from logcat.
Not being able to see the /data folder means that you will not be able to get your application's private data.