We don’t know what is available on the client-side yet for users to exploit, but we know with the base of some exploits already discovered that the server trusts the client in some aspects. What is happening now is exploiters digging the communication between client and server to find out what they can exploit. That is why on these issues they only release mitigations, not a proper fix.
The gold dupe on the server transfer was a clearly evidence that just using an old trick of cutting the communication with the server, can avoid some sort of transaction on the server-side to be completed.
Imagine disqualifieng all YouTubers without any evidence.
Impossible to proof unless you’re a dev. Even then, its risky to proof because it’ll involve making public proprietary code. If you say to prove regardless, by extension you are demanding the game go open sourced.
Even a statement is hard because it’ll probably reveal enough information to expose said code to further exploits.
Its like a robber asking the bank to prove that 111 is not the pin to the safe. The bank says/proof its not, and now the robber knows 111 is not the pin. The robber than ask the bank to prove that 222 is not the pin to the safe… etc. Eventually the robber figures out that 123 is the pin without the bank even telling the robber or the robber asking straight up what the pin to the safe is.
I don’t know what exactly streamers or YouTubers people refer to, they always put all in one pack ignoring they are different people with different backgrounds.
The tests themselves on exploits already discovered already prove the meanings, don’t even need to see the code for it. It is an old trick faced by many games and applications in the past and until today.
The current exploits discovered to not fit on this example.
Here’s the thing, without access to the code itself, every single thing said by every single person in this universe with regards to what the client and server is doing, is speculative. Thereby, the most we can say is a “maybe, perhaps or most likely”. Anyone saying that it is “definitely, confirmed, guaranteed or without a doubt” are borderline dishonest.
ESO has run on trusted client for years. Many games do and it is possible to do it with minimal player corruption. Regardless of how things are set up people will always find a way exploit it. What may happen which happened in ESO is that more and more checks will be moved to the server. This does cause a detriment to performance though. They also be able to further calibrate anti-cheat to stop these issues and better than that catch those who choose to cheat/exploit.
Let get for example the “invincibility” exploit. When you are in window mode and shake it, the client “pause” the game, it stops the application, and with this, it stops sending information to the server, so the server thinks the user is offline and stack the requests sent by other players until it has any updates from this client that is just “paused”. What is unacceptable, the server should do the calculation is what the player character is doing by itself. If you played any other MMO, when you lag or disconnect, you just appear dead, because the server does not trust you to say what are you doing or where you are, if you stop sending commands to the server to say what you want to do now, the server doesn’t care if you lost connection, for the server you are just an AFK character, and all the damage to you is processed normally as the other players or NPC hits you.
What you are saying about reading the source code are details of implementation that do not change the fact of how the application works in a certain aspect. How you implement your field validation in a form on your website at a code level do not change the fact of when you insert invalid data, the error appears to say to the user the data is invalid. You can just debug the communication with the server and take a look on the source code of the page in your browser to see how this validation works, if it is made server-side or client-side and if I can bypass it by calling the URL directly in the case the validation is done in the browser and not double-checked by the server.
It is how exploits are discovered and abused, just need to find the means to do it, do not need to read line by line of the source code to guess it.
We don’t know what’s being kept on the client yet, which is why it’s not total doomsday, but we can infer some things…
The game state updates are handled in the same thread as the UI, which is why moving the screen stops state updates taking effect.
State changes are handled by the client not the server (I’m invincible, I’m no longer invincible, etc). Which is why freezing the message pump when you are invincible keeps you invincible.
The server therefore isn’t running checks against player state, so no checks that you aren’t invincible forever. You can also see this with the animation canceling light attacks. If the server was enforcing a set time between attacks, the animation canceling wouldn’t work.
Assumption: During combat, the server is really just a message passing system, and it’s a stateless cluster. Meaning that to enforce checks on player state, each element in the cluster would have to share information about every player it was passing messages for. This is really hard to make performant, as can be seen in the Wars. The AoE collision algorithms aren’t performant on the server when determining which players should receive messages about the AoE damage, resulting in lag.
If all this is true, then replay attacks are the best way to start fooling the game. Break the packet encryption the game is using, then just keep telling it the client did a reasonable amount damage every frame until your target is dead.
Some of this can be mitigated by AGS serverside, at the cost of some performance and more crucially, at the risk of making more bugs later. IF (as I suspect) the server side is just doing message passing, they should remove the end effect triggers from the client and instead spawn actors serverside to handle it instead (basically use AWS Lamdba, that’s what it does!), let them trigger status end effects. They can also add message filtering to stop the worst of the animation canceling / replay exploits. Basically if the server receives two messages to do damage in too short a space of time, discard the last one, and tell the client it was rejected.
The game state updates being in the same thread as the UI though? That’s a serious overhaul needed I’d reckon.
I don’t think we’ve seen any client side item duping yet (or at least I haven’t seen any), so the client might not be authoritive for that, it could only just be combat.
Caveats: All this is speculation based on my own knowledge and experience, and what we’ve seen from the current round of exploits (and more tellingly, the attempted fixes). Take with as many grains of salt as you wish.
You are dead set on this being definitively without question, beyond all doubt, working exactly as you assume it is working. You give no room that it might just be a bug or a flaw in logic somewhere, that what is happening is not supposed to happen.
The only thing you can do without access to the code itself is infer and speculate.
A NW Developer outright refuted yesterday’s assertion about how Invasion downgrades work, and the notion that there was an unintended incentive to throw Invasions.
That was well done by Amazon in terms of conflict management.
I agree that this is elementary mmo going to not trust the client, precisely to avoid this sort of thing. This claim need an official response, and the longer the thread is allowed to persist without an official position, the worse things are going to be.
Like I say at the bottom, this is all speculation, but it’s speculation based on experience. shrugs
I actually suspect 95% of the game is server authoritive. Anything that hits a database, I suspect they don’t trust the client and do things correctly. I don’t think we’ll see item dupes all over the place. You can see it when the server is busy and you are harvesting. Once that bar fills up, there’s a second of freeze while the stressed DB registers you actually harvested something (and you have to wait on the confirmation)
I think it’s mostly high scale event stuff (i.e. combat and movement) that they kept client side, and I they’ve done it for performance reasons. So you know, important stuff, but stuff that’s manageable with some effort.
SMH, exploit exist because people are trying everything under the sun to come up on top.
Its like saying you know that a person has a brain tumor, you know how he got it, where it is at and how big it is just because you observed that he walks funny.
Haters gonna hate. You are clearly not a reasonable person.
you are just delusional, there are bugs and exploits in the game that should have never made it to release. Countless players have told them so in alphas and betas and they ignored it.
Its not that people desperately have to try to find these exploits, some are just so basic that its mindblowing that they couldnt see this coming.
If I knew about this exploit/bug/coding mistake I wouldn’t have bought the game yet. Or about half of the perks not working on the release, i expected them to be little iffy in betas but not on release
Kinda feels like we were sold a beta instead of a full game. Not blaming the devs I blame amazon for pushing this game out way too soon