Reverse compiling

Mojo and Ren, the compiny you are working for is developing a commercial application in java. What are they doing to prevent reverse compiling? I always wondered how one could release closed source programs in java with the ease it can be reversed compled.



Don't get me wrong I am a big fan of java, I am just wondering how cooperations get around this problem.

or you can use tools like exe4j which create a native executable out from a jar file.

or if you can afford it use a native java compiler like excelsior jet.

Also JSmooth and Launch4j :wink: Both are open source. The latter seems to have as many features as exe4j, and is not trialware.



But the best method is to include a 'hello.jpg' file on your jar, so no one will dare to take a look inside  :stuck_out_tongue:

I've considered doing native exe distributions of my applications in the past but avoided it because it would require a lot more headache to do updates.  Most of my applications have the ability to update themselves and simply downloaded updated JARs and having a native exe no longer gives that separation between aspects of the code.



Code obfuscation is a must though if you are doing any commercial application development in Java.



darkfrog

The solutions mentioned here, such as JSmooth, Launch4j and exe4j do not do any actual compilation (they just merge the VM and class files into an exe or create a wrapper for launching the VM). You can still extract the bytecode. The only solution I know of where you can't do this easily is GCJ, the GNU Java compiler, which is still rather incomplete.



RetroGuard and Proguard make decompiled code a lot harder to read, but don't overestimate this either. With refactoring, runtime analysing and other tools (call back hierachies and such) you can make decompiled code workable again in a lot less time than it would take to write it. Escp. if you do not include LWJGL and jME in the obfusication (LWJGL would require some setting up to get it to obfusicate correctly). However, I'd still recommend this since it tends to speed up your programs some (though a lot less with modern VMs) and it can make your distribution size a lot smaller.



The point, I think, we're missing here… is that while it might be possible to steal code a little easier than in other languages, who will steal code from NCSoft and then what will they do with it?



Would they be worried about hackers for their games? This would only matter for networked games, history has shown by now that hackers get by just fine without the source.



Competing companies stealing their code and putting it in their games? I'm sure that would bring a smile to the NCSoft legal department… if it's easy for you to extract my code, it's easy for me to extract yours and see what you took. But even if you manage to obfusicate the code or hide it some clever way I didn't think of, such things are still easy to find. Just look at how many open source projects find out about their code being used by companies, without having any acces to the sources those companies used to compile their product. I don't think any company competing with NCSoft would take such an insane risk, of having to recall their product and pay damages to NCSoft over some Java code.



Tradesecrets then? Like clever new 3D stuff and fancy algorithms? I don't think there's anything you could hide using C/C++, there's many advanced tools for debugging such programs, and things like tracing OpenGL or D3D calls are even easier.

here here! :-p



Excelsior is another one that actually creates natives from your Java code, but again I don't recommend that idea.



darkfrog

Try coding to confuse te decoders



Suppose I have an Object Mushroom, I rename that to FunkyOctopus. That way after decompiling they wont understand why they have got hats in the sea nor octopi on their heads.



Time for some octopus tea  :stuck_out_tongue:

kidneybean said:

Try coding to confuse te decoders

Suppose I have an Object Mushroom, I rename that to FunkyOctopus. That way after decompiling they wont understand why they have got hats in the sea nor octopi on their heads.

Time for some octopus tea  :P


As llama said, refactoring can make this tactic useless.

…besides, that's exactly what obfuscation does, but does a better job.  It's really hard to read variable and method names that are just "a, b, c, d, e…".



darkfrog

Most good obfuscators will go well beyond variable/method/class renaming and actually take the arguments of if/while/for/etc. statements and convert them into complex method calls, rewire loops, and add some kind of tags that decompilers such as DJ have issues turning into compilable code.

renanse said:

Most good obfuscators will go well beyond variable/method/class renaming and actually take the arguments of if/while/for/etc. statements and convert them into complex method calls, rewire loops, and add some kind of tags that decompilers such as DJ have issues turning into compilable code.


Wont that slow down the program?

No, because that is simply an issue for compilation.



darkfrog

the program will go even faster. shortest method and variable names  even better callling of loops etc that are not used just for code readability.

kman said:

the program will go even faster. shortest method and variable names  even better callling of loops etc that are not used just for code readability.


I meant rewriting the statements to make them more complicated.

lol



Try coding to confuse te decoders

Suppose I have an Object Mushroom, I rename that to FunkyOctopus. That way after decompiling they wont understand why they have got hats in the sea nor octopi on their heads.

Time for some octopus tea 


The point being that hackers will expect something obscure like the class to be called A and not Hat

If you are obsessed in hacking prevention, and it is an online playable game only, then to the detriment of bandwidth, certain classes could be downloaded on log on. These of course would have to change frequently. On top of which, the server would keep a register of unsual requests ( sounds complex but reasonable once you know what youre software does ), that way the problem clients could be isolated.  Now its imagination time - how to beat the hackers, either overwrite classes or refuse to work until the server is happy the client is updated - of course, this can be hacked so you need to keep changing the detection logic.


kidneybean said:

The point being that hackers will expect something obscure like the class to be called A and not Hat

If you are obsessed in hacking prevention, and it is an online playable game only, then to the detriment of bandwidth, certain classes could be downloaded on log on. These of course would have to change frequently. On top of which, the server would keep a register of unsual requests ( sounds complex but reasonable once you know what youre software does ), that way the problem clients could be isolated.  Now its imagination time - how to beat the hackers, either overwrite classes or refuse to work until the server is happy the client is updated - of course, this can be hacked so you need to keep changing the detection logic.


You can also put all controll of what is happening in the server making cheating virtually impossible, but that may slow down many games.

Slow down to humungous proportions if many players are waiting to join a single match.





The server can be aware to record in appropiate instructions - eg if the player is supposed to be in a wardrobe, and the server gets a request to cut down a rain forest - you know something is wrong



So, do you log off youre player ( after 3 strikes ) and update his jars or what ???

Do what I do…write such crappy stuff you can't even give it away…then you have nothing to worry about. :wink:



darkfrog

You can use a DLL trough JNI. Put sensitive information, authentication, encryption there. It is harder to decompile it, and you can update it from time to time as you do with a JAR file.

darkfrog said:

Do what I do....write such crappy stuff you can't even give it away....then you have nothing to worry about. ;)

darkfrog


I would not call your work "crappy". Some if it is very good.