Potential cheating fix, crowdsourced and working

wayfarerx

Troneon wrote: »

I disabled java on my computer years ago due to

1) It is very very very unsecure...

2) Most viruses/exploits/vulns are written in java...or used to be anyway...

Do yourself a favor and get rid of java, then disable it completely from your OS.

Only good thing it ever did was help run minecraft mods...which I don't play anymore.

To be clear:

• The implementation of Java Applet support has historically been plagued by exploits. You are right to disable Applets in all your browsers.
• Java applications that you download and execute are just as secure (if not more so) than any other application you download.

SirAndy

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

yodased

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

estera

And what if someone would not what to run program with administrative rights (required to access other process's memory) from an unknown publisher that send unspecified data to remote server?

SirAndy wrote: »

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

This.

yodased

estera wrote: »

And what if someone would not what to run program with administrative rights (required to access other process's memory) from an unknown publisher that send unspecified data to remote server?

SirAndy wrote: »

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

This.

You guys can get all high horse as you want, but what are you doing to try to make this better?

SwaminoNowlino

yodased wrote: »

estera wrote: »

And what if someone would not what to run program with administrative rights (required to access other process's memory) from an unknown publisher that send unspecified data to remote server?

SirAndy wrote: »

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

This.

You guys can get all high horse as you want, but what are you doing to try to make this better?

Nothing. #ConsoleMasterRace

LegacyDM

yodased wrote: »

Potential solution to memory hacking:

Create a java program that you would run alongside eso.exe similar to ohgma infinium that checks for known memory hacks. When you zone into pvp, check for hacks and then broadcast to zone if memory is altered by a third party hook.

It's not foolproof, but it would keep the honest thieves honest.

Would you all use something like this? Would you run something that proved you were not using a cheat engine?

Do you like pina coladas? and getting caught in the rain?

Im not sure I understand. Is this an addon you would create running in the background independently of ZOS? Or something your pitching to ZOS as mandatory as part of the game? ZOS is pretty elitist and if they haven't already internally designed or bought a program like punk buster they probably won't pay any attention to you.

If this is a third party addon I'm sure your a good guy in rl, but I don't know you and how do I know your not designing a keylogger and stealing my bank credentials or eso credentials? Your asking people to install a third party software from someone they don't know. Unless it's endorsed by ZOS, I'm just not sure.

yodased

LegacyDM wrote: »

yodased wrote: »

Potential solution to memory hacking:

Create a java program that you would run alongside eso.exe similar to ohgma infinium that checks for known memory hacks. When you zone into pvp, check for hacks and then broadcast to zone if memory is altered by a third party hook.

It's not foolproof, but it would keep the honest thieves honest.

Would you all use something like this? Would you run something that proved you were not using a cheat engine?

Do you like pina coladas? and getting caught in the rain?

Im not sure I understand. Is this an addon you would create running in the background independently of ZOS? Or something your pitching to ZOS as mandatory as part of the game? ZOS is pretty elitist and if they haven't already internally designed or bought a program like punk buster they probably won't pay any attention to you.

If this is a third party addon I'm sure your a good guy in rl, but I don't know you and how do I know your not designing a keylogger and stealing my bank credentials or eso credentials? Your asking people to install a third party software from someone they don't know. Unless it's endorsed by ZOS, I'm just not sure.

This is a java program that will be sent through the appropriate vetting process, which you voluntarily download and run while you run ESO. The program will scan memory for the process of cheat engine and report the process running to the server.

The plugin will then put a text file in a temporary document to a plugin being run in ESO, which will then verify that there are no processes associated with cheating being run with that account.

Its not perfect and yest it requires you to trust me, but I'm trying something and open to interpretation and constructive criticism

FriedEggSandwich

SwaminoNowlino wrote: »

yodased wrote: »

estera wrote: »

And what if someone would not what to run program with administrative rights (required to access other process's memory) from an unknown publisher that send unspecified data to remote server?

SirAndy wrote: »

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

This.

You guys can get all high horse as you want, but what are you doing to try to make this better?

Nothing. #ConsoleMasterRace

This is also what you have to do while waiting for a hotfix right?

yodased

http://esocheaters.com/ is up, i'll have something to be able to report cheating *** by the end of the day

estera

yodased wrote: »

You guys can get all high horse as you want, but what are you doing to try to make this better?

Help -> Ask for Help -> Report Player

wayfarerx

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

The argument against your idea is not so much that it's impossible. You are venturing into a very sophisticated and fast-moving area of technology. Writing a tamper-proof piece of software that you plan on handing to you adversaries and letting them run on their own hardware is one of the most difficult tasks in software engineering. Apple has billions of dollars in motivation and world class engineers and they can't even shut down the iPhone jailbreaks.

yodased

wayfarerx wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

The argument against your idea is not so much that it's impossible. You are venturing into a very sophisticated and fast-moving area of technology. Writing a tamper-proof piece of software that you plan on handing to you adversaries and letting them run on their own hardware is one of the most difficult tasks in software engineering. Apple has billions of dollars in motivation and world class engineers and they can't even shut down the iPhone jailbreaks.

Alas, I have to try. Fail or not, I'm going to *** do SOMETHING.

SirAndy

yodased wrote: »

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

If you're checking a verified server response, then why do you need another app? The ESO client could do that just as well. The problem is that ESO is not designed that way. There is very little server "validation". That's the real problem.

Also, what good will checking running processes do? Anyone with 6 months of C/C++ experience can write their own tool to read and write ESO's memory. Yes, it's that simple.
How would a 3rd party app know which process does what? Your PC is running 100+ processes already and each PC will have a multitude of different processes.

You really think everyone will call their program "CheatEngine.exe" so you can easily spot it in the process list?

yodased

SirAndy wrote: »

yodased wrote: »

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

If you're checking a verified server response, then why do you need another app? The ESO client could do that just as well. The problem is that ESO is not designed that way. There is very little server "validation". That's the real problem.

Also, what good will checking running processes do? Anyone with 6 months of C/C++ experience can write their own tool to read and write ESO's memory. Yes, it's that simple.
How would a 3rd party app know which process does what? Your PC is running 100+ processes already and each PC will have a multitude of different processes.

You really think everyone will call their program "CheatEngine.exe" so you can easily spot it in the process list?

Again we are searching for those that are running a script they found on the internet to cheat on ESO. This is not targeted those who are actively editing memory and know how this actually works.

These people are not 'hackers' they are just cheaters, which we can identify.

InvitationNotFound

haven't read all yet, no time sorry.

just my input here:
1)if it's something not everyone is going to use it's useless. cheaters won't use it and you can't force anyone to install any additional software. I'm not cheating but why should i run some untrusted application on my system?
2) It's client side. Therefore, it's just a matter of effort to bypass this system, telling the game and other players "hey look, it's running here", while it is doing nothing at all.
3) CE is just the name of an application. There are certainly more and will end up in a cat-and-mouse game where the cheater (respectively author) simply adjusts his tools until you detect it again.

A server side verification of what is happening would make more sense in my opinion. but you can be certain ZOS won't do that.

Wreuntzylla

How much will you be charging for the account login data you send back to the server? I'm in for the accounts of the ten top guild store merchants on both PC NA and console.

Someone please come up with an idea ZoS can implement on the server side...

Rohamad_Ali

yodased wrote: »

wayfarerx wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

The argument against your idea is not so much that it's impossible. You are venturing into a very sophisticated and fast-moving area of technology. Writing a tamper-proof piece of software that you plan on handing to you adversaries and letting them run on their own hardware is one of the most difficult tasks in software engineering. Apple has billions of dollars in motivation and world class engineers and they can't even shut down the iPhone jailbreaks.

Alas, I have to try. Fail or not, I'm going to *** do SOMETHING.

I feel like we're right here in the movie

estera

Wreuntzylla wrote: »

Someone please come up with an idea ZoS can implement on the server side...

It was implemented long time ago as a botting prevention measure and server-size checks ruined PvP performance.
My guess - at least some of these checks were disabled to make Cyrodiil playable.

Uriel_Nocturne

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

So, it's a glorified "Naming & Shaming" in the Zone chat.

Which also happens to be against the ToS for the game.

Just saying.

yodased

Uriel_Nocturne wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

So, it's a glorified "Naming & Shaming" in the Zone chat.

Which also happens to be against the ToS for the game.

Just saying.

Naming and shaming on properties they control is against their terms of service. They can't stop me from creating my own list of players that are known cheaters and broadcasting that to the planet, as long as I'm not infringing on their IP.

InvitationNotFound

estera wrote: »

Wreuntzylla wrote: »

Someone please come up with an idea ZoS can implement on the server side...

It was implemented long time ago and server-size checks ruined PvP performance.
These checks were disabled to make Cyrodiil playable.

@estera as far is i know they moved some checks to the server because of botting, not cheating. (still looking for an official ZOS statement here)

anyway, please provide a reference to the statement where ZOS said that they disabled these checks.

Recremen

Incoming source code fork that implements a keylogger and broadcasts to zone your recent browser history. Millions of downloads.

wayfarerx

Uriel_Nocturne wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

So, it's a glorified "Naming & Shaming" in the Zone chat.

Which also happens to be against the ToS for the game.

Just saying.

If you want a name-and-shame app I think a better solution would be to just make a web app that people can log into and report the names of cheaters. You could even build out some addons and connectivity apps to make it work from in-game and automatically upload reports to your server. You'd still have to deal with trusting individual users and ferreting out troll reports and the like, but at least the users of your software would not also be your adversaries as well.

Whether such an app, site or even this comment suggesting them is against the TOS is up for debate.

yodased

@wayfarerx http://esocheaters.com ok

wayfarerx

yodased wrote: »

@wayfarerx http://esocheaters.com ok

Okay reporting @yodased now

LegacyDM

yodased wrote: »

Uriel_Nocturne wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

So, it's a glorified "Naming & Shaming" in the Zone chat.

Which also happens to be against the ToS for the game.

Just saying.

Naming and shaming on properties they control is against their terms of service. They can't stop me from creating my own list of players that are known cheaters and broadcasting that to the planet, as long as I'm not infringing on their IP.

Be careful because if you get it wrong and name someone who is not cheating and post it on a website and get them wrongfully banned on a game they subscribe/pay to you Might get into legal troubles.

Rohamad_Ali

LegacyDM wrote: »

yodased wrote: »

Uriel_Nocturne wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

So, it's a glorified "Naming & Shaming" in the Zone chat.

Which also happens to be against the ToS for the game.

Just saying.

Naming and shaming on properties they control is against their terms of service. They can't stop me from creating my own list of players that are known cheaters and broadcasting that to the planet, as long as I'm not infringing on their IP.

Be careful because if you get it wrong and name someone who is not cheating and post it on a website and get them wrongfully banned on a game they subscribe/pay to you Might get into legal troubles.

Still waiting on that Ashley Madison settlement check ...

booksmcread

yodased wrote: »

wayfarerx wrote: »

yodased wrote: »

SirAndy wrote: »

yodased wrote: »

check for hacks and then broadcast to zone if memory is altered by a third party hook.

Won't work.

- The 3rd party app can be easily duped. The app has to compare memory values against a list of know good memory values. The attack angle would be simple, change what the 3rd party app believes to be "known to be good".
- A lot of the hacks change number in memory offsets that change on a regular basis anyways. So simply looking for a change won't work.
- Java is probably the worst possible language to use, you can use an off the shelf java decompiler to get the source code back, making it stupidly easy to hack.

This is a circular argument. You're simply moving the client side validation from one app to another. Adding one more step does nothing to make this more secure.

The *only* way to get rid of the client side cheating is to eliminate all and any client side trust.

But I'm not just trusting the client, this will check for processes running and then check for an expected response verified by the server.

I am not trying to stop the cheating from being possible here, just giving the community the ability to at least potentially identify those who are.

The argument against your idea is not so much that it's impossible. You are venturing into a very sophisticated and fast-moving area of technology. Writing a tamper-proof piece of software that you plan on handing to you adversaries and letting them run on their own hardware is one of the most difficult tasks in software engineering. Apple has billions of dollars in motivation and world class engineers and they can't even shut down the iPhone jailbreaks.

Alas, I have to try. Fail or not, I'm going to *** do SOMETHING.

As far as I can tell, it's more than what ZOS is doing.

estera

InvitationNotFound wrote: »

@estera as far is i know they moved some checks to the server because of botting, not cheating. (still looking for an official ZOS statement here)

anyway, please provide a reference to the statement where ZOS said that they disabled these checks.

You are correct this was a botting-prevention measure and bots population dropped significantly afterward. It became possible to gather crafting materials again.

There was no official statement on disabled check, only an observable Cyrodiil performance recovery after few days of terrible lags.
I've updated my post to make is sounds like my personal opinion rather than proven fact.