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

Status
Not open for further replies.
Search This thread

vi5in

Member
Oct 6, 2010
29
0
kernel module.
it'd be near impossible to write directly to anything regarding the card, however, modules global symbols (including functions) are in the kernel's symbol table, so you can call functions defined in the mmc module from within your module.

Cool. From what you said, it looks like the symbol is exported... so if we were able to send this value to the CSD... :).

I think it might be worth a short. Will see if I can do this over the weekend. It has been a LONG time since I wrote a kernel driver. I don't remember much at all... very rusty.
 

vi5in

Member
Oct 6, 2010
29
0
already tried echoing. csd sys node is ro.

Pretty much what I expected. Another thing to think about though. If we are able to disable this (and it turns out that THIS is what we want to disable), isn't there the other problem of the image being restored while the phone is running?

Presumably this might not be a problem if the write-protect area is turned off... but I wonder how that operation would be affected.
 

krayshunist

Senior Member
Oct 6, 2010
88
0
Pretty much what I expected. Another thing to think about though. If we are able to disable this (and it turns out that THIS is what we want to disable), isn't there the other problem of the image being restored while the phone is running?

Presumably this might not be a problem if the write-protect area is turned off... but I wonder how that operation would be affected.
Assuming you turn off the correct write protection, you should be able to flash a new recovery image and have it stick. Someone please correct me if I'm wrong.
 

slayerdork

New member
May 2, 2010
4
0
Has anyone tried this?

Code:
fastboot oem mmc_send_csd d00f00320f5903fffffffde0124040c8

Maybe...lol?
 
Last edited:

damnoregonian

Senior Member
Jun 28, 2007
109
13
Seattle
Pretty much what I expected. Another thing to think about though. If we are able to disable this (and it turns out that THIS is what we want to disable), isn't there the other problem of the image being restored while the phone is running?

Presumably this might not be a problem if the write-protect area is turned off... but I wonder how that operation would be affected.

that's the scary part.
the real problem, is what if you turn it off, blocks start actually being committed, and you end up with a totally effed filesystem because half the writes were already discarded...
i'd want to have a recovery image to flash or a working hboot flashable base image in case things went wrong.

though in reality, the phone has enough memory to store quite a few writes before it starts flushing, so you might be just fine when you finally do a real sync, and yaffs is very hard to break, it has very few (none maybe?) disk structures that aren't simply inodes.
 

slayerdork

New member
May 2, 2010
4
0
I did a little searching for mmc_send_csd, this is what I found, so, maybe it needs the correct parameters?

Code:
274 int mmc_send_csd(struct mmc_card *card, u32 *csd)
275 {
276         int ret, i;
277 
278         if (!mmc_host_is_spi(card->host))
279                 return mmc_send_cxd_native(card->host, card->rca << 16,
280                                 csd, MMC_SEND_CSD);
281 
282         ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd, 16);
283         if (ret)
284                 return ret;
285 
286         for (i = 0;i < 4;i++)
287                 csd[i] = be32_to_cpu(csd[i]);
288 
289         return 0;
290 }
 

vi5in

Member
Oct 6, 2010
29
0
Guys, it was my bad earlier.

The correct value is:

d00f00320f5903fffffffde0124040c8

I edited my post, but not before it was quoted.

Please do verify the value. Bits 36:32 should be 00000b and bit 31 should also be 0b.
 

damnoregonian

Senior Member
Jun 28, 2007
109
13
Seattle
i recommend everyone refrain from playing with the send_wp_info fastboot command. it has a bracket [CMD31?]....

i found a proposed addendum to the mmc standard defining CMD31 (currently reserved) as a way to permanently write protect a group.

CMD31 Ac [31:0] data address R1b SET_PERM_WRITE_PROT If the card has write protection features, this command sets the permanent write protection bit of the addressed group. The properties of the write protection are coded in the card specific data (WP_GRP_SIZE)

makes my stomach sink thinking of some of the stupid tests i did with it....
 

vi5in

Member
Oct 6, 2010
29
0
i recommend everyone refrain from playing with the send_wp_info fastboot command. it has a bracket [CMD31?]....

i found a proposed addendum to the mmc standard defining CMD31 (currently reserved) as a way to permanently write protect a group.

CMD31 Ac [31:0] data address R1b SET_PERM_WRITE_PROT If the card has write protection features, this command sets the permanent write protection bit of the addressed group. The properties of the write protection are coded in the card specific data (WP_GRP_SIZE)

makes my stomach sink thinking of some of the stupid tests i did with it....

I didn't get the gist of your comment though -- why is it recommended not to use it?

I don't think you could have done any real damage; looks like that node is RO like you said!
 

damnoregonian

Senior Member
Jun 28, 2007
109
13
Seattle
I didn't get the gist of your comment though -- why is it recommended not to use it?

I don't think you could have done any real damage; looks like that node is RO like you said!

no, not in linux.
emmc_set_wp_info (i think it was called that) is a fastboot command issued at the bootloader (that myself and a few other people were playing with)
 

craisis

Member
Dec 3, 2009
15
0
Boulder
Check JESD84-A441

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:


• BOOT_WP [173]
This byte allows the host to apply permanent or power-on write protection to the boot area. Also, the register
allows the master to disable either power-on or permanent write protection or both. The default state
of the bits is zero.
Bit[7]: Reserved
Bit[6]: B_PWR_WP_DIS (R/W/C_P)
0x0:Master is permitted to set B_PWR_WP_EN(bit 0)
0x1: Disable the use of B_PWR_WP_EN(bit 0). This bit must be zero if PWR_WP_EN is set.
Bit[5]: Reserved
Bit[4]: B_PERM_WP_DIS (R/W)
0x0: Master is permitted to set B_PERM_WP_EN(bit 2)
0x1: Permanently disable the use of B_PERM_WP_EN(bit 2). This bit must be zero if
B_PERM_WP_EN is set. This bit has no impact on the setting of CSD[13].
Bit[3]: Reserved
Bit[2]: B_PERM_WP_EN (R/W)
0x0: Boot region is not permanently write protected.
0x1: Boot region is permanently write protected. This bit must be zero if B_PERM_WP_DIS is
set. This bit only indicates if permanent protection has been set specifically for the boot
region. This bit may be zero if the whole card is permanently protected using CSD[13].
Bit[1]: Reserved
Bit[0]: B_PWR_WP_EN (R/W/C_P)
0x0 : Boot region is not power-on write protected.
0x1 : Enable Power-On Period write protection to the boot area. This bit must be zero if
B_PWR_WP_DIS (bit 6) is set
An attempt to set both the disable and enable bit for a given protection mode (permanent or power-on) in a
single switch command will have no impact.
Setting both B_PERM_WP_EN and B_PWR_WP_EN will result in the boot area being permanently protected.

and

• USER_WP [171]
This byte allows the host to apply permanent or power-on write protection to all the partitions in the user
area. Also, the register allows the host to disable the different protection modes that apply to the user area.
Bit[7]: PERM_PSWD_DIS (R/W)
0x0: Password protection features are enabled.
0x1: Password protection features (ERASE (Forcing erase), LOCK, UNLOCK, CLR_PWD,
SET_PWD) are disabled permanently.
Bit[6]: CD_PERM_WP_DIS (R/W)
0x0: Host is permitted to set PERM_WP_PROTECT (CSD[13])
0x1: Disable the use of PERM_WP_PROTECT (CSD[13]).
Bit[5]: Reserved
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.
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.
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.
Bit[1]: Reserved
Bit[0]: US_PWR_WP_EN (R/W/E_P)
0x0: Power-on write protection is not applied when CMD28 is issued.
0x1: Apply Power-On Period protection to the protection group indicated by CMD28. This bit
cannot be set if US_PWR_WP_DIS is set. This bit has not impact if US_PERM_WP_EN is
set.
This field is set to zero after power on or hardware reset.
Issuing CMD28 when both US_PERM_WP_EN and US_PWR_WP_EN, will result in the write protection
group being permanently protected.
 

damnoregonian

Senior Member
Jun 28, 2007
109
13
Seattle
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

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.
 

damnoregonian

Senior Member
Jun 28, 2007
109
13
Seattle
0000000000000001010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a0000000000000000021596960700080604010104080700110000434000000a0a0a0a0a0a000000000001020007000200050000000000000100000000000000000000000000000000011f040000000100030000ec01010000000000000000000000000000cb0010000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

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?
 

VValdo

Senior Member
May 7, 2009
56
0
http://press.t-mobile.com/articles/t-mobile-G2-code-level-modifications

The HTC software implementation on the G2 stores some components in read-only memory as a security measure to prevent key operating system software from becoming corrupted and rendering the device inoperable. There is a small subset of highly technical users who may want to modify and re-engineer their devices at the code level, known as “rooting,” but a side effect of HTC’s security measure is that these modifications are temporary and cannot be saved to permanent memory. As a result the original code is restored.
 

sino8r

Senior Member
Sep 7, 2006
3,549
735
Birmingham, Alabama
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.
 
Last edited:
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Has anyone considered the possibility of a system.img that's being unpacked on boot? The root filesystem on our phones is unpacked from boot.img every time the phone is booted which is why there's trouble with the SGS and people rooting it by placing the su binary in /sbin...

    Back on topic, the root filesystem can be changed at runtime, but reboot, and it all goes away. That's what sounds like is going on with the G2, but I don't have one to mess with.