Decrypt Jar(JAVA Encryption, the impossible)

[TheLordOfChaos201]

Hello

I recently found a way to encrypt java programs using a program that converts jar files into exe.
It claims it encrypts java files, but the thing is java can not run encrypted files.
*Meaning it can't possible be encrypting your jar file!*
In windows renaming the jar(now exe) into a zip file allows you to open it and see your code, but with the converter it damages the achieve and thus protects your programs from being read/hacked
*This in actual fact is how it protects your programs!*
I later found out that I could open the program perfectly in Linus, meaning my code is exposed to theft(I fixed that but if it happened once it surly will happen again)

My question is, can you guys open/decrypt this file?
Have you heard about ways of encrypting jar files and or hacking protected codes?

I will know if you guys succeeded hacking/decrypting the jar file if you can tell me my computers name

Thank you for helping

Attached file
http://www.hiveworkshop.com/pastebin/06041a9abc954210508cb6a99739b00a6203/

Just for the fun of it I made a brainwashing program for anyone of you having trouble solving my problem, it is a program that has a 18% chance of making you more optimistic whether you like it or not MWAHAHAHAHA(Tested in Poland)

 

[Dr Super Good]

What you are asking makes no sense. If code is encrypted and the key is publicly known then you might as well not encrypt the code. If code is encrypted and the key is not publically known then how can the code be executed? Sure it is completely secure, but completely unusable!

The program encrypts the archive and stores the key with it inside. When the resulting executable is run, it extracts and decrypts the jar file from inside the executable file and then orders its execution. Basically a self-extracting and running archive.

Have you heard about ways of encrypting jar files and or hacking protected codes?

A custom class loader could be made to load code from non ".class" files. A file format could be created which encapsulates the content of .class files in an encrypted way. The decryption keys could be kept secure, possibly managed with authentication servers. The custom class loader needed to load these code files could be kept private, or if made public it could rely on official authentication servers which prevent unauthorized use. Without the custom loader in a functional state the code is completely secure and utterly useless. Of course when a user has the custom loader and it is in a functional state then nothing stops them from reading/reverse engineering the code.

The reality is no code is ever secure if its intended to be executed publically. People could literally put a debugger on the JVM and see the resulting assembly. The only way to keep code secure is not give it to people to execute, and instead execute it on secure systems.

 

[GhostWolf]

It's called copyrights.

 

[TheLordOfChaos201]

What you are asking makes no sense. If code is encrypted and the key is publicly known then you might as well not encrypt the code. If code is encrypted and the key is not publically known then how can the code be executed? Sure it is completely secure, but completely unusable!

The program encrypts the archive and stores the key with it inside. When the resulting executable is run, it extracts and decrypts the jar file from inside the executable file and then orders its execution. Basically a self-extracting and running archive.


A custom class loader could be made to load code from non ".class" files. A file format could be created which encapsulates the content of .class files in an encrypted way. The decryption keys could be kept secure, possibly managed with authentication servers. The custom class loader needed to load these code files could be kept private, or if made public it could rely on official authentication servers which prevent unauthorized use. Without the custom loader in a functional state the code is completely secure and utterly useless. Of course when a user has the custom loader and it is in a functional state then nothing stops them from reading/reverse engineering the code.

The reality is no code is ever secure if its intended to be executed publically. People could literally put a debugger on the JVM and see the resulting assembly. The only way to keep code secure is not give it to people to execute, and instead execute it on secure systems.

I already know all this smart ass, what I am say is despite all this the software I use claims to encrypt and run java while it Is encrypted.

which isn't possible

which is why I'm asking if anyone can read my code and tell me my computer's name, Thus proving my code is not secure

---
I also added a console so you can see any exceptions when trying to hack it
----
I've hacked it once using linux, for some reason it was impossible in windows, this might help you hack it. I've since improved the encryption to the point were even I can't hack it
--
so the question remains, can you hack it?

 

[pyf]

What you are asking makes no sense. If code is encrypted and the key is publicly known then you might as well not encrypt the code. If code is encrypted and the key is not publically known then how can the code be executed? Sure it is completely secure, but completely unusable!

The program encrypts the archive and stores the key with it inside. When the resulting executable is run, it extracts and decrypts the jar file from inside the executable file and then orders its execution. Basically a self-extracting and running archive.


A custom class loader could be made to load code from non ".class" files. A file format could be created which encapsulates the content of .class files in an encrypted way. The decryption keys could be kept secure, possibly managed with authentication servers. The custom class loader needed to load these code files could be kept private, or if made public it could rely on official authentication servers which prevent unauthorized use. Without the custom loader in a functional state the code is completely secure and utterly useless. Of course when a user has the custom loader and it is in a functional state then nothing stops them from reading/reverse engineering the code.

The reality is no code is ever secure if its intended to be executed publically. People could literally put a debugger on the JVM and see the resulting assembly. The only way to keep code secure is not give it to people to execute, and instead execute it on secure systems.

fyi, here is what is written / claimed on the Jar2Exe site. It is the software @TheLordOfChaos201 uses:
Hide and Encrypt Class Protection
Protected Resource

 

[Dr Super Good]

so the question remains, can you hack it?

Yes one can hack it, just it is probably quite time consuming to do so, at least initially while the required framework is made.

Possible attacks include from within the JRE itself, reverse engineering the class loader, and even attaching a debugger to the running process. Just cannot be bothered doing any of it lol.

 

[TheLordOfChaos201]

Yes one can hack it, just it is probably quite time consuming to do so, at least initially while the required framework is made.

Possible attacks include from within the JRE itself, reverse engineering the class loader, and even attaching a debugger to the running process. Just cannot be bothered doing any of it lol.

sounds like an excuse Dr super good? that name of yours is beginning to ring like oxymoron. how can you be super good if you can't even open an achieve

hmm....

I probably will be satisfied if your answer is just that

show me how to open the achieve, even if all I see is unreadable code

NEVER MIND!

THREAD CLOSED THANKS TO PYF

Jar2exe is indeed decrypt-able even with my minor changes

 

[GhostWolf]

Something that must be decrypted in order to run is decryptable? who would have guessed.

Companies spend ridiculous amounts of money on DRM that gets cracked within days usually, but I bet you found the magical solution, the ultimate DRM!

 

[TheLordOfChaos201]

Something that must be decrypted in order to run is decryptable? who would have guessed.

Companies spend ridiculous amounts of money on DRM that gets cracked within days usually, but I bet you found the magical solution, the ultimate DRM!

Actually I did... thank you very much for noticing

If you run the program on linux, you can make it part of the system files which can not be opened, copied or deleted. Besides that I have another solution, but I won't tell you that one because I haven't made it yet

still all together my program has been

obscured
hidden
encrypted
bugged(I added a corrupted file to the archive, making the archive crash when opened but still runnable as a exe or jar)
and most recently I've added encrypted sumchecks which are interwoven with all the other classes in the jar, meaning the program won't run without the other classes or when decrypted

Still my program is not safe until I add that one special thing I've been thinking about making, still not perfect yet

 

[GhostWolf]

Ok, I'll give it to you straight. You can't protect it. Nothing you will put won't be crackable, and it won't be "safe".
If you want your source code to not be readable, you need to compile it, and even then advanced people (aka those who know how to use a debugger and have lots of time on their hands) can figure whatever they want.
This is of course irrelevant to Java, where you cannot compile your code, and so you literally cannot protect it in any way.
Except...copyrights, like this, for instance.
This is also the type of info you write in an EULA.

Now, what is probably more important, beside setting your source license, is the reason to protect code in the first place - people will want it, either because it's super brilliant and amazing, or because it's a software they want to crack.
Do you really have something on either of those ends?

As an addendum, the only real way to protect something is with a private key and non-reversible encryption, which is just not relevant to software you want to share.

 

[TheLordOfChaos201]

Ok, I'll give it to you straight. You can't protect it. Nothing you will put won't be crackable, and it won't be "safe".
If you want your source code to not be readable, you need to compile it, and even then advanced people (aka those who know how to use a debugger and have lots of time on their hands) can figure whatever they want.
This is of course irrelevant to Java, where you cannot compile your code, and so you literally cannot protect it in any way.
Except...copyrights, like this, for instance.
This is also the type of info you write in an EULA.

Now, what is probably more important, beside setting your source license, is the reason to protect code in the first place - people will want it, either because it's super brilliant and amazing, or because it's a software they want to crack.
Do you really have something on either of those ends?

As an addendum, the only real way to protect something is with a private key and non-reversible encryption, which is just not relevant to software you want to share.

well I'm selling educational programs to schools, meaning both that people want it and that it ends up on many computers

now as for protecting it

I found a way to make a sum check that's encrypted, when decrypted the sum check changes.

so

if I use the sum check as an encryption key and encrypt my program twice, the second encrypted portion will always be protected and the key(sumcheck code) will always be inaccessible to a hacker

see any problems with that?

 

[GhostWolf]

If you are selling programs to schools, then obviously they must abide the laws, and therefore, again, you should have a license and EULA.

I am not sure what people will want to crack educational school programs.

As to problems - I have no idea. But anything that must be accessible to the process, can be accessed by anyone else, given knowledge and time, regardless of what you do.
Again, look at the DRM battles going over in the last, what, 20 years?
Did something with public interest ever failed to get cracked? No. And those are made by dedicated teams working on DRM for years.

 

[Dr Super Good]

sounds like an excuse Dr super good? that name of yours is beginning to ring like oxymoron. how can you be super good if you can't even open an achieve

I can, just I cannot be bothered to as it would likely take an excessive amount of time that would be better spent on more meaningful tasks. For example I could actually write some useful code, or help 4-5 people in the WEHZ.

see any problems with that?

How does one decrypt the program to get access to the key to decrypt the program the second time? Encryption is only useful if one can decrypt to get the original data, otherwise one might as well just have random bits and call it whatever you want.

If you keep the keys private, then the program is secure as only people with the keys can decrypt the data. However this is often contradictory to program use where one wants as many users as possible.

Did something with public interest ever failed to get cracked? No. And those are made by dedicated teams working on DRM for years.

Best recent DRM lasted ~1 year. Used by companies like EA, it operates by streaming personalized, encrypted code from a server (internet connection required) and then rapidly decrypting that code with a personalized decryption scheme with cryptographic hashes and then using the results to build the actual code that runs, making sure that never a complete version of the code is in memory at any time. On top of this monitor programs run security checks on running applications on the system to detect tampering and potentially block/ban access similar to how Blizzard games detect cheating.

Again, it is completely crack-able. However it is apparently a pain to do so due to how verbose/pedantic the DRM is and the fact that it might detect attempts to crack it and trigger extra security responses.

Runner up is awarded to Spyro the Dragon 3 for the PlayStation 1. Since the system OS was low level, it relied heavily on accurate low level behaviour of the console, including reading raw values from the CD ROM drive and correct read timings. It also checked if hardware mechanics had changed, for example if a modchip was inserted. Detection of such modification produced deferred, seemingly random and frustrating/broken results when the game was played, with the user being informed only at certain milestones if they could be achieved. Due to a combination of the games low popularity (end of life PS1) and deffered nature of the protection (first 1-2 hours of play appear to run fine), it was never cracked. In-fact people claim the protection was as good as uncrackable and would pretty much require massive reverse engineering and rewriting for a computer to be able to produce a working CD ROM of the game. The protection was so good that it took years before emulators were accurate enough to run the game without triggering any of the protection mechanisms, and even then it required purpose built emulators specifically made for the game. Even some PS2 consoles with PS1 support failed to run genuine copies of the game the protection was so powerful.

Former Insomniac employees disclosed the level of effort they went into to make the protection. They had a dedicated team of people who worked along with game code programmers writing specific DRM code as the game was developed. The result of certain checks failing was hand-made and varied from total game crashes, to progression resets, removing specific individual gems just to annoy people and even altering warp mechanics. Their biggest fear was that false-positives would occur so they had to vigorously test every single test they added to the game. Hackers recon there are several thousand such tests in the game code, so many in fact that they stopped bothering even trying to find them all and instead decided it is less effort to make an emulator just to run the game.

 

[TheLordOfChaos201]

If you are selling programs to schools, then obviously they must abide the laws, and therefore, again, you should have a license and EULA.

I am not sure what people will want to crack educational school programs.

As to problems - I have no idea. But anything that must be accessible to the process, can be accessed by anyone else, given knowledge and time, regardless of what you do.
Again, look at the DRM battles going over in the last, what, 20 years?
Did something with public interesting ever failed to get cracked? No. And those are made by dedicated teams working on DRM for years.

thanks for the copy right advice. I'll defiantly be adding one of those.

as for is someone wants to steal my program, well I'm just a little paranoid that my three year project will be snapped up in a flash. making that harder to do maked me sleep easy at night.

I still want to properly explain how the program is one hundred percent protected now because if it's not you guys will be able to tell me.

I can, just I cannot be bothered to as it would likely take an excessive amount of time that would be better spent on more meaningful tasks. For example I could actually write some useful code, or help 4-5 people in the WEHZ.


How does one decrypt the program to get access to the key to decrypt the program the second time? Encryption is only useful if one can decrypt to get the original data, otherwise one might as well just have random bits and call it whatever you want.

If you keep the keys private, then the program is secure as only people with the keys can decrypt the data. However this is often contradictory to program use where one wants as many users as possible.


Best recent DRM lasted ~1 year. Used by companies like EA, it operates by streaming personalized, encrypted code from a server (internet connection required) and then rapidly decrypting that code with a personalized decryption scheme with cryptographic hashes and then using the results to build the actual code that runs, making sure that never a complete version of the code is in memory at any time. On top of this monitor programs run security checks on running applications on the system to detect tampering and potentially block/ban access similar to how Blizzard games detect cheating.

Again, it is completely crack-able. However it is apparently a pain to do so due to how verbose/pedantic the DRM is and the fact that it might detect attempts to crack it and trigger extra security responses.

Runner up is awarded to Spyro the Dragon 3 for the PlayStation 1. Since the system OS was low level, it relied heavily on accurate low level behaviour of the console, including reading raw values from the CD ROM drive and correct read timings. It also checked if hardware mechanics had changed, for example if a modchip was inserted. Detection of such modification produced deferred, seemingly random and frustrating/broken results when the game was played, with the user being informed only at certain milestones if they could be achieved. Due to a combination of the games low popularity (end of life PS1) and deffered nature of the protection (first 1-2 hours of play appear to run fine), it was never cracked. In-fact people claim the protection was as good as uncrackable and would pretty much require massive reverse engineering and rewriting for a computer to be able to produce a working CD ROM of the game. The protection was so good that it took years before emulators were accurate enough to run the game without triggering any of the protection mechanisms, and even then it required purpose built emulators specifically made for the game. Even some PS2 consoles with PS1 support failed to run genuine copies of the game the protection was so powerful.

Former Insomniac employees disclosed the level of effort they went into to make the protection. They had a dedicated team of people who worked along with game code programmers writing specific DRM code as the game was developed. The result of certain checks failing was hand-made and varied from total game crashes, to progression resets, removing specific individual gems just to annoy people and even altering warp mechanics. Their biggest fear was that false-positives would occur so they had to vigorously test every single test they added to the game. Hackers recon there are several thousand such tests in the game code, so many in fact that they stopped bothering even trying to find them all and instead decided it is less effort to make an emulator just to run the game.

Hmm seems like something I should do. I'll probably keep adding to my protection program over the course of my life. That seems like a good idea that they came up with for that game. Instead of add to their game remove from it. My idea of protection was to add a malicious program that destroys their computer when my program is decrypted. Of course legally I can't do that. Still I'm considering it because viruses don't damage a computer when in encryption, but when decrypted and decompress they do. Which means the virus will not harm the average user, but anyone who actually decrypts the program is screwed. Then I had another program I made that slowly deletes your hard drive in the back ground while writing over the deleted space with the sentence 'your being screwed'. Still none of them as good as my current protection idea. Sumchecks.

I'll explain it again, cause I believe my first 3 explanations sucked:

Ok visualise with me.
In java you lock the door with an encryption key but then leave the key next to the lock, which is absolutely useless.
Now my idea is:
Have 2 doors with 2 keys
The first door has a normal key and can be used to open the door like normal. However, the second key is encrypted with the encryption of the first door and when the first door is opened the key to decrypt the second door is now useless and unable to open the door.

Thus solving my problems making my code perfectly safe... unless the hackers re-encrypt the key, but as very few hackers keep the encryption codes they break I feel pretty confident^^

 

[Dr Super Good]

I still want to properly explain how the program is one hundred percent protected now because if it's not you guys will be able to tell me.

It will never be 100% protected. Game and software developers spend millions of dollars on software protection solutions and they are all broken sooner or later if the demand exists for the program. The problem is that ultimately the program needs to run, and when it does then people can modify it/reverse engineer it by debugging.

 

[TheLordOfChaos201]

It will never be 100% protected. Game and software developers spend millions of dollars on software protection solutions and they are all broken sooner or later if the demand exists for the program. The problem is that ultimately the program needs to run, and when it does then people can modify it/reverse engineer it by debugging.

still you have to admit my code is pretty damn good.

first they would have to decrypt the first program, figure out what encrypts the second, re-encrypt the encryption key with the same encryption and then Decrypt the second