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.
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'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.
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.
This question comes up when my Apk file gets its size at 30MB. Now I try to reduce apk's size but the .so files are really fat.
Is it possible not pack up .so file into apk but load them from sd in Android?
I know it is not safe to use .so from sd card. Is there any sample project or code snippet for this usage, not caring about the safety.
good link please read
http://www.faqs.org/docs/Linux-mini/C++-dlopen.html
here are a few things to note when loading classes:
You must provide both a creation and a destruction function; you must not destroy the instances using delete from inside the executable, but always pass it back to the module. This is due to the fact that in C++ the operators new and delete may be overloaded; this would cause a non-matching new and delete to be called, which could cause anything from nothing to memory leaks and segmentation faults. The same is true if different standard libraries are used to link the module and the executable.
The destructor of the interface class should be virtual in any case. There might be very rare cases where that would not be necessary, but it is not worth the risk, because the additional overhead can generally be ignored.
If your base class needs no destructor, define an empty (and virtual) one anyway; otherwise you will have problems sooner or later; I can guarantee you that. You can read more about this problem in the comp.lang.c++ FAQ at http://www.parashift.com/c++-faq-lite/, in section 20.
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