Signing ROMs with the AOSP platform cert (for flibblesan)

[Guest Paul]

In my MCR ROMs, I am now signing key parts with the AOSP platform certificate.

This makes life a lot easier for themers who no longer have to worry about breaking framework-res' signature and being unable to re-sign it as it's signed with an obscure manufacturer certificate. It is necessary to re-sign the framework-res APK AND (to avoid horrible problems) those APKs in /system/app that have the matching certificate. To identify these, I have a script (certs.sh) that takes a directory and splits the APKs into directories based on the certificate. It will put APKs signed with the AOSP certs (platform, shared, media, test) in so-named directories, and everything else in an 'other' directory.

THIS IS MY QUICK AND DIRTY SCRIPT THAT I CREATED ONLY FOR MY OWN PURPOSES, which I am sharing by request. I know it's not flawless by a long shot (I should use more of the serialnumber cert serial probably) but it works for me. You should use at your own risk! :P

This is the script (I use a mac, but it should be easily editable to the OS of your choice):

#!/bin/bash


cd $1


for filename in *.apk

do

		unzip -d $filename.extract $filename META-INF/CERT.RSA

		if [ -f $filename.extract/META-INF/CERT.RSA ]

		then

				mkdir `keytool -printcert -v -file $filename.extract/META-INF/CERT.RSA|grep SerialNumber| cut -c 19-23`

				mv $filename `keytool -printcert -v -file $filename.extract/META-INF/CERT.RSA|grep SerialNumber| cut -c 19-23`/$filename

				mv `echo $filename | sed 's/\(.*\.\)apk/\1odex/'` `keytool -printcert -v -file $filename.extract/META-INF/CERT.RSA|grep SerialNumber| cut -c 19-23`/`echo $filename | sed 's/\(.*\.\)apk/\1odex/'`

				rm -rf $filename.extract

		else

				mkdir none

				mv $filename none

				mv `echo $filename | sed 's/\(.*\.\)apk/\1odex/'` none

				rm -rf $filename.extract

		fi

done;


mkdir other

mv * other

mv other/b399 platform

mv other/f2a7 shared

mv other/f2b9 media

mv other/936e test[/code]


Simple.



Now, once I have identified which APKs are signed with the same cert as framework-res, I put them all in the same directory and sign them. The required pk8 and x509.pem files are in AOSP (in build/target/product/security/), and my 'sign' script looks like this (this is my platform signing script):



[code]cd $1


for filename in `find . -name '*.apk' -or -name '*.jar'`

do

		echo $filename

		java -Xmx512M -jar ~/ROMs/tools/signapk.jar ~/ROMs/tools/platform.x509.pem ~/ROMs/tools/platform.pk8 $filename $filename.signed

		rm $filename

		mv $filename.signed $filename

done;

Same disclaimer as above applies - don't forget to zipalign afterwards too.

Re-signing the key parts of my MCR ROMs with the platform cert has worked out very well for themers, so if you're a dev, it's worth thinking about.

So, just to be 100% clear, this is how the process I use for my ROMs:

• copy /system/app APKs and /system/framework/framework-res.apk to a directory
  
• Run certs.sh against that directory
  
• Identify directory containing framework-res.apk
  
• Sign said directory with AOSP platform key
  
• Use newly signed APKs to replace those in ROM
  
• Done
  

One final thing to think about is that this may necessitate users wiping before installing the ROM, as it could (likely will) cause certificate mismatches with /data/data/packages.xml. Do it from the start of your ROM and stay consistent with certificates as you push new releases. :D

I hope this is useful to someone! B)

P

[Guest Simon O]

Useful to me! Thank you for posting this.

[Guest frankoid]

I think that this may introduce a security risk, albeit one that may be worth it. Because the AOSP test cert is available to anyone then couldn't anyone sign a malicious APK with the AOSP test certs and therefore be able to have their APK run as the system user?

I re-sign framework-res and other APKs that are signed with manufacturer certs with my own certificate (whose private key I keep secret) to avoid this security problem. That does have the disadvantage that themers can't just sign things with the AOSP cert - they'd have to re-sign all the "system" APKs with their own cert even if they just wanted to mod one of them.

It would probably be quite difficult for an attacker to get a malicious APK signed with the AOSP test cert onto a victim's phone because I expect that the Market wouldn't allow an app to be uploaded if it had been signed with that certificate so the attacker would have to get the victim to install the malicious APK using adb or similar.

[Guest Paul]

This is a valid point... interesting particularly in that some devices SHIP signed with AOSP certs!

P

[Guest frankoid]

some devices SHIP signed with AOSP certs!

I didn't know that, are any of those devices made by well-known manufacturers or are they cheapo ones?

http://source.android.com/porting/release_keys.html tells you not to do it:

Because the testkeys are part of the standard Android open source distribution, they should never be used for production devices. Instead, device manufacturers should generate their own private keys for shipping release builds.

That's what got me thinking about it, although I had to work out why it was a bad idea for myself. It would be nice if that page told you why you shouldn't use the testkeys, although I expect that some manufacturers would still ignore (or not read) it.

[Guest squrl]

THIS IS MY QUICK AND DIRTY SCRIPT THAT I CREATED ONLY FOR MY OWN PURPOSES, which I am sharing by request.

You sure it was flibblesan who requested it? :P Nevermind, thanks Paul, much appreciated. This is just what I needed :D

Edited January 13, 2011 by squrl

[Guest kallt_kaffe]

Thanks Paul, testing this right now. Hade to change the grep SerialNumber a bit as it seems my version of keytool prints it like "Serial number" (Ubuntu 10.10). Btw, is there a reason why it only cuts part of the serial number and not all 16 digits?

[Guest Sebastian404]

This might be a stupid question....

but why not just sign the framework-res and ALL the apk's with the same test key?

I was just looking at the ZTE Blades app dir, and there are 6 different certs in play there...

Edited January 24, 2011 by Sebastian404

[Guest frankoid]

but why not just sign the framework-res and ALL the apk's with the same test key?

Some applications that are supplied in /system can be updated with newer versions from the Market. This only works if the apk in /system/app and the new version of the app in the Market are signed with the same keys, so if you resign all the APKs then you'll break updates of system apps.

[Guest Sebastian404]

Some applications that are supplied in /system can be updated with newer versions from the Market. This only works if the apk in /system/app and the new version of the app in the Market are signed with the same keys, so if you resign all the APKs then you'll break updates of system apps.

Thats true, and I'd not thought about that... but I was more wondering about the differently signed apps...

for example, in the Stock OUK v8 rom, there are 8 different certs in use, discounting the Orange,Gameloft & Google signed ones we're left with 4 different certs in play..

framework-res is singed with 844e01c9, but then we have a selection of APKs signed with the following:

844e01c9 - Owner: [email protected], CN=ZTE, OU=Smartphone Software Dept., O=ZTE, L=Shanghai, ST=Shanghai, C=CN

Valid from: Wed May 05 01:11:46 PDT 2010 until: Sun Sep 20 01:11:46 PDT 2037

d30599fc - Owner: [email protected], CN=ZTE, OU=Smartphone Software Dept., O=ZTE, L=Shanghai, ST=Shanghai, C=CN

Valid from: Wed May 05 01:12:46 PDT 2010 until: Sun Sep 20 01:12:46 PDT 2037

8b94662c - Owner: [email protected], CN=ZTE, OU=Smartphone Software Dept., O=ZTE, L=Shanghai, ST=Shanghai, C=CN

Valid from: Wed May 05 01:13:26 PDT 2010 until: Sun Sep 20 01:13:26 PDT 2037

9d065a8c - Owner: [email protected], CN=ZTE, OU=Smartphone Software Dept., O=ZTE, L=Shanghai, ST=Shanghai, C=CN

Valid from: Wed May 05 01:14:00 PDT 2010 until: Sun Sep 20 01:14:00 PDT 2037

We all know ZTE are very odd guys... but I'm going to assume I can re-sign ALL of those with the test cert?

[Guest pendo]

<edit> nvm

Edited March 9, 2011 by pendo

[Guest Basher51]

.

Edited August 8, 2014 by Basher51