FORUMS

PSA: You Can Optimize Your Note 4’s Recents Menu & RAM

The Note 4 never had the fastest Recents Menu, and despite its 3GB of RAM, … more

XDA Picks: Best Apps of the Week (July 25 – Aug 1)

Apps are at the front and center of any smartphone experience, and with over a … more

Voices Of XDA: Orbiting The Earth With Android

Editor’s note: This week’s feature has been written by forum … more

CloudPlayer: DIY HiFi Music Streaming Solution

In our Helpful Guide to Music Streaming Services, we mentioned several different services … more

[DISCUSSION][SOLVED] G2 Rooting #2

405 posts
Thanks Meter: 127
 
Thread Closed Subscribe to Thread Email Thread
Seriously, actual technical discussion this time.

Continued from the other thread:
READ THIS FIRST:
Quote:
Originally Posted by ace42588

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 by Disconn3ct; 14th October 2010 at 02:36 PM. Reason: highlight ota since there is one now
 
 
8th October 2010, 07:08 PM |#2  
Senior Member
Thanks Meter: 4
 
More
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 by mattseg; 8th October 2010 at 09:27 PM.
8th October 2010, 07:16 PM |#3  
Disconn3ct's Avatar
OP Senior Member
Flag Washington, DC
Thanks Meter: 127
 
Donate to Me
More
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 by Disconn3ct; 14th October 2010 at 02:37 PM.
8th October 2010, 07:32 PM |#4  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by mrozzeh

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 by vi5in; 8th October 2010 at 07:35 PM.
8th October 2010, 07:46 PM |#5  
Disconn3ct's Avatar
OP Senior Member
Flag Washington, DC
Thanks Meter: 127
 
Donate to Me
More
Quote:
Originally Posted by vi5in

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.)
8th October 2010, 10:24 PM |#6  
Junior Member
Thanks Meter: 2
 
More
The wiki link is broken.
8th October 2010, 10:33 PM |#7  
olearyp's Avatar
Senior Member
Thanks Meter: 151
 
More
Quote:
Originally Posted by Maqr

The wiki link is broken.

Wiki is now here.
9th October 2010, 03:23 AM |#8  
Junior Member
Thanks Meter: 0
 
More
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.
9th October 2010, 03:25 AM |#9  
Dalamak's Avatar
Senior Member
Flag Newark
Thanks Meter: 8
 
More
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 by Dalamak; 9th October 2010 at 04:02 AM.
9th October 2010, 04:15 AM |#10  
PsychoI3oy's Avatar
Senior Member
Flag Denverish
Thanks Meter: 0
 
More
jeagoss has already torn one apart and JTAGed it and has been poking around
9th October 2010, 08:27 AM |#11  
Senior Member
Hollywood, FL
Thanks Meter: 65
 
Donate to Me
More
Sorry to dig up old info from the other thread, but I couldn't help but notice a few things here:

Quote:
Originally Posted by Disconn3ct

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.

Quote:
Originally Posted by mrozzeh

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.

Read More
Thread Closed Subscribe to Thread

Tags
root, s-off, tmobile
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes