FORUMS

Nexus & Cookies: A More Focused Direction?

It is that time of the year again, and we are approaching the day where Android fans all over … more

LG G4 US Carrier Release Dates

The LG G4 was announced on April 29th with its Snapdragon 808 SoC, a welcomed change from its higher-end … more

Microsoft Reaches Pre-Install Agreement With New OEMs

As of late, Microsoft has been making a subtle but widespread play into the … more

Discover XDA: Discover Greater

We’ve all been there at some point in our XDA lives; we used to spend hours browsing over the … more
Thread Closed Subscribe to Thread Email Thread

[DISCUSSION][SOLVED] G2 Rooting #2

8th October 2010, 06:40 PM |#1  
Disconn3ct's Avatar
OP Senior Member
Flag Washington, DC
Thanks Meter: 127
 
Donate to Me
More
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
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