Jump to content

giKoN

Members
  • Posts

    145
  • Joined

  • Last visited

Personal Information

  • Location
    EDDS

Recent Profile Visitors

706 profile views

giKoN's Achievements

Hunter

Hunter (4/15)

20

Reputation

  1. Packages have unique tokens. For some you can compare cInfo sender vs. instance.sender (instance being the package). If cInfo Sender != instance.sender, for some packages, its a clear catch. However. it starts getting ridiculous with some packages like NetPackageDamageEntity. Here's some example of me watching zombies run against barbed wire. So my client sends the server the info that those zombies took damage. That makes it nearly impossible to differentiate between valid packages of mismatch between entityIDs and invalid ones (e.g. spoofing ids). The issue with executing commands is that you can make your client execute them without the server knowing. For as long as the server is not in control but acts mostly as a distributor of info between a bunch of single player games, this wont change, and the network optimization/netcode will remain poor.
  2. The patch in fact fixes many of the issues on the netcode layer so thats a very good sign. First tests were positive from what I heard. The serveradmin.xml corruption is still a thing but I expect 19.3 to receive another Build which fixes that. For the EAC bypass which is going around it won't help just yet - but the bar to hack the game has been raised significantly. Honestly, thank you @Devs for taking this serious and reacting with a patch almost dedicated only to this. I think many in the server hosting community are feeling relief that they are not left alone.
  3. Well, i'm testing my client side performance during the attack. So yees this doesnt show anything with regards to the CPU of the server. The proper information is available in the pimps testers discord. However, the ping is crucial given that it was performed locally - thus, no attack on the network itself. It's simple, the game isn't dropping the invalid connect/disconnect requests as it should and instead allocates ressources. But as I mentioned, this is just one of the endless possibilities we have right now to manipulate on netcode layer.
  4. It shows how the game handles netpackage spam for connect/disconnect packages. It attributes resources to the spam prior to checking for validity/steam auth, thus, all valid packages get delayed (ping) - if done with high enough frequency/long enough the CPU will cave in. RAM load is increased significantly too. We did this with relatively small bursts to test the concept. the crash ptentially causes world saves to go corrupt and desync between client files. the spam was performed locally.
  5. The proof is the netcode. Everything that has been mentioned prior we are able to provide more details for as soon as there is reasonable interest. We do share a discord group with Allocs and Hated but the communication has rather been one-sided. I think one entire tool was shared with Allocs which shows just how easy it is to do whatever you want on a dedi server. By now: * we have fixed serveradmin.xml corruption which is caused by invalid characters (missing check on save&load). Anyone joining and getting banned with < > & " ' characters in their name will wipe out your serveradmin file. * we have fixed netpackage connect/disconnect spam which crashes servers all around the world. This is a workaround fix - needs to be adressed properly within the dev team. (Sharing my video as client, not the one performing the connect spam - the active connect spam video was shared in your testing discord) * we have identified a few netpackages which we can add additional verification layers to the instigator/sender id's matching the id that's being sent in. * for many of the netpackages we will not be able to add such verification layer. Sender and EntityID so often don't match - sometimes for good reasons. Sometimes it seems pretty random. To be honest, open dedi multiplayer simply is a @%$#show right now. >
  6. Thank you for that awesome idea. That solves all the problems. This thread can be closed now and all necessary investments into netpackage security will no longer be required.
  7. I will try not to deviate the topic more than necessary but I do hope you at some point get to realize how much a comment like this may upset the one or the other. I have corrected your statement in the quote to give you a hint where you could start.
  8. Maybe I will post a quick summary of what happened while the thread was hidden (which happened per my request to not have too many details showing, so please don't start arguing with the mods on that): Since the thread started, I know of at least 14 Servers which have been attacked, sometimes the worlds have been entirely corrupted to the point of having to start a fresh seed, some have had their serveradmin.xml restored to vanilla, some had seen their own players banned for activities based on spoofing. On the technical side, we were able to provide the proof of concept within approx. 1-2 days. While a group of coders OUT OF THE COMMUNITY takes on the huge challenge to try and add verification steps to each netpackage coming towards the server, we were however shown, that besides the obvious flaw in the netcode, EAC has been bypassed as well. One of the hackers has succesfully showcased the full toolbox he has available on our EAC protected servers, you can imagine what unlocked edit mode on a live server can do. While the work on netpackage security might even protect against some of the action of the EAC bypassing hackers, it is obvious that this is a battle which we can't win if the dev team does not start to take the netcode seriously. When it comes to EAC, invest in more than the lowest tier please, for us. Implement heartbeat checks to ensure integrity of client files and operations while the player is established. Anyone who goes through the game in detail can easily see how this game is coded for singleplayer - and to make it work for dedicated, you exchange a bunch of unsecure packages. However, in the course of this current project not only do we see that the vast amount of packages being exchanged from client to server to client is unnecessary and creates additional performance issues, it also bares the risk of clients being able impersonate (spoof) other players on the server. This has gone out of hand. And if 7 days to die does not get an overhaul to its netcode, it might as well just shut down its dedicated server branch.
  9. This sounds like the treasure bug. Make sure you do not have a duplicate treasure quest in your quest tab and if you do, cancel and reconnect.
  10. Thanks Alloc, it is a relief to know that work will be done on NetPackages. I do think it's necessary at this point. And if DM/CM on dedicated can be solely controlled by the dedicated instead of client it would definitely help. I hope I can deliver some proof of concept for the rest, there's several tutorials for Minecraft and other games on how it can be achieved in general, unfortunately as Ch1lly pointed out im still an amateur
  11. @Smegzor try making your server send this to a client and check if you find the server getting a response against it: _cInfo.SendPackage(new NetPackageConsoleCmdClient().Setup("dm", true)); This should be an easy proxy without altering client dll. In the end, it should be the same result. Regarding closed source I really would like to say something but in the interest of this topic i refrain from doing so.
  12. For as long as botman blocks all Proxies I can imagine the exposure to the blatant hackers was reduced. if however clean IPs or from botman not listed Proxies are altering packages you won’t know until they decide to do something obvious - and then you won’t know if it’s bypassing EAC (theres no EAC heartbeat checks), cheap public hack which will get banned within days or if it’s altering packages passing through. The info is retained within the client. Prisma has done the proof of concept on vanilla, he would be able to tell a lot more about the responses the servers get but unfortunately, well , you know. Just keep on mind that most of the predictable packages can be altered to execute on client. This is something which also makes Anticheat tools like Botman or ServerTools potential delivery services - particularly due to their open source. This does explicitly also includes my X-Ray Bot. Server will only be able to verify some of the packages to some extent - this explicitly the packages which clients can use to spoof entity ids or buff other players. However this will require injecting into each of those to compare entity id for validity against steam ids / ips of sender. Hopefully not causing much performance loss.
  13. It matters for the validity of outgoing packages from the clients. From what I understand (and I would love if more experienced coders would actually take their stance here), clients can send netpackages with spoofed entitiy ids and the server runs operations based on the entitiy id with no verification if it's from the steam id the package originated from. In one example, a player was hit by another player and in return the attacker was banned for godmode. The returning netpackage from damage/health calculations seem to have been tempered with in order to apply god mode bufs on other clients. Given that the buff is our only indication that a client has debug mode - this is what most managers ban for.
  14. Mod sent through PM to you @Roland. The mod is currently still under retained testing by 3 servers and thus not published open source. It is aimed to become merged into ServerTools to be part of the open source. More generally in discussions today it was confirmed that the main issue is the handling of NetPackages of any kind. There is no need to ultimately narrow it down to my mod given that every client is able to use a far broader variety of netpackages to alter. In July already I was warned by a Chinese Admin (at least I hope his main focus when going through the code actually was to protect his server) with following statement: There is no verification of netpackages being valid, no verification of permission level and no verification if netpackages sender steam ids match entity ids from as far as I am aware of. @Prisma501 has verified on vanilla servers how clients can run any command as they wish by altering netpackages on a server they have no permission level granting them such access. In the irony of his case, it was enough to alter the "access denied" package sent by the server to the client, alter it, and have it run whatever the client wants to run. This, either through injection at the client itself with required EAC bypass or through using a proxy to alter the package before it reaches the game. Given that vanilla has no checks for debug mode, spectator mode, creative mode and several others, this strips servers naked.
  15. So you're telling you're able to alter netpackages send to the server on your own will. See post 1. Besides that at least your tone is obvious enough.
×
×
  • Create New...