Database Info

Signed my ROM - still getting E:sig errors in CWM.

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

[GUIDE][TUTORIAL] Create small flashable zips to restore before applying MODs/Fonts

GUIDE: CREATING SMALL FLASHABLE ZIPs TO RESTORE FILES OR SETTINGS WITHOUT HAVING TO DO FULL NANDROID RESTORE
This will enable you to apply MODs without having to do a FULL NANDROID restore to recover if the MOD fails or if you don't like it
This brief guide will teach you how to create a flashable ZIP file that you can use to restore your phone to pre-MOD settings if you want to revert back or if the MOD simply does not work
WITHOUT having to do a full restore of your phone.​
It is a very good idea to create these backup flashable ZIPs and keep them safe to recover from mishaps or when creating/testing MODs/themes.​
*************************************************************************************************************************************************
As usual: Disclaimer: I am not responsible for any loss of data or functionality on your phone. To be 100% sure, always make a NANDROID backup if you are not 100% certain you can recover.
*************************************************************************************************************************************************​
There are many reasons you might want to do this, for example when testing a MOD for another ROM that is similar to yours but not exactly the same (eg: Optimus G3 vs Cloudy G3) or when upgrading your ROM to a new version and wanting to re-apply old MODs.
There are many ways to get into boot loops or fail to boot, the biggest culprit being fonts installations, but include also bootanimations and others.
INSTRUCTIONS:
Part 1: general
1. Install ZIPme app from playstore
2. Find out which files are being modified by the MOD you are trying to apply, this is usually framework-res.apk, LGSystemUI.apk, lge-res.apk, but be aware that some MODs affect a lot of files. See part 2 for more details on how to do this.
3. If you are applying a font, don't worry, the FONTs section (see part 2) should cover all Fonts.
4. If you are applying a bootanimation, don't worry, the bootanimation section (see part 4) should cover all Bootanimations.
5. For every flashable ZIP you create you can test it straight away by booting into recovery and applying the zip file. There is no reason why it should not work.
Part 2: FONTS
1. In ZIPme select the following:
- ADD FOLDER: /system/fonts
- ADD FILE: /system/etc/system_fonts.xml
2. Create the flashable zip in an /sdcard location you can access from recovery
Part 3: MODs that affect framework-res.apk, LGSystemUI.apk or any other app
1. Find out which apks are being modified:
- You should of course read the OP (instructions for the MOD)
- The easiest way to find out modified apks is to download the MOD and open it: the zip file will contain either the apk files themselves or have directories with the names of the apks being modified.
- You can always ask the developer to make sure
2. Once you have a full list of files being affected you can create the flashable zip:
- in ZIPme, simply select "ADD -> File" for every file being affected
- If you have an ODEX ROM (.odex files are present) make sure you pick those too!
- save the flashable zip in an /sdcard location you can access from recovery
Part 4: Bootanimations
1. In ZIPme select the following:
- ADD FILE: /bin/bootnimation
- ADD FILE: /system/media/bootanimation.zip
- ADD FILE: /system/media/shutdownanimation.zip
2. Create the flashable zip in an /sdcard location you can access from recovery
Part 5: Other flashable files you should always keep handy
1. Always keep with you the following files for good measure: they don't take much space but can help recover from problems without having to fully restore from NANDROID backup
- original kernel from your ROM
- flashable bootloader (if you do not know what I am talking about then DON'T do it)
- flashable baseband (if you do not know what I am talking about then DON'T do it)
- flashable recovery image (TWRP, etc)
- "Xposed-Disabler-Recovery.zip": this is created by Xposed when you install it. It is located in the root folder of your sdcard. Copy it and put it somewhere safe.
- SuperSU: keep a flashable latest SuperSU with you to recover root
Any comments, suggestions, feedback are welcome

reserved

bloof said:
Any comments, suggestions, feedback are welcome
Click to expand...
Click to collapse
good work mate, i'm out of Thanks for today.

Just tried, nice and easy to use. Thank u

does it save paired bluetooth and wifi devices?

deleted

Can you use this to make a zip of boot.img and libs? Not finding how to do that. Thanks for any information.

matusala said:
does it save paired bluetooth and wifi devices?
Click to expand...
Click to collapse
Nope. It saves what you tell it to save.
The guide as it is only saves files, was meant for modding restore, not other stuff.
If you try mods a lot and don't like a certain theme or icon set you don't need to do a full nandroid backup and full restore because you changed 3 files in your mod.

countryfolk07 said:
Can you use this to make a zip of boot.img and libs? Not finding how to do that. Thanks for any information.
Click to expand...
Click to collapse
Not with what I wrote.
The app ZIPme can do a lot more than simple file recovery, but I am not an expert at flashable zips so can't comment on more advanced uses like buildprop etc.
I would certainly not write anything about boot images, way too likely to cause someone to screw up their phone....
Pick a flashable boot/libs zip file from somewhere and try to reproduce at your own risk.

[SOLVED]deodex zip D6603_Customized US_1288-7827_23.4.A.1.232_R6C

Wondering if anybody around here has some experience on using SVADeodexerForArt?
Trying to deodex D6603_Customized US_1288-7827_23.4.A.1.232_R6C and from what I gathered this is the tool to use, but been bouncing from thread to thread trying to understand how to make use of it and the more I read the more confusing it has become and I'm still at square one...
Anybody willing to shade to light and give direction on how to proceed?
Thanks

-Deodex-
Ok, so after a few days of reading I figured how to deodex my rom, took the long way since I didn't have the rom on my phone, just started from the xperifirm file...
Want to give a big THANKS @serajr for answering my questions and letting me use his zip to add my files for flashing!
This deodex zip is only for the D6603_Customized US_1288-7827_23.4.A.1.232_R6C firmware with root and recovery so be sure you're on that exact firmware before flashing!
-BACK UP before you even think of flashing this-
there is no debloat in the zip , you'll end up with a full stock D6603_Customized US_1288-7827_23.4.A.1.232_R6C deodexed, rooted and dualrecovery firmware
just flash the zip through recovery, wipe cache and dalvik and then boot...
get the deodex zip to flash here

-DM- said:
Ok, so after a few days of reading I figured how to deodex my rom, took the long way since I didn't have the rom on my phone, just started from the xperifirm file...
Want to give a big THANKS @serajr for answering my questions and letting me use his zip to add my files for flashing!
This deodex zip is only for the D6603_Customized US_1288-7827_23.4.A.1.232_R6C firmware with root and recovery so be sure you're on that exact firmware before flashing!
-BACK UP before you even think of flashing this-
there is no debloat in the zip , you'll end up with a full stock D6603_Customized US_1288-7827_23.4.A.1.232_R6C deodexed, rooted and dualrecovery firmware
just flash the zip through recovery, wipe cache and dalvik and then boot...
get the deodex zip to flash here
Click to expand...
Click to collapse
Hello there,
Can you please share how you did that? I am not able to find any way.
I wanna deodex D6653 firmware 23.4.A.1.232 Customized IN
I have .ftf, PRF Creator and SVA Deodexer
Thanks in advance

Mohitash said:
Hello there,
Can you please share how you did that? I am not able to find any way.
I wanna deodex D6653 firmware 23.4.A.1.232 Customized IN
I have .ftf, PRF Creator and SVA Deodexer
Thanks in advance
Click to expand...
Click to collapse
First make sure that you have the firmware you want to deodex, rooted with recovery and installed on your phone already so in your case D6653 firmware 23.4.A.1.232 Customized IN , if not then create a prerooted zip with that ftf file, SuperSu and latest dual recovery with PRFcreator then flash it and boot....Once that exact firmware is on your phone, you can follow those steps below to create a deodex zip.
Here is the process:
-download the zip that I provided in this thread (you'll need it later to swap my files with yours)
-open the ftf with 7-Zip to copy the system.sin file
-then use Flashtool Sin Editor to extract data to get System.ext4
-from there, use ext2explore (download it here) to open the system.ext4
-Once you opened system.ext4, locate those 3 folders (app, framework and priv-app) and build.prop
-create a folder called deodex on your C drive (so C:\deodex) and copy those 3 folders mentioned above and the build.prop file to it
-then move SemcGenericUxpRes folder from framework folder to app folder and take the 2 containing folders from vendor\app and move them to the app folder as well
- then run SVADeoderForArt.exe and selected the path to C:\deodex folder, check deodexing framework, app and private-app, let the tool run (it should tell you if it ran without errors when done)
-now you should have app, dex, framework, odex and priv-app folders (inside the SVADeodexerforart folder) after the tools finished the deodexing process (you can delete the dex and odex as they're not needed anymore)...now move SemcGenericUxpRes folder back to framework folder...also move back the 2 folders that you took from vendor\app, just put them anywhere on your desktop you're going to need them in a minute
-now when you open the deodex zip that you first downloaded, go into the system folder and you'll see 4 folders, app, framework, priv-app and vendor....delete the 3 folders app (but before, move the supersu folder from my app folder to your app folder, otherwise you'll end up without supersu) , framework and priv-app folders and move your 3 corresponding folders in there...now open vendor\app and delete the 2 folders and put yours instead
-your deodex zip should be good to flash now, put it on your sdcard...reboot to recovery, choose your zip to flash , then clear cache and dalvik cache and then boot....now you should have a full stock deodexed D6653 firmware 23.4.A.1.232 Customized IN (if you want to debloat, remove what you don't want from the app and private app folder in the zip before flashing, but you're on your own for that)
And as always make a backup before you start all this
Also, you should thank @serajr, as he's the one that wrote the script to clean and replace the system odexed folders, he nicely let me use it as a base to make my changes

-DM- said:
First make sure that you have the firmware you want to deodex rooted with recovery installed on your phone..............Also, you should thank @serajr, as he's the one that wrote the script to clean and replace the system odexed folders, he nicely let me use it as a base to make my changes
Click to expand...
Click to collapse
Thanks a lot for taking your time to write this and to give me good guide. This will help others too.
Ok i will follow the guide and now i am good to go. In case, any help needed, i will post here
And i think you saying to download your deodexed.zip only for meta inf and SuperSU, so i am not going to download that because i can do it myself so why to download ~800mb zip
And ya, Big thanks to @serajr. I dont know where to post exactly. So i am thanking you @serajr here.
Thanks and Regards
Mohitash

Mohitash said:
And i think you saying to download your deodexed.zip only for meta inf and SuperSU, so i am not going to download that because i can do it myself so why to download ~800mb zip
Thanks and Regards
Mohitash
Click to expand...
Click to collapse
yes, but looks like that you know what you're doing so you should be good to go

-DM- said:
yes, but looks like that you know what you're doing so you should be good to go
Click to expand...
Click to collapse
Ya, you got me right. May be you checked my profile or you can check now my history on XDA
I am just very very new to Sony and lollipop
Sent you pm.....
Regards
Mohitash

-DM- said:
First make sure that you have the firmware you want to deodex, rooted with recovery and installed on your phone already so in your case D6653 firmware 23.4.A.1.232 Customized IN , if not then create a prerooted zip with that ftf file, SuperSu and latest dual recovery with PRFcreator then flash it and boot....Once that exact firmware is on your phone, you can follow those steps below to create a deodex zip.
Here is the process:
-download the zip that I provided in this thread (you'll need it later to swap my files with yours)
-open the ftf with 7-Zip to copy the system.sin file
-then use Flashtool Sin Editor to extract data to get System.ext4
-from there, use ext2explore (download it here) to open the system.ext4
-Once you opened system.ext4, locate those 3 folders (app, framework and priv-app) and build.prop
-create a folder called deodex on your C drive (so C:\deodex) and copy those 3 folders mentioned above and the build.prop file to it
-then move SemcGenericUxpRes folder from framework folder to app folder and take the 2 containing folders from vendor\app and move them to the app folder as well
- then run SVADeoderForArt.exe and selected the path to C:\deodex folder, check deodexing framework, app and private-app, let the tool run (it should tell you if it ran without errors when done)
-now you should have app, dex, framework, odex and priv-app folders (inside the SVADeodexerforart folder) after the tools finished the deodexing process (you can delete the dex and odex as they're not needed anymore)...now move SemcGenericUxpRes folder back to framework folder...also move back the 2 folders that you took from vendor\app, just put them anywhere on your desktop you're going to need them in a minute
-now when you open the deodex zip that you first downloaded, go into the system folder and you'll see 4 folders, app, framework, priv-app and vendor....delete the 3 folders app (but before, move the supersu folder from my app folder to your app folder, otherwise you'll end up without supersu) , framework and priv-app folders and move your 3 corresponding folders in there...now open vendor\app and delete the 2 folders and put yours instead
-your deodex zip should be good to flash now, put it on your sdcard...reboot to recovery, choose your zip to flash , then clear cache and dalvik cache and then boot....now you should have a full stock deodexed D6653 firmware 23.4.A.1.232 Customized IN (if you want to debloat, remove what you don't want from the app and private app folder in the zip before flashing, but you're on your own for that)
And as always make a backup before you start all this
Also, you should thank @serajr, as he's the one that wrote the script to clean and replace the system odexed folders, he nicely let me use it as a base to make my changes
Click to expand...
Click to collapse
I understand the problem but somehow I do follow instructions whose results have been bootloop

đạt gao ô said:
I understand the problem but somehow I do follow instructions whose results have been bootloop
Click to expand...
Click to collapse
Sent you a pm

[Q] Pushing modified framework-res.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.

How to debloat a stock rom zip file before flashing?

I have a stock rom zip file ready to be flashed into micromax c2apls but I want to remove the preinstalled apps before flashing, is there some easy way to do it like deleting some folders or something afer extracting the zip and compressing the zip please let me know.

The Stock ROM Zip-file contains an installer script that controls the installation: simply removing APKs from the ZIP-file may lead into unpredictable results.