I'm attempting to reverse engineer the data element of an android app - simply because i want a couple of the images, but I've come across a stumbling block. The files are in a .pak extensions i don't recognize and can't seem to do anything with. I've pushed them through bless and the file signature is 50 41 4B 00 which is slightly different to the .pak file signature i could find online. The only information I could pull was a recurring RIFF WEBPVP8X and occasionally RIFFv2. Has anyone ever come across this before ? Or can give me a heads up of how to go about actually pulling the images out?
It's not for nefarious reasons - just want to make a tacky montage of the characters in the game, with a few comical paint shop edits!
I would like to give out more details, but without any information on the target application my answer will be restricted.
You have to keep in mind that the application itself will unpack these files to use them. This means that the code to read the files is bundled within the application. Looking at the code might also give you more details about the file format. You may also try hooking any methods related to reading these file to see if you can dump the real resources files at run-time.
You can use Jadx to decompile the APK to get readable Java code.
You can also use Xposed to hook the app methods at runtime and dump the genuine files.
Related
Firstly sorry if the terminology of any of the below is incorrect. I'm new to the Frida/android investigation game and mostly just doing it to improve my understanding at the moment.
I have an APK which I am analysing. I can see through the usual decompilation that certain aspects are obfuscated, others appear to be encrypted and calls appear to disappear into nothing. After analysing the traffic through hooking the crypto libraries I can see it downloads a file starting PK.
To investigate further I've write the zip to disk and extracted it. Inside is a classes.dex file that I believe contains some of the hidden content I've been searching for to close the gaps I keep finding.
Unfortunately, that is where this is currently ending. I can see the new functions and classes but when I try to hook them for manipulation (bypassing emulator detection is a key thing in there) Frida complains as the function/class doesn't exist from the outset. It appears to me that these classes are imported somehow while running, post startup.
What I am looking at doing next is to intercept the download, replacing it with a dex file I modify as required which should then allow me to continue with my analysis but I wondered if there was any easier way? Is it possible to target these classes that are not loaded immediately, and if so can someone point me in the direction I need to look to investigate how? I am presuming that there is a built in android function that needs to do this import I could look for, but I'm unsure where to start.
Any help/direction/guidance would be appreciated. To confirm, I'm wondering if the below flow is possible:
Start the application, hooking crypto libraries
Wait for the new classes.dex file to be downloaded
Hook into these classes on loading
Automagically bypass the newly loaded classes
Thanks.
I'm developing an Android application which contains native code.
The native code is compiled in a .so file that has important algorithms inside.
I'm really worrying about the possibility that my .so file can be edited or modified and then re-build (re-pack). Like apks they can be modified and repacked to create a new one
I have several questions here:
1) Is there any way to edit/modify .so files and re-build?
2) If there are, how do people do that?
3) How to prevent .so files from being edited then re-built?
The short answer is that anything that a computer can read and understand, it can also modify. There is no bullet-proof signature mechanism in Android for Java or native code. Still, the so files are generally considered much less vulnerable than the Java code, even with obfuscation turned on.
Reverse engineering a shared library is hard but possible. Disassembly, change, and assembly back is not hard if one knows what to change.
There are many ways to strengthen protection of your C++ code against reverse engineering, but none will hold against a determined and well-funded attack. So, if the stakes are very high, consider running the important part of your algorithm on your server, and prey for its security.
I have download an apk from the internet and decpress it using dex2jarf tool so its gives compiled,.classes files which i convert into .java file through decompiler but it gives me classes toa proper way like it gives a.java,b.java c.java which is difficult to me read.Can i get proper classes name through apk file same as it is used in project.plz help
Thanks
What you are trying to achieve is called deobfuscation.
Programmers who wish to protect their intellectual property obfuscate their code to make it more difficult to read for those who might want to steal/copy/plagiarise their hard work.
Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.
Src: http://android-developers.blogspot.ie/2010/09/securing-android-lvl-applications.html
There is no way to recover identifiers if they have been stripped out. Compilation is a lossy process, like converting a RAW image to a low quality JPEG. There's no way to go from JPEG back to RAW.
However, there are tools like jeb and ida that allow you to rename the classes yourself. When renamed, all references to that class also get renamed. This feature is sometimes called "refactoring". This is about the best way to do it, but it takes more time.
Also, there are plugins for jeb that help automate the refactoring by generating new, more descriptive names than 'a', 'b', etc. Here's an example from jcase, which you can modify to suit your needs: https://github.com/CunningLogic/myJEBPlugins/blob/master/DeCluster.java
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 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.