Request Jar Protection

[AccessDenied]

Hello, lets say i made a nice code and i build server (l2jserver.jar)

and i gave it to someone for test before he buy it...

 

Is there any way to protect the jar from decompile-reverse? We all know that extract source

from jar is like open facebook.. so easy..

 

any chance?

[`NeverMore]

Unfortunately due to the write once run anywhere nature of java, it is fairly easy to decompile. You can use things like native class loaders and stuff, but those are still fairly simple to circumvent and dump the class files.

A deobfuscator just jumbles up the byte code and metadata a bit, with enough time on your hands you could still revert obfuscated code to readable java source code.

The best solution to protect your code is simply to not let the user gain access to it, now this depends what you are doing, maybe running a server and having clients connect to it could be an option. 

[Elfo]

The only way to protect your software is to run it as a service (SaaS).

However i highly doubt we will ever see that in l2j so, just make your code really hard  to read. That won't help from an experienced guy taking your code, 

but the crappy leechers will straggle.

[AccessDenied]

No matter how hard or fake classes ill use to lead you in wrong way still someone with experience can find it..

and is not only the test lets say you sell some files you have to give the l2jserver.jar  so the other can easily decrypt it unfortunately.. but oh well

seem a - java has compare to c and c++

[xxdem]

Just deal with the fact that you can't hide your shitcodes if you give the Jar

[Elfo]

No matter how hard or fake classes ill use to lead you in wrong way still someone with experience can find it..

and is not only the test lets say you sell some files you have to give the l2jserver.jar  so the other can easily decrypt it unfortunately.. but oh well

seem a - java has compare to c and c++

It's a little price to pay for the fact that it runs everywhere.

[Tryskell]

No offense, but I doubt the time used to try to de-obfuscate your custom worths the price of the custom. So a obfuscator solution is fine, if you can't setup a live server and make the guy tests directly on the server, without him getting access to the server files.

 

yGuard, ProGuard, etc.

[MrPro*]

No offense, but I doubt the time used to try to de-obfuscate your custom worths the price of the custom. 

[Rootware]

Launch4j. Check this out. This better solution for hidding source code.

[AccessDenied]

Well thanks anyone, it was just a question i had after i saw how easily i can decrypt jar

 

ps xxdem shit code or no if the code is like 20.000 lines is waste...

[*real*savormix]

No offense, but I doubt the time used to try to de-obfuscate your custom worths the price of the custom. So a obfuscator solution is fine, if you can't setup a live server and make the guy tests directly on the server, without him getting access to the server files.

 

yGuard, ProGuard, etc.

Have to agree here. But there are already automated name re-generators, which change the fact that in the same expression, 'a' can be both field, local param and method. After applying such a regenerator (0 minutes time investment) most of the job done by the obfuscator (shrinker) is successfully reversed. You can thus only defend by writing extremely sub-optimal, illogical code -> which means the offered code will really suck in all possible ways after this.

 

Launch4j. Check this out. This better solution for hidding source code.

Terrible solution, even at what it does (making standalone apps with an embedded JRE). Haven't you heard about Excelsior.JET?

 

seem a - java has compare to c and c++

True, when dealing with C/C++, you will not instantly get the full source, compared to decompiling C#/Java. But have you never heard about IDA & HexRays? After finding a few key points and dissecting central structures/classes, you can easily reconstruct the whole logic, even when dealing with heavily-templated C++ x64 code.

 

 

 

Now, on topic: I suggest to use the VM approach, which has been successfully applied to asm code (so protecting C/C++ - yes, they badly need protection, just like Java/C#) and now even to C#. It makes the reverse engineering costs way higher than anything you are charging. Just make sure to implement the whole logic yourself, or at least check that there isn't any openly accessible unpacker (custom instruction/program flow back to real class bytecode converter).

Edited December 26, 2015 by _dev_

[AccessDenied]

Most of you lost the point. I dont speak for Preview server.. afcourse when a client ask you u dont give him the files u preview via teamviewer or open a live server

but we speak for the kids that take your jar decrypt it and share codes.. but most of you also said it cannot happen (protection) soo..

[Rootware]

Have to agree here. But there are already automated name re-generators, which change the fact that in the same expression, 'a' can be both field, local param and method. After applying such a regenerator (0 minutes time investment) most of the job done by the obfuscator (shrinker) is successfully reversed. You can thus only defend by writing extremely sub-optimal, illogical code -> which means the offered code will really suck in all possible ways after this.

 

 

Terrible solution, even at what it does (making standalone apps with an embedded JRE). Haven't you heard about Excelsior.JET?

 

 

True, when dealing with C/C++, you will not instantly get the full source, compared to decompiling C#/Java. But have you never heard about IDA & HexRays? After finding a few key points and dissecting central structures/classes, you can easily reconstruct the whole logic, even when dealing with heavily-templated C++ x64 code.

 

 

 

Now, on topic: I suggest to use the VM approach, which has been successfully applied to asm code (so protecting C/C++ - yes, they badly need protection, just like Java/C#) and now even to C#. It makes the reverse engineering costs way higher than anything you are charging. Just make sure to implement the whole logic yourself, or at least check that there isn't any openly accessible unpacker (custom instruction/program flow back to real class bytecode converter).

 

It's a biggest pleasure.  :happyforever:

 

http://www.excelsiorjet.com/buy