Re: shared library in C: Not hard at all. Re: packet sniffers and man-in-the-middle -- not if you use the HTTPS protocol properly. That's why it exists. On the other hand, with physical access to the device, you could replace the HTTPS libraries and get the same result.
Re: JDASM -- that works on standard Java byte codes -- which aren't present on the device. Still... I don't know of one that reads Dalvik's byte codes, but I don't know of any reason it would be any harder to write. You should assume that any person who has a device with your application installed, will be able to examine your application in detail, and even monitor and alter its execution. So nothing sensitive to YOU should be in your application. What are you really trying to accomplish? What would this password protect? Who is it trying to protect it from? You can never definitely establish that the application that is communicating is yours, uncompromised. You can improve the situation somewhat, by, on first start, generating a private key, and obtaining from your servers an X509 certificate with the public key, signed by your server. If that certificate is abused, you can revoke it. You can improve it further: * When obtaining the certificate, supply the IMEI, encrypted with the private key. on communicating, again send the IMEI, encrypted with the private key. The IMEI can be included in the certificate. If combined with a nonce (a random value that forces each message to be different, preventing replay attacks), this will prevent copying the app + data to other devices. It won't protect against copying to other devices hacked to have the same IMEI, or using a hacked version of the app that doesn't look at the actual IMEI but uses the one from the system it was stolen from. * Each communication can include a secure random token that has to be decrypted with the private key, have the IMEI and a nonce attached, be re-encrypted, and included in the next communication in the reverse direction. If it's cloned, the duplicate token can then be detected, and both clones's communications can be terminated. However, the first clone to communicate will be successful until the second communicates; depending on your scenario, this may be a security breach. (This can be done symmetrically, to protect the device against compromise of the server!) The secure random token and the nonce are similar in purpose. The nonce protects against replaying the same communications. The secure random token protects against duplication of the communication channel endpoint itself. A drawback is that if it fails to be saved, due to error or turning off the device, then the communications channel will be broken. You can prevent that with the use of a two-phase commit, where the previous token is not retired until a positive acknowledgement of the new token is receive. This weakens the protection somewhat -- if you snapshot and terminate before the acknowledgement, you can communicate using the old token. If you then never commit, you'll stick with that token and won't be able to tell the two clients apart. So you don't actually allow communication with the stale token, but issue an error that indicates the app should retry with the new token you hand it, which it has to commit to before you allow communication. But if the clones are allowed to communicate, they can pass the tokens back and forth via a side channel. Essentially, they then act like a single distributed version of the application. This might or might not be considered a security breach, depending on your intent. (It could be an enhancement!) You can stop this by requiring a password from the user, or a value from a security keychain device. Unless the user is part of the conspiracy, or it has to run without human interaction. I think to get beyond this point, you need a security-hardened device. To my knowledge, none are available as handsets, but maybe the President of the US carries one. Before you go down that rathole, you need a clear picture of what you're trying to protect against -- an its value as a target. If all you need is to protect your web service from script kiddies looking for things to screw around with and messing up your numbers, a password embedded in the code could be a perfectly adequate solution. On Mar 2, 11:36 pm, Dan S <[email protected]> wrote: > On Mar 3, 6:14 am, Menion <[email protected]> wrote: > > > > > > > Hi, > > can you imagine how hard is then to decompile shared library written > > in C? Or is this even possible? Thanks > > > On Mar 2, 9:17 pm, Greg Donald <[email protected]> wrote: > > > > On Tue, Mar 2, 2010 at 12:23 PM, Anna PS <[email protected]> > > > wrote: > > > > So I would like to store a username and password for HTTP login in the > > > > Android source (it's an account that is app-wide, rather than per- > > > > user, so I would like to supply it with the app). > > > > > Is this a really bad idea? In other words, should I just assume that > > > > any text in Android source can be decompiled and read once I've > > > > released an app on the Market? > > > > I wouldn't put a login in the code. > > > > Here's the tool anyone can use to disassemble your > > > code:http://jdasm.sourceforge.net/ > > > > > If yes, would encrypting it help? Or would anyone who decompiled the > > > > app also be able to work out the encryption method? > > > > Decryption is just a matter of time, and it will go even quicker if > > > you give them your encrypted password in the code. > > You don't need to dissassemble any code at all. You just need to use a > sniffer like wireshark, or a man-in-the-middle system, to inspect the > HTTP packets and the password will be compromised. > > Dan -- 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
