Getting back to the original topic, there is a scheme that would be fairly secure if the regular JDK were used but is probably broken by Dalvik: Have the server specify a random class in the application, and random start/end offsets in the class's bytecodes, and have he application then do ClassLoader.getResourceAsStream to open the class file, access the bytes, and compute a checksum on them. The combinations would be innumerable, so there's no way the values could be precomputed, and by using getResourceAsStream you're sure that the actual code bytes are being referenced.
Alas, it's not perfect, though: The hacker could install a separate copy of the original code as a raw file and write his own replacement for getResourceAsStream. Would be a fair challenge, though. And, of course, the whole scheme is torpedoed by Dalvik, since the bytecodes are not preserved and getResourceAsStream on a class file likely errors out. On Oct 8, 8:00 am, DanH <[email protected]> wrote: > I may have misinterpreted. Presumably there's a checksum of the APK > data in the signed certificate. I would assume (hope) that's a > cryptographically strong checksum. (If not, the entire Android > platform is in jeopardy.) > > If one wants a sure "signature" (in a generic sense) that uniquely and > reliably identifies a SPECIFIC version of code, that cryptographic > checksum would be what you want (though I don't know how you'd access > that). Otherwise, the public key (which Diane has finally explained > is what the package "signature" is) is a secure, reliable way to > identify the publisher (and, with the package name, the specific app > (though not it's version)). > > There's no point in creating a separate CRC32 over the app, to use as > an identity to send back to a server or whatever. > > On Oct 8, 6:21 am, Mark Murphy <[email protected]> wrote: > > > What CRC32 checksum? > > > Trevor Johns, in a discussion of LVL, offered up CRC32 as a means of > > helping detect tampering, but that was simply an example. Otherwise, I > > am coming up with zero references to the use of CRC32 with respect to > > APKs. > > > Do you have a pointer to somewhere in the open source code where they > > are using a CRC32 checksum in this fashion? > > > Thanks! > > > On Fri, Oct 8, 2010 at 7:12 AM, DanH <[email protected]> wrote: > > > What I mean is that if the bad actor can manipulate the apk bytes > > > while still maintaining the same checksum, then the whole scheme is > > > insecure -- there's no point in having it signed. A CRC32 checksum is > > > easily spoofed -- the apk bytes need to be checksummed with a > > > cryptographic checksum of some sort. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
