Develop Reference

Securing key into Android app from decompilation and developers

I am working on a project which requires the secret key to be hidden somewhere in the Android app, so that it can't be taken out even after decompilation.
The requirement even states that the key should not be visible to the developer, that means it should be embedded into some pre-compiled library.
I have tried the following things:
Making Jar and obfuscating the jar, Which becomes unusable after that. And its useless method to work with Strings (it doesn't encrypt Strings).
Making C library and using that library(NDK). The strings can be easily read using linux commands. Example: '$ strings '.
I am trying to find out other ways by which this can be done.
Please help me with this. If you have any idea, please share. I would be more than obliged.
Thanks.

Anything that your app can do, can also be reverse engineered by a determined capable hacker, so don't expect some magic way to make this key perpetually secured.
If your goal is to supply an SDK that will be licensed to different developers, then the easy approach is to allocate a unique key for each developer, and let them take care of hiding it from hackers.
On the other hand, if I read your requirement literally, it is enough that the key string will not appear in plain text in the APK. The easy solution is to encode it. You can do something as easy as base64 encoding of the key, or as tricky as providing a C function that will calculate this key on the fly (so no traces of the key will appear in the output of strings).

It's a hard problem. You're fighting a battle against reverse engineering your application. There are tools that are build for this, notably DexGuard and Arxan. Arxan is really, really clever, but it will cost a lot more than a solution like DexGuard.

For aar and jar protection against decompilation you can use Quixxi. Of course the effort is about raising the overall protection as much as possible, impossible is nothing. But this solution joins the best of both the points you made. What happens is the following conversion:
input: unprotected jar file
output: java file calling the native layer
You [or the developer that will need to manage the app containing your library] can later integrate it as described in the same link. Moreover the entire app can be protected with the same tool if other parts of it will need to be secured

is it possible to force a(n embedded) JVM to only execute certain digitally signed apps?

A bit of a noob-who-tries-to-get-a-glimpse-of-something-without-making-homeworks-first question...
Suppose I'd like to include a JVM on a closed source O.S./hardware to be able to provide extended functionalities to customers with addon java applets, and that I'd want to be the only available source to develop and sell addon apps... then is it feaseable to easily implement such a mechanism by simply forcing embedded JVM to only allow execution of apps signed with my digital sign?
In other words I'd just like to know if this is an easy to implement, already proven to work, widely accepted path or just plain BS (for reasons you are free to not tell!) :)

It sounds like what you're wanting is class signing. The startup code for your application can install a SecurityManager to ensure that only classes signed by keys matching some particular criteria can be loaded.

Adding my own answer to get feedback on the following solution, which seems to be the most fitting with my question:
Could Java system policy file be the answer?
As far as I can understand from reading the documentation at http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html you can basically implement code execution permission policy in 2 ways:
1) implementing and extending permission policy at runtime (what #chrylis refers to).
2) using a default system policy file (java.home\lib\security\java.policy)
The second approach seems easier to implement and kind of more "static" which is a good thing given my use-case because I only need JVM to check that digital sign of app is mine to allow it to run, and will never ever need to extend this policy in any possible way.
So I am not sure yet but given my prerequisites this approach might be what I was looking for in my question... If you have any thoughts just add them, thanks.

How to pack java project?

I have made a java project and want to deliver it to a client but I don't want to deliver it as a jar file as the client can see the source code easily by unpacking the jar file.
How can I pack my java project so client cannot look at the source code or cannot change the source code?
One more thing, Can I integrate a key functionality so that client can only access that software by first registering it with the key provided by me?
Second, can I integrate another functionality through which the software can run only on a single machine through that key?
Remember, the software should still have the cross-platform functionality and if it is not possible then how can I made it for Debian Linux as I have made it on Windows.

To your first point. Why not only jar up the class files? These are in byte code so the client will not be able to view the source.
As to providing a key. This can be done and there are libraries that allow this, but be careful as , to my knowledge at least, there has yet to be developed a DRM system that hasn't been cracked. and most users do not like software restricting what they can do. The same point applies to your third question.

Obfuscators

There are some simple things you can do to make it a bit difficult for a client to get hold of your source code and to enforce per-host (etcetera) licensing. For example, obfuscators make it harder to reverse engineer bytecode files, and license managers support a range of restrictions based on the "keys" that you generate and supply.
The problem is that none of these protect you against someone who is determined to subvert the restrictions are trying to impose. For example, no obfuscator can prevent someone figuring out where your code calls a license manager, and once they know that they can modify the code to subvert any license checking.
Short of locking down the entire execution platform (e.g. turning of the client's ability to run debuggers, read physical devices and so on), there is nothing you can do about this.
A more viable strategy is to include appropriate protections in the software license that you require the client to sign. And accept that there is a risk that you may need to take clients to court if they willfully violate the license agreement.

Customizable Java application Ideas

So I am working on a java application, and the customer has requested the ability to have features that which can be unlocked to make the application customizable based upon what their customer wants to pay for. So I am trying to come with ideas for doing this in a manner that will provide some level of security, but also general maintainability and readability.
I have been doing some searching around, and had some ideas of my own, maintaining an encrypted configuration file which could possibly be stored in a jar file that I could unload, repack, and load at run time.
Looking to see if anyone else has any interesting ideas on how you might do this. I have been doing some looking on google without a lot of success thus far.
Oh one last little caveat, the machines this java application is on may not have internet available to them. So running a license server doesn't seem like a viable option

I would suggest using some sort of dependency injection or runtime weaving aspects, so you can include new jar files that have the correct xml files or configuration files for new features.
I agree with coobird that including them and locking them is inherently risky as someone will eventually decompile your application and determine how to get all the features.

The only sure way to prevent "unauthorized access" to features that are "locked" in software is not to provide the code that one does not want the user to have access to in the first place.
Enabling extra features by unlocking using passwords, encryption (where's the key going to be? In the program itself?), configuration file can usually be defeated by someone who is determined to get to the code they want to execute.
At least unlocking using software means can most likely be defeated, if the code that is locked is already being distributed in the binary. One way that I can think of off the top of my head that seems a little secure is an hardware key dongle, or having important code that is stored on hardware, but not many people like the idea of having to plug in a piece of hardware to use the software.
When it really comes down to it, don't have features in the code itself which is only disabled by some software flags.

I suggest you build a trusting relationship with your customers. Either that, or bundle a USB key dongle, but even these are not 100%.
If you are distributing software, any kind of encryption must be able to decrypt itself. You are essentially giving the customer both the lock and the key.

You could possibly implement the core product, and then have the additional features as plugins. You could put each plugin in a separate jar file. The customer could then distribute a bundle that contained the core application, and the purchased plugins. Thus the un-purchased functionality is not in any of the binaries.

Distribute the full set. Have them call you for the keys to unlock various features. (Use a simple encryption scheme so that the keys are of reasonable length and can be conveyed over the phone.)

Creating non-reverse-engineerable Java programs

Is there a way to deploy a Java program in a format that is not reverse-engineerable?
I know how to convert my application into an executable JAR file, but I want to make sure that the code cannot be reverse engineered, or at least, not easily.
Obfuscation of the source code doesn't count... it makes it harder to understand the code, but does not hide it.
A related question is How to lock compiled Java classes to prevent decompilation?
Once I've completed the program, I would still have access to the original source, so maintaining the application would not be the problem. If the application is distributed, I would not want any of the users to be able to decompile it. Obfuscation does not achieve this as the users would still be able to decompile it, and while they would have difficulty following the action flows, they would be able to see the code, and potentially take information out of it.
What I'm concerned about is if there is any information in the code relating to remote access. There is a host to which the application connects using a user-id and password provided by the user. Is there a way to hide the host's address from the user, if that address is located inside the source code?

The short answer is "No, it does not exist".
Reverse engineering is a process that does not imply to look at the code at all. It's basically trying to understand the underlying mechanisms and then mimic them. For example, that's how JScript appears from MS labs, by copying Netscape's JavaScript behavior, without having access to the code. The copy was so perfect that even the bugs were copied.

You could obfuscate your JAR file with YGuard. It doesn't obfuscate your source code, but the compiled classes, so there is no problem about maintaining the code later.
If you want to hide some string, you could encrypt it, making it harder to get it through looking at the source code (it is even better if you obfuscate the JAR file).

If you know which platforms you are targeting, get something that compiles your Java into native code, such as Excelsior JET or GCJ.
Short of that, you're never going to be able to hide the source code, since the user always has your bytecode and can Jad it.

You're writing in a language that has introspection as part of the core language. It generates .class files whose specifications are widely known (thus enabling other vendors to produce clean-room implementations of Java compilers and interpreters).
This means there are publicly-available decompilers. All it takes is a few Google searches, and you have some Java code that does the same thing as yours. Just without the comments, and some of the variable names (but the function names stay the same).
Really, obfuscation is about all you can get (though the decompiled code will already be slightly obfuscated) without going to C or some other fully-compiled language, anyway.

Don't use an interpreted language? What are you trying to protect anyway? If it's valuable enough, anything can be reverse engineered. The chances of someone caring enough to reverse engineer most projects is minimal. Obfuscation provides at least a minimal hurdle.
Ensure that your intellectual property (IP) is protected via other mechanisms. Particularly for security code, it's important that people be able to inspect implementations, so that the security is in the algorithm, not in the source.

I'm tempted to ask why you'd want to do this, but I'll leave that alone...
The problem I see is that the JVM, like the CLR, needs to be able to intrepert you code in order to JIT compile and run it. You can make it more "complex" but given that the spec for bytecode is rather well documented, and exists at a much higher level than something like the x86 assembler spec, it's unlikely you can "hide" the process-flow, since it's got to be there for the program to work in the first place.

Make it into a web service. Then you are the only one that can see the source code.

It can't be done.
Anything that can be compiled can be de-compiled. The very best you can do is obfuscate the hell out of it.
That being said, there is some interesting stuff happening in Quantum Cryptography. Essentially, any attempt to read the message changes it. I don't know if this could be applied to source code or not.

Even if you compile the code into native machine language, there are all sorts of programs that let you essentially decompile it into assembly language and follow the process flow (OlyDbg, IDA Pro).

It can not be done. This is not a Java problem. Any language that can be compiled can be decompiled for Java, it's just easier.
You are trying to show somebody a picture without actually showing them. It is not possible. You also can not hide your host even if you hide at the application level. Someone can still grap it via Wireshark or any other network sniffer.

As someone said above, reverse engineering could always decompile your executable. The only way to protect your source code(or algorithm) is not to distribute your executable.
separate your application into a server code and a client app, hide the important part of your algorithm in your server code and run it in a cloud server, just distribute the client code which works only as a data getter and senter.
By this even your client code is decompiled. You are not losing anything.
But for sure this will decrease the performance and user convenience.
I think this may not be the answer you are looking for, but just to raise different idea of protecting source code.

With anything interpreted at some point it has to be processed "in the clear". The string would show up clear as day once the code is run through JAD. You could deploy an encryption key with your app or do a basic ceasar cipher to encrypt the host connect info and decrypt at runtime...
But at some point during processing the host connection information must be put in the clear in order for your app to connect to the host...
So you could statically hide it, but you can't hide it during runtime if they running a debugger

This is impossible. The CPU will have to execute your program, i.e. your program must be in a format that a CPU can understand. CPUs are much dumber than humans. Ergo, if a CPU can understand your program, a human can.

Having concerns about concealing the code, I'd run ProGuard anyway.