Why Java is vulnerable to reverse engineering attacks

This week, I will continue to share with you Why Java is vulnerable to reverse engineering attacks.
Although Java applications can "Write Once, Run Anywhere" (Write Once, Run Anywhere) is a huge advantage, however, the architecture of this environment makes it much easier for hackers to reverse engineering than local applications. This means that developers are facing a very real risk of losing their intellectual property rights. There are many reasons why application-based virtual machines are easier to reverse engineer than local applications:
JVM is open-source
Sun provides JVM source code for free. This allows hackers to view the code to find out how the virtual machine works.
The Java. class file format is publicly available.
As mentioned above, Java source code is compiled into bytecode, which is stored in the Java. class file. Java. class file format specifications are publicly available, so anyone with a technical background can easily write tools that can process, modify, or convert. class files.
JVM is software, not hardware
Unlike the standard programming language used by experts who need to understand specific processors, JVM is an application that operates like a microprocessor and uses the built-in functions provided by operating systems and computer hardware. Since hackers do not have to go deep into the hardware level, it is easier to gain full control over JVM.
Therefore, for example, it is extremely difficult to pause the processor when debugging is performed using a standard native system development language. Therefore, expert knowledge of the processor, debugging function, and available ring debugger is required. However, since the source code of the JVM runtime environment is publicly available, developers can easily create their own virtual machines to fully control all aspects of the virtual processor. This makes it easy to analyze every application running in the running environment.
Java commands are less than local code
However, another reason why JVM code is easy to reverse engineer is that it has fewer commands than local applications. This is for performance considerations. The use of JVM adds a software layer between the application and the local processor, which negatively affects the performance. Although the increasing execution speed of modern processors will eventually alleviate this problem, it is still obvious. One way for VM developers to speed up execution is to use a bytecode instruction set that is smaller than the local processor assembler. Local applications may contain up to 400 commands, while Java applications generally use up to 200 commands. Fewer commands mean that hackers can analyze code more quickly for reverse engineering.
These features make virtual machines more vulnerable to reverse engineering attacks than other types of applications.
Third-party disassembly programs add Vulnerabilities
Not only is the JVM itself vulnerable to reverse engineering attacks, but there are also more commercial and free Java bytecode disassembly programs, which further simplifies the code reverse engineering process.
IDA and Eclipse bytecode plug-ins are two types of Java bytecode disassembly programs. As a commercial product, IDA is a common disassembly program that can be used for many different processors, including 80x86 and MIPS. The Eclipse bytecode plug-in is a free software. It can decompile the bytecode of the Java. class file and display all operation code commands in proper order.
Although these products are unlikely to perfectly restore the original code from bytecode, the source code they restore will be equivalent to the original code and be more readable than the bytecode. Once the source code is restored, attackers can easily delete part of the code and use it illegally in competitor applications, or locate and patch it in the. class file.
Figure 1 provides an example of how hackers may patch the. class file. The upper part of the screen shows a small Java source code. The lower part of the screen shows the output of bytecode disassembly, which is a list of bytecode instructions. The area marked in red is the corresponding command of the IF structure in the source code. The hexadecimal format of the bytecode command "LCMP" is 0x94. The tool also specifies the position of the operation code in the. class file. With this information, hackers can use a simple hexadecimal editor to change the IF Branch, which takes less than one minute. IF the IF condition is used for the license check, the hacker can put it upside down to indicate that "True" is returned even IF the license is verified to be invalid (e.g. expired ", to break through the license inspection. In this case, hackers can use a byte patch to complete all work. Although most applications are more complex than this example, even in complex applications, bytecode is very simple and easy to understand.
 
Figure 1-Eclipse bytecode plug-in for bytecode Disassembly