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.
Related
I've been pulling photos from my android device to my linux OS like this:
$ adb pull <what-to-pull> <where-to-place>
In the future I would prefer to pull only the ones I don't alreay have.
What's the best way to do this?
Maybe I could put all the photos I've downloaded to the same folder and skip the ones with names that already exist in the folder I'm pulling from? How to do that?
Is that even the best way? Does an easier way to do this exist?
If so... how?
I'm on arch linux by the way, in case the distribution effects your suggested answer.
adb shell find "/sdcard/DCIM" -iname "*.jpg" | tr -d '\015' | while read line; do adb pull $line; done;
^that works well enough.
From here.
The adb-sync tool worked for me: https://github.com/google/adb-sync
Note that I had to make several changes to the source code to get it working for my use-case (invalid paths for Windows causing crash, Python version mismatch apparently, etc -- for details, see issues I commented in), but it ended up being the only way I was able to retrieve my files from a corrupted data partition.
(The adb pull of the whole directory would crash on various files, and I didn't want to manually have to delete each one then restart the whole transfer. With adb-sync [+my modifications] it would just fail that one file then continue.)
Regarding your question of having it only transfer new files, I believe adb-sync does that automatically if a file hasn't been changed. If you don't want it to re-transfer an existent file ever (ie. even if the file has been updated), I think that's what the flag mentioned here is for: https://github.com/google/adb-sync/issues/22
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.
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.
I have a shared library that I build with the Android NDK, which ends up being 80MB (yes, huge!). I absolutely cannot shrink it down in size. The problem is, when the Android application is being installed the shared library cannot fit in /system on my phone because only 300K is free. So when the application tries to run, it crashes with a SIGBUS error since not all of the library is there. Freeing any more space in /system would be near impossible without possibly breaking a lot of things.
So, I was wondering if there is another way to link to this library by putting it on another partition like /data which has 150MB free. Does anyone have any ideas on this?
You can install .so files also to /data/data/YOURPACKAGE/lib/
You'll have to research how to do it, though, since I don't have experience on it.
Edit: take a look at this post: http://www.aton.com/android-native-libraries-for-java-applications/
So, I was wondering if there is another way to link to this library by putting it on another partition like /data which has 150MB free.
You are welcome to write your own firmware.
Otherwise, you cannot change what happens with this sort of thing.
I am doing a forensic course and as a requirement I have been asked to develop a forensic investigation tool (windows based) for Google's Android OS. The requirement is such that given an image file, the tool should be able to display the databases that the applications are using, call history, messages and etc..
I have little experience in Java but I have no experience in Android development. The research so far has given me nothing on how to go about this. If anyone could point me in the right direction I would much appreciate it.
Thanks in advance.
Step 1 would be mounting the filesystem. Since Android is Linux based, there's a huge array of filesystems available, and individual vendors may or may not decide to write their own filesystems, just for the fun of it. On Windows, your options include ext2fsd or ext2read, among other possibilities.
Once you've got the filesystem mounted, then you get to deal with the per-application data storage. I'd wager a fair amount of applications use SQLite3, because it is an amazing tool. But you'll have to figure out, for each type of data you want to read, where it is stored and in what format. (The standard file(1) tool on Linux systems can come in handy, it knows heuristics that are surprisingly good at showing what type of file you might be dealing with.)
If you have the .apk of an application, a tool such as dex2jar, used in combinaison with something like jd-gui, can get you the JAVA source-code of the application (which can help, if not obfuscated).
After that, an .apk is basically a zip-file -- which means opening it with an unzip-ing application will allow you to get the images and resources it uses.
Then, databases used by Android applications tend to be SQLite, on which you can do SQL queries, using an SQLite client.