yashsingh1/xdaforums huggingface dataset:
[EVO 4G Android Development] joeykrim:
flash_image does not work w/o root access.

we flash the misc partition with a mtd-eng.img file (not necessary to create a new one) during toast's root part 2 process which is EXACTLY what we would want to use here ONCE we get root access.

im new to HTC and their structure but im almost positive you need to have at least a userdebug hboot if not an ENG hboot in order to be able to fastboot partitions.

the userdebug RUU gives addition fastboot access while the eng RUU gives a ton of fastboot access including ability to fastboot recovery.img and fastboot misc. stock hboot on the other hand has a very limited set of fastboot commands we're permitted to freely use.

i dont mean to crush everybody's hopes. please keep the ideas and brainstorming coming.
[EVO 4G Android Development] fallentimm:
Could you us se a 2.6.29 exploit?

Http://milw0rm.com/exploits/8678

Or http://www.milw0rm.com/exploits/8369
[EVO 4G Android Development] joeykrim:
site seems down for me but google cache has it!

these type of ideas are great. im having trouble cross compiling it with different arm toolchains. they throw errors on the includes and other parts of the file.

took a very quick shot at this but dont have time cuz its super late right now

moment@momentdev:~/toolchain/uClibc/buildroot-2010.02/output/staging/usr/bin$ ./arm-linux-gcc -o shoryuken ~/evo/exploit/shoryuken.c

/home/moment/evo/exploit/shoryuken.c:49:24: error: linux/user.h: No such file or directory

/home/moment/evo/exploit/shoryuken.c: In function 'main':

/home/moment/evo/exploit/shoryuken.c:66: error: storage size of 'regs' isn't known

/home/moment/evo/exploit/shoryuken.c:85: warning: incompatible implicit declaration of built-in function 'strlen'

perhaps somebody else has time to mess around with the code and tweak to cross compile

the second one says in the comments at the beginning it requires "/proc/sys/fs/suid_dumpable set to 1 or 2. The default is 0 "

cat /proc/sys/fs/suid_dumpable

0

we're out of luck ...
[EVO 4G Android Development] fallentimm:
http://www.securityfocus.com/bid/36901/exploit

Linux Kernel 'pipe.c' Local Privilege Escalation Vulnerability

H as a shell script?? Says 2.6.29 affected this seems very basic....

while : ; do
{ echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
PID=$!
OUT=$(ps -efl | grep 'sleep 1' | grep -v grep |
{ read PID REST ; echo $PID; } )
OUT="${OUT%% *}"
DELAY=$((RANDOM * 1000 / 32768))
usleep $((DELAY * 1000 + RANDOM % 1000 ))
echo n > /proc/$OUT/fd/1 # Trigger defect
done
[EVO 4G Android Development] joeykrim:
in the comments for this .c it says designed for x86 systems. it would be easiest if we could find one of these designed for arm systems!

moment@momentdev:~/toolchain/uClibc/buildroot-2010.02/output/staging/usr/bin$ ./arm-linux-gcc -o shoryuken ~/evo/exploit/36901.c

/home/moment/evo/exploit/36901.c: In function 'map_struct_at_null':

/home/moment/evo/exploit/36901.c:296: error: '__NR_olduname' undeclared (first use in this function)

/home/moment/evo/exploit/36901.c:296: error: (Each undeclared identifier is reported only once

/home/moment/evo/exploit/36901.c:296: error: for each function it appears in.)

/home/moment/evo/exploit/36901.c: In function 'main':

/home/moment/evo/exploit/36901.c:546: error: '__NR_olduname' undeclared (first use in this function)

fixed up the sh cuz not all the commands are supported by stock android, so needed busybox.

while : ; do
{ echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
PID=$!
OUT=$(ps -efl | /data/local/busybox grep 'sleep 1' | /data/local/busybox grep -v /data/local/busybox grep |
{ read PID REST ; echo $PID; } )
OUT="${OUT%% *}"
DELAY=$((RANDOM * 1000 / 32768))
/data/local/busybox usleep $((DELAY * 1000 + RANDOM % 1000 ))
echo n > /proc/$OUT/fd/1 # Trigger defect
done

pushed to data/local, chmod 755

sh 36901.sh

36901.sh: 10: Syntax error: "done" unexpected (expecting "do")

im sure somebody can take these to the next level ....
[EVO 4G Android Development] sonwon:
I suggested once that we decompile the bootloader. Doesn't the bootloader have the key to decrypt the 255 byte header? I likely don't understand how the encryption / decryption process work?

Another thought maybe the header isn't encrypted at all maybe it is just obfuscated?

Go go go guys you all can do this!
[EVO 4G Android Development] SteelH:
I have a full nandroid saved to pc. I am awaiting a replacement EVO as mine got smashed. I expect I'll have this new OTA already on the replacement. I was wondering if I could somehow use my nandroid from my old rooted EVO onto a new non-rooted EVO. However, you need root to even have nandroid working. Perhaps there is some other method to use the img files nandroid made?
[EVO 4G Android Development] Mikesus:
At some point it has to be Unzipped. If that location could be located... I doubt its directly applying a zip file.
[EVO 4G Android Development] Vinny75:
ah then someone could at least try fastboot flash misc mtd-eng.img since it should have a valid signture (I was looking for the file last night but I was looking in PC36IMG.zip... must have needed sleep)

I thought supercid would allow you to flash all partitions, or is just available with the mtd-eng.ig?
[EVO 4G Android Development] enormous:
While researching the various errors I was getting last night messing with fastboot, I came across these threads for other devices. Not sure if they'll help/have been covered, but some of them seem promising...

This one is for the Dream, and uses a "loop" command to... something?

http://forum.androidspin.com/showthread.php?p=13939#post13939

This one is for the Hero, and uses a created "GoldCard"?

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

And this one is for the Sapphire, for getting around the "perfected SPL" (which kind of sounds like what we've got)

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

I'm pretty naive when it comes to most of these methods, but maybe these might spark something for someone else.
[EVO 4G Android Development] jrmithdobbs:
It does not:

$ ~/bin/fastboot flash misc mtd-eng.img

sending 'misc' (640 KB)... OKAY

writing 'misc'... INFOsignature checking...

FAILED (remote: signature verify fail)

Also just so it's in the thread it doesn't work with toast's recovery.img either:

$ ~/bin/fastboot flash recovery recovery.img

sending 'recovery' (4168 KB)... OKAY

writing 'recovery'... INFOsignature checking...

FAILED (remote: signature verify fail)
[EVO 4G Android Development] SteelH:
I had a thought maybe someone with a working phone (which isn't me right now) could test. You can run nandroid from the adb shell. The nandroid-mobile.sh file could be put on the sdcard in /sbin via adb push. Maybe you could restore this way? Not sure if all those nandroid backup files would even work. Again, I may be completely wrong here, but it's worth a test to be certain.

adb shell
cd /sbin
nandroid-mobile-sh --help

Or, I have been reading issues about the images people are trying to flash not passing verification/signing or whatever. Is a backup created by nandroid signed so that it would pass this process?
[EVO 4G Android Development] J_Tesla:
RSA research

Yes, but remember that for RSA to work it must have at least two things: a public key and a private key. Much like a "sender-receiver" kind of thing, HTC must send the private key inside the update in order for the decoder in the phone (public key) to decipher what package there is to update.

This is made mostly for all smartphones with "non-mod" security. But what makes this one special is that HTC has implanted (since this update) a package signature encryption inside their RSA private key. This makes the decoding much more challenging, since not only must you crack the code, you also need to put in the exact HTC signature puts in the update in order for the phone to accept and install the downgrade.

In other words, the phone has the part of the algorithm to decipher HTC's package. What you need to crack the encryption is the private key (which must be inside the update.zip) and the package signature.

Remember Ocean's Eleven? Instead of the Bellagio, it's Fort Knox. Yeah. It's that difficult.

(I'm saying this because of research I've done... Thank you Google. XD Members here can correct me if I'm wrong. I'm hoping for a result soon; since I've put the update I've been dying to go again to EVOlution ROM. :D )
[EVO 4G Android Development] J_Tesla:
Deja Vu

This whole problem also reminds me the problem with the MyTouch Fender and MyTouch 1.2 from TMobile. Same problem, only that the kernel's different and thus the only way to root the Fender was through goldcard. Hmm... I wonder of creating a goldcard should get the EVO en route to getting rooted...
[EVO 4G Android Development] davidlightle:
I could be wrong, but I believe this is incorrect -- partially. Yes there are two parts, a private and public key. The concept, though, is to hang onto the private key, hence the name. So HTC signs the update with their private key. The public key -- given out and shared, hence its name, too -- is on the phone and when using the public key, it reverses the "effects" of the private key.

So, update -> private key by HTC -> signed-update -> public key on phone -> update.

I believe the signature checking and decrypting will all be done within the bootloader complicating how to swap out the file (after the signature verification, before the reading of the update). This wouldn't be an issue if we had our own bootloader (the eng HBOOT for example), but at the same time, that already eliminates the need anyway. So the issue is getting a different bootloader, a custom recovery, and/or getting root -- I believe in that order of importance (as having one can lead to the others then).
[EVO 4G Android Development] J_Tesla:
Thanks for correcting! =)

And also I believe that fastboot is partially locked? If it isn't and fastboot is free, we might be able to get root via goldcard, much like the MT3GFender or the Hero. I remember putting the hboot, recovery, radio and eng SPL through fastboot and goldcard on the Fender, but I'm not sure if it might work on the Evo.
[EVO 4G Android Development] J_Tesla:
RUU is out.

The RUU of this problematic update is out. I'm not sure how it might impact the present situation, but here's the link to the thread.

http://xdaforums.com/showthread.php?t=717024
[EVO 4G Android Development] deathpod:
Sorry man, it's the other way around. You encrypt using the public key to create a "protected" package that can only be decrypted with the private key. It's a two way system comprised of two asymmetric processes.

Think of it like this. If I wanted anyone to be able to send me a secret, I would publish a public key.

So anyone could sign a package with that public key and send it out to me. But to anyone else, it's useless because only my private key can open it, and I'm not sharing that.

That means it's:

Update -> public key -> Signed update

Signed update -> private key -> update

So, the phone being the receiving end must have the private key to decrypt whatever it needs. But I'm not sure if that's even helpful to us. Plus, attempting to crack RSA, especially 128bit+, is an exercise in futility.
[EVO 4G Android Development] davidlightle:
I agree with you, but I think there are likely two scenarios and this is one of them. I believe the way I wrote previously is the other.

My thinking is this: if HTC provided us with a public key as you said, we would simply need to sign with it, and the private key would be used to open it. Meaning we would have no problem so long as we had the key, which they would be open to sharing. And this isn't the case, unless the publicness of the key is limited to, say, Sprint, and not to just anyone.

Either way, we would need access to one of the two keys (the opposite of what is in our phone for verification). If this is a public key, odds may be that we can get it (through a leak?!), but if it's the private key, this is probably a dead-end. (On the direct brute-forcing of the key part)
[EVO 4G Android Development] EtherealRemnant:
Technically speaking, we have access to both keys though. One is in the signed zip and the other is in the firmware itself... if we could locate the other key, the problem is solved.
[EVO 4G Android Development] deathpod:
It's not as simple as just having the opposite. That's what makes it asymmetric. If all you have is a public key, you have nothing. You can only encrypt and anything you do encrypt with that key is then locked even to you.

Edit: Sorry, I see what you're saying now.
[EVO 4G Android Development] SteelH:
1.47.651.1 is evil.
[EVO 4G Android Development] davidlightle:
I don't believe this is the case, but, as with almost anything I've been saying lately, I definitely could be wrong.

I believe the setup is that HTC (and/or Sprint) is hanging onto one of the keys and the phone has the opposite one. I would expect this to be that HTC has the private key (likelihood of a leak being small), and the phone has the public key (likelihood of it being discovered are smallish, but even if so, does us no good without the other).

What is in the signed zip is not the key itself. This will be more like a signed checksum. For instance, take the zip, run an MD5 on it, then sign this with the key. When the firmware gets it, it strips the 256 bytes off the zip, runs this in with the opposite key which results in the unsigned version of the checksum, then performs the checksum on the zip, which should match.

If anything in the zip changes, the checksums don't match. If the header is modified, it won't lead to a match on the checksum.

The procedure here (which is likely extremely difficult -- due to not having the key HTC is using -- except in one special case*) would be to modify the zip, calculate the checksum of the zip, sign the checksum, prepend the signed 256-byte header onto the zip. I believe that's the process HTC is using.

* The special case would be if HTC is using the public key to sign the checksum, and that the private key is embedded in the firmware; in this case, if we can get the public key, then this should all be possible! I have doubts that this is the scenario -- I imagine HTC has the private key to sign the checksum, and the firmware has the public key, which means boo for HTC.
[EVO 4G Android Development] jrmithdobbs:
Let's put all these nonsensical misconceptions out the way right here and now.

Here's a plain english explanation of how this works:

http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml

What's on the device is the public key used to verify the signature by the private key. RSA works both ways (as the document says). Anything encrypted by the private key can be read by the public key and vice versa. There is no way we have access to both keys, can we drop this and move on now?
[EVO 4G Android Development] frankenstein\:
Perhaps a more accurate analogy would be to think of this as signing an e-mail with a certificate. They aren't encrypting, they are signing.

The recipient uses the signature to validate that the sender is who they say they are, be that sender the author of an e-mail or in this case the author of the system update package.

If the e-mail is altered in any way while in transition it invalidates the signature. The same is occuring here with the update package. EtherealRemnant's description of the signed checksum becoming invalid once the pacakge is altered is in esence a correct assessment. Once the package / e-mail is altered the checksum no longer matches up and it is rejected as being a fraudulent object.

Without the key used to sign the package / e-mail it's all but impossible to impersonate the sender. Getting that key from HTC or Sprint will likely be considerably more difficult that trying to get the source code for the kernel has been.
[EVO 4G Android Development] holob:
Wrong, public/private key systems work both ways, you can encrypt with one and only the other key can decrypt. For "signing," where verification of the source of something is the issue, it is indeed "signed" with the private key and then can be verified with the public key.

If, on the other hand, you wanted to encrypt something that only HTC could view, you could encrypt it with the public key and then HTC could only decrypt it with the private key.

A key is hardly "private" if everyone has it...
[EVO 4G Android Development] SteelH:
Anything from PSAS useful for rooting this ?

1. Check validity of HTC firmware (signature check)

2. Cut out signatures from .nbh file

3. Split radio.nb into qualcomm files for analysis

4. Find HTC Public keys using Cryptosearch

5. Generate Security passwords (SPL + radio) for newer HTC

6. Generate NBH Files (you can add any device into devlist.xml)

7. Dump Files from NBH (you can add any type into nbhtype.xml)

8. Fix radio.nb checksum

9. Generic Bootloader / AT Command interface with logging functions
[EVO 4G Android Development] deathpod:
holob, I've re-read your post a few times, trying to find where we're not saying the same thing, but other than the first sentence... I just can't find it. :)

What frankenstein\ posted made me realize I'm talking about the wrong stuff anyway. What HTC does with the updates is much more in line with verification (like PGP signed messages) and not so much dealing with low trust distribution (RSA ciphers, etc.)

I don't think anyone here wants to re-live semesters of applied cryptography--I know I certainly don't--and since it's not really helping complete the task of getting our root back, I promise to shut up about it.
[EVO 4G Android Development] willy900wonka:
So attempting to crack HTC's OTA block head on is a work of brute force. Ignore it, crack the eng build PC36IMG.zip, altering its date. Use a checksum neutral date code. Based on the byte order and word length, generate an equivalent bit pattern age that is newer than the OTA. IE

011011 and 110110 will check sum same as 111111 and 010010 in a "word" sequential check sum. Roll back to the engineering rooted release.

I would find or build a virtual emulator beyond the sdk . Build one and they will come.
[EVO 4G Android Development] elegantai:
Ok, so what do our options boil down to? An exploit of some sort or somehow figuring out how to sign a new image?

Because I am somewhat unfamiliar with portions of the system, what role does the otacerts.zip file play? Also, I have no idea if this has any relevance, is the applypatch command accessible without root? What is its functionality, does that merely signal to start an ota update or something?
[EVO 4G Android Development] jrmithdobbs:
Just the former, the latter is impossible for all practical intents and purposes. Unless someone can get someone at HTC to leak the private key. (Not going to happen.)
[EVO 4G Android Development] elegantai:
So then the user debug and engineering were actual leaks from HTC? How did they get that on their hands in the first place :D
[EVO 4G Android Development] jrmithdobbs:
I don't know but if toast could get ahold of a signed pc36img.zip with root running 1.47.651.1 instead of 1.32.651.1 we'd be back where we were a week ago with no problems.

Of course, they'd just bump the required min version on the next OTA and the person leaking them would probably eventually get caught if it happened enough times.

It's too bad the microsd card slot is under the battery so we have no way to reliably re-use the incredible method without something physical to patch the battery through, assuming the same race condition even exists in the evo recovery in the first place.
[EVO 4G Android Development] davidlightle:
From some IRC conversation, I believe I heard second-hand that the leak source won't be able to get a similar PC36IMG to leak like before.

Also, I think others mentioned that the Evo can boot without the battery when connected to a power source, giving access to the sdcard. If that's not true, there are super thin and flat cable that can extend where the sdcard is actually inserted, bringing it outside the battery area possibly. So if the Incredible's rooting method is valid for the Evo, we can find the tools to make it work I believe.
[EVO 4G Android Development] Vinny75:
Yeah, my bad, changeCid is only available in the engineering fastboot
[EVO 4G Android Development] gx1400:
Does anyone happen to have any inside connections with the crew from Unrevoked?

I've been waiting for updates through their twitter; if they really do have a "stuff in the works for the EVO with the Sprint OTA applied" then the devs here could build on their knowledge.

www (dot) twitter (dot) com/ unrevoked [can't post links]
[EVO 4G Android Development] Vinny75:
The OP was working with a member of unrevoked, it's all in the first post
[EVO 4G Android Development] roghaj:
Way easier to jump the battery out of the phone. (my two cents)

-Roger
[EVO 4G Android Development] SteelH:
I wonder if there is a way to Goldcard the EVO.
[EVO 4G Android Development] unknown_owner:
I think HTC knew what they were doing when they put the sdcard under the battery. It wouldn't surprise me if this is done on every phone they produce from here on.
[EVO 4G Android Development] jasonleb1:
My Evo has light leakage so I think I'm going to exchange it and hope it get a non 1.4 one.
[EVO 4G Android Development] J_Tesla:
First, SteelH: I concur with the approach. Would the be same approach as the MT3G Fender, but this time it's not a kernel patch problem, it's an update signature that is limiting us from putting a downgrade. (other then that RSA encryption. SOB). That signature is really getting on my nerve, and right now I don't have the tools to open the freaking RUU up to find anything of interest.

Also, good point, unknown_owner. Goldcard method is entirely made through SD Card (duh) and in the process you might need to give the card the files to flash. But having the card beneath the battery is a hassle. I say let the battery be and find a way to flash AmonRA's recovery as part of the rooting process.

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

Here's the thread to AmonRA's recovery. Godspeed, gentlemen.
[EVO 4G Android Development] sonwon:
Is there a way to build off of this concept to gain root?

"Google removed two apps he used to demonstrate how easy it would be to bootstrap a rootkit onto Android phones via the Android Market."

Google's remote Android app installer explained

http://www.theregister.co.uk/2010/07/02/google_android_install_asset/
[EVO 4G Android Development] EtherealRemnant:
Maybe we will get lucky with the froyo release. HTC may just be flexing their muscles to show that they choose to let us root our phones but can revoke the privilege at any time. I remember a press release about how HTC takes a hands off approach to dealing with rooting but they void the warranty and they can change their mind at any time and lock the phone down.
[EVO 4G Android Development] SteelH:
The unpacked RUU was posted in the dev forum recently.
[EVO 4G Android Development] Vinny75:
More likely it's sprint wanting the $30/month for tethering and rooting is getting that for free
[EVO 4G Android Development] jrmithdobbs:
Well this sucks.

I'm playing around with the suid pppd and here are the things I've found out so far:

1) It cannot be tricked into running a script as root with any the follows options:

init

connect

pty

disconnect

2) It does not have 'ifname' support builtin (this value gets passed to a shell)

3) It does not have plugin support builtin (lets you load an arbitrary library ... damn)

4) It can have the entire ppp conversation redirected over tcp using a busybox nc. This is promising to some extent because I don't think pppd has been particularly hardened against the case of a malicious pppd on the other end. I'm playing with this now to see if I can overflow it in any way.

Unfortunately for #4 I'm not entirely sure how much of this data gets handled by the child process running as the user and how much gets processed by the root-level process. The pppd code is kind of a mess and I'm having trouble reviewing it.
[EVO 4G Android Development] joeykrim:
im out of town, but this is beautiful! exactly the direction I was hoping some people would have time to explore. thanks for posting back your results!