Hacker related bugs and ideas to fix them
closed
GotoFinal
Sorry for writing all of this in single post, but all of this is connected to that single issue of broken protocol design.
So far most of protocol works on very funny rule to send data to other clients, and other clients sometimes validate some of that data - but this can't be made really secure, especially that other clients trust other clients, currently client actually inform other client who it is, and this is just wrong... Anyone can spoof any packet to be send as anyone else - including mods.
Other problem is that avatars are not validated at all, client can just send custom ApiAvatar object with custom URL to his own web server with own avatar asset bundle - and every client will download it.
And they can also send custom userId of other player.
There will be more and more players each day, and with current protocol it is just impossible to make it really secure.
Stealing avatars can't be fixed, but can be made much harder to perform - we can save if given avatar id is public or not - only public ones can be used on pedestals, and if someone tries to switch to private one - no one see that change, as they will validate that given avatar does not belong to that client.
Then it is possible to also validate that changed avatar belong to that person OR that there is pedestal next to that person with this skin, so they can't change it to random skin.
People still can skip this - as they can download skin and reupload it as own one, but at least this will be much slower and will not allow for super simple troll button to become someone else.
There just need to be a server that will authenticate each player in room on join - and that server need to inform other player about new player. Players can't inform about them-self, as this can't be secure, especially that VRChat use very small room, some hackers can easily become master client or be more than 50% of the room - so any checks based on clients can be faked.
In best case server should handle all packets - to check if player is moving in valid way - not too fast, not going into a wall, not flying, not teleporting, and not sending administration RPCs without required permission.
This same checking for modded client by sending .dll hash... client can just send valid hash and random hardware id, or even inject into a process after that and mod game in runtime.
As long as you trust the client in any information they send - there will be more and more "hackers". Banning will not help with anything here.
List of bugs caused by all this stuff above:
- People can still go to non-friends friends+ room. (not sure about friends only, should be possible, at least for your friends that are in friends only world of someone else who is not your friend, but maybe for everyone)
- People can spawn portal where they want without any validation.
- And any number of them.
- People can force other clients to download avatars from their own web server.
- People can change own userId to anything they want.
- People can teleport other people
- People can logout/kick/warn other people without any validation - with custom message and colors, size etc.
- People can send invites/request invites/or broken messages that can't be close with custom text in it - including basic formatting like with warn. (and you don't even need to mod client for that)
- It is way too easy to use skin of other people
- You can use no-clip and fly whatever you want on the map (and then teleport people here so they can't even change world without restarting the game)
- And use this lack of any security in every mini-game available.
- [EDITED] You can use vrchat as free extension to your disk, files are not validated at all, you can upload anything you want to later download it, people can use that to distribute illegal stuff using vrchat servers. What is worse, each of that files then considered as "white-listed" so later someone can find a way to load it as a plugin to some world.
Also I would personally say that choosing NodeJS for game server API isn't best choice, after all NodeJS process all requests in single thread, ofc it can be scaled, but with amount of request this game can send, it would be better to have something that can operate in multiple threads, not only use async IO.
I would actually love to work on such game, especially that I have some experience with protecting game protocols, but as you seems not to be interested in hiring I hope that at least this text will help VRChat to fix all this bug, to make this better place to all of us...
EDIT: added one more issue
Log In
euan
closed
There's been a ton of changes since this post was made
~Megu~
euan: EAC Does not work .. you only blocking mods.. not these tools
euan
~Megu~: my comment does not mention EAC
~Megu~
Tupper - VRChat Head of Community
D
DovNut
As the game is in unity its very easy to rip the models from anyone giving them the files to edit and piece together in blender or other modeling software. they do say if you don't want it going around keep it off the internet not that i'm encouraging the use of mod clients or any such, nor discouraging uploads.
But you have peoples models stored on your pc in a unity file, which any smart person with any amount of time on their hands could make/get an app. to read and assemble these files. there is no way to stop it, and tbh the more you swing at the hive the madder the people get, the hackers have gone from only taking peoples models to outright deleting them...
Hello Kitty
I have not personally checked into the assemblies nor have I sniffed any traffic, so I am going to base the following statements on the assumption that the provided information above is factual.
Fixing all of these problems would, from my outside perspective, require significant architecture changes. A thoughtful authorization-centric approach to each operation would be needed but it's not so simple and I have a lot of thoughts on this topic but it wouldn't be worth the effort to go into detail right now about them. Some of the things listed are easier to solve than others are but they would require some pretty fundamental changes though.
Some are unsolvable without significant time investment into client-side protection, which is always a losing battle, such as the portal location dropping issue. At least Semi-Authoritative server simulations for each instance would be required to sufficiently solve that and similar problems but it's not worth the effort.
Blizzard has some moderate success hashing sections of memory, most notably functions, to protect naive client modification or runtime patching. This person IS right, hashing of assemblies is NOT far enough to protect against a majority of simple .NET hackers. .NET does provide afew ways to access the MSIL stream of methods. While it's a losing battle anyway, doing this against critical sections abused by exploiters, and flagging clients who return invalid results, will stop all but the best. They often distribute their tools or clients though, or even sell them, so it's not a total solution. However these are significant more difficult to spoof and deal with for average exploiters. Especially if you deal with replayability of the packets, which is simple.
Though abuse at the protocol/packet level should be the initial concern. I highly recommend an authorization centric approach be taken. Worlds and Users should be authorizing actions in some way. Clients should never trust other clients. If User A claims to own Avatar 1 then this should be verifiable, don't trust. If they don't then check if they can provide an authorization token for a World that was created by a user that was authorized (owned) the avatar on a pedestal. If they can't, the client is lying. This thought process will solve many of these problems, described in terms of the avatar issue which is high priority because of the visibility from users. I could write quite abit on this but describing all of the potential changes would take too much time right now. I am busy.
Oh, also stop providing raw assetbundles over the API. There are many trivial things you can do to make these unusable until they hit the Unity3D client in some way. Masking and adding barriers is the name of the game to protect asset content. You can't win but you need to make it more difficult.
GotoFinal
Hello Kitty: Currently they also added code obfuscation, so it is harder to follow changes, so some of that stuff might me fixed already - I currently don't have time to dig in that obfuscated code. But ofc obfuscated code isn't going to help much, it is just matter of few days to write a tool that will decompile it and create name-mapping tool that will be able to recognize function. (it is even easier if you have old versions that were not obfuscated)
(hackers are slowly returning right now, with each day you can see more people complaining about old issue with instant skin copy etc)
About portals, if you mean that it is hard to do with with current kind of p2p protocol then ok, but with typical client <-> server connection this would be very easy to fix, as it only need to save amount of portal and do one single collision check.
With typical client <-> server connection a lot issues can be fixed, near everything - all only depends on how much CPU time you can spend on validation stuff, like you can validate movement - but it can be very costly, especially if you want to do that with some good precision, but it can be just few simple checks - enough to stop some no-clip stuff, or teleporting.
Then there is no reason to fight with modded clients that much, especially that they are (or now maybe were) communities that mod clients in a good way - to fix some issues on their own, or add better support for some VR technologies. This is not typical shooter game that preventing any modifications should be our main goal. People could actually create own private servers of this game with own scripted maps, and that could be pretty amazing.
Just ban people who abuse stuff, but first fix all the stuff that can be abused but should not be possible to.
Kevin
They can also access to the DB to copy and delete Avatars ID's from other users. They have to fix this security hole.