yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] xile6:
Yea some pages back I asked some1 to time it but it was only like 3sec longer on soft root. And I believe that was only 1 test
[G2 and Desire Z Android Development] sorch:
I guess it depends on whether the Desire Z has the same security.

(does anyone know where the idea for the Desire Z/G2 came from? Was it a T-Mobile commission, that HTC took and Sensified for the rest of the world, or was it the other way around?)
[G2 and Desire Z Android Development] samjam:
And here's me in the market for an Android phone with a keyboard that offers more than my TytnII with Froyo (thanks dzo et al) and all the main vendors keep disqualifying themselves from consideration with silly lock-down trick like these.

I wish Moto and HTC etc would realise that I have more faith in XDA produced images than the ones they ship.

I'll buy your hardware but please don't make me drink your koolaid
[G2 and Desire Z Android Development] fastludeh22:
possible system change stuck

Ok so I possibley have something that stuck, I def messed something up though,lol. In between actually working at work today, I've been playin with this phone. I was trying to get the hulu_flash.apk working. It obviousally won't install when the stock flash is installed. So last night, before I knew about the reboot restore, I tried deleating stock app then installing. Well then flash didn't work at all, reboot and its back to normal.

So today I decide to try and trick the rewrite. I deleated install_flash_player.apk in /system/app, then cp the modded one back to /system/app spelling it the exact same. Still flash completely broke, reboot, and its still broke! Try to install flash from the market and I get sig verifaction error. Try to install modded flash from linda and it installs! Still doesn't work though. Weird part is if I delete flash app, reboot, its back, but does same thing. I'm at work so don't have my orignal backup to see if putting stock app back changes anything. Don't know if this helps, but figgered id tell.

When I get home ill try just about any ideas you guys have, while trying to come up with my own.

Ps. We have to get root soon, my gf is cool with me wasteing every night trying cause she wants a g2 also, but I know this won't last long, lol.
[G2 and Desire Z Android Development] harrij4:
Wouldn't it be logical to expect that the Desire Z would not have this "feature". It seems that the secured memory used to "unroot" at boot explains the extra 2GB present in the G2 vs the Desire Z. Funny that they would brag up the 4GB memory as an advantage when it's actually there to make room for this counter-consumer trickery!
[G2 and Desire Z Android Development] NicksVideo:
I was wondering the same thing so I just did a quick test. Normal reboot of the phone (turn off, wait 2 seconds, power back on) took about 55 seconds.

Then I rooted, uninstalled 9 apps (Amazon MP3, Google Earth, Finance, Google Goggles, Google Sky Map, Photobucket, QuickOffice, Shopper, and Twitter) and did the same thing. That time it took 1 minute and 3 seconds, but it seemed like the power off took a couple extra seconds that time. Boot up didn't seem that much slower, even considering that the Photobucket app launched on start-up asking me to upload a few photos.
[G2 and Desire Z Android Development] lbcoder:
Definitely not. That would be wasteful and would kill the nand quickly. Nobody is stupid enough to do THAT.

No, what this is, is simply redirected writes. rmt_storage == ReMoTe STORAGE.... store your changes in a remote location -- outside of the system partition.

When the thing reboots, all that happens is the secondary storage is wiped clean. The actual system image is only in one place, it is just write protected.
[G2 and Desire Z Android Development] tien28:
Come on guys! you can do it! Gizmodo and Engadget reported it non-rootable, but i know the smart minds at xda can root this machine, and root it to the ground!

Just think of how accomplished you guys will feel when gadget blogs around the world ( like acclaimed gizmodo and engadget) will give praise for a job well done.

The reinstalling rootkit is just another program, and with enough dedication all programs can be hacked.

Horns and trumpets will sound when you fine hackers prevail over this communist dictator who tells you what you can or cant do on your own device. Return the definition of open source, and give justice to the G2.

~cheers, a fan of root
[G2 and Desire Z Android Development] harrij4:
Plus you'll surely get lots of chicks...
[G2 and Desire Z Android Development] lbcoder:
Unfortunately, no. You didn't get anything to stick.

What you did is this;

You deleted the apk from the system partition, which caused it to be UNINSTALLED from the USERDATA partition, and then installed a different apk with a different SIGNATURE. It didn't work because it isn't signed with system keys, but its non-system signature is installed to the userdata partition. When you rebooted, the one from the system image came back with its system signature, which doesn't match the signature now stored in your userdata partition, and so it doesn't work.

In other words, you just screwed up the signature in the userdata partition.

Nice try though.
[G2 and Desire Z Android Development] lbcoder:
There IS NO REINSTALLING ROOTKIT!!!!

Don't you get it? It is simply WRITE PROTECTED with REDIRECTED WRITES!
[G2 and Desire Z Android Development] fastludeh22:
Ahh, makes sense, too bad. So I was gonna pm u as to not clog this theard with other info to ask how I can fix this so ican have flash back, but then decided it might be good to have in here since others might have done something similar...so what should I do? Thanks
[G2 and Desire Z Android Development] tux racer:
That doesn't mean rooting is impossible. Someone will find a way to trick it into believing that nothing has been changed.
[G2 and Desire Z Android Development] Algernon:
There's a 2Gb version of this chip, the SDIN5D2-2G. Another option is that it's the same chip, but being marketed differently so that people aren't screaming about their missing 2 gigs. After all, it's not like T-Mobile is known for their savvy marketing skills. :p
[G2 and Desire Z Android Development] MrNameless:
I didn't read all 49 pages, but i understood by the title what is the meaning if this topic: if we spoof the root or the custom rom?
[G2 and Desire Z Android Development] oneponyshow42:
Hey, reminds me of my ex wife!

Keep going team, I know that XDA will crack the G2 egg wide open :D
[G2 and Desire Z Android Development] harrij4:
Exactly what I'm saying! It's reasonable to think that the Z has the 2GB chip and doesn't participate in these shenanigans and the G2 has the 4GB chip to make room for the extra partition. The end result is the same amount of user-accessible space.
[G2 and Desire Z Android Development] donboyfisher:
Ah ok, i understand.

So what happens when the phone is running normally and it tries to do a write to a directory within the read-only system image? Does the write simply get re-directed to the remote location. If you then go to read that, how does the system know its in the remote location and not in the system image partition. What makes it different?

( and why would a write be allowed in the first place if its a read-only partition ? )
[G2 and Desire Z Android Development] Cel1084:
There is too much chatter going on here!

You guys need to get to work. I want a root by the end of the week:D
[G2 and Desire Z Android Development] Shano:
I don't have my G2 yet so I can't exactly test this, but has anyone tried patching the running kernel, ala ksplice?

Since we can get temp root, and its the software, the kernel thats doing the redirects writes, can we objdump the kernel, dig in a little deeper to where its happening, and patch the kernel while its running to disable that functionality?

Just throwing ideas out there ..
[G2 and Desire Z Android Development] MrNameless:
if we will spoof the custom rom in the way that system will recognize it as stock rom, will it work?
[G2 and Desire Z Android Development] gjvah:
ughhhhhhhhhhh
[G2 and Desire Z Android Development] osho741:
that requires a signature for the rom which is part of the whole problem. we dont have one to use to overwrite what's on that partition.
[G2 and Desire Z Android Development] TL24:
I'm a new Android user and the G2 is my first Android device (couldn't be happier) but i just wanna say a big "THANK YOU" to those that are working hard to ROOT the damn thing!

Your efforts are appreciated by all G2 lovers!
[G2 and Desire Z Android Development] vi5in:
So let me see if I have this straight.

When you make changes, any change that would have gone to the actual (write-protected) location gets redirected to a remote location.

When you reboot the phone, that remote location gets wiped and the phone gets the original data from the write-protected location?

As someone pointed out, isn't that a LOT of writes to the NAND just to ensure that the phone retains the original data?

It seems that the remote location is a cache of sorts. Perhaps this is what is happening (just speculation):

1) Phone starts up

2) Phone copies data from write-protected location to rmt_storage

3) User makes changes which are actually made in the rmt_storage area and not the write-protected area.

4) User reboots.

5) Go to 1.

Do I have it straight so far?
[G2 and Desire Z Android Development] grankin01:
One thing noone has directly pointed out is that rooting this and stopping the constant writes to the inand should make the device last longer and possibly be more stable.

One thing I do remember is that several types of volatile memory can only be written to a "set" number of times before they die. If that is the case here then inand dead = check failure and then device = paperweight.(possibly)

Correct me if I am wrong but tricking the system into thinking this might be a loophole as they may have set up some sort of redundant subroutine to handle this exception. Then again, if it sounds to good ....

:D
[G2 and Desire Z Android Development] Shano:
This is why I was thinking of the ksplice method.

Get temporary root, patch the running, already verified and signed kernel, and disable the rewriting of changes to the other partition.

With the rewrites disabled, you can now write to the real partition and changes there should now hold after reboots.

That is unless there is some hardware doing the rewrites, but so far I've only heard reference to it being a software problem, which once you have root you can fix that?
[G2 and Desire Z Android Development] donboyfisher:
Yup. However, a quick look around the web seems to imply that depending on the type of NAND, it can be as low as 5K write cycles or as much as 100K write cycles before you start to question the integrity of the memory block.

Even then, some controller either keep aside space to use as a replacement for bad blocks ( Bad block management ), or they monitor the number of times a block has been written and then dynamically re-assign address spaces to different physical blocks of memory ( wear levelling )

I'd imagine that the stuff in phones would be at the higher end of the write cycles .... so that would equate to a lot of re-boots.
[G2 and Desire Z Android Development] vi5in:
I read a few of the earlier posts and I'm wondering. Has anyone been able to get an image of mmcblk0p13 and mmcblk0p14?

Maybe first we can get an image of both on start up and store them in mmcblk0p13.startup.img and mmcblk0p14.startup.img. Then make some changes, and get an image again. This time, storing them in mmcblk0p13.changed.img and mmcblk0p14.changed.img. Finally, reboot the image and get another set of images, this time dumping the image to mmcblk0p13.after_reboot.img and mmcblk0p14.after_reboot.img.

If rmt_storage is what we all think it might be, examining the dumps for differences may give us some clues? I will see if I can do this when I get home tonight.

Thoughts?
[G2 and Desire Z Android Development] osho741:
if those are the temporary storage partitions then when you reboot they will simply disappear so will you be able to get a logcat of the phone overwriting those images or what?
[G2 and Desire Z Android Development] KeithLM:
First, I'm not experienced at hacking on these at all, but I have to ask why would there be any writing to the NAND? If I'm following this correctly isn't it the NAND that holds the original image, and that any attempt at getting root access is in the system memory, on what is essentially a virtual drive? So the NAND is only being read from on boot, and copied to the system.

But there must be a way to write to the NAND for the updates from T-mobile, and I'm guessing that is the hole that must be found.
[G2 and Desire Z Android Development] vi5in:
Don't know. That's why I'd like to see what they look like when you first start up, after you make changes, and then after you reboot after making changes.

If what we think is true, the images from startup and after reboot should be the same.

If one of the partitions is the "true" partition that contains the original data, it should remain unchanged. If the other partition looks different after you perform the change then that might be where the write is being redirected.

Someone said rmt_storage might be a red herring. At the very least this may let us decide if it is so.
[G2 and Desire Z Android Development] mlevin:
Right.

I don't think so. I don't think it is that anything gets written back to /system. It's that it never was changed in the first place.

I think it is basically like an overlay. The underlying files are from a read-only /system. Any changes get written to a separate place.

It sounds like it is a lot like Sandboxie (a Windows app that lets you create safe sandboxes). Any writes to your disk or registry get intercepted at a low level and end up written to another location, which you can later delete to make it as if the files were never written. It's like a read-through cache but the writes don't go back to the underlying location.
[G2 and Desire Z Android Development] vi5in:
Good point. How exactly would OTA's be handled? There must be something in the OTA update to tell the phone "Hey it's ok -- go ahead and overwrite the information in the write-protected area".

Hopefully we won't have to wait until we get an OTA to figure out what they're doing :).
[G2 and Desire Z Android Development] osho741:
well t-mobile is talking about wifi calling which would require a change to the phone's rom to work so maybe it will come sooner than we think.
[G2 and Desire Z Android Development] vi5in:
That makes a lot more sense. So:

write -> [proxy] -/-> [write-protected area]
|
V
[cache]

read -> [proxy] -> [cache] -> returns data if content exists
|
V
[write-protected area]
|
V
returns data from write-protected area if it cannot be found in cache

Then, presumably, this cache is wiped on startup.
[G2 and Desire Z Android Development] osho741:
ok here's the dumbest idea i have ever come up with. What about calling sandisk customer support up and asking them how to disable the write protection on that particular chip? i know i know dumb idea but hey, least its an idea lol
[G2 and Desire Z Android Development] smjfosho:
then call them.
[G2 and Desire Z Android Development] osho741:
i just might, who knows maybe i'll get lucky and an ex t mobile customer support rep will answer the phone!
[G2 and Desire Z Android Development] grankin01:
Not really a dumb idea. The worst they are going to do is say no we can't tell you that info.
[G2 and Desire Z Android Development] pconwell:
Yes, t-mobile can sign images with a release key. We (as in non t-mobile) can only sign with test keys. The phone (as of right now) will only accept images signed with the release key. So, the goal - well, one of the goals - is to get the phone to accept any keys, ie test keys.

OR, somehow reverse engineer / crack the release key so we can sign whatever the crap we want as an 'official' image.
[G2 and Desire Z Android Development] raitchison:
I think they already know that, who's to say that isn't why they are doing things like this?
[G2 and Desire Z Android Development] funkeee:
Call them. It's more likely to work than not if it's some innocent info. I doubt the CSRs know about a contractual obligation to protect HTC/T-Mobile secrets if such a thing exists. They are there to support users of the product. I doubt they will provide exploits or workarounds, however. So I guess it depends on the info you're trying to extract and how you present it.
[G2 and Desire Z Android Development] osho741:
well i just did a live chat with them and they referred me to the manufacturer ohh well worth a shot lol

Neo R.: We request you to contact the computer manufacturer for further assistance.

andy : ohh ok so there isnt a general way to default the disk?

Neo R.: As this support is for retail products as G3 SSD and the drive you have is an OEM product,so there are differences in both the products and we do not have expertise on OEM products.
[G2 and Desire Z Android Development] Disconn3ct:
..so call them :)

Also, rmt_storage is standard android stuff. PROBABLY nothing to do with this (although not guaranteed, since they could hide whatever they want in the apache-licensed files.)
[G2 and Desire Z Android Development] vi5in:
It seems like this sets the block to read-only:

#
# Create a remote storage service in recovery mode if eMMC booting
#
service rmt_storage /sbin/rmt_storage /dev/block/mmcblk0p13 /dev/block/mmcblk0p14
user root
disabled

on property:ro.emmc=1
start rmt_storage
[G2 and Desire Z Android Development] Shady Gambino:
I can see the Engadget / Gizmodo headline now: "HTC unwittingly help hackers hack the G2, HSPA+ Tethering GO!"
[G2 and Desire Z Android Development] osho741:
lol that would be beyond awesome!
[G2 and Desire Z Android Development] Shadoknight:
Possible explanations

1) I'm new here - and I've never rooted a phone.

2) I've got extensive experience in software development from embedded systems up to supercomputers

3) I've read every post on this thread.

Just an observation - if I were to be tasked with creating a system that behaves as you guys have so far observed, and if I had a friendly ear at SanDisk (someone I could either convince that I was a big enough market myself, or this feature could be a useful selling point), I'd have SanDisk build into the chip the ability to do Copy-on-Write at the block-level on a per-partition basis. Then, provide either an unlock mechanism (as simple as a bit, as complex as a properly signed instruction stream) to allow for 'real' writes, or a finalization mechanism (again, either a bit or a signed instruction) to force the block pointers to be permanently updated. This would result in exactly the observed behavior, with almost no overhead, no need to erase anything (change a few block pointers, but relatively little change required), etc. OTA updates are easy - same process as you guys are going through, with either a prefix to 'unlock' or a postfix to 'finalize'. The 'excessive write' scenario isn't a problem - the design of the system is such that the only intended updates will be during 'official' updates, which will be few and far between - no chance of wearing anything out. Even HTC's statement about 'nothing to prevent rooting' is technically correct - it could be (from a slightly angled perspective) viewed as an 'optimized' version of the recovery-safe update process already in place (and, in that case, OTA updates could be differences rather than entire replacement systems...). In fact, that last bit argues for a finalization procedure rather than a prefix...

Anyway, I don't know if it helps, but I figured a different way to look at the problem might cause folks to peer at different parts of the process...

SK
[G2 and Desire Z Android Development] schwiz:
Has the second method you mentioned ever been done before in the android community? Just curious, sounds awesome!
[G2 and Desire Z Android Development] vi5in:
@Shadoknight

So this would be something that HTC would have to do, since they control the hardware. But someone on this thread contacted HTC and they've denied it. Don't know if we can take them at their word or not. They seem to suggeset that it is something that T-Mobile is doing.

OOPS just read the last bit in your post. So you're saying that instead of entire updates, they send diffs.

It would seem then, that we need to figure out the signing key. Has this ever been done before?
[G2 and Desire Z Android Development] pconwell:
Not that I know of, otherwise rooting would be extremely simple. I'm not real familiar with the security of the java / android img signatures, but *IN THEORY* it should be crackable. It just may take a few years computer processing time to brute force. Like I said, I don't know though.
[G2 and Desire Z Android Development] Shadoknight:
The signing key wouldn't necessarily be required (cracking that is the realm of serious crypto work - not knowing, I'd guess they're using 2k RSA minimum, which is unlikely to be brute-force crackable anytime soon). All this is hypothetical, but I'd look at the end of the 'recovery' update process to see if there is any code that looks like it pokes data values in suspicious memory locations or anything...

My main point was that what the folks on the thread so far are describing sounds a lot like a copy-on-write scheme, and as I thought about it, such a scheme makes a lot of sense, not necessarily as a way to prevent rooting (that'd be a nice side-benefit they never have to admit) but as a way to send deltas instead of full system replacements for OTA updates, safely.... again, I don't really know - I have a G1 and was looking at maybe upgrading, but haven't ever done this level of hacking on an Android device, so this is all supposition and logical extrapolation ;-)

SK
[G2 and Desire Z Android Development] liillliillliiii:
I was going to wait to buy a G2 until it gets rooted for real, but now that this is turning into hardware limitations rather than software limitations, I'm a bit more interested.

Are there scans of the inside of this thing yet? Has anyone done a teardown of their precious new toy?

Let's find some JTAG pins! Let's hook up an FPGA and go PS3 style: force the cache to always miss or force the MMC be write-enabled?

If the entire boot NAND is marked unwritable, maybe there's a way to restart the OS without letting the cache (or wherever /system writes are going) clear? "Boot" off the cache?
[G2 and Desire Z Android Development] larryccf:
any possibility the release keys are something as obvious as what's described on the bottom of "settings>about phone", and the very bottom it describes:

Build number 1.19.531.1 CL255798 release-keys

for the hey of it, i googled "CL255798 release-keys" and found this link

http://pastie.org/pastes/1196065
[G2 and Desire Z Android Development] hansalvato:
what if this is all a game htc's just testing us,testing theyre system just to make something new everytime that plugs up each hole
[G2 and Desire Z Android Development] grankin01:
At the risk of sounding like a smartass that is exactly how this has always worked. They make a device, the dev community hacks it, they patch said hack.

Cheapest form of penetration testing I can think of. ;)
[G2 and Desire Z Android Development] surlydre:
OTA Question

I've been thinking about the process that OTA updates will have to go through to write to these blocked areas, but I'm not real familiar with the mechanics of OTA, although I've done plenty of flashing from fastboot.

Does an OTA write an update zip to the SD card first, and then force a "reboot into fastboot" with some sort silent option so fastboot can verify the update signature and flash the necessary partitions? Or does it write to the system areas while it's executing inside the booted system?

I think it's the latter since I don't remember seeing any sort of fastboot screen when I saw an Evo apply an OTA update recently. Anyone have a link to a description of the OTA process?

If it really is the latter, than the OTA executable / initiator must be issuing some sort of command to turn off the protection before it begins the write.