plaguevrc/antirip

AntiRip (Kanna Protecc) - Free and insanely strong VRChat Anti Rip. Let us rid of rippers, together.

antirip's Issues

Would it be possible to write the encryption key over osc instead of htrough unity?

Im assuming here, that the encryption key is in a parameter. If so, it should be possible in theory, to just use a small osc program, to set your encryption key, so in case you reset or something like that, you dont have to open unity and restart your vrchat.

I could be totally wrong in how this works, but i think it might be a good idea to look into it.

Suggestion: Experimentation with using Normal values for Public Key

Hashing vertices is genius. However, I am curious, what about if you use Normals on a model to decrypt the avatar. What do you think the output and issues with this would be? And the upsides compared to shaders and/or vertices. If not for decrypting, what other ways could it be used to improve usability while offering little to no compromise?

If this hasn't already been tried, I'd love to see the results, and if it is anymore efficient. If it is redundant or not a good idea for reasons outside of my expertise, then let me know.

Fallback system

For a user to see your avatar properly in VRChat, they must have your avatar fully shown. Shaders, animations and all. You are invisible otherwise.

A fallback system might help here. Thanks.

Why is this not a Fork?

Since it was GTAvaCrypt why didn't you fork it?
That's not very OSS of you

Also calling it AntiRip is misleading as it only increases the difficulty to rip

Poiyomi shaders don't like Water

Encrypted Poiyomi shaders will blur Water waves on maps with water present according to where the obfuscated mesh would be (this is with the person as a friend even).
This effect is most pronounced on avatars with high Distortion Ratios and Maps with Water.
I've had multiple people report this to me now.

Pictures pending. Too drunk and late for me right now.

Add a mappings from non-obfuscated to obfuscated names

For use with OSC you currently have the Obfuscator settings that allow you to not rename a couple things.
For advanced Users it might be possible to just lookup a mapping from an Obfuscated name to the un-obfuscated name in a custom program.

Then as an advanced user you do not need to exclude really any names manually, because even if you use OSC, you can just use the provided mappings.

I've worked with ProGuard (Java obfuscator) before and they also provide the mappings. It is immensely helpful to have the mappings from non-obfuscated to obfuscated or reverse for the creator.
E.g.: I made a mistake in my controller and want some more information. So I go open the Debug Overlay and look at my parameters/Animators with the help of the mappings. Without the mappings the Debug Overlay is of no use.

Undisposed RNGCryptoServiceProvider

Hey as a programmer myself I saw a few little bumps in the code which I think could be improved and/or made more secure. I was looking over what was in it and noticed these things.

In the KannaProteccData class an RNGCryptoServiceProvider is used, but it doesn't get disposed of. This will lead to underlying resources which it uses to not be disposed. Luckily it can be easily fixed by wrapping the RNGCryptoServiceProvider in a using statement.

void Shuffle<T>(IList<T> list)
{
    using (var provider = new RNGCryptoServiceProvider())
    {
        var n = list.Count;
        while (n > 1)
        {
            ...
        }
    }
}

• Location in source code
• Microsoft documentation

It may be a good idea to use the RNGCryptoServiceProvider to generate the random encryption key inside the KannaProteccRoot.GenerateNewKey method like this:

public void GenerateNewKey()
{
    using (var rng = new RNGCryptoServiceProvider())
    {
        byte[] randomBytes = new byte[4];
        rng.GetBytes(randomBytes);

        for (int i = 0; i < 4; i++)
        {
            for (int j = 0; j < 8; j++)
            {
                _bitKeys[i * 8 + j] = ((randomBytes[i] & (1 << j)) != 0);
            }
        }
    }
}

• Location in source code

You don't have to make these changes, I just thought it would make the code a little higher quality and more secure.
Either way I hope you have an amazing day and I believe you are an amazing person for making this project!

Only actively equipped materials are properly encrypted

I have a lot of materials on my avatar.
I updated to 1179df2 recently from a really old version.

And now I found out, that my main mesh is finally encrypted.
But only materials actively equipped at the time I press Protect Avatar work properly.
All other materials don't work, even though they are in the Additional Materials list (which also doesn't properly auto-detect my material swaps).
My material swaps are controlled by a direct blend tree, which operates on type mismatched parameters (float in animation controller and bool in VRC Avatar Parameter descriptor)

Swapping the materials works fine, but the mesh is just an exploded mess.