VRChat Cache Encryption
BellKat
Despite the EAC update, malicious users have found ways around it to obtain avatar cache data and continue to do their bidding by rippping private avatars which users such as myself have put in hours of work into their creations only for them to get stolen and used as publics, or try to impersonate the original creator. i think its time VRC would do something about this to make it harder or even impossible for malicious avatar rippers to obtain the avatar cache data by implementing some type of high security encryption on the cache itself so it cant be obtained not only by users but also the infamous RipperStore itself.
Log In
Toys0125
I actually want to input into this. I have seen that people been injucting udon prefabs into their world cache to be able to no fly and also have a full editor inside the game to hack everything. Please have either an encryption or have client side hashing to check if it was modified before loading.
Macil
As a developer who is familiar with infosec and cryptography, here's an outline of a possible implementation of this that requires an EAC break to decrypt cache files:
- A server endpoint that's restricted to logged-in EAC-running VRChat clients exists to get the list of current avatar encryption keys. (This can be a list of basic random 16-byte symmetric keys, as base64 strings, age-format keys, or etc, served in JSON.) Occasionally new keys are added to this list and old ones are removed. Maybe a new key is rotated in monthly. The keys can be global to all users or user-specific; the client doesn't really care. (User-specific may be better in some minor ways, but if the encryption is done server-side then global keys makes things on the server much simpler and allows simple file hosts like S3 to be used.) The keys must be unique per-platform (PC, Android, iOS) though to prevent a platform with weak/nonexistent anti-cheat like Android being exploited to get keys that can decrypt (possibly higher-value) PC avatars. These keys are not saved to disk by the client at all. The VRChat client fetches them every time on login.
- All server endpoints for downloading avatars are either restricted to actively EAC-authenticated VRChat clients and/or the avatars are delivered pre-encrypted so they can only be decrypted by a VRChat client that's retrieved the avatar key list. (Doing the first option alone would mean that only the client ever actually has to use the encryption keys; doing the second option can make it easier to host avatar data at simple file hosts like unauthed S3 URLs which don't do any auth checks.)
- Avatars are saved to the cache folder encrypted by a key from the above list. (If the avatar isn't delivered by the server pre-encrypted, then it's encrypted on the client using the latest key it knows about. It's not too important where this encryption takes place. It's not at all a computationally-intensive process.)
- When the client loads an avatar from the cache, it checks the list of keys it has loaded from the EAC-protected endpoint) to see if one can decrypt it. (Maybe each key has an id and the encrypted avatar file includes the id; or maybe the list of keys is small enough to just try each in series.) If the cached file is not decryptable (because it was an old cached file using a key that's been rotated out by the server) then the client deletes the cached file and acts as if the avatar was not found in the cache.
- If the avatar data is delivered pre-encrypted and decryption fails, then the client assumes it's encrypted with a newer encryption key and reloads the key list from the vrchat servers.
With this design, someone must defeat the moving target of EAC to get to the avatar files, which is the best that's reasonably possible. (Someone who can defeat EAC will always be able to pull avatar data out of a running VRChat client.) Any defeats of the system stop working in time as EAC updates to counter EAC breaks and VRChat key endpoint rotates in new avatar keys.
All of this about avatars is equally applicable to worlds. I've mostly written "avatar" everywhere for simplicity.
I believe the VRChat client runs without EAC when the VRC SDK build&test feature is used. In this case, the client will be unable to load the avatar/world keys list from the server, and will be unable to load encrypted avatars or worlds uploaded by other players. If the player was using an avatar that can't be decrypted, then the VRChat client must handle this and use a default VRC fallback avatar for themselves.
It might be helpful to not encrypt a user's own uploaded avatars/worlds for their own client specifically, so a user can see their own uploaded content while in build&test mode, and also so a user who has lost their project files can open their own content out of their own cache folder. (If files are kept encrypted server-side, then it may be necessary to add an endpoint specifically for authed EAC-less clients to request their own content in the clear decrypted by the server.)
An avatar/world author might specifically wish to allow everyone to similarly recover their content to study, reuse, or remix. There could be an option in the VRChat SDK while uploading to never encrypt the content and keep its files publicly accessible in client caches. This would also allow the content to be used by other players in build&test mode; this would be very important for avatar test worlds to be useful. World compatibility with build&test mode might be important enough that worlds should default to being unencrypted or not have encryption implemented.
a
aytimothy
It's like asking people to not Ctrl+S your JPEG or website. glhf doing that, LOL.
Not trying to be mean or spiteful but this looks like a very futile game of cat and mouse. People want freedom yet they want full lock down.
l
legleg339
you dont even need to have vrc installed to rip avatars let alone mods. ive seen rips of friends avatars that they have been working on in their home world only and no one in vrc has actually seen them yet. if its uploaded to vrc servers then it can be ripped even if no one has seen it. EAC does nothing but stop honest modders and was bypassed within hours of it being released in beta. almost all of my friends in vrc have moved to another platform that does have encryption because of this issue.
A
Airworthysage
That won’t work they arnt getting it from cache the are getting it from vrc it self
KaisōAri
Airworthysage: Actually, if you are dedicated enough, you can obtain both worlds and avatars through the downloaded cache. However, it’s a long and tedious process of searching through the cache to find what you would want and then get it to actually work. But, with VRChat’s lack of encryption, anybody with enough knowledge and patience can rip worlds and avatars without the use mods to rip it for them.
Adididi
Airworthysage I'm not familiar with how ripping is typically done, but when I had to rip my own avatar to recover the lost project, the cache was an extremely easy to target. It's crazy to me that the cache
isn't
encrypted. It won't remove the problem, but it'll help make it significantly harder to access