As far as I know OSBot does not xboot and instead injects into the gamepack and runs the game off that modified jar. Any Jagex requests they send out to detect whether there is injected code in the jar (such as getPlayer(), getCameraYaw(), etc.) are routed to the unmodified jars class loader.

 

Also, it seems like you're confused about what xbooting actually is. It doesn't actually modify rt.jar but instead looks for rt.jar class overrides found with the xbooting jar file that it will use instead of the defaults. If you actually modified the rt.jar files you'd have to delete and reinstall Java since things relying on the default Java functionality wouldn't work (assuming you did something drastic to one of the classes).

 

Interesting info thanks for explaining. Also, I was aware that Xboot works like that. The only reason I mentioned modifying rt.jar is because it's something I did myself "back in the day" with openjdk, I'm not sure if it supported -Xbootclasspath at the time. It does work "in a pinch," and breaking classes generally wasnt an issue because I had the full source of rt.jar

Definitely not a good idea to actually use though, Xboot on the otherhand can be really usefull for getting into things.

more obvious redundant statements

 

Edited October 24, 201411 yr by Aerospark

As far as I know OSBot does not xboot and instead injects into the gamepack and runs the game off that modified jar. Any Jagex requests they send out to detect whether there is injected code in the jar (such as getPlayer(), getCameraYaw(), etc.) are routed to the unmodified jars class loader.

 

Also, it seems like you're confused about what xbooting actually is. It doesn't actually modify rt.jar but instead looks for rt.jar class overrides found with the xbooting jar file that it will use instead of the defaults. If you actually modified the rt.jar files you'd have to delete and reinstall Java since things relying on the default Java functionality wouldn't work (assuming you did something drastic to one of the classes).