Sorry I am not very sure how to state the question title. My problem is like this, I had developed a Java program, and I wish to distribute it to my friends. So I export it to Jar file, but I don't want them to extract the jar file to view the code. Is there anyway to make the program so that nobody can get the source code instead just launch the program.
You can always get the original code back from compiled class files. However, you can make the lives of those who wish to decompile such code very difficult by using an obfuscator, so the decompiled code is nearly impossible to read. Here is a list of open-source java obfuscators which you might wish to investigate.
If a computer can run it, a human can reverse engineer it.
The term you are looking for is obfuscation. Ultimately
At best, obfuscation merely makes it time-consuming, but not impossible,
to reverse engineer a program.
Another technique is SaaS. Though ultimately using black box techniques SaaS is also reverse-engineerable.
Another technique is trust. Since you are distributing it to your friends, you could ask them to not extract the jar file or view the code. If they are really your friends, they will honor your request.
The truth is that nobody wants your source code. It's pretty arrogant to think that it'd be worth the effort required to keep them out.
The best you can do is obfuscate.
Jar files typically do not contain code. They usually only contain the .class (bytecode) files necessary to run the program.
You appear to be confusing the installation application with the executable. And I also think you are confusing a java jar application with a normal .exe.
Even then, these are all just bundles of code which can still be decompiled, it's just not as easy as unpacking a jar file, which are designed to be easy to extract.
Java is designed to run on the JVM, so packing it inside a .exe is poor form as that immediately locks it onto Windows, which defeats the point of Java in the first place. So I would advice against that.
As everyone has stated, it is rare that if your program works well and you users like it, that they would even think to decompile it. But if they want to they are just a single web search from a how to anyway (regardless of the language). With regards to commercial distribution, most cases the software is obfuscated and distributed in it's .jar, with with a architecture specific launcher of the form .exe, .app, .bin etc. Do not confuse those with the actual executable which is generally a .jar file somewhere.
You could execute part of your program on a server. Basically to execute some important, large and central function of your program, the clients contact your server to compute this function.
Then you can distribute the clients to everybody, and keep the server code for your self. Just keep the server running. Then the others can't get access to whole source, but can execute the software.
This is the only sure way to do this. Other ways can be circumvented in some ways with enough effort.
Related
I have been working on a project alone for more than two years for a company. The project is a really big one using rxtx to communicate with a hardware device. I used Java 8 and JAVAFX for the UI. Now it is almost finished and I am starting to search how to deliver the end user application that the company will distribute over its clients.
The problem is that the company I am working with wants the code to be non reachable when the software is between final clients hands because the Java code contains some extremely sensitive information that could have very bad consequences for the company if final clients happened to know them. The clients can literally perform actions they don’t have the right to perform.
So after searching (a lot) and thinking relatively to my case, I understood that giving a JAR obfuscated isn’t the solution. I then tried to generate a JAR and then transform it to an EXE but all I succeeded on was wrapping the JAR into EXE which does not prevent extracting the JAR and then seeing all the code easily. Finally, I found that I should use AoT compilation like GCJ compiler to produce native binary exe from my Java code but here I am stuck because after watching videos and reading articles etc I didn’t manage to find a clear way to produce the native binary exe.
I am now confused since I don’t know if I am on the right path and good direction or if I am totally wrong and there is another way of protecting the code (at least from non professional hackers, I understand that it is not possible to make it 100% safe but I am just searching for a reasonable and good way). How should I manage this final step of my work?
I currently work for a company that has code that we don't want anyone to have access to for the security of our clients and-- less important-- for legal reasons. ;-)
One possible solution you could look into would be to rewrite the code you deem most sensitive into a C/C++ library. It would be possible to compile this into a .so/.dll/.dylib file for the respective OSs and it would make it difficult, not entirely impossible, but difficult to decompile.
The trouble would come from learning how to access native code from Java as much of the documentation is not helpful or just simply nonexistent. This would utilize the Java Native Interface (JNI) which allows Java to, well, interface with the native (compiled C/C++) code. This would make it possible to create a Jar file that would effectively become a Java library for you to access throughout the rest of your project. The native code, however will still need to be loaded at runtime, but that's apart of learning how JNI works. A helpful link I found for JNI is http://jnicookbook.owsiak.org/ (for as long as it's still a functional link).
One of our clients here where I work has a project written in Java and needed to implement our code that is unfortunately all written in C. So we needed a way to access this C/C++ code from Java. This is the way we went about solving this issue without rewriting our code in Java. But we had the benefit (?) of having already written our code in C.
This solution to write a bunch of extra code last minute in another language that I may or may not be familiar with doesn't sound like particularly fun time.
I would be curious to learn what possible problems others might see with this solution.
I want to hand over a small Java app as a runnable jar but I do not want anybody to have access to my source code. Am I right in presuming that there is no source code (.java files) included with a jar file?
User269799
Assuming you don't put the java files in the jar file, they're not going to magically appear :) You can include anything you like in the jar file of course. You can list the contents to check:
jar tvf foo.jar
Note that Java can be decompiled pretty easily though - so while any recipients wouldn't have access to your actual source code with comments etc, they could see your logic pretty clearly. You may want to use an obfuscator to help protect your IP. Personally I try to avoid obfuscators - given how hard most of us find to maintain code when we do have the real source with commments and tests, imagine how hard it is when you don't have those things :) It's your call though. Just make sure you test obfuscated code thoroughly - there can be subtle issues, particularly if you use reflection.
If a computer can run it, a human can reverse engineer it, and it is not particularly hard for Java.
So technical protection simply won't work. You need legal protection in form of a binding contract or similar. You may even put your works under the GPL except for those paying you, which is sufficient for most businesses to avoid stealing your work.
What situation exactly do you want to avoid?
Jar files usually only include .class files, which are java bytecode files, as well as resources. However, to be a little more secure about your code, you'll want to turn off debugging information and if you really want to be secure, run it through an obfuscator.
Edit: berry120's comment is right - they can contain source files, but usually they do not. I just want to clarify for any future readers of this. It depends on the settings of the tool you use to generate the jar.
You are right, there is no source code in the jar (unless you configure your build system to specifically put it in there). But you are always at the risk you code gets decompiled from the bytecode. An obfuscater might help here.
Yes. Usually, jars contain only byte-compiled .class files. That said, they can contain source code as well—it depends on what you (or your tools, respectively) put into them.
Note, however, that decompilation works pretty well on .class files, so don't make anything security-related rely on code obfuscation techniques such as this one.
Normally there isn't but you can use the jar -tvf <filename> command to check it.
However I have to warn you that it's extremely easy to decompile most .class files into reasonably readable java source code.
To avoid this, you'll have to use an obfuscator, but that needs some extra effort on your behalf. (E.g. RetroGuard.)
Having said that, ask yourself the question: "Is my code really that valuable or special that I need to do all this?" Usually the answer is no, most of the code we write is nothing special.
You are are correct, however the .class files can easily be disassembled to java code, and its pretty accurate in most cases.
If you really need it to be properly secure then you'll need to obfuscate.
It will depend on the way you generated that .jar, Eclipse does have an option to include .java files on the .jar but it is disabled by default and you have to activate it if wanted.
Jar files might contain the source (you can choose whether to include it or not) so not including the source specifically isn't an issue. What you need to be aware of though is people potentially reverse engineering the class files that will be in the jar file.
You can get around this usng an obfuscator such as yGuard which easily hooks in as an ant task, but as others have said, is your code really that important that no-one else sees it?
The .jar file does not include source code, only the bytecode (.class). But as the byte code is machine independent, it can be decompiled very easily. There is no way to prevent others to access your source code.
I'm really confused - but really it's pretty wierd because I know two programming langauges but I can't figure out something simple like this...
I've been looking for ages but I can't seem to get my head around it.
You See, for a long time I've been writting in AutoIt, and I've written two programs in it that are due to go on sale soon! They were never meant to be out for a long time though (kind of like Windows Vista), so lately I've been learning Java with success. I've wrote a few very very simple applications in eclipse while going through Java tutorials! I'm now ready to transfer my programs to Java, to gain me a wider market due to Java's cross-platform ability, but I never anticipated distribution to be this complex.
My first problem I have come across is ease of use on multiple OS's: I don't want my customers to have to deal with JRE or multiple files, I need a double click solution that will work on MAC, Windows, Linux, etc so that even complete computer newbie's can launch my software! Secondly, this is not as much a problem as something I am not sure how to do. This is including files in my software package some need to stay seperate from the program but others could be compiled, but actually I suppose this can be worked around by an installer - which would probably be easier! And finally the other proram I made is stand - alone so it can work on USB sticks (which what it was designed for), now, how do you suppose I do this so it will launch on multiple opearating systems when it's plugged in without any hasle?
Update :: Forgot to add :: My concerns about security
I have read and from personal experience I know: how easy it is to decompile a .jar, and if there not protected properly read the source code! I know about obfuscation and I know I'll have legal back up but it just worries me. Even from the point of view that user may get the wrong first impretion of my software.
So to conclude in one sentace (Please read above still):
I need to be able to let people use my software written in Java by double clicking e.g. Like something made in AutoIt - a standard application i.e *.exe
Thanks in advance
There are two routes you can take without needing any extra software involved.
The first is to just make an executable jar (Java Archive) file. Java automatically associates the .jar extension with the Java interpreter on most systems. The JAR's manifest file will tell it which class to launch when you double-click it.
The second, less recommended route, is to make a Java Web Start application, with a JNLP launcher file. The is aimed more at applications distributed from web sites.
I'll suggest the third way: write several platform-specific launch scripts for your application. For example, run.bat for Windows and run.sh for Linux. Inside every script write a command to run JRE with all the necessary parameters. You can also maintain some pre-launch checks (is JRE installed?) or some platform-specific actions in this scripts.
I have to develop a small applet using, of course, java. I am absolutely ignorant about java and the java world. I dont' have the time to learn java "the programming course way". I just need to hack together this thing and then I won't code in java anymore (I assume).
My question is relative to the following subquestions:
is it feasible to code in java without eclipse, maven, etc ? I am pretty sure it is possible, technically, but is it really convenient/practically possible ?
how is the typical build/shipping process for java applets, in particular considering the presence of dependencies ? At the moment I am doing "screaming for vendetta" approach: download the dependencies jars, unpacking them, compiling my own .java file with the applet, repacking everything as .jar, copying it onto the web. I am pretty sure this is not the way to go, but it worked... at least for now. Clearly, I cannot continue this way.
I know Eclipse to be a behemot. how is the chance that I can produce something that works as in my current caveman approach within a couple of days ?
anything else that you deem important
Thanks.
Is it feasible to code in java without
eclipse, maven, etc ? I am pretty sure
it is possible, technically, but is it
really convenient/practically possible
?
Absolutely, you can write code in any text editor, compile with the javac command, and execute with the java command. It's not quite convenient, and Eclipse continuously loops a the build cycle for you.
I know Eclipse to be a behemot. how is the chance that I can produce something that works as in my current caveman approach within a couple of days ?
It's possible you'll be fine, but a little time with a real IDE will start increasing your productivity almost exponentially. To start, you'd be gaining intelligent code navigation, syntax validation, real-time debugging, refactoring support, and of course code completion.
Regarding your first point... yes, it is feasible to code outside an IDE in Java. a copy of your favorite text editor, the javadoc html pages and Ant will do just fine.
That said, you will be more productive in an IDE with Java.
"Back in the day", Eclipse and Netbeans were buggy and no other IDEs were free. So, plenty of people wrote lots of Java code (including me, and including my first applet) without the use of an IDE. You just switch back and forth between your command prompt where you would run javac and your editor-of-choice where you would make changes.
Likewise, build management tools like Ant and Maven are nice for large projects with nontrivial dependencies, but you certainly don't need them to write "Hello, world!" or even a "Hello, world!" applet.
That being said, I don't see any reason not to use an IDE today. They provide plenty of nice features that others here have already mentioned, which can save you from thousands of unnecessary keystrokes and dozens of careless bugs.
Developing without Eclipse or any other IDE (maven is a different kind of beast) is entirely feasible, but not recommended if you are ignorant about the Java world and want to finish everything within a couple of days. So, I suggest that you go with Eclipse. Download the basic Java edition, which is suitable for applet development. Among other things it will allow you to run your applet in an applet viewer (without having to start a browser). This is very convenient for debugging.
About the dependencies, you could create a "fat jar", with everything in it. A plug-in can help you with this. The other solution will be to place the dependencies in a "lib" folder. Then, in your applet jar, you need to edit the manifest file to correctly set the classpath. This is usually done with an Ant target.
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.