Can I write a custom userspace file system that can be run on non-rooted factory devices through the standard available utilities?
I am aware of the existence of fuse-android, however as far as I have understood, it requires a rooted device. If that is not the case, please do correct me.
The goal I am trying to achieve is create a 'fake' FS that actually is mounted to a file.
I had the same need some time ago and came to the point where I had to admit that's not possible at all (mostly). It shouldn't be a problem to build libfuse for android, also the Java wrapper is no problem.
The real problem is that most of the systems I have seen aren't build with fuse support buildin nor do they provide modules which may be loaded (which would require root, but anyway).
You can easily find out if fuse is enabled by reading /proc/filesystems. It should list fuse, otherwise you will need root. But it's very likely that most android devices are build without fuse support.
My other ideas were to use another filesystem to "fake" something like fuse. This may be possible with nfs or some other network filesystem where you can implement the server by yourself. This whould enable you to write a fake fuse but I don't think it's worth it.
Edit:
And even if many devices would have fuse support buildin chances are high they wouldn't let you mount it as a user, you would need root access as your app wouldn't have the privileges to mount fuse filesystems.
Luminger almost has the right idea. Here's what I found on my Galaxy S3 (on Verizon):
The appropriate fuse stuff does exist in /proc/filesystems. So something must be using it, quite possibly system. However, when I attempt to execute 'fusermount', I get "Cannot execute -- Permission denied."
So it looks like all the FUSE stuff is there, but I've got no idea whether I could actually use it directly (dropbox? sshfs?) without rooting the device.
It depends on your implementation. What it sounds like to me is you want to have a physical file(s) that represent a full user space file system. Perhaps similar to a mounted .iso. If this is the case, I cannot think of any reason for needing root: You simply create/install the file somewhere such as /sdcard/ and "mount" your file system on top of it.
That said, if you want said file system to be accessible from other applications that you do not control, you'll need root as your application will be running in a Android sandbox otherwise.
Related
is it possible to hide files in android by transfering/moving them to a location or sector (like in root folders or something) of which other apps don't have access to (via adb or termux or something)?.
I have mentioned adb and termux because i've seen performing actions like uninstalling system apps from device. and if possible, i don't want to root my device.
One humble request: i don't know the ABC's of app building/compiling, maximum i can do is execute commands in adb/termux. so if you paste any code, please also mention what to do with it.
i have tried:
putting dot at starting of the name of the files is too older method and everyone knows about it. encryption and decryption is too much time consuming process. And i don't have that much important data, i just want to hide it from direct access so that most of the people can't find it by normal methods.
Thank you very much
i´m trying to find a way how to delete and restore files in android - not using android file explorer tools or external tools for forensic analysis.
So far i understand that most devices has ext4 file system and that erased data still exist, only metadata are deleted.
I´ve read few articles about forensic analysis but they all use tools.
I guess i have to use Adb shell and find a header of the file and alter it, but haven´t found any explanation how.
Am i heading right direction or wrong ? Any help appreciated.
(I have one rooted and not rooted device, both higher than 5.0 Android)
I'm afraid you will need to use tools. Consider the question, "I want to hammer a nail into mahogany without using tools?" How would you answer that question? A hammer is the natural instrument one would us to accomplish the task. But it's a tool. I suppose you could use a rock, but technically speakinng, that's also why a tool. It's why we talk about prehistoric humans as being tool users, even if they are using tools made out of an axe.
In this particular case, you'll want to take a full image backup of the disk partition which will require root, and then use a program like photorec to recover the deleted files.
I'd like to get some numerical data from an app, but they are not stored as files like db. I know there are some memory hack apps for changing in game values although I do not know how they work.
I am looking for similar features but I don't need to change anything.
The app I am trying to write just reads some data from a specific app and do some background calculation based on that. If this is not possible, I would need to get information by reading the screen(for example get pixel color), but this seems to be very cumbersome task for getting many data.
Is there a way of achieving this?
Thanks.
EDIT: I'd assume I would need a root permission for this?
Yes, you would need root permission. Additionally your users must have fully rooted device with e.g. SuperSU or other modern Su app, that can lift most SELinux restrictions. There may also be conflicts with KNOX and other similar systems, but I am not really knowledgeable about those.
You would need to attach your process as debugger to the target application and locate the necessary data by scanning it's memory. This can be done in multiple ways, the best reference implementation to look at can be found in scanmem.
The code, performing the actual deed, which requires root rights, — reading/writing target process memory — would reside in a native executable, being run via su. You'd have to write some code to communicate with that executable (probably via it's stdin/stdout or something like that).
You will also have to write additional code to parse the memory layout of target application yourself.
Alternatively, you may prefer to inject a small module in memory of target application and/or have the app itself load a Dex file of you making (especially handy, if your target data is stored in Java memory). This approach have a benefit of minimizing interaction with memory layout of virtual machine, but you still have to initiate loading of initial Dex file. Once Dex file is loaded, you can do the rest in Java code, using good-old reflection API. If you go with this route, a (decently supported!) code for injecting executable snippets in memory of Linux process can be found in compel library, being developed as part of CRIU project[1].
Two Android processes cannot share memory and communicate with each other directly. So to communicate, objects have to be decomposed into primitives (marshalling) and transfered across process boundaries.
To do this marshalling, one has to write a lot of complicated code, hence Android handles it for us with AIDL (Android Interface Definition Language).
From the OP, as no more details can be found, I would recommend you reading/searching with the keyword "AIDL" and you will be redirected to the concrete solutions.
I have a driver compiled and running on hardware running Android 4.3. By running, I mean 'insmod gipc' loaded the driver and it ran through initialization. It assigned the major number 243 to the driver as evident in the /proc/devices files. The example code application is looking for the following two files
/sys/class/gipc/gipc1/name
/dev/gipc1
How should these files be created? Android does not have mknod and does not support udev. I do not really need the file in /sys/class, but without the file in /dev, I cannot access the driver.
I ended up using the following functions, class_create(), device_create(), and device_create_file() to accomplish this. Not sure if there is a more preferred way, or a way of having the files automatically created.
I am trying to set up a working Linux ecosystem inside an Android terminal emulator, but without actually having root access. This means that I need to adjust every reference to e.g. /bin/sh in the source code of every program I'm trying to compile and use.
Setting LD_PRELOAD before starting an application allows me to modify the behaviour of libc functions, just like fakeroot does; so I might just write a library which redirects all syscalls with absolute path names (except /dev, /sys, and /proc for example) to the folder I have write access to.
This library would have to:
Rewrite all path names so they stay inside the fake root directory
Nevertheless allow references from outside this directory, because e.g. procfs will still provide system-absolute path names
Ensure that a child process does not accidentally unset LD_PRELOAD
But how well would this turn out? I'm no expert when it comes to low-level code, so:
How consistently could I emulate such a "faked root directory"? Am I doomed from the beginning by the kernel which won't cooperate?
How easy would it be for a process inside the "fake root" to accidentally break out of it? I'm not talking about deliberately trying to escape via assembler code.
Edit: Maybe this library could even serve as a replacement for libc, as long as I link all software I compile on that system against it?