I want to encrypt the class bytecode of some compiled core classes in the springboot project, and use the JVMTI monitoring mechanism to decrypt the class. Ordinary java projects have been able to decrypt the jar after the encrypted class can be decrypted normally. It runs, but even if a specific java class is not referenced in the code in springboot, if the directory of the class is in the spring scan path by default, the encrypted class file will be caused by org even if the class file is not referenced by any code. The validation bytecode of org.springframework.asm.ClassReader throws an exception, causing the service to stop. Can you provide a configuration for this requirement to ignore certain classes that are not validated?
Comment From: snicoll
See https://github.com/spring-projects/spring-boot/issues/28504
Comment From: jhoeller
What's the specific exception thrown when ClassReader encounters one of those class files? Maybe we can make our ASM fork more lenient in that respect...
Comment From: kakahu2015
Since jdk1.5, JVMTI was introduced. I tried to encrypt a normal java class bytecode, and then I asked JVM to load it. The prompt: This is not a normal class bytecode file, so I applied JVMTI, compiled a dynamic library with C++, added the startup parameter -agentpath, so that when the JVM loads the class, it decrypts the encrypted bytecode into a normal class in advance, so that the encrypted class can be run normally. But the spring framework does not adapt to this. For example, an encrypted class file is placed under the path scanned by spring boot by default. This class is not referenced by any other class code, but it will still be due to org.springframework.asm when it is started. ClassReader performs strong verification on all bytecodes in the path scanned by spring boot by default, so that an abnormal (encrypted) class file is detected and an exception (such as Incompatible magic value, etc.) is thrown, causing the program to stop starting. , I suggest exception handling for specific (encrypted class) without verification.
Comment From: jhoeller
Reviewing ASM's ClassReader implementation, it's not clear to me which part would actually fail here. Could you provide the stacktrace of an exception raised for one of your encrypted class files? Is it ultimately an IllegalArgumentException bubbling up from the ClassReader constructor, just like in case of an unsupported class file version?
Comment From: jsbxyyx
when fixed it?
Comment From: bclozel
@jsbxyyx we didn't get @kakahu2015 's feedback to make progress. @jsbxyyx do you have the requested stacktrace showing the issue? Can you provide it here?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: kakahu2015
First, please refer to https://github.com/kakahu2015/encrypt to download the demo to your local, I will use this demo as an example to describe the problem I want to solve. Note that the package name of the org.kakahu.util.Hello class is org.kakahu.util is not inside the default scan package (org.kakahu.encrypte) of springboot, but org.kakahu in my uncompiled and packaged application There is no problem in running java -jar unencrypted.jar when the class file of the .util.Hello class performs encryption processing
But now I encrypt the org.kakahu.util.Hello class file (remember this action), run java -jar util_hello_encrypted.jar again, because the class has been encrypted and processed without any decryption, it will definitely report a magic number error first :
Next, I use the jvmti-related interface technology to decrypt the encrypted calss of the org.kakahu.util.Hello class java -agentpath:./libkakahu.so -jar util_hello_encrypted.jar, so that the program can run normally:
Because org.kakahu.util is not under the default startup scan package of org.kakahu.encrypte springboot, the encrypted classes can be processed normally by using jvmti, and then I want to do the classes under the default startup scan package of org.kakahu.encrypte springboot. Encryption processing, the JVMTI level can definitely handle the decryption problem, but springboot's own verification mechanism will scan and verify all classes under the default startup scan package of org.kakahu.encrypte springboot (even if my business logic is not really used), it will definitely If an exception is thrown, I just hope that you will provide an exception to not verify some calss files under the default startup scan package of org.kakahu.encrypte springboot:
Comment From: lunxian8
Hello, I have encountered the same issue, and the root cause lies in the extensive use of ASM technology in the Spring framework. Spring AOP utilizes ASM to directly read encrypted bytecode, bypassing the JVMTI mechanism, which results in the program throwing errors. Have you found a solution for this issue?
Comment From: kakahu2015
Perhaps java is not inherently designed to ensure protection against reverse engineering, as this issue seems to be unattractive to official springboot attention
Comment From: jhoeller
For 6.1.2, I'm introducing a system property spring.classformat.ignore which can be set to true in order to ignore class format mismatches during classpath scanning. For reliable detection, MetadataReader throws a new ClassFormatException now which the above system property reacts to. The exception messages are as descriptive as possible, suggesting common solutions such as a -target compilation downgrade, a framework upgrade, or setting spring.classformat.ignore to true now.