• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root ClockWorkMod

So; I once again do not know if this has anything to do with us not being able to boot our recoveries. But has anybody viewed the init.rc file from data/local/tmp? Does that have anything to do with what a phone does and installs upon boot? Cuz I onow that's where we push files using adb usually. And in that file it mentions a few things about install_recovery, and recovery_from_boot and somethimg about permissions and whatnot. I feel like an idiot as I do not know anything about this stuff so I'm just kinda looking at system logs for anything about rewriting and checking recoveries and am putting what I have seen.
Saw something that mentioned a service that runs or something?
"Service flash_recovery /system/etc/install-recovery.sh
oneshot" idk does that have to do with constantly rewriting our recovery?

I also found possibly a zip file from the ZV5 OTA update with some kind of .pem file that is apparently a certificates file required for the update to apply and work.

Sorry, I should have replied sooner but I forgot. A lot of the things you are suggesting would work, but the problem is that they come from directions given by the phone itself. And we need it to accept directions given by us :/
 
The ZipSigner2 app said it uses the Certificates in the System itself to sign the .zip's so it could work. Idunno, I figured maybe if they were signed like that and worked through our stock recovery that it might actually work. Maybe they added something to check whether it was signed or not? And if it isn't signed then it boots back up the original ones. Also; Would it be possible to find a such file or whatever it is causing the phone to keep rewriting back our stock one? Maybe if we found out how it does this, someone could patch it, or change it's permissions so it wont be able too? Sounds like we need to do some more tests on this system and do some comparisons here to other phones that are like this one. And did you see my edit? I had also found the app Android .img flasher and that one allows you to flash boot images. So we could possibly do something with that maybe..?

And idk if we found it yet or what this is but just an idea lol. I found a script in my System/etc/ called install-recovery.sh and I hit View on it. It apply's a patch and mentioned block 14 and block 9. Idunno if this points anything out important or not but just an idea. Still a noob on understanding stuff lol.

Both these files are involved in replacing the stock recovery on boot:
/system/etc/install-recovery.sh
/system/recovery-from-boot.p

Partition 9 (/dev/block/mmcblk0p9) is /boot and partition 14 (/dev/block/mmcblk0p14) is /recovery.

install-recovery.sh (post ZV5 update):
Code:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p14:2048:ce7707085f80931aaa82c907237c18d9b3e506f1; then
  log -t recovery "Installing new recovery image"
  applypatch EMMC:/dev/block/mmcblk0p9:4960256:b9d33598592306fe07cea6c432875fc2f1453862 EMMC:/dev/block/mmcblk0p14 6d75c268eec48a975a5e3d7738d80d1a0b6f75ea 5206016 b9d33598592306fe07cea6c432875fc2f1453862:/system/recovery-from-boot.p
else
  log -t recovery "Recovery image already installed"
fi


/system/etc/install-recovery.sh is called from init.rc upon boot and compares a SHA-1 checksum against the recovery partition's first 2048 blocks using /system/bin/applypatch.

applypatch usage:
Code:
%s <src-file> <tgt-file> <tgt-sha1> <tgt-size> [<src-sha1>:<patch> ...]
or %s -c <file> [<sha1> ...]
or %s -s <bytes>
or %s -l

Filenames may be in the form
  MTD:<partition>:<len_1>:<sha1_1>:<len_2>:<sha1_2>:...
to specify reading from or writing to an MTD partition.

If it doesn't match, it takes a copy of first 4960256 blocks of the boot partition to create a new stock recovery using /system/recovery-from-boot.p and writes it back to the recovery partition (mmcblk0p14).

That's what it looks like to me, I could be wrong.

Renaming those files should prevent the stock recovery restoration behavior, and this is a common measure when installing a custom recovery on a phone like this one.

This still doesn't help the problem we are experiencing when trying to boot a custom recovery, it only solves the issue of having the custom recovery overwritten by the stock recovery.
 
It's still worth a shot tho, I mean the boot looping could in the least be caused by the checksum failure and it wouldn't allow it to boot unless fixed. So I thought there would br a way to edit that checksum feature, or FORCE our custom recoveries to match the stock one. Renaming those 2 files as mentioned above would possibly prevent it from writing it back and replacing ours. Worth a try atleast, right? I remember somebody getting as far as the VM startup screen and then freezing. So it could be that it just fails to boot the rom after the checksum has failed, causing it to reboot as many times as it takes to apply the stock one again? I'd really be glad as for someone to try the uploaded recoveries in this thread again with combination of renaming those files, and using fastboot by zeroing out our recovery. We have an opportunity, sounds like we've been stuck for a while, and I'm just trying to find any indication of why this phone does this, and how to prevent it, now to find out why it causes the boot loops and how to stop it. Would it be possible to modify Jcases method of the .tot file and add the custom recovery into that? Or change the way it rewrites our recovery and make it rewrite our custom one too it? By like changing the checksum to match our custom recovery?
 
Both these files are involved in replacing the stock recovery on boot:
/system/etc/install-recovery.sh
/system/recovery-from-boot.p

Partition 9 (/dev/block/mmcblk0p9) is /boot and partition 14 (/dev/block/mmcblk0p14) is /recovery.

install-recovery.sh (post ZV5 update):
Code:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p14:2048:ce7707085f80931aaa82c907237c18d9b3e506f1; then
  log -t recovery "Installing new recovery image"
  applypatch EMMC:/dev/block/mmcblk0p9:4960256:b9d33598592306fe07cea6c432875fc2f1453862 EMMC:/dev/block/mmcblk0p14 6d75c268eec48a975a5e3d7738d80d1a0b6f75ea 5206016 b9d33598592306fe07cea6c432875fc2f1453862:/system/recovery-from-boot.p
else
  log -t recovery "Recovery image already installed"
fi


/system/etc/install-recovery.sh is called from init.rc upon boot and compares a SHA-1 checksum against the recovery partition's first 2048 blocks using /system/bin/applypatch.

applypatch usage:
Code:
%s <src-file> <tgt-file> <tgt-sha1> <tgt-size> [<src-sha1>:<patch> ...]
or %s -c <file> [<sha1> ...]
or %s -s <bytes>
or %s -l

Filenames may be in the form
  MTD:<partition>:<len_1>:<sha1_1>:<len_2>:<sha1_2>:...
to specify reading from or writing to an MTD partition.

If it doesn't match, it takes a copy of first 4960256 blocks of the boot partition to create a new stock recovery using /system/recovery-from-boot.p and writes it back to the recovery partition (mmcblk0p14).

That's what it looks like to me, I could be wrong.

Renaming those files should prevent the stock recovery restoration behavior, and this is a common measure when installing a custom recovery on a phone like this one.

This still doesn't help the problem we are experiencing when trying to boot a custom recovery, it only solves the issue of having the custom recovery overwritten by the stock recovery.

I looked at:

Code:
if ! applypatch -c EMMC:/dev/block/mmcblk0p14:2048:ce7707085f80931aaa82c907237c18d9b3e506f1; then
  log -t recovery "Installing new recovery image"
  applypatch EMMC:/dev/block/mmcblk0p9:4960256:b9d33598592306fe07cea6c432875fc2f1453862 EMMC:/dev/block/mmcblk0p14 6d75c268eec48a975a5e3d7738d80d1a0b6f75ea 5206016 b9d33598592306fe07cea6c432875fc2f1453862:/system/recovery-from-boot.p

Utkanos said it wasn't the problem that it is normal
 
12:32] <@utkanos> i've had a device config for months for it
[12:32] <@utkanos> if he needs it
[12:32] <@utkanos> the problem is there is some check going on at the bootloader level
[12:32] <@utkanos> could be as simple as sumchecking the file
 
I looked at:

Code:
if ! applypatch -c EMMC:/dev/block/mmcblk0p14:2048:ce7707085f80931aaa82c907237c18d9b3e506f1; then
  log -t recovery "Installing new recovery image"
  applypatch EMMC:/dev/block/mmcblk0p9:4960256:b9d33598592306fe07cea6c432875fc2f1453862 EMMC:/dev/block/mmcblk0p14 6d75c268eec48a975a5e3d7738d80d1a0b6f75ea 5206016 b9d33598592306fe07cea6c432875fc2f1453862:/system/recovery-from-boot.p

Utkanos said it wasn't the problem that it is normal

I agree, and I don't think it was even present prior to ZV5. I was just trying to give an explanation so that HaTrEd360 understands that this isn't the cause of our inability to boot CWM.
 
I've been looking at the recovery IMGs in a hex editor too, comparing the first 2048 blocks, etc. One thing I was going to try was simply editing one of our CWM builds, so that the initial blocks match up. Maybe that's crazy.

I'm curious though, which sequence looks like a SHA-1 hash to you?

AFAIK, a SHA-1 hash should be 40 characters long, with only 0-9 & a-f or A-F as possible characters.


exactly 40 characters :
0000:0240 | 8E 37 39 97 37 91 66 3F FF 3E 91 B7 4D 23 C0 37 | .79.7.f?
 
just curious,where is the donated optimus elite being purchased from? on vm the total is only 158.99. other sites have it cheaper. so where does the $165 come in?

When the donation page was initially set up, the going rate was $149.99. Add in wepay's fees plus taxes and you have around $165. I wasn't about to do an exact calculation.

just some different prices for the elite. better options for purchase available for it versus $165

See above.

Then let him spend the extra money on a screen protector and case. Or dinner and a movie.

See above.

Not that I am 'expecting' a recovery from anyone, but I would like to just chime in and say that if the original agreement was we get money for an Elite in exchange for getting a working recovery, then I think it is safe to say that for $130 we should be golden. Anything after that amount should not be expected but is up to the users to decide if they want to continue to donate in appreciation of the development.

See above.

He was probably anticipating paying $149.99 for the phone and then tax. Maybe he threw in a few extra bucks for gas to go pick it up somewhere.

I'm sure if we let him know it on sale somewhere he'll pick it up before reaching $165

See above.


Now for my slightly aggravated response to all of this nonsense:

Lucky for all you kids, I just picked up the Elite for around $135 from a Boost/Virgin retailer (which was 25 miles away, so 50 miles round-trip or about $9 in gas). So $144.

The rest of the money (after the wepay donations got transferred) was out of my own pocket. If I didn't genuinely love doing what I do, I would not have spent a god damn dime on this phone.

I guess my point is this: stop whining. I am volunteering my time and resources to break open this phone and all I'm hearing is whining about the fact that the "target" of $165 doesn't exactly match the price that you can get at (choose a retailer/source). You all are extremely lucky that I'm even attempting to do this.

Oh yeah, one more thing: I have a full-time working job as a manager at a local IT services start-up. I don't have time to be on here every damn day.
 
Now for my slightly aggravated response to all of this nonsense:

Lucky for all you kids, I just picked up the Elite for around $135 from a Boost/Virgin retailer (which was 25 miles away, so 50 miles round-trip or about $9 in gas). So $144.

The rest of the money (after the wepay donations got transferred) was out of my own pocket. If I didn't genuinely love doing what I do, I would not have spent a god damn dime on this phone.

I guess my point is this: stop whining. I am volunteering my time and resources to break open this phone and all I'm hearing is whining about the fact that the "target" of $165 doesn't exactly match the price that you can get at (choose a retailer/source). You all are extremely lucky that I'm even attempting to do this.

Oh yeah, one more thing: I have a full-time working job as a manager at a local IT services start-up. I don't have time to be on here every damn day.

I want to apologize on behalf of everybody here and say thanks, we owe you huge. Bunch of unappreciative asshats on here. Just letting you know, we love you. In a creepy internet stalker kind of way.
 
Ok, this is going to turn into a big rage-fest real quick once everyone reads this stuff. I'm not even going to dignify any of this except for bobloadmire, dont appologize on my behalf for me again. While I am grateful for the support we are getting I dont have anything to be sorry for in regards to what I previously said. There's no need to start getting all ad hominem abusive on people here for their opinions.
 
you dont need to apologize on my behalf for anything. i never intended drew any disrespect. finding a cheaper and faster means to an end was my goal. and yeah im appreciative of his efforts. and never meant to insinuate otherwise. i figured if you can save some cash and still achieve the goal then that is a better outcome for everyone involved. as for donating,well simple fact was for me i couldnt. bills and numerous other factors prevented it for me. i already had the intitial purchase price of $154 plus three months of service tied up in my device,experiencing major issues with service (which are intermittently still occuring) made me rethink my options. but with all that crap said,im glad drew went the extra mile and bought the device at some expense to him also. and no,no reason to get into some sort of childish flame war. as far as im concerned drews picking up the slack on the purchase and making it happen is a good thing.
 
Back
Top Bottom