I'm reviewing an Android app (consists of Java and C source).

There are complicated obfuscation steps in the build process (for content protection).
But it uses statically linked openssl library for AES encryption/decryption.

I'm not a binary hacker but it seems ironical to me.
Why use (almost) public open-source binary library when obfuscation is required?

Can the linked openssl library led to compromises?

Is it rational if I suggest as below?
1) get rid of openssl binary modules
2) find other open-source AES implementation
3) build the AES source with obfuscation

  • 1
    while IANAL, I think that one point to watch out for, if you recommend an AES implementation that is GPL licensed and the app. wants to statically link it, the app. would need to be GPL as well to comply with the license – Rоry McCune Jan 14 '14 at 15:07
  • Thanks @Rory. I'll do my best to fix this problem. (I'm not the owner) – 9dan Jan 14 '14 at 17:22

Obfuscation is "required" when either of the three following situations applies:

  1. The application does something which is inherently weak such as embedding a secret value in the source code.
  2. The application designer wants to "feel safe", and is sufficiently incompetent at cryptography so that obfuscation provides that feeling (ignorance is bliss).
  3. The application vendor wants to protect his "intellectual property". Code obfuscation will not ultimately prevent copiers from understanding how the code work, but it may delay their reverse-engineering efforts by a few days (not much more than that); more importantly, obfuscation is a way to make it obvious that the code contents are not meant for external inspection, which helps in obtaining legal qualification of forbidden reverse engineering in some jurisdictions.

Removing and/or obfuscating OpenSSL will not really help if the application embeds secrets or try to do "content protection"; the endeavour is hopeless anyway (that's case 1). As for case 3, there is no intellectual property to protect in AES because AES is already public, and is not the vendor's property to begin with. However, obfuscating OpenSSL (or removing it and replacing it with a homemade implementation, or any other ritualistic incantation) can go a long way towards helping the designer sleep at night; if that's what it takes to make him happy...

The underlying idea is that despite what some people strongly believe or claim, obfuscation does not work. Well, it does not break the code, the software still works after obfuscation; but it does not increase technical security against reverse-engineering, and does not improve content protection. The one point which may make obfuscation a rational decision is legal qualification; and that one does not apply to OpenSSL, which is already open-source.

  • I feel like dumb :( Btw, its a kind of DRM for text files thing, so they insist obfuscation. (case 2?) Also, it invloves encryption and embedding the key in the app is unavoidable(offline). How can we feel more safe in this scenario? Sorry for long comment, and thank you for your answer. – 9dan Jan 14 '14 at 17:42
  • 1
    Well, let me put it that way: if there was a good solution to this problem, then there would be no illegal copying of movies and music. If it makes you feel better, consider that the best you can really do is to make sure that you obtain legal qualification: if people extract the data, at least they cannot claim that they were not aware of the breach of license that this constitutes. – Thomas Pornin Jan 14 '14 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.