[Droid Eris Android Development] bftb0:
Hi binny1007,

I agree with about 95% of what you are saying - the last OTA update was signed using the "jarsigner" method (same as the way .apk's are signed, but in this case the public key belongs to HTC), and actually getting the update burned onto the phone requires getting past the S-ON bootloader defenses.

Moreover, as a practical matter, an exploit that could take advantage of a MITM attack is not easy to deploy widely - you would have to provide a routing tunnel endpoint to the MITM router, and the average joe isn't going to have the skills or equipment to set up a routing tunnel. (Alternatively, someone in (e.g.) NYC could set up a public "drive-by" MITM WiFi hotspot, but that isn't going to help "average joe" in BFE).

OTOH, the road to putting one of those signed OTA zip files could involve elevated privilege, as the (signed) zip file ends up in /cache (not necessarily, though - that folder gives write privs to the group "cache"). Even if you can't get around the zip signing, there is a slim possibility of exploiting an application (running with privilege) that is involved in delivering the OTA to the phone - for instance overflowing the JSON parser.

I don't know if I have gotten further along than nindoja on this - I have run a MITM attack, and confirmed that the phone speaks JSON with the server(s) at android.clients.google.com. Unfortunately, my phone will no longer roll back, even though I am not on 2.1-leak. (I attribute that to either the use of the 1.17.605.1 RUU updater instead of sticking strictly with the mid-January OTA... either that or nefarious behavior on the part of Google/Verizon/HTC).

In terms of where to focus effort, it seems like looking for bootloader exploits might be a better use of time - even if root is not gained by finding a bootloader exploit, the knowledge gained would be useful for creating a custom bootloader after root was gained through other methods. (A bootloader that accepts a zip signed by any cert would be extremely useful).

Do you know if any of the devs in your group are pointing IDA at the bootloader code?

bftb0

FYI, here's an example of a JSON interchange with the phone (unique IDs redacted):

============================================================================

POST /checkin HTTP/1.1

Content-type: org/x-json

Content-Length: 300

Host: android.clients.google.com

Connection: Keep-Alive

User-Agent: Android-Checkin/1.0 (desirec CUPCAKE)

{"imei":"A1XXXXXXXXXXXX","checkin":{"operator":"31 000","sim_operator":"310012","build":{"bootloader" :"1.47.0000","serialno":"HT9XXXXXXXXX","carrier":" verizon","radio":"2.32.40.11.09","revision":"2","i d":"verizon/htc_desirec/desirec/desirec:1.5/CUPCAKE/104882:user/release-keys","product":"desirec"}}}

HTTP/1.1 200 OK

Content-Type: application/json; charset=UTF-8

Date: Wed, 10 Mar 2010 05:37:28 GMT

Expires: Wed, 10 Mar 2010 05:37:28 GMT

Cache-Control: private, max-age=0

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN

Server: GSE

X-XSS-Protection: 0

Transfer-Encoding: chunked

66

{"stats_ok":true,"time_msec":xxxxxxxxxxxxx,"intent ":[{"action":"android.server.checkin.FOTA_CANCEL"}]}

0

============================================================================