Scrambling jar files

[Purple]

I've been taking a step toward making my java programs a bit more closed source lately. And the only decent way to do that due to the nature of how the things are set up is to scramble or obscurify the contents. Now there are plenty of programs I can google up for this. But because there are plenty, I'd rather ask for advice here.

So, has anyone here worked with these things and can anyone recommend a good free one? It needs to work reasonably well and come with no strings attached.

[Ace Pace]

Don't. This is a good summary for .net. You may as well change the word .net for Java in your case.

If you want to just obfuscate, just realise that it barely slows serious people down. It may deter the amateur, but a complex enough code base does that by itself.

[Purple]

Don't. This is a good summary for .net. You may as well change the word .net for Java in your case.

If I could use .net I would, trust me. It just so happens that for some situations I do have to step away from the glory that is compiling .exe files which can't be easily opened to reveal the source code as if it was a text file. God I hate java.

If you want to just obfuscate, just realise that it barely slows serious people down. It may deter the amateur, but a complex enough code base does that by itself.

It's not really meant to deter anyone serious. I am not really writing any code that is valuable enough to warrant proper encryption. If I did I'd be using C++ and adding all sorts of actual protection to it. It is just meant to look fancy and professional for the guy I am presenting it to who happens to know very little about security and deter the casual semi-literate programer among the user base from trying to mess the code up and cheat at the gaming table (It's a dice roller with a RNG, so I don't want semi literal script kiddies to open it up and modify it to cheat).

[Starglider]

It just so happens that for some situations I do have to step away from the glory that is compiling .exe files which can't be easily opened to reveal the source code as if it was a text file. God I hate java.

The problem is not Java, the problem is that you are a marginally competent programmer apparently trying to con someone. .NET programs are trivially decompilable regardless of whether they are compiled into an .exe with dotPeek. Conversely, Java can be compiled to a proper .exe with C++ equivalent difficultly (and efficiency) using Excelsior JET. All purely client-side programs regardless of development language can still be hacked by a resonably competent person with a disassembler and passing familiarity with x86 ASM.

Anyway, ProGuard is the gold standard for Java obfuscation, but it is more useful for its jar size reduction and optimisation capabilities than simply stripping all the identifiers.

[Purple]

The problem is not Java, the problem is that you are a marginally competent programmer apparently trying to con someone.

I take offense to that. I am not trying to con anyone. I simply want to make a program that is not really worth much protection beyond deterring a very casual user. This is a freaking RNG dice roller for a D&D game for a bunch of friends I have, none of whom are particularly computer savvy but at least some of whom could reasonably be expected to try and use tools such as jd-gui to edit the code. Obscurify that and I would literally make it not worth their time to cheat at a gaming table. These are people who gave up on trying to mod minecraft because the de-obscurification utility provided on the wiki was too complicated for them.

This isn't some sort of commercial program for a massive banking company or something.

But I guess it's impossible for people here to actually answer a fucking question helpfully instead of making retarded and offensive assumptions!
FORGET I FUCKING ASKED!

[Purple]

LATE EDIT: Sorry for the meltdown. I have a very personal beef against situations where I ask a simple question and than people jump in to educate me on why the question was wrong assuming that I am an idiot who does not know better as opposed to answering me. Especially if it comes packed together with a rude affront toward my abilities. But I should not have allowed it to get the better of me this way.

Bottom line is that I know very well why and how these things are flawed. Which is the reason why up until now I have not had the need to use one. Which is the reason why up until now I have had no idea which one to use. Turns out they can be useful against the right crowd. Go figure.

[Starglider]

people jump in to educate me on why the question was wrong assuming that I am an idiot who does not know better as opposed to answering me

Java is a deceptively well engineered platform which gets a lot of underserved crap from people pretending to be computer experts, which annoys me.

Regardless of the technical issues, if you can't trust your 'friends' not to cheat, I don't know why you'd be gaming with them. If you insist on doing it anyway, use on of the approx. 16 billion existing dice rolling web sites or free programs. If you insist on writing it yourself, make it a web service (if playing online) or put it on your phone/tablet (only) and pass it around.

[Purple]

Java is a deceptively well engineered platform which gets a lot of underserved crap from people pretending to be computer experts, which annoys me.

Ah, you are that kind of guy. (A java person)
Basically I am one of the anti java crowd but not for the reasons you think. I just have a lot of experience working in C++ and C# and dislike some of the general decisions they took when designing Java. Like for example the lack of double inheritance, operator overloading (god I wish I had this one) and stuff like that. It's a good concept. I just feel that Microsoft did it better with .NET. Which is no surprise given that they had years of Java to look at and learn from.

Regardless of the technical issues, if you can't trust your 'friends' not to cheat, I don't know why you'd be gaming with them. If you insist on doing it anyway, use on of the approx. 16 billion existing dice rolling web sites or free programs.

What's the fun of a gaming group if there isn't a little bit of dice fudging? But we are getting off topic anyway. Story is dead anyway. I figured out something more fun to do with this thing...

[Starglider]

I just have a lot of experience working in C++ and C# and dislike some of the general decisions they took when designing Java.

Really, then why are you writing this program in Java? I regularly write high performance algorithmic trading code in C++ (unfortunately, hope to get back to OpenCL soon) and I still prefer doing it in Java.

Like for example the lack of double inheritance, operator overloading (god I wish I had this one) and stuff like that. It's a good concept. I just feel that Microsoft did it better with .NET.

Language convenience during initial developmet is only the most important thing if you are lone developer making small programs. For serious enterprise applications, the quality of the runtime and libraries and the robustness and maintainability of the application are far more important. I like C# for writing toy programs but the VM is nowhere near as good as Hotspot or Zing : the question of 'would you attempt to write an eTrading app in C#' comes up regularly in City of London pubs and the answer is a resounding 'no'. I do miss structs and interlocked for convenience when optimising, but operator overloading in particular inevitably results in unmaintainable messes.

[sarevok2]

You might wanna take a look at reverse engineering tools to understand hiding your code better.

Look up JD-GUI. http://jd.benow.ca/

It is a pretty good java decompiler. Gives you mostly readable source that you can use to reverse engineer algorithoms and with patience even recompile it back.

There is also various Byte code disassemblers and editors that let you directly edit the byte code in a jar, often useful for "cracking" java app and inserting your own code into an existing app.

For android look up Apktool. It disassembles apks into easy to understand Dalvik assembly code you can edit and recompile back into working APKs very quickly. Often used by modders who change their phones or hackers who remove copy protection. Dex2jar is another utility that converts APKs into a jar file which can then be read with JD-Gui. This gives you human readable java code for the Android app. It's pretty rough but you can understand the code behind most apps easily.

I am not an expert but from what I seen both java jar and androids APK obfuscution tools are a joke. Try it yourself, you can easily reverse engineer any app from a bigname company. I would not rely on obfuscation to hide my java code.

.NET is almost as bad. Games like Magicka which are written in C# are often decompiled by fans for modding purposes. The .NET reverse tools like .NET Reflector are highly polished and probably even more powerful and easier to use than java.

[Terralthra]

I just have a lot of experience working in C++ and C# and dislike some of the general decisions they took when designing Java.

Really, then why are you writing this program in Java? I regularly write high performance algorithmic trading code in C++ (unfortunately, hope to get back to OpenCL soon) and I still prefer doing it in Java.

Like for example the lack of double inheritance, operator overloading (god I wish I had this one) and stuff like that. It's a good concept. I just feel that Microsoft did it better with .NET.

Language convenience during initial developmet is only the most important thing if you are lone developer making small programs. For serious enterprise applications, the quality of the runtime and libraries and the robustness and maintainability of the application are far more important. I like C# for writing toy programs but the VM is nowhere near as good as Hotspot or Zing : the question of 'would you attempt to write an eTrading app in C#' comes up regularly in City of London pubs and the answer is a resounding 'no'. I do miss structs and interlocked for convenience when optimising, but operator overloading in particular inevitably results in unmaintainable messes.

Likewise, I've never seen a problem that could be "solved" by multiple inheritance that couldn't be more effectively solved by single inheritance and proper use of interface classes. In general, multiple inheritance is a massive headache and requires someone looking at your code to hold an inordinate amount of state in their head to understand what any small piece of it is doing. That's the exact opposite of what you want.

[Starglider]

Likewise, I've never seen a problem that could be "solved" by multiple inheritance that couldn't be more effectively solved by single inheritance and proper use of interface classes.

Trendy politically correct programmers all prefer composition over inheritence anyway : current 'best practice' is that subclassing should be rarely if ever used and it's an antipattern to ever implement more than two interfaces. I am neither trendy nor politically correct and wish those quiche eating blog darlings would go drown themselves in the Haskell forums instead of bothering the people doing real work, but even I have to admitt that explicit mix-in is the only sane way to do multiple inheritence (and even then most corporate programmers can't be trusted with it).

[Purple]

Really, then why are you writing this program in Java? I regularly write high performance algorithmic trading code in C++ (unfortunately, hope to get back to OpenCL soon) and I still prefer doing it in Java.

Because I want to. Basically, I dislike working in Java but it's a skill that's essential to have these days. So this is as good as time as any to get some practice. Especially since the actual code is rather trivial but the GUI is complex so it helps me practice the one part I was newer good at.

Language convenience during initial developmet is only the most important thing if you are lone developer making small programs. For serious enterprise applications, the quality of the runtime and libraries and the robustness and maintainability of the application are far more important.

I am not saying you are wrong but I disagree. Which of the two is a priority depends on what kind of program you are making. You seem to have a background in commercial applications, possibly for large clients. At least I deduced as much from your priorities. You value a system that is easy to maintain and robust so it won't crash or cause unexpected errors. And that is good if your software needs to work like that. But not every software does. Nor does every application value quality over speed of development.

Say you aren't making software for a bank but a video game. Suddenly making stuff work quickly and easily becomes a much higher priority than making it maintainable or crash free. Because you can expect people to pay for your stuff even if it's buggy as long as it's done in time for the next big sales season.

I like C# for writing toy programs but the VM is nowhere near as good as Hotspot or Zing : the question of 'would you attempt to write an eTrading app in C#' comes up regularly in City of London pubs and the answer is a resounding 'no'.

That goes for anything with a VM, C#, Java or what ever else might exist that I have not heard off. VM's are just inherently slower and less stable than native code. But people do still write a lot of code for them for a reason. And that reason is that not every piece of software is meant to be a super secure bank account application. Some times you just want to write a minecraft.

but operator overloading in particular inevitably results in unmaintainable messes.

Honestly I feel that you are both right and wrong here. Operator overloading is not inherently bad. And I shall now demonstrate it.
How is my_object_1 += my_object_2 any less readable or maintainable than my_object_1.add(my_object_2)?
It isn't. Not in the slightest.


The real problem is people who would use either of those for applications where they does not belong. If your class is not a structure that can be reasonably seen as a mathematical variable you have no place using either and should instead use separate modification functions for each of its variables. But you can't cure stupid by taking away our tools. You can't even make it harder for them to be stupid.

On the other hand if you are working on mathematical problems such as computing geometry than it makes sense to have access to mathematical operators. And if you do not, than having to write functions for every single one of those (Add(), Subtract(), Multipy()...) becomes tedious at best and copy paste work at worst.

Take for example a project I was working on in my free time last year. I was working on (still am but paused due to other stuff to do) a sprite based graphics engine. Just fooling around to see how far I could take it. And part of that was a class for handling angle conversions. I have this class prosaically called Angle which contains the angle value and encapsulates a whole bunch of various calculation methods both standard mathematical (Sin, Cos, conversions etc.) and based on my own specific needs (like direction in my coordinate system). And for that class it made perfect sense to have the entire range of mathematical operators. After all, I was constantly handling those angles and calculating everything through them. So why should I write something like Angle_1.add(Angle_2) when i can write Angle_1 += Angle_2? It's just stupid.


The point of this? Tools are not inherently bad. Stupid people are bad. And the logic of tying our hands and taking away our tools because of the stupid programers out there is at best annoying and at worst harmful because we are distracting everyone from the real problem which is bad programers.

Likewise, I've never seen a problem that could be "solved" by multiple inheritance that couldn't be more effectively solved by single inheritance and proper use of interface classes. In general, multiple inheritance is a massive headache and requires someone looking at your code to hold an inordinate amount of state in their head to understand what any small piece of it is doing. That's the exact opposite of what you want.

I actually have run into situations where multiple inheritance would have been useful in the same project I mentioned above. It was not a strait up case of it being necessary but it would have saved me a lot of duplicating code.

Basically, imagine a situation where you want to separate out a certain functionality (like say collision or movement) into its own class because you know said functionality will only have a single implementation ever and more importmantly because you have some external system to keep track of everything and run the place (like my main timer). So you have one class which is for movement and one for collision damage. Now say you want to have three objects on the screen. A space fighter, a projectile and a wall.

The space fighter only inherits from the movement class. Since it is not a ramming weapon and does no damage on collision.
The wall only inherits the collision damage class because it's a fixed projectile that stands in your way and hurts you if you touch it.
But the projectile needs to inherit both. It needs to move and do damage when it hits something.

In my case, the issue was massively more complicated but it boiled down to this. Now you can do it through interfaces and resign your self to having copy paste duplicate code implementing the same thing in every inherited class. You can also do it by having a single joined class and than hacking it so that the fighter does 0 damage and wall has 0 movement. Or you can start from scratch.


But the question is not what you can but what you should be allowed to do. And there is no logical reason why I should not be allowed to do something that is useful just so as to protect me from misusing it. By that logic we might as well ban automobiles because, as useful as they are people abuse them to street race.

[Steel]

Your multiple inheritance example with the fighters is like the canonical example of when to favour composition over inheritance.

You don't make everything a collision object, you GIVE them all collision objects. The colliding ones have a normal one, the non colliding another that never collides. This is vastly more flexible and extensible- you can even easily modify behaviour at run time just by swapping components.

Have a read up on composition vs inheritance. There are loads of dickheads blogging about it.

[Starglider]

That goes for anything with a VM, C#, Java or what ever else might exist that I have not heard off. VM's are just inherently slower and less stable than native code.

The number one reason anyone uses VMs on the server side is that managed code is more stable than direct pointers; largely due to the garbage collection, where fully correct compacting GC (rather than conservative non-compacting) is only practical to implement with a VM. You are wrong on the performance point as well - VMs can often be as fast and sometimes actually faster due to dynamic optimisation - but that's an actual subtle debate, your first comment is an utterly ignorant non-sequitur.

Your multiple inheritance example with the fighters is like the canonical example of when to favour composition over inheritance. You don't make everything a collision object, you GIVE them all collision objects. The colliding ones have a normal one, the non colliding another that never collides. This is vastly more flexible and extensible- you can even easily modify behaviour at run time just by swapping components.

That's a completely valid response, but I'd note that while this approach is certainly neater and more maintainable than multiple inheritence, it does use a little more memory and suffers from the same basic performance problems as the original; virtual function call overhead, stack thrash and poor memory locality. For a simple game that isn't pushing the hardware that's fine. 3D games that do serious physics use either an old-skool data driven approach (have several passes each walking the whole scene graph, process tagged objects in batches to implement behaviours) or a modern refactoring of the same batching paradigm (e.g. registration with event processors implementing behaviours, maintain and batch-process live object sets).

Even there more specialist behavior like AI would still be implemented compositionally, or maybe mix-ins if optimising for memory use. There's another advantage you didn't mention; the old-skool multiple inheritence approach (or even mix-ins if you're talking about the engine classes rather than scripting) is pretty much incompatible with dynamic, runtime editors or in fact letting anyone design game content without being forced to hack the engine code and do a full rebuild. The compositional approach is very amenable to run-time customisation. This is moderately useful for indie devs but very relevant for dev studios.

[Steel]

That's a completely valid response, but I'd note that while this approach is certainly neater and more maintainable than multiple inheritence, it does use a little more memory and suffers from the same basic performance problems as the original; virtual function call overhead, stack thrash and poor memory locality. For a simple game that isn't pushing the hardware that's fine. 3D games that do serious physics use either an old-skool data driven approach (have several passes each walking the whole scene graph, process tagged objects in batches to implement behaviours) or a modern refactoring of the same batching paradigm (e.g. registration with event processors implementing behaviours, maintain and batch-process live object sets).

Yes, you'll always be paying a bit more for virtual function calls but it doesn't have to be so bad for the allocation. If you're allocating components in isolation then they'll be shotgunned all over the place, but if you maintain a structure that holds all the e.g. collision objects which are allocated contiguously within that then you're effectively at the same stage as the tag and process paradigms.

The total freedom of structuring the objects and dynamically whacking things together is always going to come at some cost compared to one static architecture.

There's another advantage you didn't mention; the old-skool multiple inheritence approach (or even mix-ins if you're talking about the engine classes rather than scripting) is pretty much incompatible with dynamic, runtime editors or in fact letting anyone design game content without being forced to hack the engine code and do a full rebuild. The compositional approach is very amenable to run-time customisation. This is moderately useful for indie devs but very relevant for dev studios.

That's what I meant to refer to with:

you can even easily modify behaviour at run time just by swapping components.

although yes, creating components from scripting on the fly rather than just using swapping a pre-built library of parts isn't actually conveyed in that.

[Starglider]

If you're allocating components in isolation then they'll be shotgunned all over the place, but if you maintain a structure that holds all the e.g. collision objects which are allocated contiguously within that then you're effectively at the same stage as the tag and process paradigms.

You found a genuinely useful application for factory pattern in gaming, well done

That's what I meant to refer to with:

you can even easily modify behaviour at run time just by swapping components.

Sorry, reading comprehension fail.

[Steel]

If you're allocating components in isolation then they'll be shotgunned all over the place, but if you maintain a structure that holds all the e.g. collision objects which are allocated contiguously within that then you're effectively at the same stage as the tag and process paradigms.

You found a genuinely useful application for factory pattern in gaming, well done

Hooray! I could have been at the cutting edge of game design in ... 2003!

That's what I meant to refer to with:

you can even easily modify behaviour at run time just by swapping components.

Sorry, reading comprehension fail.

Well, I think the ability to entirely design components from external script at run time is actually a massively significant feature that wasn't explicit in my original post, so lets say you were expanding on that.

It does actually seem that a lot of indie games are building some kind of a base engine and then putting most of the actual game logic in external lua, which is sort of coming full circle.