Is there a way to update my published app's first version if I have lost my signed apk, keystore and .pepk files? My laptop crashed - my data was not backed up. The only thing I have is that 1.aab file from Google play - I don't know how can it be helpful in my case.What can I do?
If it's published you can download the apk in the Google Play Console. APK extraction tools are there, as well as (dex2jar), what you'd have to do is rename file to zip, extract the contents, use dex2jar, change bundle ID/version or whatever in the manifest, resign it, then repackage the APK.
Those are the gist of it, high overview steps, you can easily find a detailed version on the internet or on SO if you look deeper.
You can use google console to recreate your signing stuff, keys, etc.
No, there is no chance to do that. You just learned how important a backup can be.
Related
I'm currently using Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS) as a path. I have requested android.permission.WRITE_EXTERNAL_STORAGE. I am targeting SDK 30. I have had success reading and writing a file on Android 8 and Android 11, but not Android 10. Adding android:ignore="ScopedStorage" and android:requestLegacyExternalStorage="true" to my AndroidManifest.xml didn't work.
Reading through the official docs, it's very confusing. I tried an alternative approach with an ACTION_OPEN_DOCUMENT_TREE indent, but all I could navigate was the Downloads folder. I couldn't get to the Documents folder.
There are multiple questions on here that are similar, but don't quite get to the nub of the matter for me. Can anyone please share some light on how to do something as basic as simple file access to the Documents folder?
Actually, the problem was that on this particular Android 10 device there was no "Documents" folder. Manually creating one fixed it. So the real gotcha is that Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS) sometimes doesn't give you a "Documents" directory depending on the device.
However, I'm not convinced this is the correct way to do this with Android 11 (even though it's currently working for me).
I have an apk file present in 2 standalone servers both of which have separate download links.
I would like to know if it is possible to detect from which link the apk was downloaded after the app was installed and opened.
The download is via browser and the one of the requirements is that the build has to remain the same.
If you are just installing your APK as a link directly on a file server, and the APKs are exactly the same, then no, there is no way to do this.
Here are some work-arounds:
Google Play provides a way for you to do this, but they are doing this through broadcasting an intent to the application after it has been successfully installed. You could release the APKs through Google Play privately through the beta / alpha channel, and take advantage of this feature perhaps. You'd not be able to use a private file server though.
You could create your own application that downloads and installs
the APKs and mimics Google Play's functionality which I described
above. This would probably be ridiculous for you to do, and I don't recommend it.
You could differentiate the APKs in some way. You could keep the content exactly the same, but configure some fields in the build logic through Gradle using the buildConfigField. You could also do split apks, use flavors, or a number of other different creative solutions if you wish.
So if for some reason the above suggestions don't meet your requirements, another solution that would be extremely hacky would be to use different APK file names. The browser would download the APK to the download folder, and you could probably look at the Android downloads folder after opening the app and look at the file name. This would not be reliable in any way though, as users could easily delete the file before actually opening your app, or there could be old downloads also. You'd have to look for base file names, and identify the most recent file based on creation date.
I have got lot of doubts to be cleared in the case of Android signature verification and its vulnerability.
Once we generate apk for an application we can unpack the apk and edit resource files using apktool. As we repack the edited apk back it loses its signature. I can resign the unsigned apk using the jarsigner with my own private key that i used while generating the apk. I found an application named zipsigner in playstore which can be used to sign such kind of unsigned apk.
So when this zipsigner signs the unsigned apk, whether the apk is signed with my same private key or with a different key? Because my META-INF folder still holds the XXX.SF and XXX.RSA files which holds the information of my private key. If it is with my same private key then the new apk will be an upgrade for my application or if it is a different key i will be having two different applications with same name.
From the above situations there are possibilities that malware could be included in my apk while repacking. There seems to be a loophole in Android's signature verification mechanism where the message digest of the files inside the META-INF folder are not included in the MANIFEST.MF as well as in the XXX.SF file. This creates a possibility for anyone to include malware codes inside these folders, repack the apk and resign it with the zipsigner application.
I was searching for a solution where i can prevent files being added into the META-INF folder and i found one from the below blog. But I'm unable to get the point of the solution. This looks like more of a research topic so there is not much information available in the internet. Can someone try and figure out the solution specified in the blog. The blog link is specified below the question.
http://blog.trustlook.com/2015/09/09/android-signature-verification-vulnerability-and-exploitation/
Private key is never part of a distributed APK, unless I misunderstood your question. Someone else signing on your behalf is not possible unless your own system is hacked.
The shared link (blog.trustlook.com) talks about Android skipping checking of files with .sf (and files with related extensions) extensions. So a malware could cloak itself in a file with one of these extensions. The fix mentioned there is an Android "system firmware" fix, not something that can be done at application level. This means, an OEM (Google itself, or Samsung/other) has to release an updated firmware to fix this. Check the latest updates, it might have been fixed already.
In my opinion, even if an user sideloads APK's, this is more of a nuisance than a real attack/threat. Refer to the Blackhat paper below for further details - https://www.blackhat.com/docs/ldn-15/materials/london-15-Xiao-What-Can-You-Do-To-An-APK-Without-Its-Private-Key-wp.pdf
You should also read this for potential ways of tamper proofing APK - https://www.airpair.com/android/posts/adding-tampering-detection-to-your-android-app
Reading from the other answers link black hat : APK issues
If you keep your private key safe, then only you can sign APKs, and only you will be able to publish them to a given store.
Extra information in the META-INF directory is not checked, and validated. This allows extra data to be added to the jar file, which could be used to smuggle information into the APK. But this would not be used by your APK file, and would not cause reputational damage.
There is a weakness in the testing algorithm, which means the validity of a certificate is not checked on the device if self-signed.
Data smuggling
Not checking the META-INF file is a side-effect of how the crypto- code works. In order to protect things you need to create a message which uniquely describes the message. This is a hash of the protected data. Unfortunately, the certificate, can't be included in this, as it is added after the hash is calculated.
So generally there are places which can be added to without breaking the signature. For windows and .exes, Microsoft's report here:MS13-98. In this case some installers used the unchecked data to choose where to download files from. This made them vulnerable.
Within an X509 certificate, there are unchecked fields. (unauthenticated attributes). Which makes any X509 based solution capable of smuggling data. Your protection, is the local copy you uploaded doesn't have the smuggled values.
If you don't rely on the un-authenticated data in the security directory, then you can't be made vulnerable to it being changed. So best option is to not do it.
Self - signing issue
Self-signing causes some checks to be missed. This allows an attacker to create an updatable package, which purports to be theirs. This is a copyright issue, rather than a security issue, as it is visibly the tampered binary (does not pass the self-signed check).
Is there any way of repacking the apk and signing the application with the same private key?
The private key is not available within the APK, so it can't be used to re-sign the data.
The files in the APK (outside META-INF) can not be modified without changing their hash.
whenever the apk is unpacked does it lose its signature information?
Un-packing the APK does not break its signature, and you can re-pack. You can remove items from the APK without breaking the signature. However, it is not possible to change resources, and code without breaking the signature.
I'm trying to push one mp3 file to (Emulator) the location /system/media/audio/ui using command adb push But, i'm having
E:\Android\android-sdk\platform-tools>adb push song.mp3 /system/media/audio/ui
failed to copy 'song.mp3' to '/system/media/audio/ui/song.mp3': Read-only file system
this error. How can i change the Permission or how to push the files to this location. Any idea?
Unless you have a really good reason not to, you should stay in the /sdcard/ folder. Except for /sdcard/, most of the file system is read-only for a normal user.
It is possible, but not recommended, to "root" the phone. After which you would have full access to the whole system. Attempting this on a real phone, could break the phone, or invalidate your warranty.
If you wish to get root-privileges on the emulator, you can look at the accepted answer to this question: how to root/getroot access on android emulator?
That means your emulator does not support the sdcard. So create the emulator with sdcard option. see the bello image...
I'm currently developing an application for a company which includes livescoring. The XML-files I access (from the net like: "http://company.com/files/xml/livescoring.xml") are not intended to be public and should only known to me.
I was wondering if it is possible for anyone to decode the .apk file and read my original .java files (which include the link to the XML files).
So, I renamed the .apk file to .zip and could access the "classes.dex", which seemed to include the .java files (or classes). Googling led me to a tool named "AvaBoxV2" which decoded this "classes.dex" file. Now I have a folder including an "out" folder where files named .smali exist. I opend one of these with an editor and finally there is the link to the xml file. Not good. :(
Is there a way to encrypt my app or the classes.dex file? I don't want to tell that company, that anyone can access the original xml-files. Maybe signing the app probably helps?
Also, do you know a really noob-friendly tutorial to prepare apps (signing, versioning,...) for Google Market?
Thanks in advance!
The .java source code is not included in the APK.
It is possible to disassemble the Dalvik bytecode into bytecode mnemonics using a tool like baksmali, but there's no way a user can recover the original .java source.
Furthermore, you can use a tool like proguard (included in the Android SDK) to obfuscate your byte code, making it hard to interpret the behavior of the disassembled bytecode.
You can make small tricks too, like storing the link string in some sort of obfuscated form, and then de-obfuscating it at run-time in your app (a simple example would be to use base 64 encoding, but someone could probably reverse that quickly if they wanted to).
That said, it's pretty trivial for someone to run tcpdump and sniff the network traffic between your device and the server, and get the URL that way, so there's no way to completely prevent anyone from getting this value.
Yeah, its impossible to fully prevent something like this. Its the same on a desktop application, or any other application.
As mentioned, obfuscation will help, but people who are persistent can still get past it. Especially for something like a url like that.
One solution of making it much more tricky for hackers is to use PHP on your webserver and some sort of token system to determine if the request is coming from your app or not... That would get a bit tricky though, so I don't really suggest it.