thedushan / openwolf-engine Goto Github PK

The purpose of this system is to guard against a set of abuses/attacks against game servers. An extreme example of such an attack has occurred on Trem, where a ton of spoof server listings were made on the master server with the same name of a legitimate server that was growing in popularity at the time, and confused people as to which listing was the correct server. There can be more subtle abuses of server name/brand stealing/misleading with that old basic approach as well.

https://imagebin.ca/v/5ToPBUcmfWSs

Proposed server name registration system:

Game servers would not be required to register their server name in order to list their server, they can use unregistered server names, However, no unregistered server names can be listed more than once. That is if a server lists itself with a server name that isn't registered, no other server can use that name for as long as that server is online and lists with that name (if/when they change their name, or if the server goes offline, maybe there should be a buffer time, maybe an hour, after which if that first server doesn't reuse that name again within the buffer time, another server could use that name).

Server owners could apply to the administrator of the master server to register a game server network group name, the master server administrator would approve/deny/unregister group name registrations, there would be an e-mail associated with a registered group name for verification purposes, and there would be one registered player account associated with the group account that would be the group owner. Management of the group accounts could be done by the group owner through the client's main menu.

The registered group names would appear in a new column in the server browser. If a listed game server isn't associated with any registered group, the group name would be blank for that particular listing.

decolored group names would have a minimum character count requirement (maybe 5 printable characters?) and a maximum character count requirement.

The group owner could associate a/some ip addresses of game servers that are currently live, ownership of a given live server should be verified by having the group name set in a cvar on the server being registered.

Registered group names can't be used as part of server names for on unregistered ip addresses.

Unprintable characters will not be allowed for group name nor for server names.

Before comparing group name strings and/or server name strings, the strings will be decolored, they will be converted to all lower case, and spaces will be removed. Similar looking characters should also be treated like they are the same (like 0 and o, or 1 and I and l and |).

If a server attempts to use a server name that is currently taken, their server will not be listed, and they would be prompted in the server console to rename their server.

@Buom01 brought this issue up recently. It occurs at least on Linux, I've also found that this issue doesn't happen on linux if you set the build type to release this bug doesn't happen and the console in game works properly, this bug seems to only happen when the build type is set to Debug (also this seems to only happen when a map is loaded, and doesn't seem to be an issue at the main menu). When the bug does happen, once you reach a certain number of input characters in the console, the console input start spazing out, and the client can segfault. Here is the backtrace from gdb that I get when the segfault happens:

           Thread 1 "StellarPreyTest" received signal SIGSEGV, Segmentation fault.
                                                                                  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:505
505	../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:505
#1  0x00007fffb1084e7b in idCmdCompletionLocal::CharEvent (this=0x7ffff3ed0220 <cmdCompletionLocal>, edit=0x7fffc49b4600 <g_consoleField>, ch=8 '\b')
    at /home/sparky/Documents/StellarPrey/dev/Stellar-Prey/source/OpenWolf-Engine/src/engine/framework/CmdCompletion.cpp:748
#2  0x00007fffb1031192 in CL_CharEvent (key=8) at /home/sparky/Documents/StellarPrey/dev/Stellar-Prey/source/OpenWolf-Engine/src/engine/client/cl_keys.cpp:1532
#3  0x00007fffb101529d in Com_EventLoop () at /home/sparky/Documents/StellarPrey/dev/Stellar-Prey/source/OpenWolf-Engine/src/engine/qcommon/common.cpp:2660
#4  0x00007fffb1017d30 in Com_Frame () at /home/sparky/Documents/StellarPrey/dev/Stellar-Prey/source/OpenWolf-Engine/src/engine/qcommon/common.cpp:3601
#5  0x00007fffb108b60b in engineMain (argc=13, argv=0x7fffffffdda8) at /home/sparky/Documents/StellarPrey/dev/Stellar-Prey/source/OpenWolf-Engine/src/engine/platform/systemMain.cpp:758
#6  0x000055555555534a in main (argc=13, argv=0x7fffffffdda8) at /home/sparky/Documents/StellarPrey/dev/Stellar-Prey/source/OpenWolf-Engine/src/engine/platform/systemLauncher.cpp:84

This is an important bug we are going to have to fix in order for the Debug builds of the client to be useful.

As a side note regarding the main Stellar Prey repo, the build type of the binaries can be set at your local setup in the config.sh file (found at the root of the main Stellar Prey repo after the repo is initialized) for the variable CMAKE_BUILD_TYPE . where it says:

#Build type options: Debug, Release, RelWithDebInfo, MinSizeRel
CMAKE_BUILD_TYPE="Debug"