6

I'll get right to the point so you don't have to read a lot.

Basically, I have an AES-128bit Encrypted Jar file. I want to make a launcher so that I can load this encrypted Jar into memory and run it (using the key).

I have a simple Class Loader working although unless I decrypt it to a directory and run it, it obviously won't do what I am needing (decrypt & memory load).

TL;DR: I need to make an AES-128bit Encrypted Jar run in memory.

Any help is much appreciated, feel free to ask questions!

Timothy Hanes
  • 297
  • 1
  • 5
  • 17
  • 2
    If you want your code to be that secure you probably shouldn't be writing it in one of the most easily decompiled languages out there. It's possible to write a jar loader but there's no way to stop people from just dumping it from memory. – 0x5f3759df Oct 22 '11 at 10:17
  • It needs to be compiled in Java. Not because I can't code in other languages but more of, other languages don't support what I'm doing. – Timothy Hanes Oct 22 '11 at 10:24
  • @0x5f3759d And the same is true for C, C#,.. well absolutely any language. It may take 5minutes longer, but in the end if someone wants the jar file he'll get the key easily enough (set a breakpoint for CreateFile and consorts in the debugger, maybe add one for ReadFile with the found fd and you'll get it easily enough). Though I don't really see the problem here - what stops you from reading the file in and decrypting it if you already have your classloader? I.e. what is your actual problem? – Voo Oct 22 '11 at 10:27
  • 1
    @Voo I'm not aware of anything that does even a remotely good job of decompiling compiled C/C++ code back to source files. You can of course look at the assembly but having nearly original code like Java/.NET provides makes decompiling much easier. – 0x5f3759df Oct 22 '11 at 10:30
  • @0x5f3759df I'm not saying "decompile the whole program and look through millions of unreadable c lines", I'm saying "check when he opens/reads the file and follow the handful lines until he decodes it" - and that's trivial in both/all languages. Heck if you use an imported function to decode the file it's even more trivial. – Voo Oct 22 '11 at 10:31
  • The key is not stored locally, I'm not dumb like that. It is much more secure than that as the key will be separate for every Jar given out and every time you launch it. Hard to explain, I basically created a PHP file that would encrypt it and download the encrytped jar based on the input. Although, I also have custom obfuscation + ProGuard on it. Nothing is uncrackable, as you will agree, although I will do my best to stop them. – Timothy Hanes Oct 22 '11 at 10:32
  • @Voo and once you locate the decrypted code in memory you have your "millions of unreadable c lines." Anyway I get what you're saying, anything will be cracked eventually. We might as well stop arguing as he's using Java. – 0x5f3759df Oct 22 '11 at 10:33
  • @Mhmk To decipher your jar file you need the key. You can obfuscate it as much as you want, give anyone halfway competent your program and at most half an hour (and that's if he's slow) and he'll give you your keys back. It's obfuscation at best really – Voo Oct 22 '11 at 10:34
  • @Voo Yes you do. The key will be entered in the launcher. Eg. Like a serial key box. That serial key will be used to download the encrypted jar file. The decryption key would be in the format of MD5 Serial Key as well as a Session Number that will be returned when you download the jar. Kinda Hard to explain. Basically, it will let the user input the serial key which is part of the decryption key. Decryption key consists of the user input and a session that is gained off the site in MD5 form. – Timothy Hanes Oct 22 '11 at 10:38
  • @Mhmk I'm just saying if you decipher the data on the users box, the user will have easy access to the deciphered data. Though I'm not sure if your goal is to keep the data secret from the user itself - if it is, you should be aware that anyone with some basic CS knowledge will be capable of getting the key (and therefore the deciphered data) in no time at all. – Voo Oct 22 '11 at 10:51

2 Answers2

8

For sample code on how to load a jar/class from byte[] (which should be the result you get after decrypting it in memory/no need to save it anywhere in the filesystem) see http://www.javaworld.com/javaworld/jw-10-1996/indepth/indepth.src.html

Basically you need to use defineClass to achieve what you want.

BUT beware that this offers no real security since all ends up (after decryption) as Java Byte code in memory and can thus be accessed/manipulated/saved etc.

A little bit of security would be possible by implementing a custom JVM and/or pre-JITing the code so that it is native... for some information see for example How to create encrypted Jar file?

Community
  • 1
  • 1
Yahia
  • 69,653
  • 9
  • 115
  • 144
  • Thanks! I'll have a go at this at let you know how it works. I was also thinking that an easier option would be to create a temp file that contains the decrypted jar/bytes. I load the temp jar into memory then delete it from the temp folder. – Timothy Hanes Oct 22 '11 at 10:48
  • you are welcome... please don't forget to upvote/mark as accepted any answer that was of help! – Yahia Oct 22 '11 at 10:49
  • I need to get 15 reputation before I can up vote it. But I'll be sure to when I reach 15 rep! – Timothy Hanes Oct 22 '11 at 10:52
1

This article is a good read that illustrates nicely why air-tight protection of your code is simply not possible. You can make it harder, very hard even by staying as low-level as possible, e.g. compile your code down to native instructions that are not (cleanly) representable using regular language constructs.

But you should keep in mind that in any case, ultimately your encrypted data will have to be decrypted using some key and this key will, even if only briefly, but the important point is that it will, end up in memory. There's no way around this with common operating systems and hardware. So as a hacker you can always fall back to fetching the key from memory and work your way backwards from there on. Not something that average users are capable of, but it is certainly possible.

emboss
  • 38,880
  • 7
  • 101
  • 108