This tantilising and makes me want to work out what the problem is pre-Blackhat. Looking at JAR signing in general (which is what Android packages are) I see a few possible flaws:
* The zip format doesn't structurally guarantee uniqueness of names in file entries. If the APK signature verification chooses the first matching file entry for a given name, and unpacking chooses the last then you're screwed in the way described.
* The JAR signing scheme signs a file containing hashes of file name/data hash pairs. However, there seems no part of the verification steps (in the JAR specification) where extra files not mentioned in the signed data cause signature rejection. This seems like a bad idea.
From the description, though, it sounds like a key management problem. Anyway, this talk is definitely on my Blackhat schedule!
You should really dig into this more, regardless of Bluebox's work.
I was approached about buying two different Android 0days related to APK signing about 3 months ago, so definitely some issues to be found. The seller wanted unrealistic terms, so I never got full details.
* The zip format doesn't structurally guarantee uniqueness of names in file entries. If the APK signature verification chooses the first matching file entry for a given name, and unpacking chooses the last then you're screwed in the way described.
* The JAR signing scheme signs a file containing hashes of file name/data hash pairs. However, there seems no part of the verification steps (in the JAR specification) where extra files not mentioned in the signed data cause signature rejection. This seems like a bad idea.
From the description, though, it sounds like a key management problem. Anyway, this talk is definitely on my Blackhat schedule!