yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] bled82:
Ok sounds like you are all on the write track . But i was wondering if we could maybe trick the system by getting root then changing the root id or the root pw to prevent the system from over writing the changes that we make . Kinda like if we hacked into a pc and then locked out the admin user account ?
[G2 and Desire Z Android Development] craisis:
Flow chart logic

Ahh, I see now. The test is for if US_PWR_WP_DI == 0, if true then continue down, if false return can't be set.

And you want to talk to damnoregonian for the source. :-( I don't have a G2 yet so I'm doing all this from datasheets.
[G2 and Desire Z Android Development] krayshunist:
The issue is that we can't get any changes to stick upon reboot and that has little to do with the root itself.

I hope damnoregonian didn't leave for good because of you clowns. He made excellent progress.
[G2 and Desire Z Android Development] craisis:
Wrong problem

Hi,

I know 80ish or whatever pages we're on is alot to read, so I'm not gonna make a fuss... But we've basically come to the conclusion that the problem isn't that the changes are being overwritten on reboot, but that they never get written to the flash in the first place.
[G2 and Desire Z Android Development] testing567:
Can this work? The way I understand it from reading this thread, the changes stay in cache and the changes revert when the cache expires. Even if we could mark the changes we want as "protected" in the volatile cache somehow, it would still revert when powered off.

Am I understanding the situation correctly?
[G2 and Desire Z Android Development] Disconn3ct:
This isn't a pc. There is no root password. This has zero to do with what is going on.
[G2 and Desire Z Android Development] bled82:
Ok thats what i thought but as you can tell i dont know much about programing i do tech support so just pulling from what i know . I have read all the post or at least 90% of it and from what i can tell its over my head about 40 pages back lol . But if you need any help I hav a G2 that has not been modded with the temp root yet and i am able to follow directions to pull info that is needed if you provided directions . So let me know if i can help if not ill just sit back and read and wait like all the other none programmers . Thanks for all the hard work guys . :cool:
[G2 and Desire Z Android Development] mrozzeh:
No offense, but that should have been reason enough to not post in this thread. The only way for any real work to happen is to keep the SNR high enough so real information can actually flow.

I'm just going to say this once, even though I'm going to be completely ignored. Looking into eMMC standards and hardware specifics of the chip is a complete waste of time. Put your efforts into the bootloader and rmt_storage, where the solution is actually going to be found.
[G2 and Desire Z Android Development] havikx:
great work so far guys!

did any1 see on androidcommunity front page tmo responded to g2 being un-rootable? has any1 heard anything on how CM feels about this? or if he's paying attention? i know 6.1 is coming...
[G2 and Desire Z Android Development] thatruth132:
http://www.thinq.co.uk/2010/10/8/t-mobile-confirms-g2-root-block/
[G2 and Desire Z Android Development] slayerdork:
cyanogen hasn't said anything on t-mobile's response, but ChrisSoyars the project manager of CyanogenMod did respond on twitter by asking for the source code, which is required under GPL licensing.

ChrisSoyars twitter post goo<dot>gl/UiUU
[G2 and Desire Z Android Development] Disconn3ct:
Bootloader, maybe. (Or a recovery exploit to flash or modify the image.) However, those areas are pretty well tested at this point, after being exploited on so many other devices.

Since it is set poweron-ro, being able to reset the emmc (even just once) to disable the ro flag would be enough to root it. The chip is accepting and dropping writes. We need to get that to stop (reset the chip) or to never be enabled to begin with (alter bootloader or subvert recovery.) It cannot be disabled without an emmc reset/powercycle.

I disagree that that is a waste of time, unless you have some knowledge that we've all missed. (And if you look at rmt_storage, it has nothing to do with this - it is how the modem cpu talks to the app cpu to get access to mmc. Wrong direction entirely.)

(Also, the "voice of reason alone in the wild surrounded by morons" tone is usually a good indicator that the following text is less reliable than it may appear. "going to be ignored" "waste of time" etc.. even if you can back it up, you are absolutely right - most people won't bother with you. And since you made a suggestion without actually contributing, later on if an exploit is found in bootloader, you can go "see! toldya!" without having ever done anything..)
[G2 and Desire Z Android Development] ace42588:
the following facts are evident:

There are still multiple camps/factions with evidence for different approaches

Feuding has started to consume this thread

n00bz to the topic don't have the patients to read the whole thread

based on these facts, i humbly suggest we fork this thread.

Suggestions:

eMMC focus

whatever the hell else someone feels is important to focus on

progress stutters when people have to defend their reasoning

plus, people fresh to the subject will see a quick synopsis at the beginning and can contribute to each effort.
[G2 and Desire Z Android Development] vladyman:
This thread needs moderation!

This thread is getting more and more useless. The objective should be to get root, and people keep interrupting it with uninformed questions, repetitions of outdated ideas (because they don't read the whole thread!), thank yous (which are nice, but also irrelevant at the moment), rude explanations what team douche is (which is completely irrelevant in this context!) etc. All of this is making the few people that are actually posting useful information, writing kernel modules, leave prematurely or give up on this thread.

I think it is best to stop this thread and start a new one which is moderated to remove off-topic posts. To root this phone it is NOT sufficient to have seen the Linux command line once. It is quite deep stuff so if you feel you cannot really contribute, there is no point to write anything. I have been observing this thread for a week now, without writing a single post, because people either had already mentioned what I thought or I felt that I did not have the expertise to comment on a certain post. Feel free to observe and provide information that you think is going to be helpful, like for example if somebody asks to run a certain command and you happen to own the phone.

At the moment lots of time is wasted on these useless posts and repetition of the same information to people who are unwilling to read, and would like the developers to summarize the thread for them, which is not their job!

Here is a quick summary: As it stand at the moment people seem to agree that there are hardware-related things preventing from permanent writing to the system partitions. It would probably help to have the HTC kernel sources, but I have just received a response from them that they do not expect to publish those for the next 90-120 days (emails I will post further down). As such it looks like reverse engineering for now, and it could take a while, unless somebody *really* good at these difficult things decides to help. At the moment it looks to me that whilst nobody was actually able to prove that what we see is hardware-related, T-Mobile's comment yesterday as well as some findings here make it seem very likely. As such it seems sensible to first try to start off with a kernel module to disable the write protection as has been suggested by damnoregonian and others (who I hope will come back!). The next step would then be cracking the phone open and try the JTAG route which some people are also apparently working on. As far as I understand this is basically all we know in this thread and it might make sense to start a new (hopefully moderated!) thread targeting these specific things.
[G2 and Desire Z Android Development] mrozzeh:
Bootloader, definitely.

It's not necessarily "dropping writes". As far as the device knows, it's accepting them perfectly to the ramfs. It's not syncing them back to the physical medium.

If you would have looked into rmt_storage, you would have seen that it is one of the parts responsible for mounting the ramfs.

We actually have most of the unrevoked team working with the cyanogenmod team, working with the alpharev team, and a bunch of smart guys from #g2-dev. And we're miles ahead of this thread. But apparently because we don't post in this thread that's going nowhere we're noncontributing; that's cute.

There's a reason these "think tank" threads never go anywhere.
[G2 and Desire Z Android Development] vladyman:
Communication with HTC about the kernel sources

I thought I'd post this here, in case people are hoping for the kernel sources to shed some light on the rooting process. I had requested the kernel sources and received the following response:

I thought that "This time frame is within the requirements of the open source community" this was very vague and responded

after which I have received the exact copy of the first response. So there is clearly nothing one can do through technical support, but I don't know who else one would contact (they haven't responded to that question). I believe that they are clearly breaching GPL, but in a way which would be very difficult to follow up in court as the GPL doesn't set any time limits (though these are clearly implied). But given that HTC does this with every single device, it looks to me as if this is part of a strategy...
[G2 and Desire Z Android Development] grennis:
Hey guys, I don't know my ass from a hole in the ground, but I was wondering if anyone tried to format the D: drive? I mean my friend's cousin's roommate had a similiar problem with his coffee maker and he said he tried that and it worked. Just my contribution, I'm sure we all get this working soon!
[G2 and Desire Z Android Development] VValdo:
I don't see anything about 90-120 days in the GPL. Is this permitted?
[G2 and Desire Z Android Development] Disconn3ct:
mv money $(find / -name mouth)

Someone spilled a basket of names, were they yours? I'll help you collect them up and get them off the floor before someone steps in it..
[G2 and Desire Z Android Development] vladyman:
The GPL doesn't give any timeframes. It would be up to a court to judge what a reasonable time frame is, and as far as I know this has not been tested in court yet.
[G2 and Desire Z Android Development] Disconn3ct:
No.

..etc

Not "someday" but "immediately, along with it."
[G2 and Desire Z Android Development] mrozzeh:
I'm not even going to waste time coming up with a response to that. I'll let you continue being the cute snarky guy; You sure are doing a hell of a lot.
[G2 and Desire Z Android Development] VValdo:
Wiki

Someone (pconwell) in #g2root started a wiki to collect/organize what we know:

Update: Moved to http://xdaforums.com/wiki/index.php?title=HTC_Vision#Rooting_the_G2

Set up an account and go to it!

W
[G2 and Desire Z Android Development] scooter185:
you want to contact their legal dept. Their was topic on this for the EVO a couple months ago.
[G2 and Desire Z Android Development] gee one:
When the other ROM is flashed, is it persistant across reboots? Hopefully it is.
[G2 and Desire Z Android Development] vi5in:
Can you tell us why? So far (in this thread) I haven't seen any information that would tell me to pick one over the other. I initially suspected that it was rmt_storage too.

I asked for images of mmc0blk13 and mmc0blk14 before and after making changes to see what was happening.

What we think is that a section of the eMMC is being used to store the original data. Any writes to this section are being redirected to rmt_storage (or whatever). If we can unlock (un write-protect) this section then writes should go there (based on what we think).

Any OTA that comes through would have to do something similar -- tell the phone that it is ok to make changes to the "protected" part.

If you have any knowledge about why we should focus on rmt_storage and the bootleader, we would appreciate it!
[G2 and Desire Z Android Development] Disconn3ct:
Already did it, and got most of the (recent, relevant) info up: http://xdaforums.com/showthread.php?p=8523533 Not all, but enough to get it started.
[G2 and Desire Z Android Development] 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.
[G2 and Desire Z Android Development] 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?
[G2 and Desire Z Android Development] mrozzeh:
I think we're misunderstanding each other.

I'm not saying that rmt_storage is what is creating the fs (I'm going to stop calling it a ramdisk, it was the easiest term I could think of to describe it to non-technical people.), I'm saying that it basically was proof to us that we're dealing with a software lockout, not a hardware one. To us, it looks like it is talking with the msm_nand driver to control writes and syncs.
[G2 and Desire Z Android Development] damnoregonian:
# insmod /sdcard/wpthis.ko
insmod: init_module '/sdcard/wpthis.ko' failed (Function not implemented)
# dmesg
<4>[10669.060546] wpthis - init
<4>[10669.060668] wpthis - sizeof(struct our_mmc_card): 392
<4>[10669.060913] wpthis - sizeof(struct device): 168
<4>[10669.061035] wpthis - bdev: 0xe7402ac0
<4>[10669.061248] wpthis - bdev 179:0
<4>[10669.061370] wpthis - name: mmcblk0
<4>[10669.061492] wpthis - gd: 0xe7163c00
<4>[10669.061614] wpthis - part: 0xe7163c38
<4>[10669.061737] wpthis - dev: 0xe7163c50
<4>[10669.061859] wpthis - dev->init_name: <NULL>
<4>[10669.061981] wpthis - dev->parent: 0xe7141008
<4>[10669.062072] wpthis - dev(name): mmcblk0
<4>[10669.062194] wpthis - dev2: 0xe7141008
<4>[10669.062408] wpthis - dev2->init_name: <NULL>
<4>[10669.062530] wpthis - dev2->parent: 0xe713fc08
<4>[10669.062652] wpthis - dev2(name): mmc0:0001
<4>[10669.062866] wpthis - dev3: 0xe713fc08
<4>[10669.062988] wpthis - dev3->init_name: <NULL>
<4>[10669.063110] wpthis - dev3->parent: 0xc055b398
<4>[10669.063323] wpthis - dev3(name): mmc0
<4>[10669.063446] wpthis - card: 0xe7141000
<4>[10669.063568] wpthis - card->dev.parent: 0xe713fc08
<4>[10669.063781] wpthis - card->host: 0xe713fc00
<4>[10669.063934] wpthis - Found card->host->card at card->host + 108
<4>[10669.064147] Attempting to get status register (CMD_SEND_STATUS)... see you on the other side.
<4>[10669.064422] Got it! (status: 0x00000900)

haven't really played with any of the other commands available, i haven't read the specs for the chip to be honest.
[G2 and Desire Z Android Development] dpw13:
Hey, good to see you're back.

Apart from the STATUS_SEND which you've already gotten, there's also this from mauritsd:

There's also some worry about corrupting the state of the filesystem by having some cached writes discarded and other go through, so there was discussion of remounting /system ro, flushing cache, then resetting the eMMC to possibly remove its write protection.

I think resetting the chip (once you ensure linux won't write to it) and reading as much status as possible is probably the next step, as long as you're willing to try it.

There's also the group write protection commands. See craisis on post 746.

My understanding is that we're still not clear whether the WP is group-based or not, but I may be misinformed.
[G2 and Desire Z Android Development] Mauritsd:
Another useful bit from the spec which could be used by wpthis.ko:

"The host has the ability to check the write protection status of a given segment or segments by using the SEND_WRITE_PROT_TYPE command (CMD31). When full card protection is enabled all the segments will be shown as having permanent protection.

The SEND_WRITE_PROT and SEND_WRITE_PROT_TYPE commands are similar to a single block read command. The card shall send a data block containing 32 or 64 write protection bits, respectively, (representing 32 write protect groups starting at the specified address) followed by 16 CRC bits. The address field in the write protect commands is a group address in byte units, for densities up to 2GB, and in sector units for densities greater than 2GB."
[G2 and Desire Z Android Development] craisis:
Things to try

Hey,

We definitely want to try a hard reset, and a soft reset. I think a soft reset should remove "temporary" write protect?

For the hard reset, it would probably be best if we could find (from decompiling probably) what the bootloader/kernel send by way of initialization commands.

And trying to find out what blocks are write protected and which aren't (see Mauritsd above) would also give us the blocks to try to run CLR_WRITE_PROT. Again, CLR_WRITE_PROT will only work if it's a temporary write protect. If it's a Power-on, then I think we'll need to find a way to do a hard reset.
[G2 and Desire Z Android Development] damnoregonian:
i am so not the hard-reset guinea pig.

not without reading those docs twice :)
[G2 and Desire Z Android Development] Disconn3ct:
I'll do it, shoot me the sources or just a couple of modules (soft-reset and hard-reset). Or hop on irc and we'll hash it out there..
[G2 and Desire Z Android Development] damnoregonian:
i just finished a 12 hour coding marathon and tore apart every single portion of the storage layer from the block device ops handlers all the way up to the mmc bus controller.

nand doesn't factor in, that subsystem isn't being used at all.

i think it's some sort of storage mechanism for the radio, which perhaps only has nand interfaces (since an mmc interface is not feasible to share)

i think rmt_storage has you barking up the wrong tree.
[G2 and Desire Z Android Development] GargFunk:
Temporary root w/ permanent changes

NB: I have neither a G2 nor Android dev experience, but lots of embedded Linux experience.

Someone mentioned using an overlay FS; I think you could use it as follows to make your post-rooting changes permanent modulo a little manual per-reboot work:

1) Create and mount a loopback FS on the SD card a la www . walkernews . net / 2007 / 07 / 01 / create-linux-loopback-file-system-on-disk-file / (parts of this can be done on any system, not just the G2)

2) Mount that file as a copy-on-write overlay of /system (is unionfs included in the kernel? If not, damnoregonian can probably build it...)

3) The above can probably include a new kernel, but to get that kernel running would require some ksplice-like operation, possibly via a custom kernel module, and would require some trickyness to keep the overlay FS mounted, so stick with the default kernel if you can live with it. I think someone referred to this above as a "two-kernel monte" =)

4) kill and restart init (I forget the exact steps to get the system to do this, is "init 6" enough? remember, you don't want to reload the kernel, or lose mounted file systems, just close down and restart init so that it runs all the new init scripts etc...)

You would have to rerun the root-getting stuff and a script to accomplish the above every time you hard-reboot the device, but otherwise this should be identical to a fully rooted permanent root.

Implementation details left as an exercise for the reader =)
[G2 and Desire Z Android Development] olearyp:
For reference: Two-Kernel Monte and kexec.
[G2 and Desire Z Android Development] damnoregonian:
i don't believe there is an overlay.

kexec is not compiled into the kernel.

they're using a custom init, it doesn't support runlevels, nor does it have a socket interface to switch runlevels like normal init.

there are a few ways to keep your changes by mounting over the critical parts of the system partition, but they're a hassle as they all require re-running the root process.
[G2 and Desire Z Android Development] hiko36:
Has anyone thought about the mytouch slide method where we faked it through with a legitimate update.zip and then once the keys had verified, pushed an alternate update.zip to the phone via adb?

Only reason I haven't tried this is because I'm at work and don't have ADB. I'm also not sure what files we would use to 'fake' it. Just tossing out an idea. Possibly the PC10IMG.zip?
[G2 and Desire Z Android Development] hiko36:
Also, I found otacert.zip in /system/etc/security that had this information inside of it. Don't know if it can help us fake keys or not but thought it might prove useful to someone.
[G2 and Desire Z Android Development] cyanogen:
Its old news. I just posted that because the news sites and blogs have their info wrong and keep publishing it. And also because tmobile lied and went along with it.
[G2 and Desire Z Android Development] GargFunk:
Feel the love

Thanks for the support Disconn3ct, but I have read and understood everything in this thread and nothing I posted required more googling than I did. It's all practical, pretty standard, Linux hacking.

Without overlay you can still go with the approach from another thread of having a copy of /system on the SD card, not an overlay (probably a more useful approach in the long run, and a few steps easier).

A funky init suggests to me that instead of trying to figure out how to interface with their kernel, it would be more efficient to spend resources on building a kernel that can mount its root from the SD card, and a Two-Kernel Monte-like module (TKM is x86 only) to load that kernel in the absence of write access to the MMC chip.

TKM is basically a boot loader wrapped in a kernel module; google "arm linux kernel loader" for some pages that describe the simple steps for loading an ARM kernel. I'm sure the TKM team would welcome code that makes it work for ARM.

Building a kernel from public sources that can access the SD card and other hardware, starting with only its initrd loaded, is long-term required for permanent root anyway, so people should be working on this already. For other phones, has this required waiting for the manufacturer to release their kernel sources?

Relatedly, has anyone asked RMS about current case law that supports or refutes HTC's claim that a 120-delay before releasing kernel code is acceptable?
[G2 and Desire Z Android Development] GargFunk:
BTW, the reason I think the TKM+SD root approach is worth spending effort on is that it's applicable to any phone, not just the G2, where you can get root and want to start developing the kernel or other parts of the system. It bypasses a few steps of learning to access the built-in MMC and creating a from-scratch boot loader and lets other teams make progress while the native flashing and booting work happens.

In case it's not clear to those that aren't linux savvy, remounting /system from an SD card partition eliminates the problem that changes disappear randomly as the cache gets flushed. It allows you to maintain root access and keep changes you've made indefinitely until reboot, and recover them quickly after reboot.