You can’t decompile a C++ DLL, it’s currently not possible to do that as C++ removes most of the metadata during compilation. C++ is a lot harder to hack than Java, as for example in Java, the following code:
int i = 5;
will become
bpush 5
istore 1
while in C++ the following code would be similar to
push 5
mov [ebx+8], edx
mov eax, [esi+10h]
As I never experience with javabyte code but having years of ASM coding the ASM one if far more readable ( nb : the result you post is unrelated to the provided C code… depending on the context it will be more something like mov [edi+n],1 on only one line)
Have to disagree with this specific point. I’ve tried cracking a native app for fun and it was not easy. I’ve decompiled many unobfuscated Java apps and it was very easy. Sure, obfuscation would make it more painful, but I could make my way through it eventually, whereas with the native app I hit a brick wall very quickly and couldn’t make any further progress.
If Program can be run Then you may gain access to shi code (Like OS do),any os any language
The only thing you can do is win some time .
That’s hard, that’s sometimes painfully but its possible.
@Nate: This problem is much easier than cracking a protection scheme as the entire protection mechanism can be completely skipped. It’s closer to attempting to hide texture and/or model data. The only way to do client side java (or any dynamic language) “hard” is to use and distribute a custom VM.
Cracking native stuff is tons harder than cracking Java stuff… if you don’t know how to do it. But looking at the vast array of torrents and cracks for torrents available it would appear there are easily enough of these people that you could reliably say that it’s a complete waste of time.
We released the full source code to our already very weakly protected game, and it’s still selling the same.
Cas 
This basically converts a standard JVM to a custom JVM during runtime via memory patching
Not really (see previous comments on outstanding issues). Also the patching solution is far harder (work wise) for you than a custom VM. Really the majority of the “hardness” of your currently proposed system is the native classloader. For the subset of people that are able to break that part, about 99% of them can get around the rest with little to no additional difficultly.
If you want to play with native patching I’d suggest removing “trapolines” chains from something like OpenGL.
no “this is not easy” but with the habit it becomes easier and it is the same process (also maybe you do not spent as many time in programming in assembler than you do in java).
I used to do that years ago when crack was not that easy to found (nowadays it is pretty useless to hack any soft because it took less time to find&download a crack on internet), my prefered tools use to be w32dasm, most of the time hafter running the soft in debugging mode, one simply had to change a single byte to build a patch (for example replacing a JNE by a JE or vice-versa) even for a cupple of well know software.
but as already explained in this thread : after all it doesn’t matter how hard it is or not to hack the dll you cannot rely on security based on the fact that the decompiled program will be harder to read (ASM vs Java). you can also add as many layer as polymorphic code you want, the energy the hack will requiere will not be proportional to the energy you will have spent to add this extra security layer.
here OP choose to make it classloader in native code, but the extra time/energy he have spent to do that (not to mention problem of compatibility), is a lot more than what he add in term of security