[DISCUSSION][SOLVED] G2 Rooting #2

Status
Not open for further replies.
Search This thread

Disconn3ct

Senior Member
Nov 5, 2008
439
157
Washington, DC
andblogs.net
Seriously, actual technical discussion this time.

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.

What we know now:
- 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.

Status Blocks:
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.
 
Last edited:

mattseg

Senior Member
Apr 9, 2009
129
5
Edit: What I posted is now in the above post. Just trying to help. I have faith in you guys to get root.
 
Last edited:

Disconn3ct

Senior Member
Nov 5, 2008
439
157
Washington, DC
andblogs.net
CHANGELOG:
- 10-08 18:32 wiki link fixed
- 10-08 22:07 added the cache examinations
- 10-09 13:45 added the disclaimer and the currently-trying
- 10-13 10:11 add CSD decode
- 10-14 09:37 add kernel source :)
 
Last edited:

vi5in

Member
Oct 6, 2010
29
0
rmt_storage was basically just proof to me that there was a write-back issue in place.

Part of the bootloader's preboot sequence is a call to mpu_emmc_protection(I believe that is what its called off the top of my head), followed by a call that sets up the physical nand protection that we're already used to. Setting superCID or S-OFF would disable those calls, which would kill the ramfs and allow physical access.

Ah, ok this makes sense to me. Basically you are changing the time of the attack to earlier on in the life-cycle. I agree that disabling write-protection while the phone is operational (after boot) could be problematic (because we seem to have cached writes).

So what you're suggesting is that we turn off protection earlier on (in the bootloader)?

Oh by the way, there's no point writing that value (that I mentioned earlier) to the CSD register since those bits are RO.
 
Last edited:

Disconn3ct

Senior Member
Nov 5, 2008
439
157
Washington, DC
andblogs.net
Ah, ok this makes sense to me. Basically you are changing the time of the attack to earlier on in the life-cycle. I agree that disabling write-protection while the phone is operational (after boot) could be problematic (because we seem to have cached writes).

So what you're suggesting is that we turn off protection earlier on (in the bootloader)?

It may be that it can't be turned off at all once it is turned on (eg if we can't get the chip back into a sane state after a reset), so it is possible that the only time we can turn it off (or rather, not turn it on) is bootloader.

The cached writes issue is easy to deal with - there is no reason to ever remount it read/write, so there are no cached writes pending. (There is a red herring from earlier - htc didn't set it up read/write, that is a side-effect of a typo in the 'root' script from the directions thread. The last line attempts to put it back to read-only, but fails because it uses android mount instead of busybox mount.)
 

Dreamer5

New member
Jul 12, 2010
1
0
Now im not a dev by any means.

let me see if i have this right:there is a read only file that contains the "primary" android system files and we cant modify that and it gets re applied everytime the phone is restarted.henchforth makeing the phone unrootable. now logically speaking the area had to at one point been writable, and has since been locked by a command, of which we cant find. and the mmc has a little todo with the whole process. so its safe to say that it might be one of the "key" components. just looking at the design of the phone and with what looks like a back cover sensor on the lower of the hinges on the back cover. Now the command to read the read only part of the phone is looking like what we have to get too to change where it is looking for the sys info to allow us perm root. i have a g2 and am excited on the amount of skill comming to gether to get this done.
 

Dalamak

Senior Member
Dec 2, 2008
301
8
Newark
Always willing to donate for a good cause, let me know if we need to get a pot going to buy someone a G2 like JesusFrekee.

Maybe HTC wants to force use inside the G2 so we void warranties. Jtag adapter, or a hardware related jumper/mod.

Someones gonna need a G2 bought by the community that they are not going to mind tearing apart
 
Last edited:

HamNCheese

Senior Member
Apr 15, 2010
247
63
Hollywood, FL
Sorry to dig up old info from the other thread, but I couldn't help but notice a few things here:

Where do you think the ramfs is coming from, as opposed to a write-through cache? It certainly behaves like a cache. (Not disagreeing that it gets set early. And if we can't get the bootloader, replacing recovery might be enough - it has to be r/w when starting recovery for OTAs to work, so the bootloader can behave 'as designed'.)

rmt_storage_client_txt (and the source)


this post shows changes disappearing after a cache flush (easily verifiable) and memory use going up as data is 'written'.
changes disappear "randomly" over time - ramdisk maintains data.

Where is the info that got you thinking rmt_storage creates a ramdisk? I saw something about that a couple days (and dozens of pages) back, but it didn't pan out. Did we miss something?

I think there is an interaction between rmt_storage and the actions of the radio/mmc interfering with the temp root. rmt_storage is certainly being used as a proxy to communicate with the storage in some way. Not as a ram-disk, but as an overlay to the visible partitions that are on lock-down. Your observations of free memory being clobbered by big writes to protected partitions could very well be linux caching the writes - because there's simply nothing better to do with that memory at that moment in time. However, as rmt_storage continues to communicate with other parts of the system, the trigger to flush cache as it sees fit may very well be sent through the RPC mechanism. It does not exactly explain the cache flush scenario, unless rmt_storage sends a message to clear all volatile blocks at that time. Any way you slice it, rmt_storage has a lot to do with the overlay, and probably nothing to do with the lockout.

rmt_storage was basically just proof to me that there was a write-back issue in place.

Part of the bootloader's preboot sequence is a call to mpu_emmc_protection(I believe that is what its called off the top of my head), followed by a call that sets up the physical nand protection that we're already used to. Setting superCID or S-OFF would disable those calls, which would kill the ramfs and allow physical access.

This makes sense to me. Coming from a N1, I did the locked bootloader root via SDcard trick a few months back. This explains why HTC has blocked adb from communicating with the device while in recovery mode. The same trick would presumably work if they left it open.

So....

It seems we have some evidence that the lock happens during the early stage of the boot sequence. From here, it is likely that rmt_storage plays a role in how the overlay/cache/whatever is reverting writes over a period of time. But it does not appear to have anything to do with the security lock-out.

With no recovery vector to exploit, this leaves us with few options. I would put my money on exploiting the pre-boot process (possibly with a race condition exploit similar to what we have seen with other recent HTC devices) and either preventing the partitions from being write protected *or* disabling the security outright. I have yet to see any evidence that we can disable the write lock from userspace *or* kernelspace - only speculation.

Re-read rmt_storage_client.txt - it seems likely that this is what we are observing with the rooted units degrading over time. rmt_storage sends RPC calls, stuff happens, filesystem overlay changes disappear. Once the kernel is up, this is *the only* interface to restricted parts of the storage system.
 

biosehnsucht

Member
May 7, 2009
26
0
Based on the rmt_storage_client.txt you linked, rmt_storage provides storage access to the radio / modem processor via RPC since it doesn't have any direct way to access emmc, rmt_storage doesn't sound like it's doing anything for the application (the one android runs on, we root, etc) processor.

It's not impossible that it might somehow be exploitable in some fashion but I glanced through the code and nothing jumped out at me as doing anything interesting.
 

VValdo

Senior Member
May 7, 2009
56
0
This explains why HTC has blocked adb from communicating with the device while in recovery mode.

But wait- don't you remember the part when T-Mobile said that the inability to save changes is a mere side effect of HTC's security measure intended only to prevent "key operating software from becoming corrupted and rendering the device inoperable"?

And their 90-120 day delays are totally "within the requirements of the open source community", no matter what the GPL might say.

I'll keep looking here.

W
 

HamNCheese

Senior Member
Apr 15, 2010
247
63
Hollywood, FL
Based on the rmt_storage_client.txt you linked, rmt_storage provides storage access to the radio / modem processor via RPC since it doesn't have any direct way to access emmc, rmt_storage doesn't sound like it's doing anything for the application (the one android runs on, we root, etc) processor.

It's not impossible that it might somehow be exploitable in some fashion but I glanced through the code and nothing jumped out at me as doing anything interesting.

My understanding is that the eMMC is abstracted since it is not yet directly supported by linux. Therefore, the radio would be the next logical choice for accessing it.

rmt_storage = remote storage. Keep in mind that we're dealing with a new SOC - it's perfectly reasonable to assume it has the ability to access eMMC on its own. RPC via rmt_storage is a likely suspect. It would also explain where the missing space went.
 

Disconn3ct

Senior Member
Nov 5, 2008
439
157
Washington, DC
andblogs.net
You have it backwards. Read the beginning of the rmt_storage doc. The radio can't access it so it makes rpc calls to linux so that linux can handle read/write for it. It is well documented. Seriously people. Stop guessing and do a little reading..
 

damnoregonian

Senior Member
Jun 28, 2007
109
13
Seattle
My understanding is that the eMMC is abstracted since it is not yet directly supported by linux. Therefore, the radio would be the next logical choice for accessing it.

rmt_storage = remote storage. Keep in mind that we're dealing with a new SOC - it's perfectly reasonable to assume it has the ability to access eMMC on its own. RPC via rmt_storage is a likely suspect. It would also explain where the missing space went.

the emmc is very directly supported by linux.
the radio does not have the ability to talk to the controller, that is why its storage must be proxied through one of its mailboxes to the kernel, and then to the userspace client.
i don't believe it's related to our root issues.
 

burpootus

Senior Member
Sep 10, 2010
72
8
I own a Droid X and I hope you guys have more success with the G2 than the X community has had unlocking our bootloader. In the long run though, the manufacturers will win the battle of locking devices. The answer to this problem is really to stop buying locked devices. Not much chance of that happening either. A pretty depressing picture for the time being and short term future.
 

ohhdavid

Senior Member
Sep 7, 2009
225
23
Philadelphia
Google Pixel 6
I own a Droid X and I hope you guys have more success with the G2 than the X community has had unlocking our bootloader. In the long run though, the manufacturers will win the battle of locking devices. The answer to this problem is really to stop buying locked devices. Not much chance of that happening either. A pretty depressing picture for the time being and short term future.

Its truly my belief that they do these things to prevent having to fix peoples rooted phones... android, with its open market and cross-hardware nature, are already a big risk for manufacturers but fortunately they have given it a shot (and we have rewarded that)

If you were truly passionate about having an unlocked phone, vote with your dollar and buy a dev phone like the new nexus one dev phone.

Otherwise.. pay less and work for root.

Sent from my T-Mobile G2 using XDA App
 

schwiz

Senior Member
Jul 3, 2009
204
29
Hah web2go is 'key operating software' ? I call BS
But wait- don't you remember the part when T-Mobile said that the inability to save changes is a mere side effect of HTC's security measure intended only to prevent "key operating software from becoming corrupted and rendering the device inoperable"?

And their 90-120 day delays are totally "within the requirements of the open source community", no matter what the GPL might say.

I'll keep looking here.

W



Sent from my T-Mobile G2 using XDA App
 
Status
Not open for further replies.