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
Related
Assume we have a process that may dlopen() some third-party library. This library may perform open("write_only_logfile", O_WRONLY) on some file to which user has only write access. We need to have an ability to be notified if this library attempts to open a file, so later we may dup() returned descriptor and redirect output.
There are few restrictions that make interception harder:
LD_PRELOAD is forbidden - no way to hook open()
inotify(7) doesn't help because user has no read permissions on "write_only_logfile" and it is owned by admin
we have no access to library sources and therefore cannot modify it
"write_only_logfile" is hardcoded inside the library, so we cannot pass another name to perform redirecting
I'm wondering if Linux has an efficient way to help in such situation.
Especially taking in account the fact that process may open() miscellaneous files pretty often.
P.S. To avoid confusion and understand better - it is a regular Android application with loaded JVM. If app hangs (so called ANR) - system sends SIGQUIT to it. Signal is received via dedicated thread that open()s /data/anr/traces.txt and writes JVM state to it. These data extremely useful for debugging. But app cannot read that file directly because of security reasons (All applications write to it, so there may be somewhat sensitive). Anyway I believe that it is absolutely fair to intercept content that my process would write to it.
P.S.S. In the worst case it is possible to find JVM library image (libart.so) and manually patch jump slot for open(). But it doesn't sound well.
Sounds like you are in troublesome situation. Most solutions briefly mentioned below are guaranteed to interfere with SELinux, so don't take my word for any of that.
Debugging your own process with strace to intercept open is one of usual solutions on normal Linux. I am not sure if it would work in Android; it certainly might become off-limit for non-debuggable apps starting in some new versions (if it is has not been banned yet).
seccomp-bpf is another possibility. Might not be available on older Android versions, but since Android O seccomp is going to be a guaranteed part of Android security getup. Intercept open in warn-only mode and give control back to yourself when something interesting happen (via debugging or signals).
If /data/anr/traces.txt is opened on-demand, you should be able to observe that by watching contents of /proc/self/fd/ with inotify or via polling. You might be able to reduce impact of races by setting io niceness of the opening thread…
All of above are only partial solutions, you still might need to decode actual open syscall that happened (strace source code might be helpful there for strace/seccomp solutions, readlink for /proc/self/fd/) and act upon it (dup2, as you already mentioned).
"write_only_logfile" is hardcoded inside the library
Is it possible to modify the memory of data segment of the library/executable? Afaik mprotect and PROTECT_EXEC in particular have been heavily restricted, but at least mmap is certainly permitted (to support JIT compilers etc). It might be possible to cook something up to edit the string constant in place (as long as doing so is possible and allowed, I am not sure myself about that).
If this is just about redirecting writes (and reads) to a single file, you could run the application in a mount namespace with a suitable bind mount for that particular file. Setting things up in this way probably requires a small SUID binary.
A more general solution quickly approaches a union file system, and getting it right is quite hard. Even the in-kernel union file system, overlayfs, does not manage to provide full POSIX semantics.
You need LD_PRELOAD to hook an application. To hook a third-party library, just load your hook normally before the library (or have it in your executable).
Assuming the library calls open from libc and not the corresponding syscall directly, and that it is linked in a normal way, you just have a function named open somewhere in your code. Make it call open from libc (RTLD_NEXT or whatever). The third-party library (and all other libraries of course) will resolve its open symbol to your function.
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.
It's probably not possible due to safety issues and many other reasons, but it's worth a shot, so here goes:
Is it possible to push files from an Android device directly to a computer using ADB?
Why would you want that, you might ask. Good question. I find it useful to view larger Strings on a computer instead of on an Android device, especially since Log.d() won't show Strings of a length more of a couple hundred characters. Things like SOAP requests and responses, other xml files are not easily viewable on my Nexus 7. I've tried some things with the UsbManager class and the UsbDevice class, but I can't seem to find the USB-connection to my computer.
PS. I can think of other methods, like using a logging webservice, for all I care, or writing a script which pulls a certain (log) directory periodically, but I'm just curious whether or not it is possible, it makes my life ever so slightly easier.
As I can read in your question, you are quite aware of the fact that you can pull files from your Android device to your PC, so I won't suggest that.
To answer your question: No, this is not possible. It's not how adb works. Even if you could "push" from Android to PC, you need a piece of software to handle the data. Android does not contain any API which makes that possible, and neither does any part of the Android SDK.
Still you could use any of the methods you already know of (adb pull, Eclipse DDMS View, and yes, even a logging webservice, as you yourself suggested).
Hope this clarifies a bit.
You can push files from ADB to PC (eclipse).
In Eclipse Window-Open Perspective-DDMS
and then in DDMS view select your device from the left side list.
and in the Right side view, you will find a folder called mnt, inside it you will find sd card. There are your files. your devices files. Now to get them out to your pc
There are two buttons on the right side top.
one button says pull a file from device
another button says push a file to device
You need pull the file from device.
Select your respective file and click the pull a file from device button.
To copy a file or directory (and its sub-directories) from the emulator or device, use
adb pull <remote> <local>
For more details on the usage, refer this link
EDIT: What I understand is that you want your app to pull a particular file right? If yes, you need to use
public class YourAppCode {
public static void main(String[] args) throws Exception {
Runtime runtime = Runtime.getRuntime();
Process process = runtime.exec(new String[] {"/usr/bin/adb", "devices");
}
}
Instead of devices, you need to send pull command along with the source and destination.
What is the best (most safe) way to change protected system settings like brightness, gps, data, ... within a root app?
I read about 2 ways to do so:
1) copy settings.db to your app folder manipulate it with sql api and then copy it back -
seems more than just a bit risky to me.
See here
2) use root to copy your app to the system folder and hold WIRTE_SECURE_SETTINGS permission - seems doable, but does that break the market link, so the users won't receive updates anymore? See here
Or is there a different way?
Thx for your help!
Instead of moving your app to /system/app, you can execute your "modification" commands as root using su
An explanation of how to do this using Runtime.exec() (and also one implementation) can be found here.
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.