yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] linkage2424:
Edit:

Useless info, other people posted right before me about the same thing.

Delete if needed.

No offence, but did you read the thread or just the title?

No one here has done it yet, and they've been trying (according to..that thread).

But if it were to work, couldn't you use the Unrevoked method to exploit sense and unlock NAND?

I know it's a couple steps away still, but it's possible we could take G2, flash Z, exploit it for root since it has sense, install rooted vanilla rom.
[G2 and Desire Z Android Development] slindeneau:
After reading these new threads I have something new to add. The eMMC is not completely locked. Only some sectors of it. The rest of the sectors are unlocked. afaik kmmcd is either locking the sectors read-only or reporting them as read only. I haven't been able to figure out exactly where they are being locked but it is sometime after the kernel boots. There is even a time when the /system partition is writable so that the ext3 file system can write jouraling updates. Its all in the kernel log if you care to look.
[G2 and Desire Z Android Development] lbcoder:
If the protection is the same, and the "evo" was cracked, and given that the "evo" source code HAS been released at developer.htc.com, then it follows that all the information required to break this sucker IS OUT.
[G2 and Desire Z Android Development] Disconn3ct:
I'm going to put a lock on your front door and an identical one on mine. The difference is, I also have a dog inside, a security guard outside and am in a gated secured community. Sure, the guy with the lockpick can go through the locks in the same amount of time.. but he's gonna get tazed trying to get to my door to begin with.

Evo is cdma, and the radio is -way- less paranoid. (Or so I am told by the guys who were trying to adapt the evo hack.) AFAIR they just had to set s-off (in misc? in one of the radio/bootloader partitions) and it "just worked". Gsm radio is way more secure. :(
[G2 and Desire Z Android Development] lbcoder:
Then there goes the theory that it is the same protection...
[G2 and Desire Z Android Development] Disconn3ct:
It is the same protection - the emmc is marked r/o by the bootloader. The fact that the bootloader (and associated apps) are smarter just means we can't trick it into leaving the door unlocked..

A better example is an "unbreakable" lock - if I can convince you to leave it unlocked, we still have the 'same protection' but you (not the lock) failed to apply said protection. Neener neener, you're cdma and I'm gsm ;)

In any case, the protection is still there and identical, it is just a question of whether it is applied or not. (And in the end, when the emmc reset or whatever method is complete, the first order of business will be to convince it to stop applying it forever..)
[G2 and Desire Z Android Development] lbcoder:
Quit it with your boring examples. I'm an engineer, you're NOT.

The mechanism is irrelevant. The only thing relevant is the MEANS BY WHICH the mechanism is protected -- that is the ONLY thing that matters.
[G2 and Desire Z Android Development] Disconn3ct:
Wow, wrong on two counts. If you are an engineer, then you shouldn't have been assuming that two very different radio OS builds, for different radios under different regulatory requirements, etc would magically fall to the same exploit. (Also, htc seems to have a -lot- more experience protecting their gsm radios than the cdma.)

For an 'engineer' you seem to have real trouble comprehending the technical aspects of this thread. Perhaps you're just too busy to pay it proper attention, but I glanced through your post history (for the g2 stuff) and didn't find any contributions, just ranting and *****ing..

And fyi, all the same info is not available. We have less info about the radio (OOOH wait thats the thing thats different!!) and even less about the power management chip driver (hey wait, there's TWO differences? Whoa!) Both of those gaps are affecting the attempts - the first because thats where the evo hack was and second because at core, the protection is power-on ro emmc and to reset that requires bouncing the chip vcc. (Not, as several of us thought earlier, just issuing a chip reset.)

Just cuz you hate them, I'll get back to the second analogy - whether you lock the door or not, the protection is still the door. It isn't you, because you're gone and can no longer affect the situation. (The arm7, radio firmware, bootloader, etc hand complete control of the emmc interface over to linux during boot - this isn't nand, its not shared. Hence the need for rmt_storage.)
[G2 and Desire Z Android Development] cmstlist:
Well, if the key to understanding how to write to /system comes from an OTA update... congratulations, you have your first OTA update according to another thread. Enjoy =)
[G2 and Desire Z Android Development] Disconn3ct:
Know whats fun? The wiki. Specifically, the part about OTAs
[G2 and Desire Z Android Development] lbcoder:
I've decided to rephrase a bit of my response since it may come off more harshly than it needs to be....

I didn't say it was! I was simply making a response UNDER A CONDITION that the previous poster's ASSUMPTIONS WERE CORRECT. Not my fault that they weren't. It would be helpful for you to read WHAT IS ACTUALLY WRITTEN rather than reading whatever you feel like reading.

Flippy125 said that ITS THE SAME and NEED KERNEL SOURCE,

Scooter 185 said EVO.

Therefore ****IFF**** ( EVO is the same problem, and it was simply a matter of kernel source ) THEN EVO's kernel source would suffice.

If you don't know what "iff" means, it means "if and ONLY if".

Therefore *what I said is true* IFF what I responded to was ALSO true, and I made NO CLAIMS regarding the truthfulness of that.

I am certain that I understand far better than you do, you seem to have a tendency to read further into statements than what is actually written.

In fact, it is impossible to make any reasonable contribution under the circumstances;

1) I don't have one of these phones and won't be acquiring one unless it ships as a DEV phone since I have NO INTENTION of supporting lock outs,

2) Trying to formulate theories BASED ON REPORTS FROM THE MISINFORMED who either post INCORRECT information or have no clue what they are talking about is apparently quite pointless.

I am therefore constrained to whatever information happens to be available and confirmed by anyone who ACTUALLY UNDERSTANDS. Unfortunately, information that meets these qualifications is extremely sparse.

Please don't read further into written words than those words that are actually written. This isn't literature class, it is a technical discussion.... There is no hidden meaning.
[G2 and Desire Z Android Development] lbcoder:
Don't be so narrow minded. Monitoring what happens during an update (would require jtag) could yield secrets.
[G2 and Desire Z Android Development] Phxphenom:
What is wrong with you people? I work with Mechanical Engineers all day and none of them ever get this worked up......I would bet I speak for the entire readership of this forum when I request that we keep things civil. Thanks, Marc
[G2 and Desire Z Android Development] grankin01:
+1 for this post. Lets not turn this thinktank into what the other one became.

We all share a common goal. Look past yourselves and lets show tmo and htc that we are smarter than they think! :)
[G2 and Desire Z Android Development] lbcoder:
Mechanical engineers are a different type. You know, with the slide rules and thick glasses.... we computer engineers tend to be hot headed and omnipotent :D

It's not uncommon to find a computer engineer picking fights in bars or running from the police. :eek:
[G2 and Desire Z Android Development] cmstlist:
I didn't say OTA would necessarily be exploitable - I said it would help in *understanding*. And it has indeed helped.

I think this thread has already gone the way of the previous. Don't forget to enjoy some fresh air now and then - I hear it helps to cool off the snark factor.
[G2 and Desire Z Android Development] philosophics:
See what happens when I'm not around to nag at people to stay on topic? Your true immaturity level just came out guys. Of course, you're probably already aware of that...

I agree with the countless moderator warnings and other people who have requested this...

STAY ON TOPIC FOR THE LOVE OF GOD!!!

I can't have anyone banned but I can sure make requests and send emails like others who have probably done the same already.

You keep this crap up and we're gonna have to open up yet another thread for this topic and by then, it will be too late. Everyone would have givin up on trying to overcome the bickering and the people who are actually trying to find this information wont be able to cause it would be buried in this crap so knock it off, please!
[G2 and Desire Z Android Development] Captainkrtek:
I'm ready to close this thread if this doesn't get back on topic soon. Clean it up in here guys, its just a phone and everyone has opinions on different things
[G2 and Desire Z Android Development] memes:
OTA exploitability

Do somebody know the inner workings of OTA updates?

I've read the wiki but some details are missing (and a quick search with google didn't helped).

What protocol is used by an OTA update via wi-fi? From what ip address the device try to download the update? Is it possible to send (NAT? MITM?) to the device a "custom" update.zip?

What about the signature checking of update.zip? Is it checked against /system/etc/security/otacerts.zip or another known file? And what about the "update script" (that is written after the update.zip download) and is executed after the reboot? Is it downloaded with update.zip? This "update script" is executed before or after the signature checking? Or is this "update script" that check the signature?

A lot of questions, but if:

a) is possible to "feed" a custom update.zip and the "update script",

and

b) is the update script that check the update.zip signature against otacerts.zip (or another known file),

or

c) the update script is executed before the update.zip signature is checked,

then OTA is, for what I know,

in theory

(and with some luck), exploitable.

So, my last question is: is it possible to

1) building an update.zip signed with a private key

2) overwrite otacerts.zip (ok, temporarily, until the kernel flush the /system cache) with the public key certificate corresponding to the key used to sign the update

3) feed the update.zip to the device via wi-fi

4) make the "update script" overwrite the otacerts.zip after the reboot and before the update.zip signature checking

or I'm missing something?
[G2 and Desire Z Android Development] mattseg:
Dead horse. Consensus is the OTA won't help much, if at all.

It MAY answer some questions about how the whole thing functions with regard to write protection.... which is the question in the forefront on the chat. Moreover the question is what chip, how does it work, and who did what to put us (or rather the smart kids) in a quandry of how to circumvent the damned thing.

The questions, as I understand them, now.

1. how does this chip really work.

2. will a kernel based route work.

3. what does the radio control

4. is jtag the option.

Hope that helps. (I know I'm no spot on, but that's a good layman over view I think)
[G2 and Desire Z Android Development] cyprusxr3:
If my understanding is correct, this is a no-go. Allow me to try to explain why:

1. An OTA update is written to the space once filled by /cache

2. The phone is rebooted (wiping any changes to /system)

3. Recovery checks the key in the update against a key on the NAND

4. Recovery flashes the system if the key is correct.

So, it would seem, even if we know the location of the hash which the update key is checked against, we cannot modify it (since the check happens AFTER a reboot). If we could, we'd have perm. root already. Since the key hash is unmodifiable (currently) then our own signed OTA wouldn't take (unless we can break RSA - unlikely).

The problem is not having remote access during recovery - since it does it's thing on a stock NAND, and won't allow us to interfere, it's hard to trick it. The kernel solution being pursued right now is attempting to modify the NAND from within a booted android - allowing us to place modified keys into the recovery check, or perhaps sidestepping the need for recovery all together.

I hope that was technically accurate but still understandable!
[G2 and Desire Z Android Development] antiraza:
pardon my ignorance...

but:

assuming the private key would take perhaps one decade to brute force.

if the brute force attack was divided amongst 10 attackers, our wait time is now 1 year.

further divisions decrease the time required to break the key further.

if an app was developed that assigned ranges to users and tracked back the attack results, and all of us put in a few weeks of time, could we not break the key?
[G2 and Desire Z Android Development] cyprusxr3:
Some food for thought: distributed.net has been working on a 72-bit RSA key since 2002. Yesterday, 3,432 computers contributed to the project, testing on average 1,366,184,457,035 keys per second. There are 4,722,366,482,869,646,000,000 possible keys for the project. Currently, they have tested 1.096% of all possible keys. They estimate it will take 2,871 days to complete from here.

This is a 72-bit key. Can someone confirm the key bit length for the updates? Currently ssh commonly uses 2048-bit keys, or nearly 30 times the length. The total possible keys increase exponentially.

Short answer: No, we could not break the key.
[G2 and Desire Z Android Development] Denkai:
Quick question, I know we cant use the desire z rom, but has anyone tried to modify the desire Z recovery seeing as it's MCC I believe. From what I have gathered the original formats of recovery will not work on the new HTCs. Probably already been tried I just could find anyhing or results from any attempts.

On a side note I understand why, as system is reset each reboot. So don't freak. But once we figure out how to edit the locked space, it could expidite the process.

I understand how the protection works (basics only), but I'm not sure about some commands. If you typed reboot recovery, would that work correctly? If so is there a way to monopolize on that redirect it to a recovery on sd card? Or would it simply understand the command and reboot to system/recovery.img instead? I know most of this is a moot point however I like to learn why stuff does and doesn't work.

sent from my POS Cliq using the XDA App
[G2 and Desire Z Android Development] memes:
Yes, this is what the wiki says, but it also mention an "update script", and somewhere (don't remember where but I can found it if nedeed) I've read that is this update script that check the signature after the reboot.

So, where this update script comes from? If it comes with the OTA update then, maybe, is possible to modify it to make it overwrite (

after

the reboot) otacerts.zip (temporarly, ok, but perhaps for the time needed to check the signature).

But, as I don't know the details of the OTA update process, this is just a pure speculation...

This is what I meant in my previous post, I didn't even think about breaking RSA :-)
[G2 and Desire Z Android Development] daijizai:
They are working on RC5-72, not 72bit RSA... RC5 is symmetric, RSA is asymmetric... Yes, one of the creators of RSA is the guy that invented RC5 (Ronald Rivest), but RSA was invented in the early 80s and RC5 in the mid 90s.
[G2 and Desire Z Android Development] lbcoder:
Your theory fails at #2. The problem is that we gain temporary root in the running system. It would need temporary (or permanent) root in the RECOVERY system.

Note that the source code for the recovery system is all part of AOSP in the path bootable/recovery. That is, aside from any custom alterations that may have been made by the OEM, including kernel changes (which GPL requires them to hand over.... eventually). Any OTHER changes they made to the recovery system are under APL license and they are free to keep it a secret.

Also, the mechanism for acquiring the update package is irrelevant. The magic happens on the update.zip file itself and not during download. The entire zip file is signed, and that signature is verified against otacert. update-script is IN the zip file.

So if you could figure out some way to temp root the RECOVERY system, you should have no trouble making whatever changes you like to the system. Problem is that we don't know any way to get hold of a console within recovery...
[G2 and Desire Z Android Development] lbcoder:
That is fairly well known.

That is the running theory.

The radio is the gate keeper, and htc the keymaster.

Anything can be done via jtag. The main problem is in finding the path of least resistance. Though jtag is a strong means of access, it is less than trivial for a layman to implement and may require some serious reverse engineering to get anywhere. It could definitely work that way though.
[G2 and Desire Z Android Development] lbcoder:
Specifically, each additional BIT doubles the time it takes to break.

So if it takes 10 years to brute a 72 bit key, it will take 10+10*2^(2048-72) years = the universe will collapse into a singularity LONG before breaking a 2048 bit key *using current technology and methodology*.

That's a little too long to wait. Might be good idea to focus on a more direct approach ;)
[G2 and Desire Z Android Development] lbcoder:
Once we can write the locked space, the problem will be solved and there will be nothing left to expedite.

Without a phone to test with, my guess would be YES, it would work right. Problem is that doing so would obviously drop the caches and you're in a non-root recovery... same problem.

Unfortunately, no -- that wouldn't work. It is because reboot recovery works like this;

You know that the MISC partition is actually just a data structure? It has a field... the COMMAND field. A reboot recovery writes "boot-recovery" into the command field, it then initiates a full system reboot. When the SPL reads the MISC partition, it sees boot-recovery in the command field and understands that that means that it should boot from the recovery partition instead of the boot partition.

In other words, reboot recovery is a dead end unless you can rewrite the recovery partition permanently first, by which time, there is no need to make this exploit.
[G2 and Desire Z Android Development] lbcoder:
The update script ITSELF is subject to signature check. If the update script fails signature check, it won't run.
[G2 and Desire Z Android Development] fastludeh22:
figured id post up some stuff ive tried as to save someone some time, or maybe spark an idea.

we know that adb is locked in recovery, so a push there is out of the question, even if we had a signed.zip.

but what we do have is a desire-z ruu. yes i know, it wont flash the desire-z rom to g2, i tried, it does go alot further in fastboot though. however this process is done in windows. when you run the ruu it creates a temp folder with the rom.zip in it to flash. if you replace the rom.zip in the temp folder, with the offical g2 one it flashes. big deal its the same rom we have, but to me it might be a big deal, since we have full access to windows.

i tried using rom.zip with clockwork recovery in it, of course fail sig check. i also tried adding cwrecovery to the zip file while it was uploading, got a corrupt messege from winrar.

then was thinking it reboots after the radio flashes, but before recovery does. so i replaced the rom.zip while the phone was rebooting. it then failed a 2nd sig check i didnt count on.

i tried fastboot flash recovery, while the ruu was flashing (dangerious i know, but i was desperate, lol) but got different errors depending on when i sent it.

ive got a few differnt ideas gonna try today. if only we could mod fastboot.exe to add a push command, lol.

hopefully this helps someone, i know it cant hurt. funny part is i didnt know thats how the slide was rooted(swap update in recovery) until after i tried all this. it was the old ps1 "swap disc" trick that inspired it, lol...
[G2 and Desire Z Android Development] lbcoder:
The fastboot command is trivial to modify. The problem is that the controlling force is again the phone itself. Sending incorrectly signed files, even via fastboot, are still subject to the signature testing. The only POSSIBLE way to implement this file swap process would be to actually swap the the file ON THE PHONE ***AFTER*** the signature is checked, but BEFORE the file is actually installed.

This is interesting stuff;

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

Now what makes it interesting is not so much the procedure as it is the actual reason it works... in that particular update procedure (may or may not be the same with this phone), it looks like the update process actually OPENS the file TWICE. The first for signature check, the second for actual install.

This all boils down to HARD LINKS. You start with a hardlink to a properly signed file, after that one is opened, you install another file and REPLACE the original hard link to the original file with a hard link to the new file, so the SECOND time it opens the file, it is actually opening the new UNSIGNED file, thus tricking the signature check!

So how does this help?

Well, this attack exploited a defect in recovery that made it possible to push a file with ADB. That appears to have been patched in this newer phone, but the underlying open-twice problem probably remains.

The big question I have is this; does the recovery on this phone install updates from sdcard still? I suspect it does.... in which case, it IS possible to create a FAKE SDCARD -- one wired into a computer that presents what looks like a fat32 filesystem that magically replaces files after detecting the first read.

I am 99% certain that this would work. http://stackoverflow.com/questions/...-sd-card-with-a-live-connection-to-a-computer (not necessarily this device... but this procedure -- would require some programming to simulate an sdcard.)

... the android emulator contains an sdcard simulator. :eek:

Just need an INTERFACE!
[G2 and Desire Z Android Development] renn9420:
Is it possible to push a custom rom and/or custom recovery during a data factory wipe and reset? Just a question. Just thought it would be possible due to the fact during that time there isn't any system and its most vulnerable.
[G2 and Desire Z Android Development] lbcoder:
Not vulnerable at all since factory wipe doesn't unlock anything. It just clears the userdata and cache partitions, leaving the system and recovery locked up nasty.
[G2 and Desire Z Android Development] renn9420:
Just a thought thanks
[G2 and Desire Z Android Development] defconoi:
we need to crash, currupt, or exploit the bootloader, and have it execute some custom exploit that will give us write access, we dont necessarily need to rewrite the recovery/bootloader, just exploit it on every reboot to allow custom roms

so lets see about fuzzing any type of input to the bootloader we currently have, and find some bugs
[G2 and Desire Z Android Development] fastludeh22:
pretty much where i was going with this. heres what i was thinking. if you take the offical tmo img, name it PC10IMG.zip, put it on the root of your sdcard, and go into hboot. it scans the card, finds it, checks it then asks you if you want to flash it. if u say yes you see the progress bar go for each .img it flashes. SEEMS that the "load check sig, load flash" might be going on here also. if i can "fastboot push PC10IMG.zip /sdcard", with the modded recovery in it after the check, but before i say yes, might work

if someone edits the fastboot.exe and posts it up,ill try it...