DroidForums.net is the original Verizon Android Forum! Registered Users do not see these ads. Please Register - It's Free!
Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: FRG01B OTA enables a feature to undo custom recovery partitions

  1. Chief Droid Scientist
    MotoCache1's Avatar
    Member #
    83203
    Join Date
    Jun 2010
    Posts
    530
    Liked
    6 times
    Phone
    A855 / MB810
    #1

    FRG01B OTA enables a feature to undo custom recovery partitions

    Two days ago (8/20) over in the SBF to root/unroot topic I was helping a couple people troubleshoot a very strange problem they were having. The result of that troubleshooting led to a very interesting (and important) discovery. Perhaps this has already been discovered by someone else, but if it has, I've not seen it. This discovery may help resolve a lot of bizarre problems that are going on out there.

    Symptom:
    User successfully flashes a new image to the recovery partition (we'll say it is Clockwork for this example, but it could just as well be SPRecovery or any other recovery). They are able to boot into recovery and their custom recovery is shown as expected. When finished they boot the phone back to the OS. The next time they try to go into recovery, they find that the phone is now back to the stock recovery. Both users received FRG01B OTA and are unrooted. They attempted to install SPRecovery using my new "recovery only" SBF that does not touch the kernel (/boot) partition. This would also occur if they had rooted with EasyRoot and then used ROM Manager to flash Clockwork or SPRecovery on (tested on my phone after resolution was known). It was observed that their phones were reporting a boot loader version of 2C.7C whereas my phone (and the phone of everyone else who could not reproduce the problem) was 2C.6C.


    Outcome:
    It turns out that the FRG01B OTA package contains a new feature that I have decided to call "Flash Recovery Service" (hereinafter "FRS") after I dug through the OS and found the code that was responsible. FRS knows what the SHA1 hash (similar to an MD5 sum or hash) should be for the recovery partition. When you boot the OS, FRS checks the SHA1 hash of the recovery partition, and if it is not correct it "patches" it back to stock. Hence, you can change the recovery to whatever you want, but at the next boot of the OS it will change back.


    How to Fix It:
    Many aren't interested in the technical details of how it was isolated or how it works, and will stop after this section.

    To keep FRS from flashing your recovery partition back to stock on each boot of the OS, you need to rename or delete the /system/recovery-from-boot.p file so that FRS can't find it. There are many ways to do this. I will present two manual methods here which both require root.

    [I have built a method to fix this which does not require root and which will go ahead and root your phone in the process. I will be publishing that information soon and will update this post with a link when it is published.]

    Using Root Explorer:

    1. Navigate to /system
    2. Remount the partition r/w
    3. Delete the file or rename it recovery-from-boot.p.not (or whatever you want).
    4. Remount the partition r/o

    Using ADB:

    1. adb shell
    2. su
    3. mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
    4. cd /system
    5. mv recovery-from-boot.p recovery-from-boot.p.not (or "rm recovery-from-boot.p" if you want to delete it)
    6. mount -o remount,ro -t yaffs2 /dev/block/mtdblock4 /system


    [Remainder of this is not for folks who don't want to understand how any of this works.]

    Troubleshooting Highlights:
    Problem initially could not be duplicated on my Droid 1 even after flashing FRG01B on using the SBF. Flashing the FRG01B SBF onto my phone did not change the boot loader from 2C.6C to 2C.7C. I was ultimately able to get my phone to boot loader 2C.7C by flashing ESE81 on via SBF and then applying the FRG01B OTA (update.zip). Once I did that, I was able to reproduce the problem they were seeing. Since applying the FRG01B SBF did not exhibit the problem and applying the OTA update.zip did, my first effort at a crude fix was just to flash the SBF back on. This did get rid of the "feature" but did not change the boot loader back to 2C.6C. This told me that the boot loader had nothing to do with the issue. Then I sifted through the OTA update.zip file looking at what the code was doing and found the rest of the pieces of the puzzle.


    How Flash Recovery Service Works:
    Under FRG01B, in the init.rc file there appears something new that wasn't there in ESE81:

    Code:
    service flash_recovery /system/etc/install-recovery.sh
        oneshot
    Each time the OS boots it therefore runs /system/etc/install-recovery.sh.

    install-recovery.sh:
    Code:
    #!/system/bin/sh
    if ! applypatch -c MTD:recovery:2048:e341bb90b74f7eb644b7d72501be659ce229bb1b; then
      log -t recovery "Installing new recovery image"
      applypatch MTD:boot:2875392:d104d2ec84a2d0660e786c0fb8174bfacb4079d6 MTD:recovery 57de46b6424e717d68c9c3856b339271bc0e5980 3125248 d104d2ec84a2d0660e786c0fb8174bfacb4079d6:/system/recovery-from-boot.p
    else
      log -t recovery "Recovery image already installed"
    fi
    What this does it look at the first 2K block of the recovery partition image and take a SHA1 has of it. If the hash isn't the one shown then it calls "applypatch". Applypatch uses the first 2,875,392 bytes of the boot partition image (headers, kernel, and ramdisk) and the contents of /system/recovery-from-boot.p (a "diff" file) to mathematically reconstruct an image of the recovery partition. I went through this process myself and indeed ended up with a byte-perfect "stock" recovery image. Then the re-created stock recovery image is flashed to the recovery partition.

    By making the diff file (recovery-from-boot.p) unavailable the applypatch can't run and it has no choice but to leave the recovery partition "as is". It will still put an entry in the system log each time you boot that says "Installing new recovery image", but it won't actually be able to do it. If you want, you can also rename or delete the /system/etc/install-recovery.sh file and then it won't even try. In my instructions I don't have you do that just because if you ever want to re-enable it, it's easier if you've only renamed the .p file and just have to rename it back.

    Interestingly, even though the version of FRG01B in the SBF does not exhibit the FRS feature, it does contain it. The "service" commands are included in the init.rc in the FRG01B SBF, but interestingly the /system/recovery-from-boot.p and /system/etc/install-recovery.sh files are not. So, the service tries to run but doesn't because the files it needs aren't there.

    I have dissected the ramdisk out of the ESE81 kernel (where the init.rc file is located) and ESE81 did not have this "service".

    That was a fun one.

    [Edited to add: If you flash a custom ROM or kernel that will also kill the FRS. Since the applypatch command uses data from the boot image coupled with the recovery-from-boot.p file, if the boot image doesn't match the SHA1 hash the applypatch will abort as well. This may be why fewer people have noticed -- many of the people who root also put on a custom ROM or kernel shortly thereafter. In some further looking through prior OTA's, the recovery-from-boot.p and install-recovery.sh files were actually in the ESE81 OTA too. The "service" wasn't in the init.rc, but presumably they got kicked off a different way (and it isn't worth going back and figuring out what that way was at the moment).

    If you go back far enough there used to be a recovery.img in /system that got flashed in on each reboot. So it seems like this scheme has been around in some form for a long time. I'd bet that with each new OTA there is a round of people having strange problems putting on a custom recovery and having it revert, and they somehow get it fixed and everyone forgets about it. I did some searches and found several such posts here. I read them grinning because everyone is confounded as to how you could flash on a recovery and have it just disappear and go back to stock. Eventually the OP magically fixes it but they don't know how. Usually how they fixed it was by flashing in the recovery within ROM Manager and flashing in a ROM within ROM Manager at the same time. That replaces the boot image with one with a "wrong" SHA1 signature and voila the recovery partition stops reverting. Of course they don't know that was why. Anyway, these discoveries certainly make the presence of this feature in the 2.2 OTA a lot less insidious. It's still important that everyone understand it so they can avoid all the thrashing around trying to solve some odd problem of their recovery not "sticking". I'd still like to know why the boot loader needed to change from 2C.6C to 2C.7C. That probably worries me more than the FRS.]
    Last edited by MotoCache1; 08-22-2010 at 11:18 PM. Reason: New information added...
    Droid 1 - the "unbrickable" droid.
    FRG22D - stock, rooted, ChevyNo1 LV 1.1GHz kernel, SetCPU 2.0.2, Superuser 2.3.6.1

    Droid X, Droid 2, Droid 2 Global (Band Unlocked), Droid Pro Global (Band Unlocked)

    Recommended reading for newbies: How to ask questions the smart way
  2.  
     
     
     
  3. Super Moderator
    Corinacakes's Avatar
    Member #
    5472
    Join Date
    Nov 2009
    Location
    Maine
    Posts
    5,033
    Liked
    9 times
    Phone
    DrOiD
    DroidForums.net Theme Developer
    Premium Member
    #2
    Great discovery and writeup!!!!!!
  4. Banned
    gavron's Avatar
    Member #
    32757
    Join Date
    Jan 2010
    Posts
    555
    Phone
    VZW Moto Droid + N900 ;)
    #3
    Nicely done!!! Very well annotated!
    E
  5. Droid Ninja
    cupfulloflol's Avatar
    Member #
    12086
    Join Date
    Dec 2009
    Posts
    1,898
    Liked
    65 times
    Phone
    Galaxy Nexus
    #4
    Those sly and persistent devils.

    Good writeup.
  6. Droid Newbie
    k3mist's Avatar
    Member #
    107961
    Join Date
    Aug 2010
    Posts
    1
    Phone
    Enter Current Phone Model Here
    #5
    I decided to root my phone for the first time ever yesterday after the 2.2 update because of amazon and visual voice mail constantly running in the background even after you kill them over and over. Seriously retarded.

    I was in a bad situation with my droid1 because of this recovery issue just about an hour ago (playing with stuff already). I still could get into stock recovery but I don't have a windows PC anywhere in the house, so no RSDLite for me. Luckily, I found the full system update on this forum, put it on the sdcard and was able to run update.zip and from there, re-rooted, flashed, restored from backup. And obviously, thanks to the OP, I do not have to go through that again



    http://www.droidforums.net/forum/dro...tml#post747069
    Last edited by k3mist; 08-22-2010 at 07:22 PM.
  7. Master Droid
    beneharris's Avatar
    Member #
    20226
    Join Date
    Dec 2009
    Location
    portland
    Posts
    318
    Phone
    droid
    #6
    ok this one is sweet too. this should be considered for a sticky also.

    or at least in someone's sig so that its easy to find!
  8. Droid Ninja
    Se7enLC's Avatar
    Member #
    5148
    Join Date
    Nov 2009
    Posts
    1,263
    Liked
    6 times
    Phone
    Samsung Galaxy Nexus
    #7
    Isn't this old news? 2.0, 2.0.1 and 2.1 all did that, too - on boot, it would run install-recovery.sh and re-install the stock recovery image.
    Cool CM Tricks
    custom_backup_list.txt - make a list of files in /system that will survive a nightly install (ringtones, notifications, system apps, wallpapers, whatever)
    in Terminal Emulator, set this as your shell command: "/system/xbin/su -c /system/xbin/bash". You get all the features of bash, root access, and you can still use the initial command field for whatever you want (default is adding /data/local/bin to your path)
  9. Chief Droid Scientist
    MotoCache1's Avatar
    Member #
    83203
    Join Date
    Jun 2010
    Posts
    530
    Liked
    6 times
    Phone
    A855 / MB810
    #8
    Quote Originally Posted by Se7enLC View Post
    Isn't this old news? 2.0, 2.0.1 and 2.1 all did that, too - on boot, it would run install-recovery.sh and re-install the stock recovery image.
    Check the "Edited to Add" block toward the bottom. Apparently the concept has been implemented in the various builds, but not necessarily always functional. My stock ESE81 didn't exhibit the behavior, and the FRG01B SBF image has the service but not the script or the .p file in it.

    Even if it is old news, judging by posts here over the last year+ very few people were aware of it and it has caused (and continues to cause) quite a bit of confusion. At least now it's documented.
    Droid 1 - the "unbrickable" droid.
    FRG22D - stock, rooted, ChevyNo1 LV 1.1GHz kernel, SetCPU 2.0.2, Superuser 2.3.6.1

    Droid X, Droid 2, Droid 2 Global (Band Unlocked), Droid Pro Global (Band Unlocked)

    Recommended reading for newbies: How to ask questions the smart way
  10. Banned
    gavron's Avatar
    Member #
    32757
    Join Date
    Jan 2010
    Posts
    555
    Phone
    VZW Moto Droid + N900 ;)
    #9
    Quote Originally Posted by Se7enLC View Post
    Isn't this old news? 2.0, 2.0.1 and 2.1 all did that, too - on boot, it would run install-recovery.sh and re-install the stock recovery image.
    I don't know. Nobody in real life runs these OTA builds. Everybody I know runs a custom ROM and enjoys the features of free WiFi tether, etc.

    It's only on the net that some people apparently think they should stick with OTA. Their experience is what has led to this thread.

    E
  11. Rescue Squad
    Tallica's Avatar
    Member #
    48266
    Join Date
    Mar 2010
    Location
    Middleboro, MA
    Posts
    3,259
    Liked
    6 times
    Twitter
    Tallica21
    Phone
    GSIII-Rooted
    Premium Member
    #10
    Quote Originally Posted by gavron View Post
    Quote Originally Posted by Se7enLC View Post
    Isn't this old news? 2.0, 2.0.1 and 2.1 all did that, too - on boot, it would run install-recovery.sh and re-install the stock recovery image.
    I don't know. Nobody in real life runs these OTA builds. Everybody I know runs a custom ROM and enjoys the features of free WiFi tether, etc.

    It's only on the net that some people apparently think they should stick with OTA. Their experience is what has led to this thread.

    E
    You couldn't be more wrong. 99% of people with these phones run them stock and have no idea what root or a custom Rom is.

    Only about 1% of android users root their phones.
Page 1 of 3 123 LastLast

Links

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Similar Threads

  1. custom CW recovery is out
    By doug piston in forum Droid Incredible Hacks
    Replies: 26
    Last Post: 04-16-2011, 09:22 AM
  2. No "undo" feature on the Droid?
    By corvettemit in forum Android General Discussions
    Replies: 9
    Last Post: 12-31-2010, 12:20 PM
  3. Replies: 0
    Last Post: 06-15-2010, 04:32 PM
  4. Undo BB custom droid boot
    By ksmckay in forum Android Hacks and Help
    Replies: 2
    Last Post: 06-15-2010, 10:25 AM
  5. Question about feature of Recovery 0.15.0
    By Bear in NM in forum Android Hacks and Help
    Replies: 8
    Last Post: 12-28-2009, 07:04 PM

Search tags for this page

android service flash recovery
,

droid frs

,
droid x boot doesn't match mtd
,
flash recovery partition droid 2
,
huawei u8110 cant flash from sd
,
huawei u8110 stock recovery
,

recovery-from-boot.p

,
recovery-from-boot.p install-recovery.sh service flash recov
,
rename install-recovery.sh
,

service flash recovery /system/etc/install-recovery.sh

Click on a term to search our site for related topics.

Tags for this Thread

Find us on Google+