So we have shared library from a vendor who won't deliver their library in a static archive .a format on Linux or Android (but does on other platforms) because it would be inconvenient for them to change their build process. The issue is that need to wrap thread creation, malloc, and ton of other apis to work around bugs in the platform's nonstandard libc. We do this with LD using the "--wrap" command to redirect functions to our wraps. Unfortunately with a compiled .so, we can't relink it. Is there anyway of turning the .so into a static archive and relink it or even rewriting the link table to redirect these calls to our wraps?
Outside of disassembling, changing the library, and reassembling I can't think of any way to do this easily.
Is there anyway of turning the .so into a static archive
No.
LD_PRELOAD seems the easiest way to achieve what you want.
because on android, you are fork of the Zygote process for your startup, you can't use LD_PRELOAD. You can LD_PRELOAD on subprocesses but you can't do it on your main process.
So in your "startup" process, modify the environment and execve the real program. Problem solved?
Related
Is it possible to copy a function to an external application's shared library in memory? If so, how? I'm trying to achieve external hooking by making a trampoline hook externally.
This require very deep understanding of the binary formats used by the operating system. Not all code is relocatable, your code must be compiled with -fPIC for this to work for sure. You will need also to resolve manually all external symbols. In fact, you will have reimplement parts of the ELF loader. It is possible but definitely not trivial and very machine dependant.
Also you will have to find a way around the new execution restriction - nowadays most OSs have various protections against writing in executable memory regions.
I have my own developed Android app in kotlin. I lost my all source code (hard disk crashed) after that I pull my apk from my physical android device using below adb commands -
c:\> adb shell pm path com.digi
Response of this command is full path of apk. after that I used below command to get actual apk-
c:\>adb pull /data/app/com.digi-ZF6WfmctELhsLvm4oICrAQ==/base.apk Destination\folder
After that I used android studio and using build -> analyze APK
This is giving some folder structure but did not get any kotlin class what I developed.
Is there any way to get at least kotlin source code?
Well, yes and no. You can't recover your source code fully, but you can at least get some of it. It will be partially gibberish and partially almost fine, you'll lose local variable names, comments, formatting, etc., so you will need to go through all files and fix them or even rewrite some of them entirely. But still it could be better than starting from scratch.
I did not decompile Android apps for a long time, so my knowledge may be outdated, but the standard procedure is:
Convert the code from dex to jar.
Decompile to Java.
In your case: convert Java to Kotlin.
Ad.1.
AFAIK there are two tools to do this: dex2jar and enjarify. I suggest using enjarify, it always gave me better results.
Ad.2.
There are several Java decompilers and some of them will work better with some code, others will work better with another. I suggest trying at least Fernflower and JD-CORE/JD-GUI, maybe Krakatau.
I guess the results will be far from perfect, because the application is written in Kotlin, not in Java. Suspend functions and other features specific to Kotlin will be even worse.
You can also use ByteCodeViewer which is a GUI applications that simplifies the process of 1. and 2. It contains all above tools and more. You can also switch the decompiler dynamically to see results of different ones.
Ad.3.
IntelliJ has some utils for converting Java to Kotlin. I never tried this with decompiled code and I guess it will be problematic
If you would need to recover the resources (XML files, etc.), you can try to use apktool.
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 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.
Im writing my entire Android project in NDK C/C++, and I now want to open some jpg files.
Ive read a lot people suggesting compiling libjpeg or libjpeg-turbo for use with NDK, but others suggesting libjpeg is already in with android is this true?
I'd rather use an existing lib but dont want to rely on it if some units its not there.
I use libjpeg-turbo, statically linked with my other libs, it works fine. I don't think libjpeg is already installed on Android.
Even if libjpeg already exists within android, it's not a public API, so therefore whatever gain you get by not having to bundle it, might come back and bite you later. I'd say it's not worth it - bundling your own copy of libjpeg (or similar) makes sure you don't rely on platform internals.
If applicable, you could use e.g. some of the public java APIs (android.graphics.BitmapFactory etc, which in the end calls the internal bundled libjpeg or whatever) via JNI to decode your images - then you don't have to ship the jpeg library yourself, but have to do a bit more JNI function calls. (There might be a small performance overhead compared to calling libjpeg directly, but not significant unless you're loading huge amounts of images.) If you're interested, I can share example code for this (it's about 50 lines).
Solution:
Thanks guys for the help, I was hoping libjpeg was accessible to my development but as pointed out is in Android though not public through the NDK.
So I spent sometime reading the spec for jpg and decided on writing a C decompresser from scratch until I fell upon jpgd by Rich Geldreich, and although C++ its single file implementation of jpeg decompresser in the public domain which Ive now used without any issues on Android.
He also has an accompanying jpge (encodeder) although surplus to my requirements for this project well worth noting.
My NO-JAVA application continues.
Solution:
C++ jpg Decompressor Android NDK