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

The problem with fixing things that are required for your server to function (like your quest dialogs) with EO.Addons is that you have to assume and/or force everyone to use them. The whole quest thing could be fixed but with some massive assumptions. Reminds me of the EOJobs addon. Yes, I can make an addon to use it but you have to force everyone that uses the server to use the addon.

Slightly off-topic but as for the keyboard leak problem: The way the client gets keyboard input is totally bizarre. Vults code uses a keyboard hook, which I assume he did to try and prevent trainers/bots from working, however he totally misunderstood how input hooks work and achieved no protection from bots while simultaneously making EO grab keypresses while not active. I've already fixed this but just as a side effect of how the EOInjectInput addon works. EOInjectInput sits between Vults code and actual keyboard input allowing other addons to simulate both mouse and keyboard input while also rejecting any input if the client window isn't active.

---
http://sordie.co.uk
http://twitter.com/@SordieEO

Plasmastar
Ok, I understand. I realize now that what I was suggesting for it wouldn't work.
The pointer I was talking about shows 1 when a quest dialog is open, and 0 when it's closed.
I didn't think hard enough though, because either way, there would still be no way to know if the cancel button, the ok button, or a quest npc input was selected. I thought there could possibly be something related to that address, and pressing the cancel button, that could be used to verify if the cancel button was pressed or not, but it looks like that's not the case after looking into it more and hearing from you..

Nothing wrong with using addons, but personally I would hope to see this implemented server side.
Maybe it's too cheap to do it this way, and maybe not even feasible, but couldn't you do something like the below, server side?

First of all, you could read clients memory for the pointer that holds the 'window state' address/value.
Pointer 6cba40+2c+250+0+278+84   (0 = Active Window), (1= Minimized by Taskbar), (2= Minimized by - Button)

Then you could write to the clients memory to activate/deactivate keyboard functioning depending on the pointer/window state.
Address: 00401ABC Light Dark.TMainFormActivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],01
Address: 00401AC4 Light Dark.TMainFormDeactivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],00
Address: 00401ACC Light Dark.TMainFormMinimizeForm$qqrp14SystemTObject - C6 80 2C040000 01     - mov byte ptr [eax+0000042C],01
Address: 00401AD4 Light Dark.TMainFormRestoreForm$qqrp14SystemTObject - C6 80 2C040000 00     - mov byte ptr [eax+0000042C],00

If this is a stupid idea, let me know.. xD

Sordie
Very useful information, thanks.
In regards to anti chat leak, I would think this would be possible to do server side.
Maybe it's just me, but I'd rather not use an addon to prevent chat leak, if it's doable server side.
(Pretty much what I said in response to Plasmastar.) Again, I'm not sure if that's a bad idea or not. I can't stress that point enough. =d

---
EO Resources/Guides: â—„ eobud.boards.net â–º

shayne posted: (6th Mar 2017, 11:26 pm)

Hacker_Alex posted: (6th Mar 2017, 07:02 pm)

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

Then provoke a hack server side to stop players from being able to chat, or just block chatting..
Then you can reactivate chat once the value of the pointer is 0 (active).

0= Active
1= Minimized by 'task bar' (Chat Leak)
2= Minimized by '-button'

Maybe there is a way to do it with the client alone, but I'm not really sure, and haven't messed around enough yet. =/

Providing a server side fix is useless. Any server owner can surely block the chat, but who's to say they arent recording what the client is saying for themselves. Like if a server owner knew when a client is minimized, they could effectively turn their server into a keylogger.

Without knowing when the client is minimized, they have to search through ALL their chat data to look for leaked data. But with knowing when it's minimized, they have effectively filtered out what they don't need.

[quote]
Maybe it's too cheap to do it this way, and maybe not even feasible, but couldn't you do something like the below, server side?

First of all, you could read clients memory for the pointer that holds the 'window state' address/value.
Pointer 6cba40+2c+250+0+278+84   (0 = Active Window), (1= Minimized by Taskbar), (2= Minimized by - Button)

Then you could write to the clients memory to activate/deactivate keyboard functioning depending on the pointer/window state.
Address: 00401ABC Light Dark.TMainFormActivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],01
Address: 00401AC4 Light Dark.TMainFormDeactivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],00
Address: 00401ACC Light Dark.TMainFormMinimizeForm$qqrp14SystemTObject - C6 80 2C040000 01     - mov byte ptr [eax+0000042C],01
Address: 00401AD4 Light Dark.TMainFormRestoreForm$qqrp14SystemTObject - C6 80 2C040000 00     - mov byte ptr [eax+0000042C],00
[/quote]

I don't think you quite get how the client and server work.

The client is a closed box [CLIENT] and the server is a closed box [SERVER]
[CLIENT] --> [SERVER]
[CLIENT] <-- [SERVER]

the server and client communicate using a pre-built set of "phrases" ; you're limited to modifying the possible phrases used and their actions by whichever box you do not have the means of editing and re-compiling. In this case we are limited by the set of phrases Vult programmed in the client, and the actions they do to the client.

The phrases are simply things to make the game work like
(phrases that can be sent by the client) "Im adding 3 items into the locker". "I just attacked", "I just moved 1 tile north", "I want to login with this username and password".
(phrases that can be received by the client) "Hey this person wants to trade you, do you accept?", "there's a player here here and here and they are wearing this and that, this ones sitting", "Here's the next map you requested", "Hey this monster just died", "Hey here's 90 exp", and so on

You can't make up new phrases that can be used. And we certainly aren't aware of the existance of a phrase that let's us read/write the client's memory haha. (most likely is inexistant but if you want to you can scoure the executable for packet types we yet havent discovered.)

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Hacker_Alex posted: (8th Mar 2017, 12:49 am)

shayne posted: (6th Mar 2017, 11:26 pm)

Hacker_Alex posted: (6th Mar 2017, 07:02 pm)

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

Then provoke a hack server side to stop players from being able to chat, or just block chatting..
Then you can reactivate chat once the value of the pointer is 0 (active).

0= Active
1= Minimized by 'task bar' (Chat Leak)
2= Minimized by '-button'

Maybe there is a way to do it with the client alone, but I'm not really sure, and haven't messed around enough yet. =/

Providing a server side fix is useless. Any server owner can surely block the chat, but who's to say they arent recording what the client is saying for themselves. Like if a server owner knew when a client is minimized, they could effectively turn their server into a keylogger.

Without knowing when the client is minimized, they have to search through ALL their chat data to look for leaked data. But with knowing when it's minimized, they have effectively filtered out what they don't need.

[quote]Maybe it's too cheap to do it this way, and maybe not even feasible, but couldn't you do something like the below, server side?

First of all, you could read clients memory for the pointer that holds the 'window state' address/value.
Pointer 6cba40+2c+250+0+278+84   (0 = Active Window), (1= Minimized by Taskbar), (2= Minimized by - Button)

Then you could write to the clients memory to activate/deactivate keyboard functioning depending on the pointer/window state.
Address: 00401ABC Light Dark.TMainFormActivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],01
Address: 00401AC4 Light Dark.TMainFormDeactivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],00
Address: 00401ACC Light Dark.TMainFormMinimizeForm$qqrp14SystemTObject - C6 80 2C040000 01     - mov byte ptr [eax+0000042C],01
Address: 00401AD4 Light Dark.TMainFormRestoreForm$qqrp14SystemTObject - C6 80 2C040000 00     - mov byte ptr [eax+0000042C],00[/quote]

I don't think you quite get how the client and server work.

The client is a closed box [CLIENT] and the server is a closed box [SERVER]

the server and client communicate using a pre-built set of "phrases" ; you're limited to modifying the possible phrases used and their actions by whichever box you do not have the means of editing and re-compiling. In this case we are limited by the set of phrases Vult programmed in the client, and the actions they do to the client.

The phrases are simply things to make the game work like
(phrases that can be sent by the client) "Im adding 3 items into the locker". "I just attacked", "I just moved 1 tile north", "I want to login with this username and password".
(phrases that can be received by the client) "Hey this person wants to trade you, do you accept?", "there's a player here here and here and they are wearing this and that, this ones sitting", "Here's the next map you requested", "Hey this monster just died", "Hey here's 90 exp", and so on

You can't make up new phrases that can be used. And we certainly aren't aware of the existance of a phrase that let's us read/write the client's memory haha. (most likely is inexistant but if you want to you can scoure the executable for packet types we yet havent discovered.)

That is a good point. But it would still be nice to have a server-side solution. If I am hosting the server, the personal information of others would be unwanted from me and their security is very important to me. I think the main concern with this chat leak, is that other players could take advantage of your personal information, rather then a server host who probably has bigger fish to fry.

---
Just your friendly neighborhood Programmer-Man!

Shilo posted: (8th Mar 2017, 01:12 am)

Hacker_Alex posted: (8th Mar 2017, 12:49 am)

shayne posted: (6th Mar 2017, 11:26 pm)

Hacker_Alex posted: (6th Mar 2017, 07:02 pm)

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

Then provoke a hack server side to stop players from being able to chat, or just block chatting..
Then you can reactivate chat once the value of the pointer is 0 (active).

0= Active
1= Minimized by 'task bar' (Chat Leak)
2= Minimized by '-button'

Maybe there is a way to do it with the client alone, but I'm not really sure, and haven't messed around enough yet. =/

Providing a server side fix is useless. Any server owner can surely block the chat, but who's to say they arent recording what the client is saying for themselves. Like if a server owner knew when a client is minimized, they could effectively turn their server into a keylogger.

Without knowing when the client is minimized, they have to search through ALL their chat data to look for leaked data. But with knowing when it's minimized, they have effectively filtered out what they don't need.

[quote]Maybe it's too cheap to do it this way, and maybe not even feasible, but couldn't you do something like the below, server side?

First of all, you could read clients memory for the pointer that holds the 'window state' address/value.
Pointer 6cba40+2c+250+0+278+84   (0 = Active Window), (1= Minimized by Taskbar), (2= Minimized by - Button)

Then you could write to the clients memory to activate/deactivate keyboard functioning depending on the pointer/window state.
Address: 00401ABC Light Dark.TMainFormActivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],01
Address: 00401AC4 Light Dark.TMainFormDeactivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],00
Address: 00401ACC Light Dark.TMainFormMinimizeForm$qqrp14SystemTObject - C6 80 2C040000 01     - mov byte ptr [eax+0000042C],01
Address: 00401AD4 Light Dark.TMainFormRestoreForm$qqrp14SystemTObject - C6 80 2C040000 00     - mov byte ptr [eax+0000042C],00[/quote]

I don't think you quite get how the client and server work.

The client is a closed box [CLIENT] and the server is a closed box [SERVER]

the server and client communicate using a pre-built set of "phrases" ; you're limited to modifying the possible phrases used and their actions by whichever box you do not have the means of editing and re-compiling. In this case we are limited by the set of phrases Vult programmed in the client, and the actions they do to the client.

The phrases are simply things to make the game work like
(phrases that can be sent by the client) "Im adding 3 items into the locker". "I just attacked", "I just moved 1 tile north", "I want to login with this username and password".
(phrases that can be received by the client) "Hey this person wants to trade you, do you accept?", "there's a player here here and here and they are wearing this and that, this ones sitting", "Here's the next map you requested", "Hey this monster just died", "Hey here's 90 exp", and so on

You can't make up new phrases that can be used. And we certainly aren't aware of the existance of a phrase that let's us read/write the client's memory haha. (most likely is inexistant but if you want to you can scoure the executable for packet types we yet havent discovered.)

That is a good point. But it would still be nice to have a server-side question. If I am hosting the server, the personal information of others would be unwanted from me and their security is very important to me. I think the main concern with this chat leak, is that other players could take advantage of your personal information, rather then a server host who probably has bigger fish to fry.

The point is, there's no point of going into the sketchy part of town into the criminals' den whom you can already convict and put in jail, just to get their pictures and warn all the shop keepers by providing a picture of these criminals. Which may or may not help the public.

There is no server-side cure for this. And you're not going to go into the client and modify it to warn the server when this happens, when this is more complicated than just fixing the problem that you can fix because you're already modifying the client.

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Not trying to be rude Hacker_Alex, but your post always seem really unconstructive, some of us are server owners who are just trying to better our servers without bad intent I am not claiming everyone is clean, but if your not going to be constructively helpful, please stop making rude post. This isn't the only one I have seen and its a little irritating course I assume your free to post however you want... but don't you think it would be less spammy and more helpful if you actually had helpful information?

---
Graphics Designer.
"I'll keep believing in the future, not caring if anyone laughs at me"
Hi : D I am me!

MezPez9358 posted: (8th Mar 2017, 04:11 am)

Not trying to be rude Hacker_Alex, but your post always seem really unconstructive, some of us are server owners who are just trying to better our servers without bad intent I am not claiming everyone is clean, but if your not going to be constructively helpful, please stop making rude post. This isn't the only one I have seen and its a little irritating course I assume your free to post however you want... but don't you think it would be less spammy and more helpful if you actually had helpful information?

You do not seem to understand the topic. It is quite hurtful to me that you would not understand the topic and go all ahead to call my post unconstructive and spammy. I am always here trying to help as much as I can. If you have any challenges understanding what I am putting forward, please ask as many questions as you may have, as I would love to help you understand.


If you didn't catch it, the chat leak bug is undetectable by the server. The only way to detect it is with client hacks.

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Wanting to be here to help and actually helping are 2 different things.... Just saying that sometimes it seems like half of your post always seem to say something helpful but at the same time insulting..... and it can be upsetting to some people or offensive :/ that's all i am saying bud. Just my opinion though I guess.

---
Graphics Designer.
"I'll keep believing in the future, not caring if anyone laughs at me"
Hi : D I am me!

I don't think its a matter of understanding the topic or not. I get that you are trying to help and you had a good point along with useful info. But in my opinion, your last post didn't seem constructive to me. Thank you for the help though!

---
Just your friendly neighborhood Programmer-Man!

Hacker_Alex posted: (8th Mar 2017, 12:49 am)

shayne posted: (6th Mar 2017, 11:26 pm)

Hacker_Alex posted: (6th Mar 2017, 07:02 pm)

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

Then provoke a hack server side to stop players from being able to chat, or just block chatting..
Then you can reactivate chat once the value of the pointer is 0 (active).

0= Active
1= Minimized by 'task bar' (Chat Leak)
2= Minimized by '-button'

Maybe there is a way to do it with the client alone, but I'm not really sure, and haven't messed around enough yet. =/

Providing a server side fix is useless. Any server owner can surely block the chat, but who's to say they arent recording what the client is saying for themselves. Like if a server owner knew when a client is minimized, they could effectively turn their server into a keylogger.

Without knowing when the client is minimized, they have to search through ALL their chat data to look for leaked data. But with knowing when it's minimized, they have effectively filtered out what they don't need.

[quote]
Maybe it's too cheap to do it this way, and maybe not even feasible, but couldn't you do something like the below, server side?

First of all, you could read clients memory for the pointer that holds the 'window state' address/value.
Pointer 6cba40+2c+250+0+278+84   (0 = Active Window), (1= Minimized by Taskbar), (2= Minimized by - Button)

Then you could write to the clients memory to activate/deactivate keyboard functioning depending on the pointer/window state.
Address: 00401ABC Light Dark.TMainFormActivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],01
Address: 00401AC4 Light Dark.TMainFormDeactivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],00
Address: 00401ACC Light Dark.TMainFormMinimizeForm$qqrp14SystemTObject - C6 80 2C040000 01     - mov byte ptr [eax+0000042C],01
Address: 00401AD4 Light Dark.TMainFormRestoreForm$qqrp14SystemTObject - C6 80 2C040000 00     - mov byte ptr [eax+0000042C],00
[/quote]

I don't think you quite get how the client and server work.

The client is a closed box [CLIENT] and the server is a closed box [SERVER]
[CLIENT] --> [SERVER]
[CLIENT] <-- [SERVER]

the server and client communicate using a pre-built set of "phrases" ; you're limited to modifying the possible phrases used and their actions by whichever box you do not have the means of editing and re-compiling. In this case we are limited by the set of phrases Vult programmed in the client, and the actions they do to the client.

The phrases are simply things to make the game work like
(phrases that can be sent by the client) "Im adding 3 items into the locker". "I just attacked", "I just moved 1 tile north", "I want to login with this username and password".
(phrases that can be received by the client) "Hey this person wants to trade you, do you accept?", "there's a player here here and here and they are wearing this and that, this ones sitting", "Here's the next map you requested", "Hey this monster just died", "Hey here's 90 exp", and so on

You can't make up new phrases that can be used. And we certainly aren't aware of the existance of a phrase that let's us read/write the client's memory haha. (most likely is inexistant but if you want to you can scoure the executable for packet types we yet havent discovered.)

I get how the server and client interact with each other. (Some what)
My main point was about reading the pointer server side, so you know when the client is minimized, active, or minimized with chat leak active..

Really all you need to do is read a multi level pointer, than block or unblock chat depending on the addresses value.
I really don't understand why this can't be done server side. It can definitely be done I'd think, even if it's a shitty idea. (Which I'm still not sure of.)

If someone wants to turn there server into a keylogger, they could do it by other means then this. There is a million ways you could do this without depending on knowing if a client is minimized or not, no? It's not like that would make it less detectable?

I wasn't suggesting you had to block or unblock chat with the addresses/opcodes I provided, it was just a relative example, and how I actually had to do it when I made my shitty test program to achieve this.. (I have little, to no programming experience to do this server side, or I would have tried it already.)

Don't even consider the blocking chat part I was referring to, the whole point of my post/problem is for a way to know whether the client is active, minimized, or minimized with chat leak.
(Which you could easily know server side by reading the clients memory for the 'Window State'  ML Pointer)

Edit: To go off topic, I'd generally have to agree with Hacker_Alex.
He has a pretty good understanding of things, especially programmatically. All that really matters, is that he tries to help others whenever he can.
Not many people do this, especially around here, so I have only good things to say about people like that..

---
EO Resources/Guides: â—„ eobud.boards.net â–º

shayne posted: (8th Mar 2017, 01:38 pm)

Hacker_Alex posted: (8th Mar 2017, 12:49 am)

shayne posted: (6th Mar 2017, 11:26 pm)

Hacker_Alex posted: (6th Mar 2017, 07:02 pm)

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

Then provoke a hack server side to stop players from being able to chat, or just block chatting..
Then you can reactivate chat once the value of the pointer is 0 (active).

0= Active
1= Minimized by 'task bar' (Chat Leak)
2= Minimized by '-button'

Maybe there is a way to do it with the client alone, but I'm not really sure, and haven't messed around enough yet. =/

Providing a server side fix is useless. Any server owner can surely block the chat, but who's to say they arent recording what the client is saying for themselves. Like if a server owner knew when a client is minimized, they could effectively turn their server into a keylogger.

Without knowing when the client is minimized, they have to search through ALL their chat data to look for leaked data. But with knowing when it's minimized, they have effectively filtered out what they don't need.

[quote]
Maybe it's too cheap to do it this way, and maybe not even feasible, but couldn't you do something like the below, server side?

First of all, you could read clients memory for the pointer that holds the 'window state' address/value.
Pointer 6cba40+2c+250+0+278+84   (0 = Active Window), (1= Minimized by Taskbar), (2= Minimized by - Button)

Then you could write to the clients memory to activate/deactivate keyboard functioning depending on the pointer/window state.
Address: 00401ABC Light Dark.TMainFormActivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],01
Address: 00401AC4 Light Dark.TMainFormDeactivateForm$qqrp14SystemTObject - C6 80 2D040000 01     - mov byte ptr [eax+0000042D],00
Address: 00401ACC Light Dark.TMainFormMinimizeForm$qqrp14SystemTObject - C6 80 2C040000 01     - mov byte ptr [eax+0000042C],01
Address: 00401AD4 Light Dark.TMainFormRestoreForm$qqrp14SystemTObject - C6 80 2C040000 00     - mov byte ptr [eax+0000042C],00
[/quote]

I don't think you quite get how the client and server work.

The client is a closed box [CLIENT] and the server is a closed box [SERVER]
[CLIENT] --> [SERVER]
[CLIENT] <-- [SERVER]

the server and client communicate using a pre-built set of "phrases" ; you're limited to modifying the possible phrases used and their actions by whichever box you do not have the means of editing and re-compiling. In this case we are limited by the set of phrases Vult programmed in the client, and the actions they do to the client.

The phrases are simply things to make the game work like
(phrases that can be sent by the client) "Im adding 3 items into the locker". "I just attacked", "I just moved 1 tile north", "I want to login with this username and password".
(phrases that can be received by the client) "Hey this person wants to trade you, do you accept?", "there's a player here here and here and they are wearing this and that, this ones sitting", "Here's the next map you requested", "Hey this monster just died", "Hey here's 90 exp", and so on

You can't make up new phrases that can be used. And we certainly aren't aware of the existance of a phrase that let's us read/write the client's memory haha. (most likely is inexistant but if you want to you can scoure the executable for packet types we yet havent discovered.)

I get how the server and client interact with each other. (Some what)
My main point was about reading the pointer server side, so you know when the client is minimized, active, or minimized with chat leak active..

Really all you need to do is read a multi level pointer, than block or unblock chat depending on the addresses value.
I really don't understand why this can't be done server side. It can definitely be done I'd think, even if it's a shitty idea. (Which I'm still not sure of.)

If someone wants to turn there server into a keylogger, they could do it by other means then this. There is a million ways you could do this without depending on knowing if a client is minimized or not, no? It's not like that would make it less detectable?

I wasn't suggesting you had to block or unblock chat with the addresses/opcodes I provided, it was just a relative example, and how I actually had to do it when I made my shitty test program to achieve this.. (I have little, to no programming experience to do this server side, or I would have tried it already.)

Don't even consider the blocking chat part I was referring to, the whole point of my post/problem is for a way to know whether the client is active, minimized, or minimized with chat leak.
(Which you could easily know server side by reading the clients memory for the 'Window State'  ML Pointer)

Edit: To go off topic, I'd generally have to agree with Hacker_Alex.
He has a pretty good understanding of things, especially programmatically. All that really matters, is that he tries to help others whenever he can.
Not many people do this, especially around here, so I have only good things to say about people like that..

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.

It might not be the best solution, but has anyone put any thought into patching this server-side? I've had some thoughts about giving players an option to stop the server sending their public chats while afk. (Make an afk timer for 5-7 mins). Or just make it do it by default and give them a command to opt out of it?.

Shilo posted: (8th Mar 2017, 06:25 am)

I don't think its a matter of understanding the topic or not. I get that you are trying to help and you had a good point along with useful info. But in my opinion, your last post didn't seem constructive to me. Thank you for the help though!

I was explaining to you the situation at hand. I apologize if you took the analogy the wrong way. I am explaining that if you are a police man and are going to the criminal's house because you have proof they have done the crime. Of course you would arrest them and put them in jail.

But what's being described "The server reading the pointer" is equivelant to going to the criminal's house and maybe injecting a tracker into the person's body and then giving (in the case that this criminal robs stores) all store owners a computer program that shows on the GPS where this criminal is so that they can block them.

When you have the choice of arresting the criminal, you will not do something more complicated that only gets the job done in some of the cases. You will arrest the criminal because that gets the job done for all the cases.

I don't understand how my posts are un-constructive.

I'm simply replying to peoples' comments. I'm not trying to single anyone out or make them feel bad. Well I'm sorry that I'm so sure that I'm correct, but if you would thoroughly read and understand my explanation, you would agree as well and understand that there will not be a way to block chat on the server side when the game is minimized, because no one in their right mind would put a tracker inside the person and let them be free instead of arrest them on the spot.

Programs on a remote computer are not allowed to read or modify memory on another computer.

Imagine how wrong it would be if anyone could write code to read memory off a server such as okay a banking server. They'd be able to see exactly what code is running, and use that to their freedom to develop hacks to steal money. If they could inject their own code and it could do anything.

Your computer is no different from a bank server. If you're running windows or mac, the operating system protects your computer from outside attacks by not allowing your computer memory to be read and edited from a remote computer.
 
Truth be told you would need code in the first place running on your computer that would be able to understand commands from a remote server to do such a thing as read memory or write to memory. So this statement is fine for people who haven't studied how their operating system works, but misleading for people who do understand how their OS works.

I'm not going to post anymore since it would appear that I'm spamming the same ideas over and over again.


@Callum

That's a really cool idea that doesn't involve hacking the client! :]

@Everyone

Well I wasn't trying to say there's no other way of doing it, I meant in the case of detecting when the client is minimzed, no one will hack a permanent solution into the client that will warn the server, because that involves injecting custom code that sends information to the server, when that injected custom code can instead contain the solution to disabling chat when the game is minimized. It might be the case of the way I understand things in my head doesn't align with the way anyone else understands things..

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

@Callum
I agree. This is the main reason I decided to remove all developer support for EO.Addons. It's simply too dangerous.

@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

---
http://sordie.co.uk
http://twitter.com/@SordieEO

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 not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

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.