yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] craisis:
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:
[G2 and Desire Z Android Development] sinistersai4d4d:
Sooooo..... what are the odds this thing will get rooted?
[G2 and Desire Z Android Development] uta8111:
Upon minor reflection, it would appear that temporary root will likely be useless in the long run unless permanent root is achieved. Without permanent root, there's presumably no way to prevent standard OTA upgrades, one of which is bound to close the temporary root access method at some stage. Correct?
[G2 and Desire Z Android Development] damnoregonian:
sooo... we have dumps of the running csd and ext_csd registers :)

tell me if we're working with power-on or temporary enabled after power-on wp mr. perl binary decoder man :)
[G2 and Desire Z Android Development] sino8r:
All that means to me is that stuff will have to be written and changed in recovery, right? Well, once we figured out how to enable writing, period.
[G2 and Desire Z Android Development] damnoregonian:
bingo.... well, short of remembering to wipe your /cache before ever powering down or rebooting your phone, lol.
[G2 and Desire Z Android Development] sino8r:
That's just silly...

Oppsy... nevermind. I see what you saying now. That won't be an issue though.
[G2 and Desire Z Android Development] craisis:
Will it root?

I have no doubt it my mind it will be rooted at some point. It might not be easy, but it is definitely doable.

Now I'm not willing to make any actual bets... but I won't return my G2 (when I get one... contract up for renewal in 6 more days...) even if it doesn't look like a root exploit will be right away... But we're still in the infancy of searching for a root exploit.
[G2 and Desire Z Android Development] craisis:
Decoding now

Will do. Standby...
[G2 and Desire Z Android Development] damnoregonian:
until we get the kernel source and make the damn thing remove wp at boot, ya, assuming we can remove wp *period*, changes to system will have to happen in recovery - or after an elaborate setup.

it's utterly unsafe to make changes to /system from within android, even after wp has been removed.

toggling off wp without a flushed cache could leave you with a fubar'd /system.

the only safe way to do it is to remount /system ro, flush cache (removing modifications), insmod our un-wp modules, re-root, remount rw, then make changes.
[G2 and Desire Z Android Development] sino8r:
Yeah... yeah... we used to be able to do such things. They were safe if you knew what you were doing and a back up or a rom to flash and fix it with. Those days are over, I gues..
[G2 and Desire Z Android Development] damnoregonian:
ya - that's why i really really wish we had a stock rom we could flash from hboot.

i'm a little scared to go forward even if i can turn off the wp groups.

filesystems really don't like it when what's on disk doesn't jive with what they think they have written, and i really don't feel like rendering my phone incapable of booting, stuck with a brick until someone releases an ota update on the net.
[G2 and Desire Z Android Development] sino8r:
I'm not too worried. I've bricked a phone or two and have sent them back no problem. Of course, they were truely bricked. Bad spl, etc. Won't turn on so they couldn't prove crap. Hehehehe! Tmobile don't check them for bricked unless its obvious... in that case it wasn't bricked anyways. They just check for water damage and physical damage, mainly.
[G2 and Desire Z Android Development] techdaring:
So, it's mean we can't rooted the T-Mobile G2 at all. I see the news from Engadget that tell it will automatic install the original ROM after you install a 3rd ROM into it.
[G2 and Desire Z Android Development] vi5in:
Strange. From the flowchart it seemed like if it was 0, it wouldn't let you set permanent write-protection.
[G2 and Desire Z Android Development] slayerdork:
No, it means root is only temporary for now. Work continues on obtaining permanent root. You currently can only obtain root, loading a custom ROM is not possible at this time.
[G2 and Desire Z Android Development] craisis:
RE: flowchart

Hmm, maybe I'm missing something, can you show or point me to the flow chart you're referring to?

Thanks
[G2 and Desire Z Android Development] damnoregonian:
# insmod /sdcard/wpthis.ko
# dmesg | grep wpthis
<4>[ 630.323364] wpthis - init
<4>[ 630.323516] sys_init_module: 'wpthis'->init suspiciously returned 32, it should follow 0/-E convention

getting closer.
[G2 and Desire Z Android Development] craisis:
Write Protect info

Ok, so I need more info before I can come back with more data. What I do know is that write protection mode is not power-on and is not permanent, leading me to believe it is temporary. However, it also appears that the bit in he CSD that enables write protection by groups (no the entire card) is disabled. It might just be because it's late and I'm tired, so I'll take another look in the morning. I've attached my notes below along with a request:

If anyone who has the phone now has a way to run the SEND_STATUS (CMD13) command, it would be very helpful.

My notes are below:

## CSD

size of erase unit = 512 (ERASE_GRP_SIZE * ERASE_GRP_MULTI)

ERASE_GRP_SIZE = 32 (0d31 + 1) (CSD 42:46; 11111)

ERASE_GRP_MULTI = 16 (0d15 + 1) (CSD 41:37; 01111)

WP_GRP_SIZE = 32 (0d31 + 1) erase groups can be write protected (CSD 36:32; 11111)

WP_GRP_ENABLE = 0d1 (CSD 31)

### Extended CSD

HC_ERASE_GRP_SIZE = 4096 KByte (512Kbyte * HC_ERASE_GRP_SIZE(8)) (EXT_CSD byte 224; 0000100)

HC_WC_GRP_SIZE = 32768 KByte (8 * 4096 (HC_WC_GRP_SIZE * HC_ERASE_GRP_SIZE)) (EXT_CSD byte 221; 0000100)

PARTITION_CONFIG = 00000000 # Device not boot enabled & No access to boot partition & No boot acknowledge sent

BOOT_CONFIG = 00000000 #

## PERM_BOOT_CONFIG_PROT is disabled

## PWR_BOOT_CONFIG_PROT is disabled

ERASE_GRP_DEF = 00000000

## Use old erase group size and write protect group size definition

BOOT_WP = 00000000

## Master is permitted to set B_PWR_WP_EN

## Master is permitted to set B_PERM_WP_EN

## Boot region is not permanently write protected

## Boot region is not power-on write protected

USER_WP = 00000000

## Password protection features are enabled

## Host is permitted to set PERM_WP_PROTECT

## Permanent write protection can be applied to write protection groups

## Power-on write protection can be applied to write protection groups

## Permanent write protection is not applied when CMD28 is issued

## Power-on write protection is not applied when CMD28 is issued

# Password is stored in 128 bit PWD and 8 bit PWD_LEN registers.

# TODO: Get status register contents

#	This is accomplished by CMD13 (SEND_STATUS)
[G2 and Desire Z Android Development] craisis:
Not sure if this will relate to us or not, but the card appears to have a way to password protect itself, one of the reasons I want the status register is to check if it's locked. If it is we need to find the password before we can even issue almost any other command.
[G2 and Desire Z Android Development] damnoregonian:
stop breaking my heart
[G2 and Desire Z Android Development] damnoregonian:
status register:

00000900

i am a little worried that wp groups aren't enabled.... that seems like the only way they could be protecting only part of the card, and the fastboot commands seem to reflect that there are groups.
[G2 and Desire Z Android Development] dynamikd:
Just got my G2 in the mail.

Sent from my OC844 Stock R00T3D Mytouch 3G Slide
[G2 and Desire Z Android Development] dyndragon:
What's worse is that the G2 has the SD card under the battery, so we can't get it in and out like we could with one of the N1 root methods (shaving the battery down).

grr...
[G2 and Desire Z Android Development] Gr8gorilla:
maybe they couldn't fix the software hole that method used so they fixed it by making it impossible to do it.........
[G2 and Desire Z Android Development] dyndragon:
well, technically all you'd need to do is mcguyver it and solder up some wires to the battery contacts...but that's hella annoying....though I'd do it if someone proved that it would work!
[G2 and Desire Z Android Development] hendusoone:
Does the battery need to be plugged in for the phone to power on? I know my G1 does... G2 was delivered to my home today and I'm still at work, so haven't been able to test myself. Failing that, maybe hack up some wires to connect the battery from a bit of a distance?
[G2 and Desire Z Android Development] Gr8gorilla:
I am most certain that one of the Big guys, either Cyanogen, Unrevoked, etc will have a root method for the phone shortly. I don't think it will require anyone soldering wires into the phone, lets not get overly extreme, it is only day two of people having the phone in hand......
[G2 and Desire Z Android Development] dyndragon:
Battery has to be in I'm pretty sure. I don't have my charger to try, but that's how the N1 was too. I think most HTC phones are like that.
[G2 and Desire Z Android Development] ericc191:
I'll donate $15.00 to whoever comes up with a root.
[G2 and Desire Z Android Development] dcman008:
No adb in bootloader

/home/not/Desktop/android-sdk-linux_86/tools# ./adb devices

* daemon not running. starting it now *

* daemon started successfully *

List of devices attached

I get this under recovery

root@not:/home/not/Desktop/android-sdk-linux_86/tools# ./adb devices

List of devices attached

HT09MR215322	offline
[G2 and Desire Z Android Development] crr127:
well atleast adb notices it has a device attached to it... hmmmm it is only a matter of time boys.
[G2 and Desire Z Android Development] notxel21:
I've had no luck getting ADB to recognize the G2. :confused:

Any help would be appreciated. Thanks! :cool:
[G2 and Desire Z Android Development] grankin01:
When you plug the g2 in go to device manager look for other devices and adb device (or something to that effect) double click on it and choose update driver. Choose browse for driver and then let me choose from a list. You should see an adb test interface driver. Choose that one and it should work(mine did).

Assuming your using a windows machine. :-)
[G2 and Desire Z Android Development] Jorsher:
If the suggestion by grankin91 doesn't work for you (I didn't try that method), then editing the *.inf file as outlined works:

http://xdaforums.com/showthread.php?t=795982
[G2 and Desire Z Android Development] notxel21:
This method worked like a charm!! :D

Thanks! :cool:
[G2 and Desire Z Android Development] grankin01:
Sorry, sent the reply from work on my phone couldn't remember what everything was named or called. Interesting note for anyone else having that problem that I probably should have pointed out (oops :-)) is that it worked for me and I am using win 7 pro 64 bit.
[G2 and Desire Z Android Development] ChiefzReloaded:
Hmmmm..... trollin.... No progress yet I see... I was not eligible for an upgrade and sure as hell dont have 500 bucks so im burnt... But I have ideas... I have someone willing to let me use them as a guinea pig via gtalk so I will see if i cant come up with something for you guys and help u out... CR
[G2 and Desire Z Android Development] notxel21:
Sounds interesting! What do you have in mind.

Gtalk: my username without the 21 @ gmail.com
[G2 and Desire Z Android Development] crr127:
I'll unwrap mine when i get home and load up adb... and start helping and trying stuff with you guys.
[G2 and Desire Z Android Development] zapote21:
Who you calling Guinea Pig? LOLOL ;-)
[G2 and Desire Z Android Development] Aphotic:
Originally Posted by Jorsher

If the suggestion by grankin91 doesn't work for you (I didn't try that method), then editing the *.inf file as outlined works:

http://xdaforums.com/showthread.php?t=795982

That method worked for me to. Thanks
[G2 and Desire Z Android Development] smjfosho:
"ChrisSoyars: Seriously, @HTC @TMobile your little G2 "omg no hackers" thing is a joke, we're very close. Just need kernel source, GPL ring a bell?"
[G2 and Desire Z Android Development] damnoregonian:
who the hell is chris soyars?
[G2 and Desire Z Android Development] craisis:
Status register

Awesome! Now if I could find an easy way to see what blocks are write protected without going through each address one by one...

Ok, well that bodes well for the password. Bit 8 is "READY_FOR_DATA", and bit 11 would put the card's current state as being "Tran", whatever that means I haven't yet found...

It makes the most sense. I hope I'm just misreading it or misunderstanding what it means.... More tomorrow, I need to be up in exactly 6 hours....

'Night all!
[G2 and Desire Z Android Development] smjfosho:
He is a part of team douche. The team who builds CM6.
[G2 and Desire Z Android Development] mark925:
Read that on Twitter a little bit ago...music to my ears. :D
[G2 and Desire Z Android Development] mghtyred:
BWAHAHAHA. Who the hell are you?

Seriously though. in regards to the respected Mr. Soyars statement, I really don't think T-Mobile is to blame here. My guess is this is an HTC measure entirely, and it won't be carrier specific.

Expect HTC to pull this on ALL future Android phones, regardless of carrier. Heck, they did it on the Desire Z.

Like I told Chris though, once it's tackled on the G2, it should be cake and pie to do the same on future HTC devices. ;)
[G2 and Desire Z Android Development] damnoregonian:
watch the tone. i'm looking for your contributions and struggling to find any.

or is that really the team name? i hope you didn't just call me a douche.
[G2 and Desire Z Android Development] damnoregonian:
who am i?

i'm the guy with code running in the kernel sending commands to the mmc card and getting dumps from it.

who are you?
[G2 and Desire Z Android Development] mrkite38:
Lol - that's actually their name.
[G2 and Desire Z Android Development] thatruth132:
i dont think he was calling you that....lmao :D
[G2 and Desire Z Android Development] damnoregonian:
good to know. i'm not privy to the android scene.
[G2 and Desire Z Android Development] smjfosho:
its there team name, but youve been a member since 2007 and dont know who he is, so yes. team douche is there team name, and you are one for not knowing of the almighty chris soyars. good day sir.
[G2 and Desire Z Android Development] Bzerk1:
team douche is the actual name of there team.
[G2 and Desire Z Android Development] VValdo:
Yeah look for hashtag #teamdouche on twitter or the conveniently homonymous #teamdouche channel on freenode irc.

Although I believe that's invite-only. Chris is a top lieutenant in the Cyanogenmod army...

W
[G2 and Desire Z Android Development] vi5in:
It's on page 218 of the PDF. I might have read it wrong. It's past 11 here and I need to get up early to go to work. Also I have a project due tomorrow.

Thanks for all the work you're doing. Also, what is wpthis? Is it a kernel module that you wrote? I'd like to look at the source if possible!

I'll take a look at that data you posted to see what it all means. The thing not being password protected is a good sign. I hope we're not going down the wrong path! Good luck and thank for working on it!
[G2 and Desire Z Android Development] tawnchan:
okay.. their team's name is *douche*.. get it.. got it... good with it. Let's not start online android gang battles over names now or who's who? I thought this was a think tank on rooting this damn phone! Noob here trying to learn something to teach you something in the future SENIOR MEMBERS who moderate.
[G2 and Desire Z Android Development] damnoregonian:
lol, i clearly need to develop elsewhere.

cheers 'sir'.
[G2 and Desire Z Android Development] Captainkrtek:
Stop the flaming and get back on topic
[G2 and Desire Z Android Development] vi5in:
Did a google search and it seems that "TRAN" state means the card has not left the busy state. Does that mean the card is busy?
[G2 and Desire Z Android Development] mghtyred:
Please no.

Look, I'm sure nobody meant any offense, myself included. My "who the hell are you" was a direct response to you asking who the hell Chris was.

It's kind of like walking into the Fryers club and asking who the hell Mel Brooks is.

It's very easy for sentiment, and meaning to be misconstrued in a non verbal medium like a message board. I'm a pretty jovial cat, and the sarcasm is VERY strong with me.

In answer to your question as to who the hell am I, I'm a "semi-retired" rom developer. Yes, "Team Douche" is their actual name. Yes, there are a LOT of SMARTASSES on XDA and well, the internet in general.

We all appreciate your contribution to the work being done here, and nobody wants to see you go. I hope you can get past this, and continue to be an active part of this community. :)
[G2 and Desire Z Android Development] thatruth132:
you have to be bigger than that , help me out at least and keep posting
[G2 and Desire Z Android Development] Captainkrtek:
Let's just stay on topic, enough with this whole misunderstanding and let's root the G2
[G2 and Desire Z Android Development] mark925:
Agreed!
[G2 and Desire Z Android Development] jfwfreo:
Some more thoughts:

Fact: We have a ROM signed by HTC that will load onto the phone and properly flash without errors (I think its either the stock G2 or the DeeZire Z ROM or both that work). This ROM (or ROMs) change /system.

Fact: There are 4 possible answers to how things could be working:

1.The flash chip has config registers set so that when it powers up, the relavent areas are read-only but the flash process for the aformentioned signed ROMs sends some commands to unlock the flash

2.The flash chip starts out with /system being writable but the bootloader sets it to read-only with the flash process setting it to writable again

3.The flash chip starts out writable with the kernel code setting it to read-only

or 4.The flash chip starts out writable and remains writable with some kind of software overlay in the kernel preventing changes to /system when in normal phone mode

If #1 or #2 are the case, then we should be able to reverse engineer the recovery/flash process from the "can be sucessfully flashed" ROMs we already have.

If #2 or #3 is the case, we should be able to reverse engineer the bootloader/kernel and figure out what is being sent to the flash to make it read-only (and from there what commands to send to undo it)

If #4 is the case, we should be able to find the code in the kernel resonsible for it and patch the running kernel to disable it.

Has anyone tried writing directly to the raw block device for the /system partiton. If writes to the raw device disappear, we know its not a filesystem layer block.

Also, reverse engineering the flasher/bootloader/whatever does the signature checks may help find an exploit in it (I know of several phones including the Motorola Z6 where the signature checks were bypassed by finding an exploit in the bootloader)
[G2 and Desire Z Android Development] smjfosho:
i was playing around, i do apologize. i am very thankful for everything you have contributed.
[G2 and Desire Z Android Development] Cel1084:
You programmers are too sensitive.... Now get back to work, I have "Permanent Root by Saturday" in a pool, and its up to $500 dollars now.
[G2 and Desire Z Android Development] rpmccormick:
Isn't it possible that system is actually a ram-disk and not actual nand? It could be loaded from nand on each boot.
[G2 and Desire Z Android Development] testing567:
To put it in a more relevant context Chris Soyers is user "ctso" on the XDA forums, although I don't think he posts here much anymore.
[G2 and Desire Z Android Development] biosehnsucht:
Are you using the "suspicious" return from init result to communicate indirectly through dmesg ? If so, wonderful hack lol.

If it turns out that the protection is configured in the kernel, then either tweaking it via an inserted module (which you've already demonstrated is doable, thankfully) or resurrecting the old TiVo hacking method of two-kernel monte (load a module that will load a desired kernel and boot into it, then use a command line program to feed the desired kernel to the module which then reboots into the 2nd kernel).

If it is configured in the HBOOT somehow, then things are trickier. I haven't been able to discern whether issuing a reset (CMD0) is different to the eMMC than a real reset, and some protection mechanisms can only be changed / set during the boot phase of the eMMC. Though since it looks like from the CSD / EXT_CSD dumps that boot partition stuff isn't enabled then perhaps it doesn't even use the "boot" mode, and if that's the case then anything HBOOT can do we can do, or do after sending CMD0 to reset the eMMC, from a kernel module.
[G2 and Desire Z Android Development] Mauritsd:
Looking at the eMMC 4.4 spec it seems there are two ways (accessible to us) to reset the controller:

CMD0 with 0x00000000 - this is a soft reset, which shouldn't reset the power-on write protection.

CMD0 with 0xF0F0F0F0 - this is a 'hard reset', which should be equivalent to doing a reset with the reset pin on the controller.

Or to quote the spec: "The card will be in boot mode after power cycle, reception of CMD0 with argument of 0xF0F0F0F0 or (e•MMC only) assertion of hardware reset signal."

Also: "Hardware reset may be used by host resetting a card, moving the card to Pre-idle state and disabling power-on period write protect on blocks which had been set as power-on write protect before the reset was asserted."
[G2 and Desire Z Android Development] whywhy1:
7.3.7 Boot Partition Write Protection

In order to allow the host to protect the boot area against erase or write, the MultiMediaCard shall support

two levels of write protection for the boot area.

• The boot area can be permanently write protected by setting B_PERM_WP_EN (EXT_CSD[173] bit 2).

• The boot area can power-on write protected by setting B_PWR_WP_EN (EXT_CSD[173] bit 0).

When using power-on write protection for the boot area the host must be aware of the following:

• After a power failure event that causes the device to reboot occurs or a hardware reset occurs the power-on

write protection must be reapplied, if required, since the boot area returns to the unprotected state.

• Permanent write protection can still be applied to the boot area after power-on protection has been enabled.

Therefore if permanent write protection is not required, B_PERM_WP_DIS (EXT_CSD[173] bit 4) should be

set to prevent permanent protection from being set maliciously or unintentionally.

The host has the ability to disable both permanent and power on write protection in the boot area by setting

JEDEC Standard No. 84-A44

Page 40

B_PERM_WP_DIS (EXT_CSD[173] bit 4) and B_PWR_WP_DIS (EXT_CSD[173] bit 6). If boot area

protection is not required it is recommended that these bits be set in order to ensure that the boot area is not

protected unintentionally or maliciously.

http://rere.qmqm.pl/~mirq/JESD84-A44.pdf
[G2 and Desire Z Android Development] craisis:
Different PDFs

Hmm, We're looking at different PDFs, my last page is 214 and it's blank.

I'm looking at JESD84-A441, what one are you looking at?
[G2 and Desire Z Android Development] jtc442:
Awfully quiet in here today. Hope that's a good thing?
[G2 and Desire Z Android Development] dudinatrix:
You didn't actually leave, did you? Hope not, you seemed to be making good progress... Thanks for your efforts!
[G2 and Desire Z Android Development] Dblfstr:
I keep reading as if I know what they are actually talking about... :confused:

Luck!
[G2 and Desire Z Android Development] vi5in:
Sorry I'm retarded. I was looking at the page number in the pdf reader. It's on page 200 and 201 of the actual document. I just gave it a cursory glance, but it looks like it says if US_PERM_WP__DIS is 0, then permanent protection cannot be enabled.

Oh, and do you have the source to your module?? :)