Root Eris gets official booloader unlock support (*yawn*)

[scotty85]

with the S-OFF bootloader installed and you will see them. I put up a thread on XDA a long time ago documenting them, and have a bootable version of Amon_RA that will allow you access to all of them**

so could be flash this version of amon,then change the mainversion without a bootable OS?

 

[erisuser1]

Hey scotty85,

What am I doing wrong?

# [color=green]fastboot flash zip Eris_151_rescue_PB00IMG.zip[/color] 
sending 'zip' (3979 KB)... OKAY
writing 'zip'... INFOsignature checking...
FAILED (remote: 12 signature verify fail)

I tried this:

(a) with the 1.51.0000 bootloader unlocked (and in RUU mode via "fastboot oem rebootRUU")
(b) with the 1.51.0000 bootloader RElocked (and in RUU mode via "fastboot oem rebootRUU")

same result both times.

I took the HTC Root ROM, unzipped it, deleted everything but

hboot_7501a_1.49.2000_100124.nb0
android-info.txt

edited android-info.txt so that MainVer: 2.41.605.6

and then dropped scary alien's trackball optional (v1.7.1) recovery into that folder as "recovery.img"

Then I zipped it up (Win 7 x64 Pro) as a compressed folder "Eris_151_rescue_PB00IMG.zip" and used that in the above fastboot sequences.

You mention the dependency on lock status - so I got the impression from your post that you were using the 1.51.0000 to ignore signatures - was I mistaken?

eu1


.

 

[erisuser1]

so could be flash this version of amon,then change the mainversion without a bootable OS?

Well, sure - but the misc partition is already available in plain-ole Amon_Ra and derivatives.

See for yourself - boot Amon_RA and then do a

adb shell cat /proc/mtd

It has to be available for Android in every kernel boot - cuz that's how the OS communicates with the bootloader - it writes boot commands into misc when shutting down, and the bootloader looks at it every time it powers up normally. (In most cases, button sequences during power-on can override those instructions... but we have seen Erii in the past that would always go into RUU mode for instance, probably because of crud left over in misc or even misc3)

 

[scotty85]

Hey scotty85,

What am I doing wrong?

# [color=green]fastboot flash zip Eris_151_rescue_PB00IMG.zip[/color] 
sending 'zip' (3979 KB)... OKAY
writing 'zip'... INFOsignature checking...
FAILED (remote: 12 signature verify fail)

I tried this:

(a) with the 1.51.0000 bootloader unlocked (and in RUU mode via "fastboot oem rebootRUU")
(b) with the 1.51.0000 bootloader RElocked (and in RUU mode via "fastboot oem rebootRUU")

same result both times.

I took the HTC Root ROM, unzipped it, deleted everything but

hboot_7501a_1.49.2000_100124.nb0
android-info.txt

edited android-info.txt so that MainVer: 2.41.605.6

and then dropped scary alien's trackball optional (v1.7.1) recovery into that folder as "recovery.img"

Then I zipped it up (Win 7 x64 Pro) as a compressed folder "Eris_151_rescue_PB00IMG.zip" and used that in the above fastboot sequences.

You mention the dependency on lock status - so I got the impression from your post that you were using the 1.51.0000 to ignore signatures - was I mistaken?

eu1


.

eu1,you are correct- when i got my "mini ruu" to flash,it was with 1.51.0000 unlocked.

you are prolly getting the failed error because you are trying to trick it into flashing an hboot and unlocked only ignores the signitures on system,boot and recovery

if you remove "hboot_7501a_1.49.2000_100124.nb0" then scarys recovery should flash just fine.

edit: now that i think about it some,i remember that rescue attempts on bricked erii,the root rom failed to install completely,leaving 1.49.2000 s-off behind. fastboot boot was an important part of the process,as we were able to fastboot flash amon,but not launch it conventionally.

were we not able to launch the recovery becasue the phones were ONLY going ito RUU mode?

do you think if we were able update a bricked 1.49.0000 s-on phone to 1.51,that we would be able to unlock,flash,then launch the recovery? im pretty confident we could unlock with the phone in ruu mode,but what would happen after that?

i think i may tweet at htcdev that 1.51 sucks i can fastboot boot a recovery on my rezound,inc,and every other phone ive messed with.

2nd edit: https://twitter.com/#!/scotty1223/status/171347522265153538

anyone with a twitter may want to follow them and tweet similar

 

[erisuser1]

you are prolly getting the failed error because you are trying to trick it into flashing an hboot and unlocked only ignores the signitures on system,boot and recovery

if you remove "hboot_7501a_1.49.2000_100124.nb0" then scarys recovery should flash just fine.

Doh! indeed you are correct:

# fastboot flash zip scary_trackball_optional_PB00IMG.zip 
sending 'zip' (3816 KB)... OKAY
writing 'zip'... INFOzip header checking...
INFOzip info parsing...
INFOchecking model ID...
INFOchecking custom ID...
INFOchecking main version...
INFOstart image[recovery] unzipping & flushing...
INFO[RUU]UZ,recovery,0
INFO[RUU]UZ,recovery,20
INFO[RUU]UZ,recovery,41
INFO[RUU]UZ,recovery,64
INFO[RUU]UZ,recovery,84
INFO[RUU]UZ,recovery,100
INFO[RUU]WP,recovery,0
INFO[RUU]WP,recovery,20
INFO[RUU]WP,recovery,40
INFO[RUU]WP,recovery,60
INFO[RUU]WP,recovery,80
INFO[RUU]WP,recovery,100
OKAY

FWIW, when you flash the 1.51.0000 bootloader as a HBOOT+PB00IMG.zip install, it updates the MainVer to 2.42.0.0 - so in the above I needed to set MainVer to that same value in the "android-info.txt" file to get it to work, otherwise you get the dreaded error

FAILED (remote: 43 main version check fail)

If you only flash the hboot...nb0 file using the S-OFF bootloader, MainVer doesn't change... but folks with soft-bricked phones will be most likely to perform either a PB00IMG.zip install, or an RUU install - which will kick the MainVer value up to 2.42.0.0.

edit: now that i think about it some,i remember that rescue attempts on bricked erii,the root rom failed to install completely,leaving 1.49.2000 s-off behind. fastboot boot was an important part of the process,as we were able to fastboot flash amon,but not launch it conventionally.

were we not able to launch the recovery becasue the phones were ONLY going ito RUU mode?

Yeah, possibly - I see what you are saying. I do remember reports of people having phones that could be recovery-flashed via the S-OFF bootloader, but not bootable into recovery using key-press sequences during power on. OTOH, not all soft-bricks suffer from that exact syndrome. Perhaps some, but not all can be saved. If we can get the recovery running, then we can alter MainVer (in the misc partition) ... and that means that we can get the S-OFF bootloader back on to the phone.

do you think if we were able update a bricked 1.49.0000 s-on phone to 1.51,that we would be able to unlock,flash,then launch the recovery? im pretty confident we could unlock with the phone in ruu mode,but what would happen after that?

I think we will just have to find out. Strangely, the unlock procedure performs a wipe of /data (and probably /cache, too) - without any appearances of having booted into the recovery to do this. If the bootloader is doing this operation (in the past factory wipes were always performed by the recovery boot), then I suppose having a bolluxed /data partition might cause trouble during the unlock sequence. To date though, we have most frequently seen reports of NAND corruption involving boot, system, and (rarely) misc.

Do you want me to solicit some "soft-bricked" phone owners on XDA?

eu1

 

[scotty85]

Do you want me to solicit some "soft-bricked" phone owners on XDA?

eu1

i think that is a most excellent idea!

also good catch on the hboot/ruu install changing the main version number... i forgot all about that!

 

[erisuser1]

2nd edit: https://twitter.com/#!/scotty1223/status/171347522265153538

anyone with a twitter may want to follow them and tweet similar

I see you got a response. Sort of curious that they ask about carrier; I would guess that the bootloader was carrier independent.

I don't have service on the unit I am using - it seems hard to imagine that you would need service to fully unlock a bootloader.

i think that is a most excellent idea!

Done. 72 views and no replies as of 20:30 UTC 2012-02-20. Traffic is pretty light these days on Eris forums - we'll see what happens.

eu1

 

[scary alien]

I see you got a response. Sort of curious that they ask about carrier; I would guess that the bootloader was carrier independent.

I don't have service on the unit I am using - it seems hard to imagine that you would need service to fully unlock a bootloader.

Done. 72 views and no replies as of 20:30 UTC 2012-02-20. Traffic is pretty light these days on Eris forums - we'll see what happens.

eu1

eu1 (bftb0 ),

There's still a couple (at least one, anyways) threads on XDA where there's a few folks that still have outstanding bricking issues:

Problem: does not boot and does not recovery - xda-developers

Perhaps a little thread-specific prompting (i.e., "see my new thread...", etc.) might yield more results/responses where folks have posted and therefore subscribed?

Just an idea...

-SA

 

[scotty85]

I see you got a response. Sort of curious that they ask about carrier; I would guess that the bootloader was carrier independent.

I don't have service on the unit I am using - it seems hard to imagine that you would need service to fully unlock a bootloader.

only reason i can see that it matters is that there is a 2nd RUU listed for MTS india,wich will prolly not flash on an s-on vzw phone. in the unlikely event that the inda exe may contain a support 1.51 hboot that works correctly,i just attempted to download it. however,it appears that no matter wich link you click,you downloaad the DesireC_VERIZON_WWE hboot

my eris isnt active either,but i kept that part under my hat for now as well as how i got the hboot on my phone

maybe they will release one that has working fasboot boot/flash that will still be of some use. not heard anything back yet

Done. 72 views and no replies as of 20:30 UTC 2012-02-20. Traffic is pretty light these days on Eris forums - we'll see what happens.

eu1

awsome! hopefully we get some bites. i went to scarys thread to leave a message and saw doogald had done it. ive subsribed to them,so ill be watching

 

[metlcat]

You guys seem to have a plan set, but if you need another Eris to try something out, let me know and I'll see what I can do. I haven't booted the little guy since I got my gnex, but as long as I get some detailed instructions I can do whatever you need.

Keep fighting the good fight, gentlemen.

 

[scotty85]

ok,new question

came across this today in the rezound section of xda.
[DEV] Flashing Boot Images From Recovery. Rezound can take S-OFF like roms now! - xda-developers

in a nutshell,they are renaming a recovery image "boot" and flashing it to the boot partition via hboot(fastboot works too) in order to boot recovery instead of the operating system. with the resound,the significance is that roms can be flashed conventionally,instead of having to flash the boot image seperately.

significance for the eris... since fastboot flash and fastboot boot are not working(tho i still have hopes maybe HTC will fix it),is it possible we could do the same? simply rename trackball optional recovery to boot.img,pack it up with appropriate android info document and flash as PB00IMG or RUU,fastboot reboot and have amon running?

at this point,the bad blocks can be fixed,the main version edited,or whatever needs to happen,and bam! another eris back to life

im wanting to put 1.51 back on my lil buddy and give it a shot,unless you think i shouldnt... since the rezound is an emmc device,idk how it might be different for the eris

what are your thots?

 

[scary alien]

Way, way cool, Scotty!

Its funny how some folks think of these things (flashing a recovery image to the boot partition). Its brilliant in its simplicity.

So, that caveat here is that one (i.e., a soft-bricked) device would have to flash 1.51 before booting a newly-repackaged (recovery as boot.img) PB00IMG.zip file, right? (didn't you and I play around with repacking these type of files before? I think it was for installing Amon_RA, right?).

Cool .

 

[scotty85]

yes sir,you got it!

1.49 s-on soft bricked eris should be able to flash 1.51 hboot. install amon as boot image. its brilliant indeed... i downloaded that guys .boot files and compared md5s to my amon image-same! fastboot flash boot recovery-ra-vigor-3.14-gnm.img on my rezound and voila! fastoot reboot or adb reboot just kept booting recovery

whoda thunk?!

i know we can install amon to the recovery partition with htc dev,but then the prollem is getting it running in some stuations. as long as the bad blocks are not in the boot partion,this seems like a way to get amon running onthe devices in absence of fastboot boot

 

[erisuser1]

what are your thots?

scotty85,

It would work - in principle. Because neither the "boot" nor the "recovery" partition are ever mounted or even read by the kernel once it gets itself bootstrapped and the ramdisk initialized, you could conceivably swap the roles of the two partitions. (You can think of them as being 100% "read-only" partitions, excepting for flashing operations. This means that the running kernel can over-write into the very partition that it booted from, but not change one iota about the way the currently running kernel behaves)

In doing that, if you powered up the phone normally, it would go into recovery mode, and if you powered it up to one of the bootloader modes (fastboot or hboot mode) and thence to the "recovery" option, the phone would boot up "normally".

After all, there is no functional difference between "boot" and "recovery partitions - they are raw partitions containing a (packed) kernel and compressed ramdisk. In fact, if you unpack a HTC boot and recovery boot from the the same HTC release, you will see that the kernels are identical.

But notice that I said "in principle". The sticky widget is that the size of the boot and recovery partitions are not equal for the Eris In fact, the default recovery partition is twice the size of the boot partition. Amon_Ra's recovery is about 3.9 MB, but the boot partition is only 2.5 MB - simply put, it won't fit.

You certainly might be able to hack together a recovery that is small enough to fit; I'm not sure as I haven't tried. You definitely could flip the value of the secure flag in the standard boot image without changing the resulting image size.

eu1

P.S. If it worked, I see it would be of value in a couple of corner cases:

- the boot partition is horribly defective. Replacing the recovery partition with a standard "boot" image would allow you to use an Eris in a normal way. You'd just have to start your phone up in an unusual fashion (as if you intended to start it in recovery). Of course, if you wanted to flash a new ROM, you would need to manually flash the "recovery" partition with your boot.img file from that ROM. And re-install your "recovery" in the boot partition, since the ROM install would stomp on it.

Note that there were a few reports of Erii that had a couple of bad blocks in their "boot" partition, and as a result could not flash certain roms that use something like 95% of the total space in "boot". This trick would overcome that roadblock as the recovery partition is 2x the size of the boot partition.

- the case you mentioned previously - where you can write to the recovery partition, but can't seem to get the recovery to boot with key sequences; in that case fastboot boot would get you into a recovery for repair operations.

.

 

[scary alien]

So, is S-ON / S-OFF simply reflecting the value of ro.secure?

If so, its trivial to repack a boot.img with that.

I'd be happy to do that and if you want, streamline a version of Amon_RA sans images and some of the larger files (you're probably only sacrificing rarely-used functionality). Not sure how big (or little) it will be until I finish it, though.

Say the word and I'll build a new boot.img and recovery.img (Amon_RA style, of course).

 

[erisuser1]

So, is S-ON / S-OFF simply reflecting the value of ro.secure?

Well, no. There is no reason to believe that the bootloader unpacks boot images to figure out whether it should enforce either a S-ON or S-OFF policy.

Embarrassingly, I don't actually know what ro.secure enforces I thought it controlled whether or not shells under ADB are root shells or not, but please don't quote me on that - wanna give it a try and find out?

(This might be one of those cases where a little googling will find the answer faster.)

If that works, about the minimum thing you would need to add ( to /sbin in the boot image ) would be Amon_RA's "flash_image" binary - fortunately, it is statically linked. Maybe a busybox and some symlinks too - the HTC "toolbox" is pretty weak sauce.

eu1

 

[scary alien]

Well, no. There is no reason to believe that the bootloader unpacks boot images to figure out whether it should enforce either a S-ON or S-OFF policy.

Embarrassingly, I don't actually know what ro.secure enforces I thought it controlled whether or not shells under ADB are root shells or not, but please don't quote me on that - wanna give it a try and find out?

(This might be one of those cases where a little googling will find the answer faster.)

If that works, about the minimum thing you would need to add ( to /sbin in the boot image ) would be Amon_RA's "flash_image" binary - fortunately, it is statically linked. Maybe a busybox and some symlinks too - the HTC "toolbox" is pretty weak sauce.

eu1

LOL, there's usually precious little (easily obtainable) information posted about these things like ro.secure, but I believe you are exactly right (of course -- again ).

I've repacked my own boot.img for the Galaxy Nexus to enable that property (even threw-in turning-on USB debugging to boot (pun fully intended ) for a user that had a hung device--turns out the adb daemon is started-up too late in the boot sequence to help him escape the problem he was having).

Say the word Scotty and co. and I'll build you some files if you want to test.

Cheers!

 

[scotty85]

that would be pretty sweet,mister scary. it would not be a recovery that folks with working phones would want to use,it could be a sort of "rescue recovery" so i dont think it would even need to back up or restore... just flash and wipe? and allow adb commands.

not sure why i get such a kick out of bringin these lil guys back from the dead,but i do

and of course thank you eu1 for all the interesting info youve provided

 

[scary alien]

that would be pretty sweet,mister scary. it would not be a recovery that folks with working phones would want to use,it could be a sort of "rescue recovery" so i dont think it would even need to back up or restore... just flash and wipe? and allow adb commands.

not sure why i get such a kick out of bringin these lil guys back from the dead,but i do

and of course thank you eu1 for all the interesting info youve provided

No problem, Scotty. I'll whip something up tonight for the slimmed-down recovery, but I'll let you pack it into something flashable (been since our last adventure together since I've done that and I'm sure you can do that in your sleep now ).

 

[scotty85]

No problem, Scotty. I'll whip something up tonight for the slimmed-down recovery, but I'll let you pack it into something flashable (been since our last adventure together since I've done that and I'm sure you can do that in your sleep now ).

sounds most excellent mister scary! lookin forward to messing with it a lil more.

no responses back from htc as to why it doesnt work like the others. still keeping fingers crossed

 

[scotty85]

update,i have just:
1)flashed the v3 leak 2.36.605.1 as an RUU in fastboot
2)rebooted bootloader,verified 1.49.0000 s-on
3)installed 1.51.0000 as an RUU
4)reboot bootloader
5)flashed my original unlock token,unlocked and rebooted.

so now im unlocked and on v3 leak,a situation that would prevent flashing the root rom to get the s-off hboot.

im ready to flash a tiny recovery to the boot partition and see what happens

but take your time,sir,no rush

 

[scary alien]

I've got my Linux laptop out and am starting to look at it...sorry, got buried with a few things after I got home...

BRB...

 

[scotty85]

I've got my Linux laptop out and am starting to look at it...sorry, got buried with a few things after I got home...

BRB...

no prollem,like i said,no hurry... tomoro is cool if you got other stuff goin on

 

[scary alien]

no prollem,like i said,no hurry... tomoro is cool if you got other stuff goin on

Scotty, eu1:

This is a toughie...the kernel itself is 2,092,176 bytes, so that leaves us with just under 500k for the ramdisk pieces...

I thought about just redacting a few components like busybox (735kb), parted (346kb), and tune2fs (303kb) and the ramdisk still ends-up being 108+ kb in size--still way too big.

I could remove other pieces from /sbin, but I'm not sure what else I could without crippling the recovery. Here's the remaining top files:

428664 Feb 23 22:04 ./sbin/e2fsck
342500 Feb 23 22:04 ./sbin/recovery
316528 Feb 23 22:04 ./sbin/mke2fs
113280 Feb 23 22:04 ./sbin/adbd
107412 Feb 23 22:04 ./init
80832 Feb 23 22:04 ./sbin/mkyaffs2image
76044 Feb 23 22:04 ./sbin/flash_image
76028 Feb 23 22:04 ./sbin/dump_image
71952 Feb 23 22:04 ./sbin/unyaffs
71944 Feb 23 22:04 ./sbin/reboot
63830 Feb 23 22:04 ./sbin/nandroid-mobile.sh
16047 Feb 23 22:04 ./sbin/sdparted
15373 Feb 23 22:04 ./sbin/bart
13801 Feb 23 22:04 ./res/images/icon_install_corrupt.png
12717 Feb 23 22:04 ./res/images/icon_firmware_install.png
12645 Feb 23 22:04 ./sbin/fix_permissions
11872 Feb 23 22:04 ./res/images/icon_error.png
11493 Feb 23 22:04 ./res/images/icon_installing.png

I'm open to suggestions for what to strip-out...(obviously init and recovery are off the table , which basically leaves e2fsck and mke2fs--those would get us there as long as they are used when mounting / unmounting things that you might do in a ping (i.e., flash a key .zip file).

Lemme know what you think... I probably won't get back to this tonight, though, but I'll have a lot of time this weekend to tweak and rebuild if needed.

Cheers!

edit: oh, almost forgot...if there's a smaller kernel that you guys know of, that would help, too!

 

[erisuser1]

Just a guess here, but

e2fsck and mke2fs

should only be used for dealing with extN partitions on SD cards - all other filesystems in NAND are yaffs2 (or raw partitions).

I wouldn't sweat the loss of those two - I suspect mke2fs is only used when partitioning the SD card with an ext, and e2fsck *might* be used by certain roms which auto-mount an ext partition; if the SD card is unpartitioned, I would presume it is not used during boot.

Considering the likelihood of this ever being used - and the fact that it is intended for rescue in any event... I wouldn't worry too much about it.

IIRC, Amon_Ra used the HTC kernel from the Leak_V2 HTC Rom. S'pose that earlier ROMs (Cupcake) might have smaller kernels. Given that application-level programs are separated from the kernel by an essentially fixed (syscall) API, it is fairly safe to use an older kernel... touch wood.

eu1