EOSERV Forum > EOSERV > Quest rule for handling "Cancel" button in dialog?
Page: << 1 2 3 >>
Quest rule for handling "Cancel" button in dialog?
Author Message
Post #202758 Re: Quest rule for handling "Cancel" button in dialog?
Hacker_Alex posted: (8th Mar 2017, 04:43 pm)

Sordie posted: (8th Mar 2017, 04:34 pm)

@Hacker_Allex

The EO Protocol (or "phrases" as you like to call it) can be expanded. There are a few ways this can be done. While it would be possible to add new packet families/actions to the server very easily the problem is making the client respond and process these packets. Although I've already demonstrated this is possible there is a much simpler solution: It is possible for the server to create oversized packets containing more information than the client processes. The client happily accepts this extra data and just ignores it. It would then be possible (in my case, as always) to create an Addon that reads the extra data, performs the action required and tag it's result onto the end of the next packet bound for the server.

These both have the same problem of needing new code added to the client, forcing all your uses to use either a custom client (don't trust anything that isn't an unmodified .28 imho) or an external program such as EO.Addons to add this functionality. I strongly disagree with forcing people to do this. It should be the players choice if they want to accept the risk of 3rd party modifications, not "use this or gtfo" =S




I feel the same way about clients. That's why when I play this other game I play with private servers, I always use the same vanilla client for all the servers and hex in the server IPs.. I got lazy one day because someone was rushing me to play and GG I got sality.

With the phrases I was just trying to explain that you can't have your server do whatever it wants to the client, and that someone has to program the client to be able to accept new phrases. But yeah..


@Shayne

You can add custom programming code into your trainer like a read the ML pointer every x seconds right? Maybe you can add an option called Stop Chat Leak and then it enables a loop to check the pointer status every half second and if it detects it minimized it applies the blocking of the text field, and when it detects it unminimized it applies the unblocking?
I'm using Game Trainer Studio, and you are able to some what add custom code I think, but I'm pretty sure you're very limited with what you can do, and there is no documentation of how to do anything.

I'll need to familiarize myself with assembly more, and then I could do this with cheat engine I'm sure.
You can do quite a bit with cheat engine and the trainer creator, but I've just been lazy to bother learning, and checking into it.

Callum
Yea, I can understand why this is not a good way to go about it now.
I never considered the mentioned potential issues in doing it this way.
---
EO Resources/Guides: ◄eoguide.boards.net►
1 year, 6 weeks ago
Post #202761 Re: Quest rule for handling "Cancel" button in dialog?
callum posted: (8th Mar 2017, 03:21 pm)


I gotta be honest, I agree with Alex here. If someone as sly as elevations got ahold of it god knows what would come of it. I'm all for client hexing and such but these addons and forcing the client to do stuff is really shady and I'd imagine super dangerous in the wrong hands.

Just for the record EO.Addons does nothing more than what you call "hexing the client". Most of what EO.Addons does is edit the memory inside the client, much like Shaynes program does only he achieves similar results for way less effort because he takes the time to follow pointers back where as I just go the long way around and replace code. Most hacks he does are way more efficient than EO.Addons. 

The thing where EO.Addons shines is it's ability to work with executable code rather than just values in memory. The most complicated part is the "CodeSize" function that can disassemble IA86 machine code, following JMPS, JE, JNE, JG RETS, etc.. until it works out the size of a procedure. It can then take functions of the client and move them somewhere else (adjusting relative jmp's and pointers) replacing them with new code provided by an addon whitest preserving the functionality of the original code. Basically allowing addons to insert their own code at any point in the client and still allowing the original code to be executed.

But!!!! My point is this is all done through nothing more than "hexing the client". All it's doing is reading and writing memory in the client like shayne does. Anything EO.Addons does could be implemented with shaynes app. Infact, it's about time we worked together XD


EDIT: "Disassemble IA86 machine code" is an exaggeration. It knows instruction sizes and the op-codes of instructions that branch and how to follow them =P


---
http://sordie.co.uk
http://twitter.com/@SordieEO
1 year, 6 weeks ago
Post #202762 Re: Quest rule for handling "Cancel" button in dialog?
Apollo posted: (8th Mar 2017, 08:41 pm)

Hacker_Alex posted: (8th Mar 2017, 04:43 pm)

Sordie posted: (8th Mar 2017, 04:34 pm)

@Hacker_Allex

The EO Protocol (or "phrases" as you like to call it) can be expanded. There are a few ways this can be done. While it would be possible to add new packet families/actions to the server very easily the problem is making the client respond and process these packets. Although I've already demonstrated this is possible there is a much simpler solution: It is possible for the server to create oversized packets containing more information than the client processes. The client happily accepts this extra data and just ignores it. It would then be possible (in my case, as always) to create an Addon that reads the extra data, performs the action required and tag it's result onto the end of the next packet bound for the server.

These both have the same problem of needing new code added to the client, forcing all your uses to use either a custom client (don't trust anything that isn't an unmodified .28 imho) or an external program such as EO.Addons to add this functionality. I strongly disagree with forcing people to do this. It should be the players choice if they want to accept the risk of 3rd party modifications, not "use this or gtfo" =S




I feel the same way about clients. That's why when I play this other game I play with private servers, I always use the same vanilla client for all the servers and hex in the server IPs.. I got lazy one day because someone was rushing me to play and GG I got sality.

With the phrases I was just trying to explain that you can't have your server do whatever it wants to the client, and that someone has to program the client to be able to accept new phrases. But yeah..


@Shayne

You can add custom programming code into your trainer like a read the ML pointer every x seconds right? Maybe you can add an option called Stop Chat Leak and then it enables a loop to check the pointer status every half second and if it detects it minimized it applies the blocking of the text field, and when it detects it unminimized it applies the unblocking?

I am not sure of what you mean by "hex in the server's IP", but there is a text file config and the econfg included in the vanilla client that will allow you to change the domain and port. But hey, if you want to use a hex editor on a notepad file who am I to judge.

Pretty sure  he didn't mean EO when he said "other game I play with private servers" in the first paragraph.

@Sordie &Shayne I'm definitely not accusing you guys of anything, please don't think I was aiming at at you guys in the last post. In fact you guys are at the other end of that argument where you've both made contributions that help the community.

As much as I love the interest in client editing lately I'm still rooting for an official c++ client release.

1 year, 6 weeks ago
Post #202793 Re: Quest rule for handling "Cancel" button in dialog?
Sordie posted: (9th Mar 2017, 02:40 am)

callum posted: (8th Mar 2017, 03:21 pm)


I gotta be honest, I agree with Alex here. If someone as sly as elevations got ahold of it god knows what would come of it. I'm all for client hexing and such but these addons and forcing the client to do stuff is really shady and I'd imagine super dangerous in the wrong hands.

Just for the record EO.Addons does nothing more than what you call "hexing the client". Most of what EO.Addons does is edit the memory inside the client, much like Shaynes program does only he achieves similar results for way less effort because he takes the time to follow pointers back where as I just go the long way around and replace code. Most hacks he does are way more efficient than EO.Addons. 

The thing where EO.Addons shines is it's ability to work with executable code rather than just values in memory. The most complicated part is the "CodeSize" function that can disassemble IA86 machine code, following JMPS, JE, JNE, JG RETS, etc.. until it works out the size of a procedure. It can then take functions of the client and move them somewhere else (adjusting relative jmp's and pointers) replacing them with new code provided by an addon whitest preserving the functionality of the original code. Basically allowing addons to insert their own code at any point in the client and still allowing the original code to be executed.

But!!!! My point is this is all done through nothing more than "hexing the client". All it's doing is reading and writing memory in the client like shayne does. Anything EO.Addons does could be implemented with shaynes app. Infact, it's about time we worked together XD


EDIT: "Disassemble IA86 machine code" is an exaggeration. It knows instruction sizes and the op-codes of instructions that branch and how to follow them =P


I'd love to learn to do the types of things you do. I really wouldn't even know where to start though. =d
Exactly because of what you've stated basically, it would be neat to do something more complex and versatile, then simply editing the actual values in memory.
It would be really cool to make the client behave more so how you want, kinda like how you do with your addons.

Don't think that I know so much, because I don't.. At least 90% of what I know and do with client modification, is trial and error, and logical guessing.
I find the odd new trick to help ease the debugging process, and look for patterns in memory to help also.
I'm still trying to wrap my head around all the different functions within the eo client. There is so much to go through..
It's hard to know which functions do what sometimes, and which modifications would apply to which function.

I couldn't really do much to help you currently, as I have very little experience in programming/assembly, but I can provide any addresses/opcodes you may need.
Feel free to ask if there is something specific. Maybe I can help more in the future also once I really get into assembly, and learn more important stuff.

Callum
Don't worry, I don't take offense very easily anyways, especially over the internet.. I never thought your intent was to offend anyways.. xD
I agree about finally having a custom client done in c++. That would be the best end result.

It will be a long time before a fully functional client is actually released.
That is why I mess with debugging and modifying the client.
Bypass as many client side limitations as possible, while we await a custom client. It's all we can do for now unfortunately.





---
EO Resources/Guides: ◄eoguide.boards.net►
1 year, 6 weeks ago
Page: << 1 2 3 >>

EOSERV Forum > EOSERV > Quest rule for handling "Cancel" button in dialog?