DO NOT DEAL WITH THIS MEMBER
Hello! Which type of hacked client would you guys prefer to have (Forge or Normal), and why? (Please tell why)
Forge Client or a standard client with your versions folder or whatever the fuck? Thanks for your opinions 🤝🤝
You could always have a client that both works with and without Forge, like Iridium
DO NOT DEAL WITH THIS MEMBER
(Aug 12, 2017 06:33 PM)marcusant Wrote: You could always have a client that both works with and without Forge, like Iridium
That sounds pretty cool, but I don't know how Forge works and just started coding with it a bit today.
Do you develop 2 different Iridiums? One for Forge and the other for normal MC?
(Aug 12, 2017 06:35 PM)I Like Gold Wrote: That sounds pretty cool, but I don't know how Forge works and just started coding with it a bit today.
Do you develop 2 different Iridiums? One for Forge and the other for normal MC?
Nope. It uses runtime bytecode injection so it works no matter what mods are installed, including optifine and forge. I don't edit Minecraft directly at all.
DO NOT DEAL WITH THIS MEMBER
(Aug 12, 2017 07:29 PM)marcusant Wrote: Nope. It uses runtime bytecode injection so it works no matter what mods are installed, including optifine and forge. I don't edit Minecraft directly at all.
That sounds like some complex stuff, yet it sounds fun. Are you taking the Java Instrumentation approach?
Aug 12, 2017 07:52 PM
(This post was last modified: Aug 12, 2017 07:53 PM by marcusant.)
(Aug 12, 2017 07:45 PM)I Like Gold Wrote: That sounds like some complex stuff, yet it sounds fun. Are you taking the Java Instrumentation approach?
Yes. I used to (in Iridium 4) attach to a running instance with the com.sun.tools.attach stuff (so the client could be injected on the fly to an already running game). Here's a video of it: https://streamable.com/nzqgm . I haven't decided on a way to deploy the payload for Iridium5 yet -- I probably won't use attach again since it didn't really provide much benefit to just loading into the classpath from the beginning.
DO NOT DEAL WITH THIS MEMBER
(Aug 12, 2017 07:52 PM)marcusant Wrote: Yes. I used to (in Iridium 4) attach to a running instance with the com.sun.tools.attach stuff (so the client could be injected on the fly to an already running game). Here's a video of it: https://streamable.com/nzqgm . I haven't decided on a way to deploy the payload for Iridium5 yet -- I probably won't use attach again since it didn't really provide much benefit to just loading into the classpath from the beginning.
That inject button thing looks sick! Don't you have to program in strings in order to inject, though?
(Aug 12, 2017 08:16 PM)I Like Gold Wrote: That inject button thing looks sick! Don't you have to program in strings in order to inject, though?
You're most likely thinking of javassist, which lets you insert your code as you would normally program it in in the form of strings.
You don't have to use this library though as you can just use asm (which iirc javassist is based off of, but the difference is that compiler that converts strings to bytecode).
DO NOT DEAL WITH THIS MEMBER
(Aug 12, 2017 08:38 PM)MadZ Wrote: You're most likely thinking of javassist, which lets you insert your code as you would normally program it in in the form of strings.
You don't have to use this library though as you can just use asm (which iirc javassist is based off of, but the difference is that compiler that converts strings to bytecode).
Awesome! Thank you! ASM seems harder to use than Javassist (probably because you deal with actual bytecode), so I think I'll try Javassist.
My plan would be to create maybe a Mapper utility class, and place inside of that class a method which converts the MCP Mappings you input (for ease and readability of code), into Notch Mappings for the minecraft jar file you're dealing with. Then you could probably inject classes without naming errors.
However, when you inject your String code (for example, event calling code) into the minecraft class files, does it automatically inject your normal java code along with it?
For example, do I need to attach an agent jar? And.... oh damn this is getting confusing
Aug 12, 2017 08:58 PM
(This post was last modified: Aug 12, 2017 08:58 PM by MadZ.)
(Aug 12, 2017 08:51 PM)I Like Gold Wrote: However, when you inject your String code (for example, event calling code) into the minecraft class files, does it automatically inject your normal java code along with it?
For example, do I need to attach an agent jar? And.... oh damn this is getting confusing
Although I am very inexperienced with instrumentation and the whole injection thing, the agent jar is what you are injecting into Minecraft; so yes, you need to attach the "agent jar."
Keep in mind the primary feature that makes a jar an "agent jar" is the agentmain method (which is what you're dealing with when injecting into already loaded classes). This will then call your transformers etc, which can all be put into a single jar, along with your standard client related packages.
I can't really explain it that well because I have never taken the time to really learn it that well or even make a client with any of it. I've only started reading about java agents and javassist (as I have little experience with bytecode). Hope someone else can properly answer your question.
Good luck with your project and the same to Marcusant.
DO NOT DEAL WITH THIS MEMBER
(Aug 12, 2017 08:58 PM)MadZ Wrote: Although I am very inexperienced with instrumentation and the whole injection thing, the agent jar is what you are injecting into Minecraft; so yes, you need to attach the "agent jar."
Keep in mind the primary feature that makes a jar an "agent jar" is the agentmain method (which is what you're dealing with when injecting into already loaded classes). This will then call your transformers etc, which can all be put into a single jar, along with your standard client related packages.
I can't really explain it that well because I have never taken the time to really learn it that well or even make a client with any of it. I've only started reading about java agents and javassist (as I have little experience with bytecode). Hope someone else can properly answer your question.
Good luck with your project and the same to Marcusant.
Thanks a lot, MadZ! You actually made me think a lot better about how it works, and taught me a bit.
So, you're saying that if I create an Agent JAR with all of my class transformers, agentmain method, and minecraft hacked client code packed inside of it, I simply attach the agent jar file to the running Minecraft, and then it will technically be on its classpath?
Aug 12, 2017 09:25 PM
(This post was last modified: Aug 12, 2017 09:27 PM by MadZ.)
(Aug 12, 2017 09:08 PM)I Like Gold Wrote: Thanks a lot, MadZ! You actually made me think a lot better about how it works, and taught me a bit.
So, you're saying that if I create an Agent JAR with all of my class transformers, agentmain method, and minecraft hacked client code packed inside of it, I simply attach the agent jar file to the running Minecraft, and then it will technically be on its classpath?
Yes. If you have any additional dependencies you can point to them in your manifest Class-Path attribute.
The method used to actually attach the agent can also be in the same jar as the agent (someone correct me if I'm wrong). Just call the method in the entry point/main-class.
Again, I honestly don't know much about all of this, just recalling the things I've read in the past few days.
Aug 12, 2017 09:25 PM
(This post was last modified: Aug 12, 2017 09:29 PM by marcusant.)
(Aug 12, 2017 09:08 PM)I Like Gold Wrote: Thanks a lot, MadZ! You actually made me think a lot better about how it works, and taught me a bit.
So, you're saying that if I create an Agent JAR with all of my class transformers, agentmain method, and minecraft hacked client code packed inside of it, I simply attach the agent jar file to the running Minecraft, and then it will technically be on its classpath?
If you don't modify MC's classpath on launch you'll probably have to load your stuff into the classpath from the agent (i.e. with URLClassLoader) since IIRC Attach only loads in the specific class list you specify. Basically IIRC I made my attach load a minimal class or two that dealt with loading and executing the others. I don't remember too many specifics since it was a while ago.
Aug 12, 2017 09:36 PM
(This post was last modified: Aug 12, 2017 09:36 PM by MadZ.)
(Aug 12, 2017 09:25 PM)marcusant Wrote: If you don't modify MC's classpath on launch you'll probably have to load your stuff into the classpath from the agent (i.e. with URLClassLoader) since IIRC Attach only loads in the specific class list you specify. Basically IIRC I made my attach load a minimal class or two that dealt with loading and executing the others. I don't remember too many specifics since it was a while ago.
Ahh...
https://github.com/Xyene/ASM-Late-Bind-A...r.java#L38 (basic library to attach to jvm proc)
I suppose you would have to pass those additional classes to the resources argument.
Most of the writeups I've read were based on "premain" javaagents, which are loaded with the javaagent argument at launch, which didn't seem to have this requirement. I suppose using agentmain/attaching to already loaded classes you would have to specifically load relevant classes.
Aug 12, 2017 09:39 PM
(This post was last modified: Aug 12, 2017 09:39 PM by marcusant.)
(Aug 12, 2017 09:36 PM)MadZ Wrote: Ahh...
https://github.com/Xyene/ASM-Late-Bind-A...r.java#L38 (basic library to attach to jvm proc)
I suppose you would have to pass those additional classes to the resources argument.
Most of the writeups I've read were based on "premain" javaagents, which are loaded with the javaagent argument at launch, which didn't seem to have this requirement. I suppose using agentmain/attaching to already loaded classes you would have to specifically load relevant classes.
Yep. Not too bad if you use a classloader from within the few classes you manually specify. Never did any of the premain stuff and didn't use any libs that weren't part of the JDK (although that would probably be smarter and less work).
|