Continued from the other thread:
READ THIS FIRST:
If the phrase "I don't know if anyone has tried this..." appears in your post, stop. Read both threads. Reconsider your post. Your post should no longer have that phrase and wont waste space.
If the phrase "I don't know, but..." appears in your post, stop. Find out. The interwebz is amazingly useful for learning things. Reconsider your post. Your post should no long have that phrase and you will sound knowledgable and educated.
If you don't have any idea how an exploit is supposed to work, please don't suggest it. Look it up. If it sounds applicable to the G2, proceed to share.
- The eMMC supports setting a range of blocks temporarily or permanently read-only. That seems to be the case for the bootloader, /system and recovery.
(From the datasheet: Specific segments of the iNAND may be permanently, power-on or temporarily write protected. Segment size can be programmed via the EXT_CSD register.)
- The reason we can write to /system using "temproot" is that it is getting cached by linux. (Write-through, so the card is accepting and discarding writes but we are seeing the cached version only.) Flushing the cache removes all changes from system and upsets the kernel.
- Because no changes are making it to the actual flash, rebooting removes all updates. It is not being magically reflashed.
- It is not a rootkit. It is the OPPOSITE of a rootkit. Rooting it is much much more like a rootkit. Seriously.
- OTA isn't an answer. It isn't even helpful. The way it works: update.zip is downladed, and the key checked. saved to /cache, and an update script is written. it reboots to recovery. recovery checks the keys again, then runs the script to install it. there's no exploitable action there. It doesn't unlock the emmc, etc.
The eMMC security standard (pdf) and specifically, the parts applying to write protection
And the SanDisk part manual/datasheet
Some pieces of the current state are accessible from fastboot, or by mounting debugfs.
CSD and decode
Decode of EXT_CSD (via "fastboot oem get_ext_csd_emmc")
EXT_CSD (raw) while the phone is running
Some notes concerning the above
Useful flags in the security standard, specifically relating to temporarily and permanently write protecting regions of flash.
CMD29 is clear write protect. Hmmmm...
Or we might permanently writeprotect it. Or permanently -block- write protection.
Can a kernel module just reset the WP blocks? maybe (more info here) and the value should be "d00f00320f5903fffffffde0124040c8"
If we have to reset the controller, here is how
Examinations of the cache behavior, rmt_storage, etc.
If you have other updates, stick the links in the replies. Also, there is a wiki being set up.
Currently (10/9) we're looking at either resetting the part (and then reconfiguring it to get it out of boot mode - page 38 in the spec) or chewing up the bootloader.
Alternate approach by lbcoder - apply the leaked engineering bootloader as an update, convincing the system via misc that it has already passed signature validation:
Kinda unrelated, but here is HTC's response to their gpl violation. And finally, here is their possibly-accidental source code release.