Amit’s lab

Okay.. finally i managed some more time to write a post. Although, the stuff I post on my tech blog is not a very complex one as I just post basics but I aim to provide just reference in regards to bytecode reverse engineering. 

Alright!!! this time again, I’ll deviate from the topic and I’ll talk about how to make java code execution faster and tougher to reverse engineer. This covers the basic question “How do I get an .EXE (executable) from java code?”

hmm.. to begin with, everyone knows that java compiler generates a class file which is interpreted by the bytecode interpreter and then executed. Now, to execute some java code, VM should be running, class loaders play some role, some java reflection etc etc… and finally, even the obfuscated code also gets decompiled and the code can be understood by anyone.

So, how to protect your code and make it execute faster?

Think that if you java code looked like some machine language native code. Wouldn’t it be running faster? wouldn’t it be tough to decompile or reverse engineer?

Yes, the best way is to write the whole code in java and then transform into some native code or machine level code. This way you acheive a high degree of obfuscation. and the performance of your system is improved as the code executes faster. Now, head of complains that native calls are expensive on performance oriented systems? yes, this is one of highly used solutions for improved performance of java code especially in embedded domains. It is also referred to as Native Compilation

Different from normal Java bytecode compilers (like javac or jikes), native compilers do not create bytecode files (.class) that are interpreted by a Java Virtual Machine but native executables (like .exe files on Windows).

How does it work? it is very simple actually. There are lot of tools (both free & commercial) are available for use. They read the java code and convert them into machine readable format like hashcodes, enrypted syntaxes, some autogenerated C code, some more bits and bytes etc etc. even the VM code is completely native. So, whenever the code is executed, it actually looks for some VM function calls which, in turn, calls you defined methods registered in the method stack and Voila!!! java code is executing faster.

Advantages of Native compliation (copied from a text book )

Higher execution speed - Actually, that is not guaranteed, it depends largely on the application type, the system environment, the way a particular solution was coded etc. You must do a lot of testing to find out if your code benefits from native execution.

Faster startup time - Native applications typically start faster than bytecode applications. That doesn’t matter if your program runs for a very long time, but for small command line applications that get started often it might make a difference.

Easier deployment - It seems to be better to give Windows users an EXE file - they know what it is, how to run it, etc. However, JAR files with a main-class manifest entry can also be run by double-clicking on them (with certain JREs). Installation wizards are also available. Often, developers don’t want their users to have to install a JRE. But with many native compilers, you have to have a JRE and various other code installed to run the EXE, so there is no real simplification.

Higher number of concurrent program instances - Every instance of a JVM requires at least several MB of RAM, while some of the more advanced native compilers create executables that share memory between instances of the same application. That way, you can run more instances on the same system.

Better code obfuscation - If you don’t want people to reverse-engineer your code, native executables are typically harder to understand than bytecode, even if the bytecode was run through an obfuscator.

Disadvantages of native compilation

No more platform independence - Instead of having a single JAR for your application that runs with every JVM, you have to maintain several versions. This is very much against the Write Once, Run Anywhere idea that was one of the reasons to create Java in the first place.

Less platforms - From what I can see, there are no native compilers for several platforms, so that the number of potential users is smaller with a native application. However, the most important platforms seem to be supported, so that the absolute number of potential users is not much smaller.

Higher costs - It seems that all good native compilers are relatively expensive. This does not apply in a commercial environment where spending several thousand US dollars on a product is not unusual.

Quote of the Day:"Kenny's family is so poor that yesterday, they had to put their cardboard box up for a second mortgage." -- Cartman

Related posts

• ByteCode Reverse Engineering Season 1 Episode 2 (0)
• Bytecode Reverse Engineering Season 1 Episode 1 (0)
• Tainted Object Propagation (0)
• Making your code Faster, Stronger, Safer…. (0)
• Twitter compromised !!! Another Example Why Security is so important?? (1)

Reading: Bytecode Reverse Engineering Season 1 Episode 3Tweet This: Send Page to Twitter