[DISCUSSION][SOLVED] ROOTING G2 Vision T-mobile

vabovyan · Oct 8, 2010

Try to mount as ext2

Can anybody try to mount system partition as ext2? And try t write to it.

mount -o rw,remount -t ext2 /dev/block/mmcblk0p25 /system

It is also possible that HTC modified ext3 module in kernel so all writes are redirected to cache. I am not sure that mounting it as ext2 will work though...

damnoregonian · Oct 8, 2010

vabovyan said:
Can anybody try to mount system partition as ext2? And try t write to it.

mount -o rw,remount -t ext2 /dev/block/mmcblk0p25 /system

It is also possible that HTC modified ext3 module in kernel so all writes are redirected to cache. I am not sure that mounting it as ext2 will work though...

i'm beginning to think that there's nothing shady going on with the caching, it's just that either the device or the mmc driver isn't returning an error on the write. since writethrough caching is enabled, we see that cache.

(dd or even a cat into the block device won't return an error either)

xile6 · Oct 8, 2010

sino8r said:
This bs is not gonna stop us. I don't understand the point in it. I mean how many devices do they have to fix because someone bricked it. Very few, I would imagine. I hate **** like this. They are placing any blame on HTC when it was clearly tmobile's idea.

It also makes me sick and thinking of tmobile laughing at us when we stuck with a bloated G1. Stupid thought, I know but it just makes me so angry.

HTC did have to replace alot of phones because of people bricking them so it makes sense for them to up there game and try to stop people some messing them up. But were there is a will there is a way and we will have root one day.

mark925 · Oct 8, 2010

xile6 said:
HTC did have to replace alot of phones because of people bricking them so it makes sense for them to up there game and try to stop people some messing them up. But were there is a will there is a way and we will have root one day.

If that is the case then the G2 won't be the last phone they do this with.....

Sent from my T-Mobile G2 using XDA App

sino8r · Oct 8, 2010

xile6 said:
HTC did have to replace alot of phones because of people bricking them so it makes sense for them to up there game and try to stop people some messing them up. But were there is a will there is a way and we will have root one day.

Yeah, I know... its just a bit disheartening, ya know? Got any more encouraging rhymes?

craisis · Oct 8, 2010

mmc command

Ok, after further reading in the specs documents (mentioned above). It appears that we're going to need to issue a "CMD29" with the address of write group we want to unlock.

CMD INDEX: CMD29
Type: ac
Argument: [31:0] data address
Resp: R1b
Abbreviation: CLR_WRITE_PROT
Command Description: If the card provides write protection features,
this command clears the write protection
bit of the addressed group.

See section 7.10.4 of the JEDEC 84-A441.

sino8r · Oct 8, 2010

mark925 said:
If that is the case then the G2 won't be the last phone they do this with.....

Sent from my T-Mobile G2 using XDA App

Yeah, we get that but it HAS TO BE us who will be first to deal and develop this new root method. Why couldn't have started with the stupid mytouch hd, lol?!

amwilliams9 · Oct 8, 2010

disregard prior post. I'm to new to add useful input.

damnoregonian · Oct 8, 2010

craisis said:
Ok, after further reading in the specs documents (mentioned above). It appears that we're going to need to issue a "CMD29" with the address of write group we want to unlock.

See section 7.10.4 of the JEDEC 84-A441.

see:

damnoregonian said:
well that's really depressing.
the spec i got didn't specify rw or ro.

well, if the BOOT_WP and USER_WP flags are what we want to attack, the kernel also provides mmc_send_ext_csd.

though i really don't think those do what you think they do.
whatever mechanism we're going after has to support groups, or areas because not all of the flash is write protected.

it may be we have to send the CLR_WRITE_PROT command to clear out the write protect groups after finding a way to list them....
but the kernel doesn't seem to have any exports for handling that.

i'm working on it.
there doesn't seem to be an easy interface for sending arbitrary commands, and there are no exports for that particular command.

grankin01 · Oct 8, 2010

TFJ4 said:
I guarantee you that "fastboot oem unlock" didn't result in many bricked devices (Can't flash SPLS/Splashes). HTC also didn't have to take away 2GB of space to do it.

Figure of speech.

I am all for root and would be sorely disappointed if they somehow (not likely) did find a way to honestly keep us from achieving it.

I spent quite a bit of money on this device (as did everyone who has it) and don't like the fact that someone else thought it would be a good idea to tell me how I could use it.

Will be a tester as soon as steps are posted for perm root.

vi5in · Oct 8, 2010

craisis said:
You guys should go read the spec at (URL below, see EDIT).

EDIT: Apparently I can't post links yet... : goo<dot>gl/iAWY
The WP_GROUP_SIZE and WP_GROUP_ENABLE is CSD are read only values.
I think we're more interested in are BOOT_WP and USER_WP in the EXT_CSD. See section 8.4 of the above documentation.

Also, we should make sure we don't make it permanently read only, the device supports write once bits in the register, so it's impossible to undo. Even with chip resets/etc.

Below is the spec on the relevant bits:

and

Bummer. Yeah, just looked at it. They are RO. Ugh. Looking more and more like I have to return this phone.

craisis · Oct 8, 2010

damnoregonian said:
ext_csd from while the phone is running (already booted)
i'm assuming it's different from what we got from fastboot.
someone wanna see if USER_WP and BOOT_WP are enabled in that?

Ok, if my quick perl code to parse that binary worked... Both USER_WP and BOOT_WP are all zeros (both are bytes), which would be good news for us. (None of those bits define if the protection is enabled or disabled, just what we as a user or "host" can do.)

thatruth132 · Oct 8, 2010

craisis said:
Ok, if my quick perl code to parse that binary worked... Both USER_WP and BOOT_WP are all zeros (both are bytes), which would be good news for us. (None of those bits define if the protection is enabled or disabled, just what we as a user or "host" can do.)

good work craisis

wrxtc714 · Oct 8, 2010

I feel you
I have 20 more days to find perm root otherwise this thing will go back
As much as I love this phone, without root i'm just not satisfied.
Glad I haven't sold my nexus yet.
What would have been so bad about making it like the nexus
I know there is a way to root it without unlocking the bootloader now but I had no problem unlocking my bootloader and voiding my warranty.
That was such a simple way to seperate the rooters and the rest of the crowd
it's that simple and was a great idea that they should have stuck with imo

vi5in · Oct 8, 2010

craisis said:
Ok, if my quick perl code to parse that binary worked... Both USER_WP and BOOT_WP are all zeros (both are bytes), which would be good news for us. (None of those bits define if the protection is enabled or disabled, just what we as a user or "host" can do.)

Right. It's good they are zero because it means that we can't set permanent protection.

craisis · Oct 8, 2010

Bit def revisited.

vi5in said:
Right. It's good they are zero because it means that we can't set permanent protection.

Actually it means we can:

Bit[4]: US_PERM_WP_DIS (R/W)
0x0: Permanent write protection can be applied to write protection groups.
0x1: Permanently disable the use of permanent write protection for write protection groups
within all the partitions in the user area from the point this bit is set forward. Setting this bit
does not impact areas that are already protected.

But it also means that when the command to disable writes is issued it is not permanently applied.

Bit[2]: US_PERM_WP_EN (R/W/E_P)
0x0: Permanent write protection is not applied when CMD28 is issued.
0x1: Apply permanent write protection to the protection group indicated by CMD28. This bit
cannot be set if US_PERM_WP_DIS is set.

But most importantly, it means we do have a bit that if we can find how to set it will disable all write protection:

Bit[3]: US_PWR_WP_DIS (R/W/C_P)
0x0: Power-on write protection can be applied to write protection groups.
0x1: Disable the use of power-on period write protection for write protection groups within all
the partitions in the user area from the point this bit is set until power is removed or a hardware
reset occurs. Setting this bit does not impact areas that are already protected.

damnoregonian · Oct 8, 2010

i'm not entirely sure what they mean by power-on write protection...

osho741 · Oct 8, 2010

I think it refers to wp enabled when the device powers on but what would be the point of that?
Unless its intended to be used with a specific partition that is used for powering the device up.

craisis · Oct 8, 2010

Power on write protection

The chip is enabled to make sections permanently read only, I think it's write protection that is not permanently enabled, but it enabled as soon as the device powers up.

It doesn't give anything other than context, but from the data sheet for the eMMC:

Specific segments of the iNAND may be permanently, power-on or temporarily write protected. Segment size can be programmed via the EXT_CSD register.

sinistersai4d4d · Oct 8, 2010

Sooooo..... what are the odds this thing will get rooted?

Sent from my T-Mobile G2 using XDA App

[DISCUSSION][SOLVED] ROOTING G2 Vision T-mobile

New member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Member

Senior Member

Senior Member

Member

Member

Senior Member

Senior Member

Member

Senior Member

Similar threads

Top Liked Posts