When Java source code is compiled, it is converted into bytecode, saved in one or more class files, and executed by the Java Virtual Machine (JVM). Java class files may be compiled on one machine and executed on another machine. A properly generated class file is said to be conforming. When the JVM loads a class file, it has no way of knowing whether the class file is conforming. The class file could have been created by some other process, or an attacker may have tampered with a conforming class file.
...
The bytecode verification process runs by default. The -Xverify:none flag on the JVM command line suppresses the verification process. This noncompliant code example uses the flag to disable bytecode verification.:
| Code Block | ||
|---|---|---|
| ||
java -Xverify:none ApplicationName |
...
Specifying the -Xverify:all flag on the command line requires the JVM to enable bytecode verification (even when it would otherwise have been suppressed), as shown in this compliant solution.:
| Code Block | ||
|---|---|---|
| ||
java -Xverify:all ApplicationName |
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
ENV04-J | highHigh | likelyLikely | lowLow | P27 | L1 |
Automated Detection
Static checking of this rule is not feasible in the general case.
...
Under the default settings, bytecode verification is enabled on the Dalvik VM. To change the settings, use the adb shell to set the appropriate system property, : for example: , adb shell setprop dalvik.vm.dexopt-flags v=a or pass -Xverify:all as an argument to the Dalvik VM.
Bibliography
"The Bytecode Verifier" | |
Section 7.3, "The Class File Verifier" |
...