As the subject line states: I've signed (successfully?) my custom ROM zip file using various programs/methods. Each of them claims a successful signed zip at the end. However, when I try applying my ROM via CWM, I get the standard E:sig verification failed error msg. (Of course, disabling the verification check in CWM allows my ROM to be installed, error-free).
Yes, I've been through all the signing tutorials (that I could find) on this board. A couple were quite useful, but all they did was confirm I was doing the procedure correctly.
Here's a bit of background on my ROM:
It's actually a collection of 4 types of APKs:
some stock, Sense stuff... presumably signed by HTC
some 3rd party (Market) APKs... presumably signed by the appropriate author
some of my own APKs (signed by me, with my own SSL key)
some of my own APKs (not signed at all)
I've also gone in and modified some existing stock HTC APKs.
I tell you this info because I think this is where the problem might be.
Is it possible to sign a ROM file only at the ZIP level (and thereby encompass all the APKs within it)?
If not, do I have to go inside the ROM and sign each APK individually? Do I need to sign them all, or only those that have changed? And which key do I sign it with? (mine? generic test?) Is there ever a scenario where I have to remove/replace an existing signature from an APK with my own signature? Do I need to remove any existing META-INF folders before attempting to sign anything?
These are the questions to which I could find no answers.
Any help would be greatly appreciated.
Thanks,
- Anthony
Tigger31337 said:
As the subject line states: I've signed (successfully?) my custom ROM zip file using various programs/methods. Each of them claims a successful signed zip at the end. However, when I try applying my ROM via CWM, I get the standard E:sig verification failed error msg. (Of course, disabling the verification check in CWM allows my ROM to be installed, error-free).
Yes, I've been through all the signing tutorials (that I could find) on this board. A couple were quite useful, but all they did was confirm I was doing the procedure correctly.
Here's a bit of background on my ROM:
It's actually a collection of 4 types of APKs:
some stock, Sense stuff... presumably signed by HTC
some 3rd party (Market) APKs... presumably signed by the appropriate author
some of my own APKs (signed by me, with my own SSL key)
some of my own APKs (not signed at all)
I've also gone in and modified some existing stock HTC APKs.
I tell you this info because I think this is where the problem might be.
Is it possible to sign a ROM file only at the ZIP level (and thereby encompass all the APKs within it)?
If not, do I have to go inside the ROM and sign each APK individually? Do I need to sign them all, or only those that have changed? And which key do I sign it with? (mine? generic test?) Is there ever a scenario where I have to remove/replace an existing signature from an APK with my own signature? Do I need to remove any existing META-INF folders before attempting to sign anything?
These are the questions to which I could find no answers.
Any help would be greatly appreciated.
Thanks,
- Anthony
Click to expand...
Click to collapse
Here is something that works if you decompile and recompile a apk take the res folder out the part you tweaked and throw it in one that wasn't tweaked or extracted and the Sig will be good.
Sent from my PG86100 using xda premium
reaper24 said:
Here is something that works if you decompile and recompile a apk take the res folder out the part you tweaked and throw it in one that wasn't tweaked or extracted and the Sig will be good.
Sent from my PG86100 using xda premium
Click to expand...
Click to collapse
Okay, so you're saying that signing at the level of the ROM ZIP simply isn't enough. (I wish the guides would say that).
You're saying, I will need to preserve the sigs on the original APKs? I get that. But now that raises more questions:
- when you say "decompile" an APK, I assume this is a simple unzip/extract? That's all I've been doing so far (I use 7-Zip).
- Say I now have an extracted APK (assume it was an HTC stock), I can inject my modified files. Piece of cake. I now have an HTC APK with my own data in there. But what about all the other APKs that make up my entire ROM? Do they ALL have to been signed the same way? (In this example, do they ALL have to be HTC signed?) I'm guessing NO, because there are apps in the data/apps directory from the Market, with their own vendor sigs. I can't see why I would have to re-sign those APKs using the HTC sig.
- So, we're back to my original question: can't you sign a ROM at the ZIP level, or do I have to go back into each individual APK inside that ROM and re-sign them all? Why would the original signature work, but not my own? I have generated my own SSL keys, so in theory I should be able to unzip a APK, tweak it, and re-sign it as my own.
Why does my ROM keep failing the signature test in CWM? I am looking for the necessary and sufficient conditions to allow my ROM (any ZIP file, really) to pass the signature verification check.
No one on this board has been able to answer that, so far.
Thanks so much,
- Anthony
Related
hello guys
through sbfrecalc I managed to open a original ROM 2.1 of droidx
I would like to try different type apk on my milestone: blurhome, blur service, blurcalendar, blurupdater etc etc..With rootexplorer installing them, after write me "apk not installed"
is a test without success, or do I have to change any library?
any advice is welcome!
thanks
any ideas?
1. do a test-key sign of apk.
2. copy appropiate jar files associated with apk
3. copy the libs needed
4. make sure framework support the blur functionality
5. update init.rc to load the required jar files at the end.
you're up for a little challenge. My mod of Motoblur is the closest you get to using it.
Dexter_nlb said:
1. do a test-key sign of apk.
2. copy appropiate jar files associated with apk
3. copy the libs needed
4. make sure framework support the blur functionality
5. update init.rc to load the required jar files at the end.
you're up for a little challenge. My mod of Motoblur is the closest you get to using it.
Click to expand...
Click to collapse
thank's dexter!
your motoblur its base froyo, but my idea was to prove eclair, and how do I know which are the correct libraries?
at your 5 answer im not sure to understand!
thanks for the reply and thanks for your work!
Hello, I would like to create my own update.zip that would be compatible with clockwork mod. I have several files in several locations that I manually copy over after new installs like multicolored bash nano iwconfig iwlist etc. And I think it would be much easier to create a installable package for that, I also delete a number of built I. Apps like tweeter amazon etc. And I have seen the scripts inside oyhers update.zip's that I could add the bash commands to remove those things as well.unfortunately I know nothing about what clockworkmod wants and I see binarys inside these zips dont know if those are customized for each zip or the same in all of them, I dont know what files or information is absolutely required. The best possible solution is if I had a blank update.zip that held all of the required files settings and all I needed to do was add my files and asd a few lines to a preexisting script to remove sum stock apps.thinking back I might have seen a file containing all the files names and md5 chucksums for each as well which if necessary I can do. Is there something like this available for download sumwhere? If not ajy resources to learn the required information and find the required binarys.thank you in advance.
Sent from my Droid using Tapatalk
Hi,
I've been trying to learn the same thing. I'm curious if you found anything useful since posting this.
Of course, if I find anything, i'll post back here too.
Thanks.
Same problem here
Good to hear someone with same problems. I want to create a generic ROM for myself and I want to use ClockworkMod to help flash it instead of using fastboot.
Well, I have found no documentation about what ClockworkMod may need for a zip file.
But I guess it could be possible to just replace them with your own by downloading an existing zip file created by someone else.
I'll try it to see if that works or not. Of course, a documentation would be better.
I regularly flash a new CM7 Nightly as they are released and I have to manually modify some things each time a new rom is flashed. I change screen density and add a notification ringtone that CM7 does not have. I wanted to automate that. Since I have to reflash the Google Apps each time anyway, I thought why not modify the gapps zip to include my changes. After searching the web I found a little info about how to do it. I just modify the zip on my computer using WinRar, copy the file to my device and re-sign the package using signapktic which is free on the market. Then flash using CWM. It worked great. No more manual adjustments. There are some instructions here which helped me:
http://forum.cyanogenmod.com/topic/15030-moving-apps-to-system/
I been getting into the kitchen
http://forum.xda-developers.com/showthread.php?t=633246
So far i`ve managed to integrate a few apps , ringtone should be easy
next the fonts from utmost rom
thanks to the kitchen, Im now running at script kiddie level
I know I have done this before and this is a noob question, but lately I've been having trouble with this.
If I make changes to the zip file of a ROM (eg replace a few existing files, and remove some unwanted system APKs, but not add anything new), do I need to sign the zip before flashing or just flash straight after editing? Also what's the best tool to use to replace the files within the zip? I trust WinRAR will do the trick...
djsubtronic said:
I know I have done this before and this is a noob question, but lately I've been having trouble with this.
If I make changes to the zip file of a ROM (eg replace a few existing files, and remove some unwanted system APKs, but not add anything new), do I need to sign the zip before flashing or just flash straight after editing? Also what's the best tool to use to replace the files within the zip? I trust WinRAR will do the trick...
Click to expand...
Click to collapse
I've never added anything (yet!), just deleted un-wanted APK's and altered some system files (ie build,prop etc). I've never signed anything and I used IZArc although only as that's what's installed on my XP system.
This is something that I too would like to do more so that I can further personalize and tweak some of these already great ROMS, so I'm also curious for some pointers from more the experienced.
Check the portal, there's an app to create flashable zips there.
PS - POST QUESTIONS IN THE GENERAL SECTION !!!!!!!!
You can set a flag in recovery to check for signatures or not. When it is not set you can flash any zip file
Sent from my HTC Desire S using XDA App
jorgen2009 said:
You can set a flag in recovery to check for signatures or not. When it is not set you can flash any zip file
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
I tried this once, and then I flashed the zip. It was a CM7 zip which would normally take at least 20-30 seconds to complete, but this modified zip flashed in less than ten seconds. It said successfully flashed but when I rebooted nothing had actually happened. Hence I was wondering what went wrong?
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
deomaki said:
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
Click to expand...
Click to collapse
All system apps have to be signed the same way, yes. You can sometimes mod your services.jar to turn off signature verification but that can leave you a bit more open to malware.
When you mod a system app, you just have to make sure you use the original signature in the new version. The only exception to this is if you change anything in the manifest. Then you will need a new signature, which means either signing everything else with that signature or doing the services.jar I mentioned earlier.
Hello Ticklefish,
first of all: Thanks a lot!
To summarize your answer:
1) Modding services.jar is out of the question! Would never have done this anyway...(risky from a malware point of view)
2) In case I modify a system apk WITHOUT altering the manifest.xml I can reuse the old apk signature for my new apk (the whole META-INF folder has to be copied over to the new apk?)
Nothing else has to be adjusted?
I suppose I still can do a zipalign afterwards in that case?
3) In case of modifying the manifest.xml I would have to resign ALL system apks.
All of them or only those that rely on the same framework as the modded apk?
Do I have to resign the framework apk as well?
I am asking, because I will have to mod several apks relying on different frameworks: At least one where I have to alter manifest.xml...
Thanks in advance
Markus
deomaki said:
Hello Ticklefish,
first of all: Thanks a lot!
To summarize your answer:
1) Modding services.jar is out of the question! Would never have done this anyway...(risky from a malware point of view)
2) In case I modify a system apk WITHOUT altering the manifest.xml I can reuse the old apk signature for my new apk (the whole META-INF folder has to be copied over to the new apk?)
Nothing else has to be adjusted?
I suppose I still can do a zipalign afterwards in that case?
3) In case of modifying the manifest.xml I would have to resign ALL system apks.
All of them or only those that rely on the same framework as the modded apk?
Do I have to resign the framework apk as well?
I am asking, because I will have to mod several apks relying on different frameworks: At least one where I have to alter manifest.xml...
Thanks in advance
Markus
Click to expand...
Click to collapse
If you're modifying an APK without changing the manifest, the best method is to use 7zip or similar to open the new APK and drag the modded files over to the original APK. That way you're still using the same META-INF at the same compression ratio.
Or use Tickle My Android (https://forum.xda-developers.com/showthread.php?t=1633333) to do it for you....cough...cough...
You can zipalign afterwards, just remember that any further changes will affect that zipaligning so you'll have to do it again.
As far as resigning the APK goes, all I know is that you have to change every file that uses the same key/signature as the app you resigned so that they all match.
I have to confess that I've never actually done this. I rarely change the manifest myself and, when I do, I disable signature verification. Yes, it makes you more prone to malware but as long as you're careful about what you install you should be okay.
deomaki said:
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
Click to expand...
Click to collapse
I usually use Mixplorer, (if you use your phone to de/re-compile). Click on compiled apk, select 'explore' and a new tab opens with the contents of the apk. Delete the manifest that was created in recompile, then go to folder with decompiled apk, /original, and long-press to select android manifest xml, and META-INF folder. Choose copy, and paste them into new apk.
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider. I've used the latest apktool (2.3.4) to unpack and repack the apk. I'm replacing it from TWRP and I checked that it has the same owner and rights. And after rebooting the device never finishes booting up (stuck at Samsung logo and blue led).
If I boot back to recovery and put back the original framework-res.apk the system boots fine.
What else do I need to do to make it accept the modified framework?
hey
Are you ONLY modifying the apk?
I would say there is a lot of things to check. It could be that the apk is being rejected by your handling of it. Compare both versions by 7zip lz4 without extracting. Try and use the best tools during the process.
Also more than likely you're conflicting with a service or permission that a perfect apk can't fix.
Have you tried a search in your ROM to see if any files might be associated with the result you want?
Stuff like...
com.android.location.provider.jar
com.android.location.provider.odex
com.android.location.provider.xml
Try doing all the work from your phone without any windows apps. FX explorer and symlink the apk.
Now that everything I said was probably wrong, someone else can tell you how. I'd try fx and symlink, though. It may just align the planets for you
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
@wirespot - Did you ever solve the problem you described in this thread?
Not really. My last attempt was to use Runtime Resource Overlays (RROs) to override certain framework values in order to allow org.microg.nlp to run side by side with Google's service.
I will provide them below but it ultimately didn't work. The RRO apk was installed correctly, I could access the NLP settings in the system settings but the main app still could not detect or connect to the service and none of the apps that use location would work.
If anybody else wants to build or use the RRO apk I'm attaching the relevant files as well as the apk. Please note that the built apk only has "org.microg.nlp" as service in arrays.xml (but I provide an arrays.xml with all three services).
apktool.yml is provided as txt file because it wouldn't let me upload it otherwise, remove the .txt. It's used if you build the package with apktool. Remember that you'll also have to generate your own certificate and sign the package in order to install it.
Also some links that may help:
https://forum.xda-developers.com/t/guide-how-to-make-gsis-overlay-file-for-your-phone.3878974/
https://github.com/ReinhardStrauch/framework-res-overlay-sample
https://android.stackexchange.com/questions/110927/how-to-mount-system-rewritable-or-read-only-rw-ro
https://source.android.com/devices/architecture/rros#configuring-overlays
https://source.android.com/devices/automotive/hmi/car_ui/appendix
https://source.android.com/devices/automotive/hmi/car_ui/rro#step_6_dump_the_idmap
https://dzone.com/articles/customizing-android-devices-using-the-runtime-reso
https://dzone.com/articles/android-solution-install-parse-1
https://stackoverflow.com/questions...s-not-recognized-internal-or-external-command
https://github.com/lineageos4microg/android_prebuilts_prebuiltapks/issues/22
wirespot said:
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Click to expand...
Click to collapse
For decompiling and building Android Oreo, I prefer version 2.3.1 of APKTool to other versions of APKTools.
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
...
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
wirespot said:
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider.
What else do I need to do to make it accept the modified framework?
Click to expand...
Click to collapse
I have not tried modifying framework-res.apk of a Samsung Android Oreo nor have I particularly tried the location services mod you are attempting (though I might get around to trying it someday) and do not know if it is valid to to accomplish what you want with it, but believe that the process should be similar to modding the file on LG Android Oreo. I shall try to guide you to how to prepare a framework-res.apk that is proper.
To answer your question about expecting a certain key. The answer to that is that that is usually the case. The signing scheme checks on system apps; however is usually not as thorough as non-system apps. framework-res.apk is also special in that it is not a running app and is instead used as a cache of system resources and system meta information. In the past, before Android Oreo, a rebuilt framework-res.apk may be made to work simply by including original signature files (META-INF) and corresponding AndroidManfest.xml file from the original framework-res.apk into the rebuilt fraemwork-res.apk file. The system would evaluate these files, and pass a check for valid platform signature. With Android Oreo, it appears that there is an additional check that was not present in the past; my best guess is that the system is checking for the V2 signing scheme signing block within the V2 Signing Scheme APK file structure. The check does not, however, thoroughly validate the signing block information.
Your mod seems rather simple and, given your previous posts, would only involve a modification to framework-res.apk "resources.arsc" member file (which contains the compiled "res/values/arrays.xml" file). If the rebuilt "resources.arsc" can be used to update ("Update" is an actual ZIP archive operation) the original framework-res.apk's member file, the updated framework-res.apk should work (and remained zip-aligned if originally zip-aligned), so long as the packed file size of the updated member file is less than or equal to the packed size of the original member file, plus up to 4 bytes depending on proximity to the next member file data if original framework-res.apk is zip-aligned as expected. If the packed modified member file(s) are larger, the original APK file structure would likely not be preserved, and a different method might have to be used. Also note that 7-Zip is not reasonable software to use for this, despite it being included with many tools on XDA to modify APK files; the software has had a history of rearranging unnecessarily zip file table entries when a change is made to an archive. Use a different tool that does not do this, such as WinRAR (I have tested version 5.61).
For normal apps, one may not copy over "resources.arsc" or resources from two different app builds and have things work correctly when the app runs; one would also need to make corresponding changes in the *.dex APK member files. framework-res.apk, not being an app the runs, has no corresponding *.dex files, and one need not worry about corrupting the relationship between the *.dex files and the resource files because none exists to corrupt.