• Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.

Signing ROMs with the AOSP platform cert (for flibblesan)

12 posts in this topic

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

Useful to me! Thank you for posting this.

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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

P

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted (edited)

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 by squrl
0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Sebastian404
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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: EMAILADDRESS=[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: EMAILADDRESS=[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: EMAILADDRESS=[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: EMAILADDRESS=[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?

0

Share this post


Link to post
Share on other sites

Posted (edited)

<edit> nvm

Edited by pendo
0

Share this post


Link to post
Share on other sites

Posted (edited)

.

post-1045626-0-42947400-1407463218_thumb

Edited by Basher51
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.