Is it possible to inject an app into another after installation process?
Consider the following example:
Device D is rooted and Android version is >= 5, means it's using ART.
App A gets installed via "adb install App_A.apk". At first startup dex2oat gets called and creates the .oat file for app A. My goal is now to inject App B into App A so that App B gets started instead of App A. For another reason, the .oat file of App B gets "crosscompiled" for the device D. What parts of App A now need to get exchanged by App B to get it to work?
I guess the following steps are necessary, still the app crashes when I am trying to start it:
use the same package name "com.example.app"
use the same application name
Exchange AndroidManifest.xml
Exchange/Add res and lib folders and resources.arsc
Exchange the .oat file
Use the same key for signing the final apk (in /data/app/App_A/base.apk) after exchanging the parts above
For my understanding, "classes.dex" should not be needed, because the oat file is already present. So in theory, it should also work with a broken classes.dex?
What am I missing here? I also tried to monitor what Android does when starting an app (which files are touched and so on) but could not get behind the scenes really :(
I would apreciate every kind of help. Thanks a lot!
Regards
Related
I am developing an Android application that has a NDK .so file which I need to iterate on and fix + improve.
The current workflow has me having to generate a APK and install it every iteration which updates a whole plethora of non NDK elements in the process really slowing things down.
The question is how could I access the installation folder of my own APK? I have both a rooted and unrooted device.
Is there some change I could make to install the app in an unprotected location for development purposes even. The installation data is my own application after all so feels like should be a way...
Help greatly appreciated :)
EDIT1:
I found Unity3D has some sort of patching mode, maybe this is a sign that with the correct ADB commands it may be possible... https://docs.unity3d.com/Manual/android-AppPatching.html
EDIT2: I found the location of the .so I am building in... checked on unrooted device and don't have permission.
If your app is not a native-only app (has a Java/Kotlin part) then your so library should be loaded at the moment using a call to System.loadlibrary(..).
What is interesting on this method is, that calls to this method are ignored if the library to be loaded has already been loaded. So if you modify the Java code of the development build of your app to manually load your library before the original loadLibrary call is executed you can end up with a different library loaded.
The only problem is that System.loadLibrary(..) does not accept a file-name or path as argument. But using System.load(..) which uses a full path as argument you should be able to specify a full path to a file e.g. in the app's data directory. That way you can replace the library as often as you want and then just restart the app to load the updated library.
In the app I was helping developing, the users seen that each time they use apps like CM Security to clean 'junk', the files inside the folder associated with the app were instead considered as 'junk' and are deleted.
The app itself would create the folder in the C side of the code instead of using Java.
Firstly, when the app is first launched, custom C code will check if the app folder (e.g. 'Game') exists. If it doesn't, it makes it (regardless of OS. The app is cross-platform, sorry I forgot to say it.) It puts it in the external SD card ('sdcard/'). When it's seen, it can now run the app.
I get about the getFilesDir, but since the directory is made using C code and not through the java activity, it doesn't count as its app directory.
Is there a way to link the folder to the Android code so that it would be recognized as the app folder?
I am trying to change the display name of an Android file (the name shown on the screen once the app is installed). I only have the apk file*.
When I unzip the apk file, it's partially binarized. I know that to change the display name, I have to change the AndroidManifest.xml file, but that file is partially in binary.
If I unzip an application, change something (or nothing!), zip it back up, sign and zipalign it, the application does not work anymore. It doesn't install, but crashes while trying, claiming Parse Error - There was a problem while parsing the package.
If I unzip the application using ApkTool, change something (or nothing) and rezip it using the apktool b apkFolder -o changedApk.apk, then sign and zipalign it, the app does install, my changes seem to be present, but the app crashes the moment it opens up. The stacktrace seems to indicate that the following is the problem:
F/monodroid(12679): No assemblies found in '(null)' or '/storage/emulated/0/Android/data/Geocortex.App/files/.__override__'. Assuming this is part of Fast Deployment. Exiting...
If I rezip the application using the apktool b apkFolder (thus to place the changes in the original apk file), sign and zipalign, the application installs and works, but none of my changes are present. The last modified date on the apk actually doesn't even change, so it seems like the tool does nothing.
ApkTool seems to have been successfully used in the past by many others to do the same thing as me, but now I am wondering if perhaps it wasn't updated to the Android L version.
I also noticed that the original unchanged apk is about 3 mb bigger than the output from both the apktool and the regular rezip. As another side note, I am using the original key, keychain, password to resign the app.
Does anyone know how to do this, or why the application might be crashing? Does the apktool work for Android 5.0+? Any insight is greatly appreciated!
*Details about the source of the apk and my authorization (as requested by Chris in his comment): This particular application belongs to the company I work for (so yes, I do have the entire source code and could change the AndroidManifest.xml file there). However, this application is distributed to our limited clients manually. This application does not exist in the app store and every version is manually changed to suit a certain client's desires (e.g. specific app names or icons that match their company). In order to alleviate some of the developer's work load, I am creating a Windows Program that can do all these changes automatically and the work for our team would be as easy as having to type in a new name in a textbox. At the end of the project, I plan on having a Windows tool that can take the current version of our application (in its apk format), change the app name or display icons which were inputted in simple text fields, and output signed and zipaligned application that can be easily sent to our customers.
Just out of curiosity, I wanted to know where on the file system of an Android device the application icons are stored.
Like I have shortcuts to various applications on the homescreen of my device, where those icons files (or images) are stored. Is it only inside the application package (.apk) or Android stores it some where else?
If it is in application package only does Android loads all the imagess from each of the apk and loads it when it is started for the first time?
When an app file is installed, the .apk file is analyzed and various items of information are extracted by the launcher. (This process does not involve loading and running the app itself.) Among these items is the app icon, which the launcher typically caches in its own private area. Exactly how this is done depends on the launcher currently active on your device. You might be able to browse through the source for your launcher to find out more details about how it caches these items extracted from the app .apk files, but I'm not sure what practical use there would be to that exercise.
The launcher's use of its own cache greatly speeds up start-up, as otherwise every installed app would have to be scanned at every reboot to extract the requisite information for the launcher to show itself. However, the cache is the source of occasional problems, such as the icon not updating right away when an updated app (with a new icon and possibly a new app name) is installed. (See, for example, this thread and this one.)
Think about what happens when you create your own app. Typically, you create icons for your app for all drawable resource buckets (or at least the ones you want to support). Then these files get packaged with AAPT into the apk with the rest of your project. Then after installing your app, the OS will pick the icon that matches your phone configuration and create a shortcut on your installed apps page.
My guess is that the contents of .apk package are extracted somewhere, and the application is registered at some directory so that the application launcher or whatever can find it. But is that all? If that is the case, is the original manifest.xml read every time the app is launched or it gets pre-processed into some other form?
Disclaimer: This answer is now 10 years old 🎉. While overall probably still accurate, details have definitely changed (ART instead of Dalvik, dynamic vs. static permissions, etc). Take it with a grain of salt!
Some basics
The .apk-file
An .apk-file is not magical at all. It's just a bundle of files which represent the content of an Android application. If you open it in a archive-tool (like 7Zip), you can browser and extract it's contents.
Android is Linux
The basic Android-System is a Linux system. Android uses a custom Linux kernel with some extra functionality on power-saving and some speed-improvements. The internal storage of an Android device is formatted with the YAFFS2-filesystem, which fully features the Linux-like access-concepts.
The used file-system might differ by manufacture or Android-Version. Newer devices often use ext3, while Samsung uses it's own file-system: RFS
This is one important aspect of the Sandbox-system, which is used by Android.
Compiling applications
What happens to the .java-files?
First, they are compiled by the normal Java compiler. After they are compiled (to .class-files), the dx-tool from the Android SDK then converts/transpiles those "normal" java-classes into Dalvik-Bytecode.
This "special" java-code is then interpreted by the DVM (Dalvik Virtual Machine), which is based on the opensource JRE-implementation Apache Harmony.
Update: In newer versions of Android, the convert/transpile step can be skipped when jack is used. This way, the .java files are directly compiled into the .dx format.
Also, since version 4.4 (KitKat) Android has the new ART runtime, which officially replaced Dalvik in Android 5 (Lollipop).
What happens to the resources i put into the /asset-directory?
Android offers the /assets-directory to add some binary raw-files (e.g. a SQLite Database). Files which are put into this directory are not compiled or optimized.
If you put your files into this directory, this is the kind of behavior you would expect from Android.
What happens to the resources i put into the /res/raw-directory?
Like the /assets-directory, you can also put binary (or other) raw-files in here (e.g. HTML-files for the Help-page). These files are compiled/optimized (if possible).
What happens to the Manifest and the other XML-files?
The Android-Manifest and also the other XML-files (Layouts, Strings, etc.) are stored and "compiled" into a binary XML-format. This is a speed-optimization.
The Sandbox
From Android OS point of view, a single Application owns:
it's own process,
it's own OS-User (like on Linux),
it's own DVM,
it's own place in the heap and
it's own place on the filesystem.
So yes, every Android app has it's own user which has the proper rights to access it's place in the internal storage (which is protected by standard Linux filesystem rights-management) and it's own DVM-process (which can't be accessed from outside of the application).
To give the application the possibility to leave the Sandbox (e.g. to connect to the Internet), the permissions declared in the Android Manifest are used.
Steps during the installation
So from the above explanations, it should be clear what happens when an Android-Application is installed:
The new user for the Application is created.
With this new users rights, the Applications directory in the internal storage is created.
The contents of the .apk-file are being extracted there.
The Android-Manifest is parsed and the declared intent-filters are registered (e.g. the android.intent.category.LAUNCHER-filter for the applications standard entry point).
Now the application is ready for it's first launch.
When you install an app, Android System copies its APK to "/data/app" folder and it named it by the package name followed by the installations number (how many times you install or update the app).
I tried to install an app manually by copying its APK and paste it in the /data/app folder and rebooted my device then it appears as an installed app and works perfectly.
Also I noticed in the link2SD app that any installed app has the folowing:
Apk located in /data/app/package-number.apk
Dex located in /data/dalvik-cache/data#app#package-number.apk#classes.dex
Lib located in /data/data/package/lib
Data located in /data/data/package
Cache located in /data/data/package/cache
Android defines an intent as "an abstract description of an operation to be performed." Not only do intents let you use activities made by others, but they are also used to launch applications. I'm sure you've seen these lines in every app you've written:
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
This intent filter allows the launcher to find the starting activity of each app. Lookup "intent resolution" for more details on this process... I'd say it's more elegant than simply registering the application at some random directory.
As stated in, http://developer.android.com/guide/topics/intents/intents-filters.html, "Android system populates the application launcher, the top-level screen that shows the applications that are available for the user to launch, by finding all the activities with intent filters that specify the "android.intent.action.MAIN" action and "android.intent.category.LAUNCHER" category. It then displays the icons and labels of those activities in the launcher"