Original Post
I heard that you can actually look into applets sources.. So you can modify it and so on? http://members.fortunecity.com/neshkov/dj.html this is the program I heard about..
🔒 Locked
[java] Isnt java insecure?
Advertisement
Just because you can apply reverse engineering on a code it doesn't mean the whole language is insecure... If it were for that, nothing would be secure nowadays.
There are plenty of other aspects involved in verifying security.. for applets, you have to sign them, and the user must accept the certificate you issue with it. Also, you do not leave sensitive code "exposed" - be exposed I mean several bad practices -, or else you're a dumb programmer.
Son Of Cain
There are plenty of other aspects involved in verifying security.. for applets, you have to sign them, and the user must accept the certificate you issue with it. Also, you do not leave sensitive code "exposed" - be exposed I mean several bad practices -, or else you're a dumb programmer.
Son Of Cain
Now I haven't dug into Java byte-code, so I am not one hundred percent sure, but unless the byte-code is littered with structure commands, I doubt that program's output will closely resemble the original source files.
I attempted to implement a simple dissassembler a while ago (for C), to examine my program optimisation, and it was a real mess, extremetly hard to get anything but basic logic back out.
As I said, I don't know how Java byte-code is, but in assembler you lose all variable names, etc. and any piece of assembly code could have been compiled from any one of several code snippets.
That is not to say that someone couldn't use such a tool to hack your games, but it isn't as easy as it might sound.
I attempted to implement a simple dissassembler a while ago (for C), to examine my program optimisation, and it was a real mess, extremetly hard to get anything but basic logic back out.
As I said, I don't know how Java byte-code is, but in assembler you lose all variable names, etc. and any piece of assembly code could have been compiled from any one of several code snippets.
That is not to say that someone couldn't use such a tool to hack your games, but it isn't as easy as it might sound.
At least he is not saying java is slow....
Actually, this is a pretty good decompiler. I tried it on my warp of file output. This is the result:
Original code:
Decompiled code:
The only changes I noticed are changes to variable names in functions parameters and bodies, and using the append function of a string instead of the operator +. The class variables kept their names, so I guess it is still easy to learn the code from there.
Well, java is meant to be an open source language anyways.
I guess this is the price we have to pay for dynamic class loading. I am willing to pay that price.
If you want to secure your java programs, use JSmooth.
Actually, this is a pretty good decompiler. I tried it on my warp of file output. This is the result:
Original code:
package someboddy.io;import java.io.*;public class OutputFile{ BufferedWriter buffer; public OutputFile(String fileName,boolean append) throws RuntimeException { try { File f=new File(fileName); f.createNewFile(); buffer=new BufferedWriter(new FileWriter(f,append)); } catch(Exception e) { throw new RuntimeException("Error while loading file '"+fileName+"'",e); } } public OutputFile(String fileName) { this(fileName,false); } public void write(String str) throws RuntimeException { try { buffer.write(str); } catch(Exception e) { throw new RuntimeException("Error while writing to file",e); } } public void write(Object o) { write(o.toString()); } public void newLine() throws RuntimeException { try { buffer.newLine(); } catch(Exception e) { throw new RuntimeException("Error while writing to file",e); } } public void close() throws RuntimeException { try { buffer.close(); } catch(Exception e) { throw new RuntimeException("Error while closing file",e); } } protected void finalize() throws Throwable { buffer.close(); }}Decompiled code:
// Decompiled by DJ v3.9.9.91 Copyright 2005 Atanas Neshkov Date: 14/02/2006 19:09:56// Home Page : http://members.fortunecity.com/neshkov/dj.html - Check often for new version!// Decompiler options: packimports(3) // Source File Name: OutputFile.javapackage someboddy.io;import java.io.*;public class OutputFile{ public OutputFile(String s, boolean flag) throws RuntimeException { try { File file = new File(s); file.createNewFile(); buffer = new BufferedWriter(new FileWriter(file, flag)); } catch(Exception exception) { throw new RuntimeException((new StringBuilder()).append("Error while loading file '").append(s).append("'").toString(), exception); } } public OutputFile(String s) { this(s, false); } public void write(String s) throws RuntimeException { try { buffer.write(s); } catch(Exception exception) { throw new RuntimeException("Error while writing to file", exception); } } public void write(Object obj) { write(obj.toString()); } public void newLine() throws RuntimeException { try { buffer.newLine(); } catch(Exception exception) { throw new RuntimeException("Error while writing to file", exception); } } public void close() throws RuntimeException { try { buffer.close(); } catch(Exception exception) { throw new RuntimeException("Error while closing file", exception); } } protected void finalize() throws Throwable { buffer.close(); } BufferedWriter buffer;}The only changes I noticed are changes to variable names in functions parameters and bodies, and using the append function of a string instead of the operator +. The class variables kept their names, so I guess it is still easy to learn the code from there.
Well, java is meant to be an open source language anyways.
I guess this is the price we have to pay for dynamic class loading. I am willing to pay that price.
If you want to secure your java programs, use JSmooth.
Thats a pretty nice decompilation, I guess it is a lot easier with Java.
I am going to have to try this at home to see if it decompiles my sample networking encryption algorythms (bad news for comertial Java game dev if it does).
I don't think it would really be that hard to convert a JSmooth'ed .exe back to a .jar, but I haven't tried (The Mac OS X 'JarBundler' just hides the .jar itself within the executable, I would imagine JSmooth is similar).
I am going to have to try this at home to see if it decompiles my sample networking encryption algorythms (bad news for comertial Java game dev if it does).
I don't think it would really be that hard to convert a JSmooth'ed .exe back to a .jar, but I haven't tried (The Mac OS X 'JarBundler' just hides the .jar itself within the executable, I would imagine JSmooth is similar).
Quote:
Original post by eedok
this has been around a long time, it was used to make macros for runescape in the gamehacking scene way back in the day.
I don't see how it makes the language any less secure though.
Actually it was used badly.. As they made their whole OWN client for it with java.. So it had features that could automate the things.. So it was bad that time.. I can still remember when I set one of the bots for my friend (my noob friend who cant even english) so I needed to set up it for him... And actually it was like the bot makers runescape.. The menus changed everything almost..
Well, you can always scramble your bytecodes to prevent reverse-engineering them. I've heard of one program that changes all your method names into numbers or random characters, say printLine() might be 1343343(). Even though this does not prevent a decompilation of the class files, it should be enough to irritate you and drive you into doing something else instead of trying to understand the code...lol
Quote:
Original post by steeg
Well, you can always scramble your bytecodes to prevent reverse-engineering them. I've heard of one program that changes all your method names into numbers or random characters, say printLine() might be 1343343(). Even though this does not prevent a decompilation of the class files, it should be enough to irritate you and drive you into doing something else instead of trying to understand the code...lol
I think it can be decrypted anyway as I think it uses hes own encryption on them.. And because he must also decrypt them to use them... And btw where does all the java applets store their files? I want to delete them as they take space :(
I think you might be looking for this:
http://proguard.sourceforge.net/
Try putting the class files ProGuard generates through DJ. It won't work, and be next to unreadable if it works. It obfuscates the code to make it very hard to reverse engineer.
http://proguard.sourceforge.net/
Try putting the class files ProGuard generates through DJ. It won't work, and be next to unreadable if it works. It obfuscates the code to make it very hard to reverse engineer.
Being able to be decompiled doesn't make it "insecure".
Your security should not rely on your object code being obfuscated. Instead, you should write code that is actually secure!
Of course languages like Java and C# lend themselves very nicely to decompiling, as they're only compiled into bytecode in the first place.
In Java, even the names of locals and privates are stored in the class files.
Of course an obfuscator like Proguard will make it a lot more difficult to decompile your classes (or indeed, read the output). In most cases, decompiling Proguard-obfuscated code generates highly illegible source, that can't then be recompiled without modification (as Proguard breaks some rules for source, but are ok in class files, like overloading and such like).
But even using Proguard doesn't defend against someone figuring out how your app works or modifying it. The same is true of (for example) C++.
Mark
Your security should not rely on your object code being obfuscated. Instead, you should write code that is actually secure!
Of course languages like Java and C# lend themselves very nicely to decompiling, as they're only compiled into bytecode in the first place.
In Java, even the names of locals and privates are stored in the class files.
Of course an obfuscator like Proguard will make it a lot more difficult to decompile your classes (or indeed, read the output). In most cases, decompiling Proguard-obfuscated code generates highly illegible source, that can't then be recompiled without modification (as Proguard breaks some rules for source, but are ok in class files, like overloading and such like).
But even using Proguard doesn't defend against someone figuring out how your app works or modifying it. The same is true of (for example) C++.
Mark
Above is me. oops!
When people say that Java is more secure they mean that the language makes it harder for programmers to make simple errors that can become security holes (like buffer overruns) and that the fact that the code is verified by the JVM before it is run means that many malicious programs can be caught at this stage. And having managed memory is another big plus when it comes to security.
But usually it is a lot easier to decompile Java code than other languages (which is probably true for any language that has built-in support for reflection).
shmoove
But usually it is a lot easier to decompile Java code than other languages (which is probably true for any language that has built-in support for reflection).
shmoove
Notably, decompiled java code is often "cleaner" than the original source code :) There are even some good decompilers that don't turn loops into ugly goto-costructs.
There are obfuscators like Proguard, JODE and Retroguard for people who have their heads up their asses and think their binaries are "secret" and should never be decompiled.
Copyright already protects all your work. In some countries (e.g. Germany), it's legal to fix one's installed software if necessary. Don't take that away from the people by unnecessarily obfuscating the code.
Also, obfuscation has some side-effects, such as reflection not working any more, and stack traces become a true bitch to interpret. Let alone classes you lost the source code for.
The only rightful advantage is in Mobile Java, where it can squeeze out a few additional kilobytes in large projects [mostly by removing unused code, though].
There are obfuscators like Proguard, JODE and Retroguard for people who have their heads up their asses and think their binaries are "secret" and should never be decompiled.
Copyright already protects all your work. In some countries (e.g. Germany), it's legal to fix one's installed software if necessary. Don't take that away from the people by unnecessarily obfuscating the code.
Also, obfuscation has some side-effects, such as reflection not working any more, and stack traces become a true bitch to interpret. Let alone classes you lost the source code for.
The only rightful advantage is in Mobile Java, where it can squeeze out a few additional kilobytes in large projects [mostly by removing unused code, though].
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement