First:"STR" is a parameter transferred by updater-script when running switch.sh
Why do you say XT720 is detected as "STR"?Does the phone itself will detect it is which device when switch.sh is running?
I re-checked and you're right. I was remembering a different step where it runs "/system/persistent/orbootstrap/utils/install.%s.btsh" and the %s is detected. I think that is always install.mapphone_umts.rc. The STR is selected when you run the OpenRecovery install.sh, so it's not probed. Sorry for incorrect info.
Second:How does the OpenRecovery works? I've reviewed install_script.sh under directory orbootstrap. I don't understand why it can “hijack” boot procedure when reboot. Someone said it utilized a defect of XT720's recovery.
The hijack is done in /system/bin/sh
Basically if you look at /init.mapphone_umts.rc, very early in boot it runs a script called /init_prep_keypad.sh. init_prep_keypad.sh is a shell script that is run by /system/bin/sh (the first line of /init_prep_keypad.sh is #!/system/bin/sh, so /system/bin/sh is started to read the commands from /init_prep_keypad.sh). This is the first time during boot that anything from /system is executed (/system isn't signature checked). Skrilax_CZ's hijacked /system/bin/sh does the following things:
1. If the volume up key is down *or* /cache/.boot_to_or file is present it runs /system/persistent/orbootstrap/utils/install.mapphone_umts.btsh
2. (On my version) if volume down is pressed -- reboot to fastboot bootloader
3. Check if /system/bin/sh_hijack.sh exists, if so run that
4. Otherwise it just runs /init_prep_keypad.sh
/system/persistent/orbootstrap/utils/install.mapphone_umts.btsh defaults to "OpenRecovery Lite". If /sdcard/OpenRecovery.zip is available that is applied and it "switches" to full OpenRecovery.
/system/bin/sh_hijack.sh reconfigures the / filesystem (on XT720 and A853 usually just by copying the contents of /system/etc/rootfs) and eventually calls /system/bin/2nd-init which restarts /init. This is how we get around the signature check. The / filesystem comes from boot.img so we can't modify it. But it is read into RAM at boot and we can modify it in RAM once we have control.
The source for the hijacked sh is here:
http://gitorious.org/droid/openrecovery/blobs/master/src/bootable/open_recovery/btsh/main.c
There's a somewhat confusing description of what 2nd-init does by cvpcs here:
http://cvpcs.org/blog/2011-06-14/2nd-init._what_it_is_and_how_it_works
NOTE: which binary to hijack varies by phone--some hijack mot_boot_mode, some hijack logwrapper--it all depends on what the stock boot does. On Milestone A853, Milestone XT720 and Motoroi XT720, the sh-hijack is the correct one.
I hope that makes sense, but I may be too comfortable with it.
Third:The bootloader is not unlocked. Why can we flash custom roms such as 2.3.7 via OpenRecovery? Why bootloader not check signature?
/system is only check during the first boot after sbf flash of the system partition. The init_prep_keypad.sh script in particular can modify /system so signatures there can be quickly invalid under normal operation.
There's a lot of very good information about the bootloader security on
www.droid-developers.org
I also like this blog post by [mbm]
http://blog.opticaldelusion.org/2010/08/clearly-you-have-no-idea-what-efuse-is.html -- this is what cleared things up for me initially.
In the CDT partition table, partitions that are "type 1" are checked each boot, and "type 5" is only checked once immediately after sbf flash:
http://www.droid-developers.org/wiki/CDT_Milestone
I think that information about whether the type 5 partitions have been checked is stored in sp (CG41). Anyway, the take away message is boot.img is always checked, system.img is checked once and may be modified afterwards.