Ban / Security Modified clients
complete
MrDummy_NL
We know why some people uses modified clients:
- higher polycount avatars (is not more reason now)
Now i see lately more use for:
- steal avatars (very bad!)
- immunity to blocks and kicks (VERY bad!)
- change other avatars on purpose (VERY VERY bad) so they will stuck or breaking TOS on stream.
- overload / crash clients
- kick others login
- steal worlds
- entering locked worlds?
- flying around without limits through worlds?
etc....
Because it happens more often lately in public rooms, i hope VRChat should make clients less moddable and more protected internally against modifications. WHY should you use modified clients? It will only damage VRChat community. You don't need it, it is used mainly for bad and wrong purposes!
Do you want VRChat add anti-cheat tools? Not all people likes it, but we might have no other choices.
Log In
Fax
complete
Thank you for the suggestion! VRChat implemented anti-cheat a few years ago.
Andarilho404
Fax I don't know whether to cry or laugh
A Naughty Miss
A Naughty Miss
Please Invite this Topic, It is Related!
Rero Rero
get rekt non client users
Demirramon
Skiddies not even knowing what a client is
kookster
To properly fix these things they need to check things on the server side. Otherwise someone will always be able to write their own client and bypass any security that they implement on the client. When someone gets vote kicked, the server needs to disconnect them, not the client. World or avatar stealing cant be prevented sadly. They need more server side verification of user actions and that should fix most of these issues. Implementing them on the client wont fix them. The problem with this though things like users flying around would require the server to actually do physics checks on every user for every action they make which will add a lot of load and cost to vrchat servers. I think instead they should focus mostly on the easier to handle issues that can be addressed. Like "immunity to blocks and kicks", "change other avatars on purpose", "overload / crash clients", "kick others login", and "entering locked worlds".
immunity to blocks and kicks - should all be done server side, if it isnt. If it is then there seems to be a logic flaw in how a user can stay connected to a instance or their info is sent to said blockee.
change others avatars on purpose - if this really is a issue the server is not verify the request for avatar changing is coming from the right person.
overload / crash clients - To properly fix this they would need to implement checks on avatars that are uploaded and or what a client will render. Use some try catches if you have too. Though this probably one of the bigger tasks, it really needs to happen as public crashers are really a plague
kick others login - if a modded client really can kick a logged in user, just like with blocks and kicks, this needs to be checked on a server.
entering locked worlds - i assume this means users are joining a friends, friends+, invite, or invite+ and they dont qualify as such. Just like almost all the other issues above this needs to be checked on the server before a user is allowed to join a server. I assume whats happening is if a user knows a instance ID they can just join and the server doesnt check if they can join it. Which means the login for who can join a instance is in the UI of the client and not the server.
Hopefully all that makes sense if not, im sorry.
TLDR we need more server side verification of user actions.
Kush Meyer
kookster: The block and kick stuff is very simple and has no server checks. This is what is going on. The person is voted to get kicked out or just kicked by the host, but when the person being kicked gets sent the "you are being (vote)kicked" their client just denies it. That's it. Gettig kicked is NOT processed by the world host. It's processed by the person being kicked.
As for getting someone kicked... you might have an idea of how this is done after seeing the above. The person kicking uses their client to send the 'you've been (vote)kicked' packet to the person and poof they are gone because their client just trusts that it is the host kicking them and not a malicious user.
a
aytimothy
Security, yes.
Lock-down: No. In fact, make it modable; it could be used for more good than evil. All you'd just need to do is have more server-side security.
For example, instead of P2P - We need some central authority server (be it a server or a master peer)
Nekoputer
aytimothy: I agree with making it mod-able to be honest. However, these mods should ONLY be local to the user so they don't affect other users. A simple programming SDK should be available to make it possible. With this SDK, the devs can control what the mods are allowed to do.
From my observations and talks with various users, a lot of the complaints are primarily aimed at those that have mods which steal avatars, avoid punishment, etc. However, I've not seen any complaints about mods which are purely local only. For example, the well-known "ruby" client which offers various performance benefits. I've came across a number of users who use the ruby client because it just runs better in terms of performance than the original unmodded client. Granted the ruby client may have more addons which are questionable, however not everyone who uses the ruby client is that low if we went by an "Honor System".
Another example is a mod that's called "Quitfix". All it does is fix the closing of the client to prevent it from "chugging" or requiring Task Manager to kill the process itself which is extremely bad and I have experienced this issue numerous times. I sometimes have to close the client via Task Manager and when I do, all the excess RAM usage floods steam processes and all hell breaks loose and Windows just breaks. I've experienced steam/vrchat suddenly flooding my RAM to the point of BSOD'ing just for restarting the client before even being able to log in.
Want another example? What about a mod that simply shows who's joining & leaving? You never know when a known avatar stealer/crasher comes in without checking social every minute or 2 if you're nowhere near the spawn location. These types are mods are just utilitarian to make things a bit easier to help you.
Not ALL mods are bad. Period. People just make them ALL out to be bad.
a
aytimothy
Nekoputer: You obviously did not read my one-liner at all O_o (READ WORDS FIVE TO SEVEN) - I'm all for mods; just complaining that VRChat themselves aren't doing enough server-side. The whole reason we have all these bad mods is because of the whole inherent architecture of VRChat's networking.
It's why even with all the mods in the world, it's very hard to cheat in Minecraft; there's a central server that checks whether players are following the rules of the game (ie. you can move only about 5.6 blocks per second while walking, or fly 18 blocks per second at /speed 2).
In VRChat, there's no central authority, and other clients do not check authority. For example, let's talk kicking. When someone initiates a votekick, the vote-kicker broadcasts to everyone "I want to kick this guy". Everybody votes, and the tallies return to the vote-kicker. If passes, the guy sends out a "kick this guy from the room" message to everyone, and thus everyone disconnects from the vote-kickee (and thus on his side is kicked).
Now, the problem here is that VRChat does not check whether someone did a vote-kick or not, or whether everyone agreed or not. Instead, if it sees a "kick X" message, everyone just kicks X.
So, what's stopping a malicious actor (those people you're talking about) from just spamming "kick X" messages in every room they visit? Nothing.
If we had a server, or master peer, now suddenly you could check: "Was there a votekick?" If yes, "did it pass?", and if yes, kick. If not, ignore. But with the P2P nature of VRChat on top of that, this isn't possible because of late-joiners. What if someone joined mid-vote-kick voting? They would have no clue that a vote-kick was happening. So if we did that check on everyone in the room after the vote-kick passes, suddenly we have one guy who hasn't kicked the vote-kickee because he doesn't know about the vote-kick; all he sees is a random kick message.
Oh, also: Mods are always single-player. They're on multi-player when all people in a room has them; it's pretty much why in Minecraft you can't expect a server that runs only Pixelmon to allow you to use Thaumcraft items on it (well, without installing it first, of course).
vote-kicker = person initiating the vote-kick
vote-kickee = person who is kicked if the vote-kick passes
Edit: Fixed some wrong numbers
Nekoputer
aytimothy: I've only talked about how I think being mod-able is good. Didn't mention anything about verification/security. I was also responding to this at around 2-3 AM UK time and I was really tired and couldn't be bothered to split it into 2 posts.
As for security, it's like you said. We need an auth. peer/server. It is really bad security if everything is pretty much done client side.
Since you've mentioned vote-kicking and joiners coming in during it, there could be some kind of temp. ignore list to put those new joiners in so they don't affect the vote. It sounds simple enough, however it's most likely more complicated than that and would probably only work if all clients interact with the auth. server just as they load into the world.
Emmanuel Lopez
I have the exact opposite opinion. These clients should be more open and easier to modify. It would make hacking seem stupid, since it's an ability everyone can have. Once everyone is super, no one will be.
Demirramon
Emmanuel Lopez: It doesn't matter if it looks stupid or not, if someone has the hability to crash people with no repercusion they will. I'm all about modding and stuff but malicious stuff has to be fought against.
Emmanuel Lopez
Demirramon:
Yes but that very same malicious stuff is being fought by clients WITH clients. https://notoriousofficial.net They're implementing standard features like VPN access and steam tag obscurification. We aren't protecting anybody by burying our heads in the sand. We should lessen the demand for illegal clients by implementing the features they have in demand, or forever be bothered by them, and for some hurt by those malicious actors. And furthermore considering that this code is clearly breaking the TOS, it shouldn't be much of a problem to borrow inspiration from it.
There should be somebody working in the inner circles of these hacker groups, working to make sure they never have the advantage.
juls
How come the client gets to decide whether a user has kick immunity or the ability to kick other people? Is this not handled on the server side? How is this sort of privilege escalation possible?
GotoFinal
juls: what server side? There is no server side. Thats why its more complicated issue, vrchat mostly communicates directly between clients, and vrchat servers only host data, avatars, worlds and provide features for managing worlds, friends etc. But all stuff that is happening in game in instance is between clients.
juls
GotoFinal: Ah, I didn't know that. That explains a lot of things, I suppose.
It seems like a strange design choice though. I understand that voice and movement data needs to be peer-to-peer, but leaving any kind of "consequential" decisions up to the client means that any security features that involve other players will always be more of a "let's ask them nicely", rather than actual guarantees (which is what I would expect from security features). :(
GotoFinal
juls: just imagine how many servers they would need to have to handle so many room instances as people create. Tho would be much more amazing for scripting.
That would just be too expensive.
Another approach would be like lavender - when you create a room you are becoming a full featured server, but then there is issue if you want to leave the room, as room with die with you.
Imho the only way to support kicks/blocks would be to tell the other clients to ignore one of clients, so they would not even try to communicate with it in any way. But now the question is... if its actually easy/possible to do with the network engine they are using. So yea, its just not that simple.
And stealing stuff like I wrote in my other comment will be always possible.
Raccoonteur
GotoFinal: It's doesn't seem that complicated, just because there's no central server.
Say one client is hacked to ignore a ban. If all the other clients in the room are not hacked, they can simply choose to enforce the ban by agreeing to ignore the hacked client as if they were blocked, refusing to send them any updates of their own status, and refusing to show their avatar. For all intents and purposes, the person who was "kicked" will then be kicked for those who kicked them, and the kickee will find themselves in a ghost town. They'll still be in the instance, and maybe the clients who aren't hacked will need to send a notification to those who join that a vote kick occurred, and the non hacked joiner will have to make a decision about whether to observe the kick or not based on that information, but this would be almost as good as a real kick.
SquidNeko
Raccoonteur: Wont worked. Hacked clients can do so they still can see you. Even if you blocked them.
GotoFinal
Raccoonteur: i already proposed this below
Raccoonteur
SquidNeko: VRChat's networking works in such a way that your client relies on other clients to tell it where you are (and since the Network IK, the positions and rotations of your bones as well). This is why people with modded clients can teleport within a world. The client simply chooses to ignore colliders and flies you through the walls to wherever your friends are.
This being the case, if someone with a modded client wanted to block you, all they should need to do is to stop transmitting their location and audio data to you, and hide your avatar and block your audio. You might still see their avatar floating there, or they could teleport it to infinity and beyond, but for all intents and purposes, you would be blocked, as wouldn't be able to interact with them.
SquidNeko
Raccoonteur: i did not say them blocking me. But me blocking them. Or anyone else for that matter.
Raccoonteur
SquidNeko: It works both ways. I only used a modded client as an example of what the official client could do, if they implemented it. You blocking them means your client chooses not to send your location data to them when they request it. There is nothing they can do to force your client to tell them where you are if your client has decided they should be blocked.
SquidNeko
Raccoonteur: They can still see me and force change my avatar etc. I have first hand expirence with this since it happened to me.
Raccoonteur
SquidNeko: There is also no reason why they should be able to force change your avatar, unless they're somehow tricking your client into thinking you clicked on an avatar change pedestal, but that too ought to be impossible because your client would know if you clicked the trigger on your controller or not.
Raccoonteur
SquidNeko: And when I say there is no reason, I'm not saying "I don't believe this happened to you". I am saying VRChat should be able to program the client to ignore the request, or to avoid sending your data to the person you blocked.
SquidNeko
Raccoonteur: The whole room got changed. And i had the person blocked. So yea.
Raccoonteur
SquidNeko: Think of it this way. When someone calls your house, and you can see it's an unknown number, even if they could force your phone to pick up, can they force you to speak to them, or to put on a pretty dress? No. And the only way they can know your position in the world in VRChat is if your client tells them your positon, and the only way they can cause your client to change avatars is if they ask it to and it chooses to do so willingly. As VRChat could program you client not to speak to a user you've blocked, and to ignore requests from them, and to ignore requests that appear to come from the VRChat server that you obviously did not trigger, like an avatar change request from a pedestal, if something like that even exists, which I don't think it does because the avatar pedestals are just objects in the world you downloaded with a trigger you activate.
Raccoonteur
SquidNeko: I believe you. But I am saying the VRChat devs could stop that by making the right changes to the client.
a
aytimothy
Raccoonteur: That works except it still doesn't defend against outside-VRChat attack, like a DDOS attack. So the whole P2P model is the fundamental problem.
GotoFinal
aytimothy: tho vrchat is not pure p2p, its easier to skip the details, and I often forget about them anyways, but there is a server between, but it just does not do much and it does not know anything about state of the instance. But communication itself is not p2p, but it works like p2p game at the end - aka there is no server to check the packets sent by clients.
Leaking IP addresses is actually another issue related to steam & voice chat if I remember correctly.
Emmanuel Lopez
Raccoonteur: This is a very pragmatic way of blocking, it's P2P and network scalable. I couldn't agree more .
blooty
Make it so only executables signed by the VRChat signing cert (which only the core dev team have access to) are able to authenticate to any of the necessary client APIs as a second factor along with the user login.
GotoFinal
blooty: and how you want to check if the signature is valid?
As no matter what you will check, a custom client can just fake this checks, and pretend to be valid
Demirramon
GotoFinal: It wouldn't be too hard to make this work and it would make custom clients' job at least a little harder. It's not a bad idea.
GotoFinal
Demirramon: it would not, as already all clients don't edit the provided files at all. So the check would pass just fine.
GotoFinal
But clients are already banned (and vrchat uses few tricks to make modding harder and detect them automatically - but anyone with a bit of modding experience know how to work around these), just its not that simple to tell if someone is using one automatically or after reporting (as report can be fake, so mods needs to later check if something actually happened). Also modding will be always possible. Tho in next version of vrchat w il2cpp there will be probably less people interested in creating clients as it will be much more work.
So you should see less issues with new vrchat on unity 2018 and il2cpp! And I guess thats a good thing, but also consider this:
Clients are also used for other stuff:
- Integration with unusual third party devices, like bhaptics.com, a lot of especially korean people seems to be using it from what I observed. And some other not really popular hardware solutions that would require a lot of work from vrchat team just for few players using it.
- Fixing a lot of issues with vrchat that people ask here for 2 years already, like: separate list for friends not in private world, not entering a portal unless you really want it, avatar collisions, more fav avatars, refreshing friend list/single friend, and a lot more probably.
And stuff like immunity to blocks or kicks should be handed by vrchat protocol, and not a client, as otherwise people will skip this anyway.
And stealing avatars and world does not even require any client, and no matter what you do to protect stuff, people will find a way to rip it. If you can see it, its already on your pc. Ofc vrchat could make it a bit harder to rip, and use some own format, but that would only stop people for few days until someone would release a tool to rip it.
Flying is also possible without clients. And clients were not used for higher polycount avatars, people were just skipping SDK limit.
And any more advanced security (by obscurity) could also hurt a performance and load times, so I would rather not want that.
And people can crash you with just animations or shaders.
What I want is to improve the security of vrchat features themself, like confirmation on email change on old email, actually making it impossible to receive any packets about players that have you blocked, and kicking should do same: no other client in lobby should be able to "talk" with kicked client.
And what you are asking for is some kind of non existing magic. Especially that vrchat is kinda p2p game, so its much harder to validate what players are doing and if they should be able to.
GotoFinal
they do, just in very simple and useless way, like checking hash of .dll and sending it to server. Most of clients don't even edit the file itself, so they don't need to worry about that. Obfuscation also exist only to prevent modifications, but again - no one cares.
Chdata
Even if modded clients add good features and CLAIM they aren't malicious;
You're trusting someone who is hacking the game's files to make their thing work. Also, depending on the client, it's probably really convenient for them to confuse people's moralities and sense of trust for these things... BECAUSE THEY WANT MONEY.
You don't know if they're also secretly distributing more malicious stuff behind the scenes. The most certainly are capable of making the bad things too though. Giving money to them, or even using their stuff and showing that you tolerate it as something that is "okay", is giving acceptance to people who could very well be damaging the game, and helping them get their foot in the door towards more people to spread this stuff.
Cl0ud Zone
Chdata: damn. Quite rude to assume that actual harmless clients are harmful. Should probably open up a google tab or youtube video my guy. Literally there is this on client that fixes bugs and all and the only thing that drops frames or causes lag actually does it to the user of said client. It's called the two modular" which runs text through a filter to make it kawaii to the user and no one else. The user could loose frames to said mod but no one else. Yes there are malicious ones but you see one bad on and go "oh shit a client people say are innocent? I've had bad experiences with clients so it isn't innocent". Seriously man. Chill and watch some video or something.
Load More
→