Alright, so I have a problem with decompiling apks with apktools. I am currently trying to edit the current version of snapchat so that I can have unlimited caption length without root. To do this I decompiled the apk with apktools, edited the smali file needed and then recompiled it, but it will not install on the phone for some reason.
I then tried to just decompile and recompile the apk without any edits and it also did not work.
Is there some special signing that needs to happen for the app to be built and installed properly? Or maybe something that I am missing with apktools? I have decompiled many other apks and they worked fine, but snapchat is not having any of it. Any help is appreciated, thanks.
Well yes. You forgot to sign the apk, but assuming you did sign you will run into another bug which affects the functionality of the application which I've noted below. Check out signapk.jar for information on signing an apk.
This is a known bug (859) in apktool. Basically you have this string
<g id="username">$1%s</g> is typing...
which apktool decodes as
<g id=username>$1%s</g> is typing....
Apktool uses a different decoder for arrays.xml <items> (which is where these strings reside). You can manually fix these arrays (happens in multiple places) after decode by re-adding the double quotes. This should fix the problem.
Related
My professor said to me that when you build apk the serial number of the computer or of the cpu that built the APK is written in the file
My question is if it’s true where it’s written?
Because I think it’s might be wrong
I tried to decompile the apk
And search inside the files
I tried using 7zip too
I have dealt with APK structure and building, and have never heard of something like that, to be honest. Has he mentioned, which file should be affected? The APK in a whole or a specific file within the APK? And in which step of APK building this happens?
The closest I can think of would be the mechanism to provide alternative resources to support specific device configurations. But that still hasn't to do anything with any kind of serial number for the computer the APK was built on.
today I tried to replace default sounds for the TickTick app with custom ones, but I failed miserably. I tried apktool to decompile the app, replace the sound files in resources, compile it back, but this is the end for me, because apktool doesn't work with my setup (Ubuntu 21.10), not even if I run apktool d base.apk; then immediately apktool d base. It just crashes with this error.
So I tried directly modifying .apk file, replacing sounds, zipaligning result and signing the app (tried apksigner, jarsigner); also tried deleting whole META-INF, not deleting it, deleting only .SF, .RSA files.
When I use the combination of not deleting META-INF, modifying the sound files, zipaligning/not zipaligning before signing, then signing the app it can be installed, but when I try to run it, only black screen gets displayed.
Logcat gives me below information.
04-15 19:09:29.442 E/AndroidRuntime(26166): at com.ticktick.task.TickTickApplicationBase.initKernelManager(TickTickApplicationBase.java:2)
04-15 19:09:29.442 E/AndroidRuntime(26166): at com.ticktick.task.TickTickApplicationBase.onCreate(TickTickApplicationBase.java:19)
04-15 19:09:29.442 E/AndroidRuntime(26166): at com.ticktick.task.TickTickApplication.onCreate(TickTickApplication.java:1)
Since I cannot turn on debug mode, because apktool doesn't work for me I am lost. Is there anyone with more knowledge on this subject than me, who would be willing to help?
Thanks for reading this far.
So it turns out apktool currently has a bug, so once I used workaround from user Gourov, I was able to use apktool. I encountered another problem however - APK exported from my mobile wouldn't start once altered, so I went to apkmirror.com to retrieve APK for the app, decoded it using apktool, replaced audio files with mine, built it using apktool, signed it with apksigner, installed it on my phone using adb install and it just works :)
I am currently working on an android app but my hard drive unfortunately crashed and I lost all the data on it... I am trying to recover my source code from the debug APK I had installed on my phone (using dex2jar and jd-gui) however, it seems like the classes are not present in the classes.dex and classes2.dex (both files are tiny and do not contain any of the classes in my code, see photo).
I used apk extractor to get the apk from my installed app and I cant seem to get anything close to my original classes... I am wondering if I am doing something wrong to get the APK from the installed app; any help would be greatly appreciated.
Thanks.
For de-compiling your APK to Java classes you can go to this site -
http://www.javadecompilers.com/apk
Just upload your apk and click on decompile. It should work for you !
I'm building phonegap app using phonegap-build.
I need to make some changes to the manifest of the android apk.
After i download the apk of my phonegap build, i rename it to .zip file to see the contents of the file.
When i open it, there i see the xml file there, and when i open that one, it has encoding problem.
This is what i see:
I understand it's a binary, but i need to see the content in plain english, if possible.
1) How can i encode it to see what is the content of this file properly?
2) After a change that i do on it, can i "decode" it back to binary?
So from what you wrote you wrote, you want to edit the AndroidManifest.xml from an APK file AFTER you built it, which is quite complicated. I suggest you editing the source AndroidManifest.xml and then re-building the APK. If you can't do this then please do the following.
(1) First, download and install Apktool. It is a free Android tool for decompiling and recompiling apps quickly. It provides access to .class files, resources and XML's. Here's a tutorial on how to install Apktool.
(2) Then you want to decompile your APK file (tutorial).
(3) Edit the AndroidManifest.xml file.
(4) Re-build the application (tutorial).
(5) Finally, you will have your APK file but it will be mostly useless as it is un-signed. You can't install un-signed apps as you will get an error (it may be possible to force-install it using root or adb tho) and you can't publish them. To sign it you can check out this link.
IMPORTANT INFORMATION: Your app will have to be signed with the same certificate with which it was signed the first time, otherwise it will be considered a different app. Not completely tho, you will have to un-install previous versions in order to install this one.
And yes, I know it's a very long and time-taking process but it is supposed to be, only if you have the source you should be able to edit the app.
As mentioned above, the tool you are looking for is Apktool.
You need to use --force-manifest flag when you decompile to decode AndroidmManifest.xml.
I'm creating a software that will guide the user through a few steps, to publish an android application (APK file).
The way I am doing this, is that the APK file is already compiled, and all I need to do is replace an XML file in the package, and that will change the behaviour of the application. My big problem now, is that unpacking the apk file, and doing any tiny text edit, and then packing it again, breaks the signature and prevents the application from running on any device, giving a message that the signature is incorrect.
How can I solve this? I want to safely open the APK, write something in a text file, and close it again. Note that this operation will be done on the user's computer (after he purchases our application) so we're look for a command-line tool with no special requirements like JDK.
Any help?
Ok I reached the best "tested" solution - I'm posting it here to save other developers hours of googling. The only downside is that I will require the customer to install JDK on his machine, unfortunately. The reason is because I did not find any apk-signing tool that works purely on windows, without relying on JDK.
I have my android application created using Air, so this makes things easy for me - all of the air files are treated as resource assets. So have your APK archive file ready.
Once you have your modifications ready, put them inside a temporary folder named "assets". You will use the 7-zip command line tool (free: http://sourceforge.net/projects/sevenzip/) to update the contents of your apk. To have it working with your apk you will have to rename your apk's extension to zip - don't worry, you'll change it back later.
Now from a .bat file (or directly in the command prompt) from the location containing both your apk file (zip extensioned) and your assets folder, you'll call: 7za u APK-file.zip assets
Now your apk file is updated. Rename it back to .apk extension
Now you'll use the signAPK tool from here https://code.google.com/p/signapk/ and note that this is the only step requiring JDK installed. It also assumes that you have your key files ready (replace the dummy ones included in the package). Extract the file contents and call: java -jar signapk.jar key.x509.pem key.pk8 [android_app].apk [signed_android_app].apk
At the very end, you may find your signed apk file size drammatically increased. So you need to use the android's zipAlign tool: (darn, can't post the link since new users can only post a maximum of two hyperlinks)
you will be calling the command: zipAlign -c 4 [signed_android_app].apk
And voila! That's the route I'm taking.
If someone finds a way to do the signing process without relying on JDK (assuming the key files are ready) please share.
How can I solve this?
You don't. If you modify an APK file, by any means, it must be re-signed.
Android apk files must be signed. That signature proves that the contents of the apk have NOT BEEN MODIFIED from what was initially published. (Which is exactly what you are doing.) The signature at the same time, also proves who the author is.
So in a normal signed apk file:
You know who the author is. (Even if it's not something you as a human can understand.)
You know the contents were put there by the author, and not modified since.
This is a key security measure built into Android, is there for very good reason, and cannot be overcome. It prevents things like viruses from being embedded inside innocent apk files.