I came across this post [1] in which the author discovers an undocumented feature in the JVM. "Although the first stable release of Java used bytecode version

I came across this post [1] in which the author discovers an undocumented feature in the JVM. "Although the first stable release of Java used bytecode version 45.3, the JVM will actually accept classfiles with versions starting at 45.0. Furthermore, there’s an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2. In a normal classfile, the stack, locals, and code length fields of the Code attribute have lengths of 2, 2, and 4 bytes respectively, but in a pre-45.3 classfile, the JVM expects them to be 1, 1, and 2 bytes instead. Normally, this means that a pre-45.3 classfile produced by ASM will just crash when run on the JVM because the JVM encounters garbage data while parsing and rejects it. However, if you are very careful, it is possible to construct a classfile that is valid when parsed with the 2,2,4 widths, and also valid when parsed with 1,1,2, but parses as different code in each case. This means that it is possible to craft a classfile that executes one piece of code when run on the actual JVM and displays a completely different set of fake code when viewed with reverse engineering tools" TL;DR JVM contained an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2. The stack, locals, and code length typically has 2,2,4 bytes rspectively; in pre-45.3 classfiles, the JVM expects them to be 1,1,2 bytes instead. [1] https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-app-engine-anatomy-of-a-java-bytecode-exploit.html https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-a... [2] https://github.com/openjdk/jdk/commit/eedc99c9ab2647f0233e4899a2976eb6f3095319 https://github.com/openjdk/jdk/commit/eedc99c9ab2647f0233e48...