How could one go about finding where in memory a running java program was storing the bytecode it was running off of? I appreciate this may or may not be excruciatingly difficult.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
How could one go about finding where in memory a running java program was storing the bytecode it was running off of? I appreciate this may or may not be excruciatingly difficult.
Look at the source code for the native function
java.lang.ClassLoader.defineClass1(String, byte[], int, int, ProtectionDomain, String, boolean)This is a VM specfic, so there is no general solution.
If you want to look at the byte code, just load the class as a resource (for example
getClass().getClassLoader().getResourceAsStream('java/lang/String.class')) and analyze that stream with a tool like ASM or similar.If you want to modify the byte code at runtime: Good luck with that. The VM has been hardened against such attacks so even if you could get the memory location, chances are that changes would get caught.
Note that debuggers don’t modify the memory, they use special class loaders (or features of the built in class loader) to return a different result when someone asks for a class when the source code has been changed in the IDE. But there are limits to that. Some VMs can’t change the number and/or arguments of methods after a class has been loaded once, for example.