I want to know that a .apk file of android is an executable or it is just a package that contains the compiled code, resources, manifest.xml etc.
It's like Zip format and it's just a Package :
Wikipedia : Android application package file (APK) is the file format used to distribute and install application software and middleware onto Google's Android operating system; very similar to an MSI package in Windows or a Deb package in Debian-based operating systems like Ubuntu. To make an APK file, a program for Android is first compiled, and then all of its parts are packaged into one file. An APK file contains all of that program's code (such as .dex files), resources, assets, certificates, and manifest file. As is the case with many file formats, APK files can have any name needed, provided that the file name ends in ".apk".1[2][3][4]
APK files are ZIP file formatted packages based on the JAR file format, with .apk file extensions. The MIME type associated with APK files is application/vnd.android.package-archive.
Another Useful Link
It's a bit of a hybrid between the two. Code isn't executed directly out of it (the classes are copied into a separate file and optimized for your system prior to execution), but stuff like the application manifest and resources are loaded directly from it when they're needed.
A general explanation can be found here. i also found a similar thread in SO (can be found here). On AndroidBook, there's an interesting thread too: In brief, it's a package :)
APK files are Android Package and a variant of the JAR file format, which are built on the
ZIP file format, with a .apk file extension.
Related
I have a project with native libraries that I want to use, files with this format: lib<name>.so do get included into apk. But files with <name>.so format does not.
Is there a way to include the later type into apk in lib directory?
If not, is there a way to include the files into a directory inside apk, where I can load it from my native code?
The short answer is "no". The native binaries will only be packed into APK, and extracted to executable files upon installation, if their names follow the lib….so pattern.
Note that these libraries will be extracted to files according to the ABI of the target system. The installer does not check the actual properties of the file. The decision is based on the name of the folder under lib in the APK structure.
If you add the attribute extractNativeLibs=false to the application tag in AndroidManifest.xml of your APK, the installer (on Android Nougat and higher) will not extract the native libraries.
You can trick the system and have files that don't follow the above rule to the lib folder of APK, but there is very little sense in it, because they will never be extracted by the loader (it may also extract file gdbserver if the file is there).
The common practice is to put the arbitrary files in the assets folder of your APK, and extract them programmatically when the app runs for the first time after install. You cannot extract these files to the secured location where the usual native libraries go. You should not extract the native libraries to sdcard (e.g. getExternalFilesDir()), because the system may not allow execution of the files there, regardless of the execute access flag on the file. Make sure that you use the correct ABI flavour.
You can peek at the source code of Nougat native lib loader that can load native libraries from the APK without extraction, and use it to load your custom libraries directly from the assets folder of your APK.
Is there any way to get to .js files with code created with Appcelerator from compiled .apk?
I lost a source coude of one of projects and now have only .apk files and would like not to rewrite the whole code.
Thank in advance
If you would like to do this manually:
In release version of the app, Titanium puts all of the assets into Java class called AssetCryptImpl, you would have to decompile apk and look for that class file in the sources.
AssetCryptImpl file will contain private method called initAssetsBytes, which returns one large chunk of data as CharBuffer, which contains encrypted data for all of the asset files. The other method called initAssets, will contain all of the original asset filenames and also ranges for each of the asset files.
Asset data is encrypted using AES in ECB mode, and last 16 bytes from asset data are the decryption key. Asset decryption method implementation is inside JNI library but its not hard to rewrite. filterDataInRange will call native code to decrypt the resource.
You can easily rewrite filterDataInRange method, with your implementation, which will get the key and decrypt the resource data and write it to file. And write a method which will call readAsset for each filename from HashMap, from initAssets method.
If you want one click solution:
You can use the tool called ti_recover.
Install it with node package manager:
npm install ti_recover
Than use it from terminal/command line:
ti_recover apkfile.apk outputdir
Depends on how the Titanium app was built. If it's an emulator build, then yes, you can get the JavaScript files. If the apk is from a device or dist build, then no.
For device and dist builds, Titanium minifies and encrypts all JavaScript, then injects it into the Java code before compiling it.
So if you have an apk from an emulator build, you can just rename the .apk to .zip and unzip and the JS files will be there.
One thing to note is if your app is an Alloy app, then you'll only get the compiled Alloy code, not the original Alloy code. That means you won't find any .xml views, .tss styles, etc.
This Website might be your best bet. It uses a range of technologies to decompile .apk files.
You can try making a new folder and copy over the .apk file that you want to decode. Rename the extension of this .apk file to .zip (e.g. rename from filename.apk to filename.zip) and save it. After extructing, Now you can access the classes.dex files, etc. Also, in Asset folder you will get the resources. Though you can't get the .js file by following this process. You can use this http://www.javadecompilers.com/apk website. But still it will give you a java dicompilation.
This question already has answers here:
What are .dex files in Android?
(3 answers)
Closed 7 months ago.
When opening an APK file with WinRar (software to open compressed files). I got a bunch of files packed inside the APK. Among them classes.dex is one. My question is what is the role of this file and if we modify/delete the same file will it affect the APK?
.dex file
Compiled Android application code file.
From Android API GUIDES
Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
And yes if you will delete those files it will effect APK.
classes.dex is essentially all of the application logic. Code of the given application is written in java and then compiled to class files, then these class files are cross compiled (with many optimisations) to dalvik VM format. Note that there also might be some .so files which are also application code but these are generated when NDK is used.
You can not delete this file. You could however change it by first running this utility https://github.com/JesusFreke/smali which will generate smali code from this compiled dex which is somewhat similar to java and could be understood. You could also use tools ApkOneClick or ApkMultiTool to get Java source from the smali files but these would probably not be perfect and will require further fixing. When you change the code you want you should build the classes.dex again and put them into existing zip/apk file you have. Note that then existing certificate files (META-INF) will not be valid anymore and you will need to delete this folder and resign the apk package in order to instal it on the phone or emulator.
For more info you could check this question too What are .dex files in Android?
Also this is a great tutorial on disassembling dex files using existing tools http://blog.vogella.com/2011/02/14/disassemble-android-dex
What is the role of this file?
The role of classes.dex in Android is similar to that of JAR files in plain Java. It's a file containing bytecodes. In Android case, the bytecode is Dalvik bytecode, which is different from Java bytecode.
If we modify/delete the same file will it effect the apk?
If you modify classes.dex, you are modifying the programs behavior, which may or may not work after a repackage. If you delete classes.dex, then your application doesn't have code and you shouldn't expect it to work.
.dex file in the apk is the compress file which is made up of all the java classes in the application code. Its different than jar file. A jar file is a collection of .class files which are isolated. If we unzip .jar, we get all the classes separately. On the other side, .dex file is a single file made up with all .class file from application code.
Code compilation flow :
multiple .java files --> multiple .classes files --> a single .dex file
.dex files are the executables which are executed by the DVM...Dalvik Virtual Machine, which is a Runtime for Android.
.dex will never include resources. Resources are separately maintained in the /res folder in .apk
I have seen some applications that reverse .apk files into elementary files. I would like to know where can I find the official specification of .apk files, but I reached nowhere! Could someone enlighten us about where to look, and what are the best resources about the specification if there is not a formal specification?
I don't know if there's an official specification, but from browsing my app's file structure, I have deduced the following:
-The .apk is simply a zip file and can be opened as such in any suitable application (7zip, WinZip, WinRAR, any OS's default .zip tool).
-It must contain an AndroidManifest.xml file in the root directory (though this is a compiled .xml file and not human-readable).
-It must contain a classes.dex file containing the actual binary code compiled as Dalvik bytecode.
-It must contain a resources.arsc file. I believe it's an index of everything in the /res folder, but I'm not positive.
-It must contain a META-INF folder in the root containing CERT.RSA, CERT.SF, and MANIFEST.MF. These are the app's digital signature files.
-The app may contain the folders /assets, /res, and /raw that contain resource files like images and databases.
-The app may contain a /lib folder that contains folders for all the native code targets (like armeabi), which contain .so files (native code).
I probably missed a ton of things, but this should give you a good start.
I saw here that someone listed the contents of the manifest of the official Facebook app's APK. Is there a way to decompile that, or is that info available elsewhere?
An APK file is just a JAR - change the extension to .JAR, and use a decompression tool to decompress it.
If you're using windows, you could just use WinRAR - that should decompress JARs.
In addition to that, a JAR is just a regular ZIP file - so you could technically just change the APK extension to .ZIP instead, and open it up using pretty much any decompression tool (as mentioned by Peter).
Here's some more info on JARs:
http://en.wikipedia.org/wiki/JAR_file