Hacker News new | comments | show | ask | jobs | submit login

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.


http://grepcode.com/file/repository.grepcode.com/java/ext/co...

As far as I can tell, these concerns shouldn't be the cause. It enumerates through all entries in the jar, regardless of duplicate names.


Replying to myself: It was the first issue. There is a cyanogenmod issue associated with this:

https://jira.cyanogenmod.org/browse/CYAN-1602




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: