Recommended Posts

I think the problem with WU pvp servers is that a lot of the WU code and calculations and stuff happens client side. So people can simply make hacks that will allow them to do things you wouldn't be able to otherwise. This ruins the experience.

 

For example, I think ESP is game breaking and it diminishes the pvp experience. Yet everyone on pvp servers use them. Sure you can rule that players cant use ESP on your server, but good luck enforcing it if you aren't there 24-7 to oversee it. So the only thing it does is put legitimate players at a disadvantage.

 

So people join a new pvp server, have fun for a few days, then wander off when the cheaters show up. I personally havent found one that doesn't suck and I think that's why.

Share this post


Link to post
Share on other sites
On 1/8/2019 at 3:51 PM, Angelklaine said:

I think ESP is game breaking and it diminishes the pvp experience.

I totally agree with this. It's too bad it can't be tweaked to work only on PvE where it's not such a big deal.

Share this post


Link to post
Share on other sites

There are server mods the limit the data sent to clients too....

Edited by bigsteve

Share this post


Link to post
Share on other sites
On 1/24/2019 at 7:07 AM, bigsteve said:

There are server mods the limit the data sent to clients too....

Do you mean to basically cancel out client mods?  If so, I'd love to hear how to get this.

Share this post


Link to post
Share on other sites

No.

Basicly the Wurm client is NOT a dumb client, it has some mechanics that stops various data from not show for the players.

The Bear mods a ways back bypassed these mechanics and was able to display player and creatures at the maximum distances, etc, etc, etc.

 

The server side mod from what i remember was not publicly available, or just on a friends network, it just limited the data that is sent to client to what ever the server owner wants..

Share this post


Link to post
Share on other sites

Why do ppl use cheats, how can so many think its fun to play outside the rules?

Share this post


Link to post
Share on other sites
Posted (edited)

So I have this initiative to hopefully have people collaborate to either play honorably or to flat out counter ESP. 

 

 

I have coworkers that are Java guru's that hopefully can provide me assistance to find a way to counter ESP.  In theory, we could have the server validate the client the same way WO does it with its client.

 

TLDR: Im exploring resources available to counter ESP thru client validation or other means.

Edited by Puertorro

Share this post


Link to post
Share on other sites
Posted (edited)

Best way I have seen so far is too restrict data that the server sends to the client.

 

Currently server sends everything that's need to view. Then the client sorts out what it should display and then displays it.

That why these cheaty mod are able to work.

Edited by bigsteve

Share this post


Link to post
Share on other sites

Isn't there a way you can disable allowing client mods?

 

Share this post


Link to post
Share on other sites

you can't stop people from using client side mods that will give them a clear advantage over others.

 

you could make your own client mod that interacts with a server mod, the client mod checks for specific things that a client mod may have like ESP and tells the server mod not to let them join server.  Sounds good? All they need to do is decompile your client mod and make it tell the server everything is fine even if it isn't.

 

This is the main reason I don't do any client mods, I only do server mods so that what ever is changed is changed for everyone.

Share this post


Link to post
Share on other sites
20 hours ago, Cuddles said:

Sounds good? All they need to do is decompile your client mod and make it tell the server everything is fine even if it isn't.

 

On that note...  I spoke to another peer at work today.  We agreed that we could decompile the code from WURMESP and see the information that it uses from the server.  From there we could find a way to block the information that WurmESP uses to work properly.  Another way is to find a way to do a checksum to validate that only mods authorized in the game are being used.

 

What I find funny is that the devs of Wurm already have this client validation for WO.  Is there a way they can help out with that?

Share this post


Link to post
Share on other sites
1 hour ago, Puertorro said:

 

On that note...  I spoke to another peer at work today.  We agreed that we could decompile the code from WURMESP and see the information that it uses from the server.  From there we could find a way to block the information that WurmESP uses to work properly.  Another way is to find a way to do a checksum to validate that only mods authorized in the game are being used.

 

What I find funny is that the devs of Wurm already have this client validation for WO.  Is there a way they can help out with that?

Why would they? They have one niche they can claim, "the perception of effective protection from macroing and other forms of cheating". The very interesting thing is that many of these mods allegedly came from what was originally used on WO. I don't think wurmESP did however it's predecessor bearmod which did everything esp does (and likely more) was said to have originated on WO. No idea personally if this is true.

 

You have to treat the client as hostile, which means you need to control everything the server sends and validate everything it receives. Been tempted to do some wiresharking on the network traffic myself to figure it out. Even considered setting up a proxy, man-in-the-middle like network filter which would allow me to filter out everything sent between server and client outside WU however all just theory right now.

 

~Nappy

Share this post


Link to post
Share on other sites
24 minutes ago, Puertorro said:

Could this be implemented on server side then added as a client mod to be able to verify the client integrity?

 

java.security.MessageDigest is your friend. Call getInstance("MD5") to get an MD5 message digest you can use.

 

or

 

http://anyexample.com/programming/java/java_simple_class_to_compute_sha_1_hash.xml

 

Please advise.

In my opinion you have to treat the client as hostile. Anything you add to the client can easily be identified and then someone can make their own client mod that provides the expected responses that you are waiting for. At that point you have the false sense of security that the client is good when in reality they have their own client with it's own hidden abilities that just sends you what you expect to see.

 

Even in WO they seem to have GM investigations where they actively watch a player or group of players for a period of time to try to identify if they are doing something wrong. 

 

I think focusing on server side control is the way to go. 

Share this post


Link to post
Share on other sites

the hash changes if changes are made to the client though.  If the hash from an accepted client were to change from the one I deemed authorized then the connection would be refused.  The game already refuses connections based on some criteria, I.E using the name Libila.

Share this post


Link to post
Share on other sites
6 hours ago, Puertorro said:

the hash changes if changes are made to the client though.  If the hash from an accepted client were to change from the one I deemed authorized then the connection would be refused.  The game already refuses connections based on some criteria, I.E using the name Libila.

 

How do you stop a modified client from sending whatever hash it wants to send?

Share this post


Link to post
Share on other sites
6 hours ago, bdew said:

 

How do you stop a modified client from sending whatever hash it wants to send?

if the hash is created based on the files being used by the client, any changes made to it will change the hash.  My theory is...  I create a hash of the client with all the acceptable mods then I add a validation on the server side using that hash.  I would just have to figure out how to implement it.

Share this post


Link to post
Share on other sites
1 hour ago, Puertorro said:

if the hash is created based on the files being used by the client, any changes made to it will change the hash.  My theory is...  I create a hash of the client with all the acceptable mods then I add a validation on the server side using that hash.  I would just have to figure out how to implement it.

 

Again, what stops a modified client sending you whatever you want to hear? You will never have any idea if it hashed any files or just read it from fake_hash.cfg

Share this post


Link to post
Share on other sites
9 minutes ago, bdew said:

 

Again, what stops a modified client sending you whatever you want to hear? You will never have any idea if it hashed any files or just read it from fake_hash.cfg

 

Ill figure it out.  If WO devs got it then anyone can do it.

Share this post


Link to post
Share on other sites
2 minutes ago, Puertorro said:

 

Ill figure it out.  If WO devs got it then anyone can do it.

 

Good luck 😁

Share this post


Link to post
Share on other sites
11 hours ago, Puertorro said:

 

Ill figure it out.  If WO devs got it then anyone can do it.

 

I'm just curious, I don't have a pony in this race...  Why do you believe the WO devs have solved this issue?  I'm pretty sure they have not.  

Share this post


Link to post
Share on other sites
10 hours ago, Ricowan said:

 

I'm just curious, I don't have a pony in this race...  Why do you believe the WO devs have solved this issue?  I'm pretty sure they have not.  

because the chaos server isnt filled with esp users

Share this post


Link to post
Share on other sites
On 4/19/2019 at 3:25 AM, Puertorro said:

 

Ill figure it out.  If WO devs got it then anyone can do it.

 

It literally doesn't matter what you try to make client programs from doing, or what claims anyone has made in order to prevent it. This will be broken. (Not "if", definitely "when".)

 

Bigsteve has already said the right answer. The only semi-solid way to protect against cheating is server-side enforcement. Even if you did find some magical way to enforce all players to run valid unmodified clients (which neither you nor Coders Club have) the data sent between a server and client can easily be intercepted passively by a packet dumper (e.g. Wireshark), then passed to a 3rd party tool as per a malicious player's desire. If this was truly unstoppable nobody would have a pirated copy of Windows. You can checksum all you like, and you may well catch a wave of cheaters doing this for your ban list, but it takes literally 1 person to work around this (and share it) for your checks to become worthless. (Do not waste any time on it.)

 

It's pretty obvious that Wurm clients get told seriously too much about their surroundings. Restricting data sent to clients is the best direction to take, but the processing of this can get pretty expensive in some ways.

  • A pretty cheap example would be hiding ore tiles of which have not been revealed so those mini-maps showing hidden ores wouldn't work. This consists of simple checks about what's around each tile and building a linked list to the tile a player is standing on. If there's no walkable route to an ore tile you simply substitute it for rock when the server is telling a client about the tiles near them.
    • This starts to get expensive as cave systems become bigger with more complex routes, but is still relatively cheap if done once per tile movement or tile change.
    • If the server has a lot of memory available binary trees can be used to cache this information for faster lookups.
    • This could be taken a bit further by using tile visibility, e.g. if there's gold ore around a corner in a "U" shape the server could quickly determine that a client has no way of seeing this from the other end of the "U".
  • A pretty expensive example would be determining if an entity (player, NPC, or item) is visible or not. It would involve calculating trace lines from a client's eye position to an entity. If there is anything opaque in the way of a trace line the server simply omits it from the client's knowledge.
    • This gets seriously complicated because entities are not point sized and not all simple cuboids either. These are models with complex vertices requiring a lot of recursive calculating, which very quickly adds up and becomes infeasible even for a single client.
    • This can be made a bit cheaper by assigning cuboid bounding boxes to all entity models reducing the number of trace lines to at least 21 for each cuboid. -- 8 verticy corners, 1 for the middle, and likely 12 at the middle of each edge line. (More detailed trace line points would be needed for larger entities though or they'd wrongly be thought of as not visible when they definitely should be visible.)
    • This can work well for relatively boxy objects (e.g. solid walls, chests, and players) but for other entities with holes in them (e.g. walls with windows and parapets) they'd need to be broken up into multiple cuboids each requiring their own trace line calculations.
    • Some entities that are very "holey" (e.g. fences) would be ignored completely as transparent.

Wurm is not new. If the above measures did not drastically impact the performance of a Wurm server they would have been implemented by now. This problem is made significantly harder by the extreme openness of the game environment making the complexity and frequency of such calculations monstrous. With servers not doing this work it saves considerable amounts of processing time, which in turn reduces lag particularly as the player count increases.

 

This is in contrast to a much more closed environment, (e.g. Counter-Strike or Call of Duty), thus their environments can be chunked up into visibility portals so the same calculations would only need to be done against much more limited areas. (ESPs and similar do still work on those games but are much less effective with limited distances.)

 

Wurm has an added disadvantage that again down to the size and openness of the environment each server has to have a capacity of 100, 200, or more players, where as more closed environment games rarely exceed 32 or 64.

 

In practise this is a very difficult problem to solve.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now