I make a program in Netbeans but I want my program files locked because I not want that any one can read or copy the source. How can I lock the files?
thank!
This is a very very broad question, but i'll try to help a little bit.
The best thing you could probably do for something written in java is called 'obfuscation', which means that your code is still readable, just very jumbled and very difficult to understand to a human
"Locking" files on a JVM language is an uphill battle that you probably won't ever win, if someone really really wants to see your source code and edit it, they can, it will just take some time, this actually applies to any language really, to be honest. No matter what you do, if someone is smart enough and really wants to edit your program, they can and will find a way, the best you can do is try to make it as hard as possible for them.
That being said, a decent obfuscator is enough to make most people look at your project and decide it probably isn't worth their time to manually deobfuscate it.
Related
From what I understand, obfuscating a java web application will just make it a little harder to read your application, but reverse engineering is still possible.
My goal is just to make it very difficult to read, and not be able to decompile and run (not sure if that's possible, I guess it will still run just with ugly variable names??)
So variable names like:
String username = "asdfsadf";
will become
String aw34Asdf234jkasdjl_asdf2343 = "asdfsdaf";
Is this correct:
public classes and variables will remain unchanged
ONLY private strings/classes/methods can be renamed
string encrytion can be used for some sensitive string data like encryption keys etc.
Really my goal is so that someone can't just decompile and release the code.
Web applications run server side. Clients will not see the code unless you mess things up.
There are plenty of good Java obfuscators which will do what you say, and much more. Here are some from google:
ProGuard
yGuard
JODE
Although these will make it much more difficult to read the decompiled code (and some decompilers will refuse to even try), keep in mind that it is always possible for someone to reverse-engineer the code if they have the binary, and are knowledgeable and patient enough.
The problem here is that the code needs to be in proper java syntax when you compile it. So no matter what obfustication you applied, if I have access to even just the bytecode I can figure out a way to reconstruct the source.
(http://www.program-transformation.org/Transform/JavaDecompilers#Java_Bytecode_Decompilers)
What you would need to do is keep the proprietary part of the software in such a place that your pirates would not be able to see it. As far as I am aware, that is the ONLY way to avoid hijacking your software.
You cannot prevent java code from being decompiled and run. Even if it is obfuscated, there may be people out there that are still able to figure out what your code is doing, despite the obfuscation. Everything you publish can be reverse engineered.
There exist even much stronger efforts in other languages to prevent decompiling and debugging, disk copy protection solutions for example, and even they get reverse engineered and hacked frequently.
If you don't want people to reverse engineer your code, let it run server side only, don't publish it and try to harden the server as much as possible.
http://www.excelsior-usa.com/protect-java-web-applications.html
Disclaimer: I work for Excelsior.
http://www.arxan.com/products/server/guardit-for-java/
Disclaimer: I don't work for Arxan.
No amount of obfuscation can protect you against "decompile & compile again" (without trying to understand what the code does). Decompilers don't care for unreadable variable names, nor do compilers.
Incidentally, if someone has access to your code, they don't need to decompile it to use it.
So the question is really: What do you want to achieve? When you know that then you can go to the next question: How much does it cost and how much money can I earn?
Usually, that equation is: You can't save/earn any money from obfuscation but doing it costs you time and money (good obfuscators aren't free). So it's a negative ROI.
Instead, try this approach: Create a great product (so people will feel it's justified to pay for it), fix bugs quickly (-> the thieves have to steal your work again and again just to keep up), add new features. That way, honest consumers have reason to buy from you.
If you plan to get money from thieves and criminals, well, forget it. They don't want to pay you, no matter what. You can make their lives a little bit harder but at a cost.
I don't want my class to be decompiled.
I have gone through some of the articles and found a patent site
Zelix KlassMaster
Is there any free tools available in the market which works in the similar way..
As far as I know there are no free tools with the same set of functions.
In my opinion the mix between ProGuard and Stringer Java Obfuscator is the best and also most cheap way to protect Java and Android applications.
N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
Proguard is the best available free and open source obfuscator. Obfuscators jumble your class, field and method names so that it becomes difficult to make sense out of the decompiled code.
Zelix Klassmaster is a commercial obfuscator and is one of the best in the commercial space. Also, it has some additional feature to encrypt the string constants to that the strings arent visible when decompiled. There are also some other commercial tools like yguard, DashO-pro, Allatori and Smokescreen etc.
You can obfuscate your code, so that when it de compiles it isn't easy to read (for programmer)
You can't specifically stop it being decompiled. After all, a decompiler only has to be able to read the byte code to turn it into source code, and reading the byte code is also what the JVM has to do. So if you were to come up with some way to prevent programs from reading the byte code, the JVM wouldn't be able to run your class.
As others have pointed out, obfuscation is the way to go if you REALLY need to do this, but I would question whether you really do need to. It's also worth pointing out that if you do use obfuscation, finding bugs will be much harder because stack traces will also be obfuscated.
Obfuscation is certainly a way to protect your code. Also, there are other tools which encrypt your classes and provide a custom classloader which can decrypt and load your class at runtime. This is not a very foolproof way but yes there are tools doing that.
You can't prevent a java class from beeing decompiled. However, you can make the life of someone who will try to understand your code very very hard. This is the task of a so called obfuscator, like KlassMaster.
Please see this list for Open Source obfuscators.
Please see also one of my questions: https://stackoverflow.com/questions/1872170/how-to-protect-intellectual-property-in-java-app
Unfortunately in Java like in JavaScript getting to the source code is easy.
Understanding it is another thing.
If you try hard enough and send date through dozens of functions each doing a small part and passing it along then obfuscating it and maybe add some fake functions you might just give enough head eke to those with ill intentions enough of a head eke that they will quit before succeeding.
I'm using Zelix Klassmaster for my app Visual Watermark for about two years now. No new program "cracks" were released since then. So, it seems a good option for protecting Java apps.
I have an issue here..and its making me really nervous.
I was working on this game, and it was going great, so I took a copy of it on my laptop to work do some work while away from my computer.
long story short, hard-drive failure + poor back ups led to me losing a very important class.
Is there a way to decompile the apk to retrieve the bit of code that was lost? It isn't overly complicated or sophisticated, its just that its impossible to re-write it without reading every. single. line. of. code. in the entire application since it initializes a LOT of classes and loads a bunch of stuff in a specific way.
With a quick google search I was able to find apktool, which decompiles it into a bunch of .smali files, which I don't think were designed for human reading.
All I need to recover is one very big method in the class. I found the smali file that contains it and I think I found the line where it starts. something like
.method public declared-synchronized load(Lcom/X/X/game/X;)I
Anyone help would be appreciated since I would have to scrap the entire game without this method.
A quick google resulted in a way to decompile apks (decompile apk to java source). However, even though it results in java code, you probably won't have any variable names (just default ones like param1) as those are unrecoverably removed when you compile the source code to byte code, also, depending on the decompiler, for/foreach loops will be while loops instead, if/else blocks might not represent your original control flow due to compiler optimization.
As a general advise: Use some sort of source control. On your own server, paid account with github doesn't matter what, but use source control. Even if you are just one person developing on a project. It helps with this situation, it helps with reverting to a previous version, it helps finding a bug you introduced. When the tools are available, use them.
I want to create a texttwist using Java with a GUI, but I don't know where to start. Can somebody give the steps to create my text twist project?
Well, this is a pretty broad question. The fact is there are dozens of ways to go about it. Do you have any Java experience?
Assuming you have no Java experience at all, I would start by finding a few tutorials online, whatever looks good to you (the official tutorials, though, are an excellent place to start). Then go on codingbat and get really comfortable with the basics of Java (also, a good understanding of the Java Collections Framework is essential for doing many things). You can do that before actually choosing an IDE (Integrated Development Environment, like this or this) to use for future coding.
Once you feel okay about actually writing code, start reading about Object Oriented Programming. Learning to make your code sufficiently modular will actually allow you to work more quickly, as you'll have fewer bugs, will be able to make large changes more easily, and will be able to reuse code.
Next you'll need to be able to create a GUI. Having just started in java, you'll most likely want to use Swing, which can very quickly give you something nice to look at. I think many Java IDEs now have Swing design tools that allow you to drag-n-drop components into your GUI.
Once you have a solid understanding of everything that you're going to have to use to build your TextTwist you should be able to plan it out. Draw some diagrams of your program, both how the classes fit together and how you want it to look (I use MS Paint and Dia). Make sure you know what you need before you start programming. Document everything you want the program and each class in it to do. This way if anything isn't going to work you'll know before you've written half your program and have to go back to fix it.
At this point, it should be a piece of cake! Get a dictionary library, pick a seven letter word, check every combination of its letters against the dictionary and store those. Provide some way for the user to make guesses (through your Swing GUI!), and a way to record them. Stick a timer in there, et voila! TextTwist.
There will be a lot of hard work in there, in and in between every step. But if you read as much as you can and keep asking questions (the more specific the better) it won't be so hard. The biggest obstacle when I started was getting discouraged when I bit off more than I could chew. Take small steps and the distance will fly by.
I find that a good place to start is just looking at existing code.
With that said, I have an Eclipse project that implements TextTwist (multiplayer) in Java that I put up on GitHub, if you're at all interested:
https://github.com/fangsterr/Multiplayer-Text-Twist
I've implemented simple GUIs that hopefully you can learn from. Hope this helps!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
After a break from coding in general, my way of thinking logically faded (as if it was there to begin with...). I'm no master programmer. Intermediate at best. I decided to see if i can write an algorithm to print out the fibonacci sequence in Java. I got really frustrated because it was something so simple, and used the debugger to see what was going on with my variables. solved it in less than a minute with the help of the debugger.
Is this cheating?
When I read code either from a book or someone else's, I now find that it takes me a little more time to understand. If the alghorithm is complex (to me) i end up writing notes as to whats going on in the loop. A primitive debugger if you will.
When you other programmers read code, do you also need to write things down as to whats the code doing? Or are you a genius and and just retain it?
No, it's not cheating.
I think that if your sense of programming "logic" has faded a bit, then the absolute, best, 100% way to refresh or even learn this is to watch code in the debugger.
This is such a cool idea that if I ever teach a beginning programming class again, I should have a computer right there running code in the debugger so that the students can watch what happens.
In answer to your second question, if I really had to worry about what the code was doing, then I'd start writing things down. However, if I'm looking at code by navigating around in Eclipse, then I rarely have to write things down because the history of where I just was is readily available. However, if that history were not written down by the computer, I would absolutely be furiously scribbling on a pad as I navigated around the code.
This was something i needed time to realize:
Understanding the code written by someone else is not voodoo magic, it's just practice.
It's not a matter of intelligence nor logic, truly this is a skill your develop while actually having to understand other's code.
I really began to understand this and increase this skill while i start working, as I needed to make changes in others' code.
Don't be afraid, the more code you'll read, the easier it'll be.
It's not "cheating" to use the debugger to find bugs or to observe your program behavior, but you have to be careful not to let it turn into a crutch. Too much reliance on the debugger can also lead to "programming by accident", which is also not very productive. Also, you really want to be able to conceptualize how something is supposed to work before you even observe in the debugger whether it works the way you think it should.
Programming is largely an abstract, mental activity. You have to work out in your head how something is going to work (the design), then you go and write the code (the implementation). The more you can work out in your head how something is going to work, the more productive you will be in the long run.
As others mentioned, there are many times when you can't use a debugger. I think in the long run you will be best served by writing your code so it is easier to understand its behavior.
Even the most experienced programmers lookup the debugger for answers and clarifications; or write plain old printf's to understand states; or write down things when they're reading/reviewing someone else's code.
I think you're learning any thing by looking at what happens under-the-hood is no cheating and in deed you'll have a clearer, more concrete understanding than just reading books and having it as an abstract idea.
So no, it isn't cheating at all.
Using a debugger and step by step execution is one of the best way to understand the internals of code, libraries, APIs,... and to learn. So it's definitely not cheating, it's learning, it's getting knowledge.
Most of the time the exercise is to get you to think about what might happen in the code, not what does happen on a particular run. So running through a couple of times with a debugger might help, but you still have to do the work to generalise from those specific runs. For algorithms, this often means thinking about how the paths grow with increasing input size. For concurrent programs, this means thinking about how the paths of different execution threads will interact with each other in your code. A debugger won't tell you these things, however many times you run it.
Stepping through with a debugger can only tell you what did happen in one trial; it won't train you to think about your program abstractly - it's one apple dropping from a tree, not the theory of gravity.
It's OK to use the debugger to try to figure out why something happened, especially in mysterious code, but it's better to try to predict what should happen first and then see if the debugger confirms your reasoning and intuition. In the future this will help you write test cases that catch unanticipated errors, and increasingly you'll write code that works from the start.
Absolutely not! That's the exact opposite of cheating! The best way learn what's happening is to get in there in the guts of things and watch it happen. Reading code out of a book can be eye-glazingly boring... but watching it execute in the debugger can be magic, especially if you are having problems with a particular section.
I NEVER release code I have written without having run it in a debugger and watched almost all of it.
I agree that you didn't cheat in the general sense. I can only see two cases where you could conceivably consider using a debugger as cheating:
you have set a bar for yourself where you want to complete the task at hand without any aid such as a debugger. Obviously if you use a debugger in this case you can consider it cheating.
you have been given instructions by your teacher or the proctor for an interview test not to use external tools.
Well, it's cheating if you're taking a midterm for a class, and there's a "programming" problem that requires you to analyze something on paper, without running it. But I always hated that kind of test, precisely because it didn't seem at all useful - it's nothing like actually programming. And heck, even there, you still probably would end up "run" it by writing down interim processing in your notes.
I do find that it's good not to over-rely on an actual debugger too much, because occasionally you have to rely on simpler methods of debugging (if, say, you're trying to debug a problem that can only be reproduced on a computer owned by a tester who doesn't want you fiddling about on her computer). But even there, you're still running code and seeing what happens (and possibly adding "debugging" message boxes or writing-text-to-disk functions). Trying to read any program much more complicated than "Hello World" without actually running it (even on paper) isn't avoiding cheating, it's masochism.
That said, it is true, you start having to do this less the more you've seen of a particular language / class of problem. But certainly, if there's ever a bug, even a bug in code you've seen similar versions of millions of times, the fastest and least painful way of finding it is always going to be running the code and seeing what it does.
I think there is extreme value in debuggers and they can be especially great as a learning tool. Sometimes you simply need them to diagnose a defect. However, I think bad programming habits can emerge if you continually rely on a debugger as you develop software.
The perfectly efficient software developer understands the abstractions that she works with -- the languages, frameworks, OSes -- well enough to be able to declare her problem to the system and know that it is correct. Of course this is an unrealistic ideal, but I think it is the right thing to strive for. If you find yourself frequently in a debugger, it means you don't understand your abstractions and this means you are going to move a lot slower when writing code. Even if you sort out that one issue with the help of the debugger, your ignorance is going to slow you down as you try to layer on capability and features.
Clearly you're in "learning" mode, so whatever gets you to that level of understanding depends on your learning style. If the debugger helps you get there, great. But if you're looking to be productive, it is a good goal to have a level of understanding where you can get code correct as you write it not when you run it.
Related to this question is Linus Torvalds' rant on debuggers, which I particularly like:
http://lwn.net/2000/0914/a/lt-debugger.php3