Stock recovery can flash root packages and custom recovery ZIPs but not custom ROMs


Question

This question might seem to be a duplicate of this question but it is different.



But I'd like to have a brief explanation on why we need a custom recovery to flash a ROM. My main points of confusion are:




  1. In stock recovery we have a option to "Install Update from SD card". Why can't we directly flash a ROM from there?


  2. If signature verification is the problem regarding the first point, then how can we root and flash custom recovery using update from SD card?




Why doesn't any signing or verification problem occur while flashing root package or custom recovery package?



Like any other custom ROM package they are also unsigned.



Kindly explain this to me. Thanks.


Answer

Now, you should be clear on 2 things:




  1. All flashable packages are signed. They can be stock OTA zips, root packages or even custom recovery or ROM zips.



So what is the difference between the "signed" and allegedly "unsigned" packages?



It's in the cryptographic keys used to sign the deployment builds, or the zips in this case.



The "signed" zips, e.g. a stock OTA zip, use a private key specific to the OEM for signing the build. This is a "release" key, and the only type of a key a stock recovery will recognize using its corresponding public key when asked to "Install Update from SD Card".



The "unsigned" zips, e.g. , root packages or custom ROMs, use the publicly known AOSP (Android Open Source Project) private keys for signing the deployment build. Even if the build hasn't been explicitly signed, the test-signing is implicit. Any released device with a stock recovery from the OEM does not have or recognise the public key corresponding to the "test" private key. Hence, it will refuse to install such test-signed or "unsigned" zips.



This is to maintain device integrity and security, at least according to the OEMs.



This is the official source: The Sign Builds for Release Page on the AOSP website.




  1. A custom recovery like CWM or TWRP either disables or provides an option disable (which is usually enabled by default) "ZIP File Signature Verification".
    This basically implies that it can flash any package, regardless of what keys, test or release, were used to sign the package. To the (stock) recovery, everything is an OTA zip.



So why can some stock recoveries flash a custom recovery zip or root package?



This is probably due to 2 reasons:




  1. The stock recovery has a security vulnerability or exploit, which the flash package uses on being initially loaded to bypass or circumvent the signature verification procedure.


  2. The OEMs private release keys are actually known to the developers of the flashable package, but not to the developers of the ROM. I have personally observed this with Mi and some low-end Samsung devices.




Also, there's another reason a custom recovery is necessary for flashing a custom ROM.



To install the ROM, you must do these steps before actually flashing the ROM zip:




  1. Wipe /data and /cache. On a stock recovery, this amounts to a factory data reset.


  2. Wipe /system. No stock recovery can do this, for obvious reasons (why would a recovery wipe the /system partition if it doesn't support getting it back from somewhere, such as a custom ROM zip?)


  3. Wipe dalvik-cache, usually done after flashing the zip. Again, no stock recovery can do this, but in this case there's no issue with the device getting bricked if the stock recovery did this.




If your stock recovery does not have either of the above 2 "features", you'll need a flashing software which will flash the recovery or ROM images to your phone from your PC. These flashing software use disk image files of the partition to be flashed, and care nothing about whether that that is signed or not. This involves the bootloader of the device, and bypasses the recovery altogether.



Custom recoveries are usually distributed as flashable disk images, not as flashable ZIPs.



A few examples of such software are fastboot(most Android devices), Odin, Heimdall(both for Samsung devices), Smartphone Flash Tool(for Mediatek devices)



Even the bootloader might perform security verifications on the flashed files on some cases, but insofar as much as fastboot is concerned, the bootloader had to have this verification disabled, that is, it needs to be "OEM unlocked"before anything can be flashed to the device. Anyway, the disk images do not contain any signature related metadata in the first place.


Topics


2D Engines   3D Engines   9-Patch   Action Bars   Activities   ADB   Advertisements   Analytics   Animations   ANR   AOP   API   APK   APT   Architecture   Audio   Autocomplete   Background Processing   Backward Compatibility   Badges   Bar Codes   Benchmarking   Bitmaps   Bluetooth   Blur Effects   Bread Crumbs   BRMS   Browser Extensions   Build Systems   Bundles   Buttons   Caching   Camera   Canvas   Cards   Carousels   Changelog   Checkboxes   Cloud Storages   Color Analysis   Color Pickers   Colors   Comet/Push   Compass Sensors   Conferences   Content Providers   Continuous Integration   Crash Reports   Credit Cards   Credits   CSV   Curl/Flip   Data Binding   Data Generators   Data Structures   Database   Database Browsers   Date &   Debugging   Decompilers   Deep Links   Dependency Injections   Design   Design Patterns   Dex   Dialogs   Distributed Computing   Distribution Platforms   Download Managers   Drawables   Emoji   Emulators   EPUB   Equalizers &   Event Buses   Exception Handling   Face Recognition   Feedback &   File System   File/Directory   Fingerprint   Floating Action   Fonts   Forms   Fragments   FRP   FSM   Functional Programming   Gamepads   Games   Geocaching   Gestures   GIF   Glow Pad   Gradle Plugins   Graphics   Grid Views   Highlighting   HTML   HTTP Mocking   Icons   IDE   IDE Plugins   Image Croppers   Image Loaders   Image Pickers   Image Processing   Image Views   Instrumentation   Intents   Job Schedulers   JSON   Keyboard   Kotlin   Layouts   Library Demos   List View   List Views   Localization   Location   Lock Patterns   Logcat   Logging   Mails   Maps   Markdown   Mathematics   Maven Plugins   MBaaS   Media   Menus   Messaging   MIME   Mobile Web   Native Image   Navigation   NDK   Networking   NFC   NoSQL   Number Pickers   OAuth   Object Mocking   OCR Engines   OpenGL   ORM   Other Pickers   Parallax List   Parcelables   Particle Systems   Password Inputs   PDF   Permissions   Physics Engines   Platforms   Plugin Frameworks   Preferences   Progress Indicators   ProGuard   Properties   Protocol Buffer   Pull To   Purchases   Push/Pull   QR Codes   Quick Return   Radio Buttons   Range Bars   Ratings   Recycler Views   Resources   REST   Ripple Effects   RSS   Screenshots   Scripting   Scroll Views   SDK   Search Inputs   Security   Sensors   Services   Showcase Views   Signatures   Sliding Panels   Snackbars   SOAP   Social Networks   Spannable   Spinners   Splash Screens   SSH   Static Analysis   Status Bars   Styling   SVG   System   Tags   Task Managers   TDD &   Template Engines   Testing   Testing Tools   Text Formatting   Text Views   Text Watchers   Text-to   Toasts   Toolkits For   Tools   Tooltips   Trainings   TV   Twitter   Updaters   USB   User Stories   Utils   Validation   Video   View Adapters   View Pagers   Views   Watch Face   Wearable Data   Wearables   Weather   Web Tools   Web Views   WebRTC   WebSockets   Wheel Widgets   Wi-Fi   Widgets   Windows   Wizards   XML   XMPP   YAML   ZIP Codes