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.
Related
For the past six months as my final university project, I've been writing a PlayStation 1 emulator in Java to prove it can be performant - part of my strategy involves writing a custom class loader that imports bytecode I have just generated from an array into a new class - in effect a Java bytecode dynarec core which speeds up the emulated CPU orders of magnitude (in theory). All quite possible on an Oracle JVM, and done before by others.
My question is, aside from the fact I would need to generate dalvik bytecode rather than Java bytecode, there doesn't seem to be anyway to dynamically load classes into a running Android app that doesn't involve loading them from a dex file on flash somewhere. I know similar things have been asked before, but as I would eventually like to port this emulator (and have it be quicker than its currently unplayable speed), is there anyway around this? I don't want to be continually writing to flash when a new section of MIPS code is converted to bytecode, as it could wear the flash out and probably isn't very fast either.
A thought I had was maybe mounting a tmpfs using a small JNI lib and storing class files there to be loaded, so in effect storing them in RAM as before - is this even possible for an unprivileged app to do though? I'd appreciate peoples input/thoughts.
No, that might be possible on a jailbroken device but it's not possible in a sandboxed app.
I tried several ways to load dynamic code on Android but the only feasible way is via the DexClassLoader where the dex file must be stored in a privileged region.
You can have a look at my project Byte Buddy where I implemented such class loading: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-android/src/main/java/net/bytebuddy/android/AndroidClassLoadingStrategy.java
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.
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?
I have built a small Android system that uses less memory for my native apps.
I found that all my apps will link to libm.so and libstdc++.so even though they were written purely in C and do not use any functions in libm (e.g sin()). The lib uses over 20K of memory.
How can I remove the linkages of libstdc++ and libm?
Without dismissing your goal in principle, Android launches apps via forking off a child from the zygote process which has preloaded lots of system libraries into memory for shared usage by all apps. Many dalvik classes are also preloaded.
Since you inherit these shared mappings, there's actually very little physical memory consumed - for each child process in which an application runs, the preload libraries and classes only consume memory for tracking data on the preloaded code space, and for writable data space.
Due to this, it actually saves memory to give all apps something which only a majority would need, rather than to have the ones that need it load their own (unsharable) copy. Also, while a developer written ndk library might use only C, an android app as a whole is unavoidably a C++ program due to included pieces of platform code.