Protection for my plugins
-
@David-Healey I do understand what you mean, I know that it doesn't cover every vulnerabilities and it can get cracked at any moment.
The goal of this security system is to discourage file sharing, not to provide unbreakable protection. I mean, I know its never gonna be between the hands of team R2R or some pentest pro, it is not meant to be available for purchase online that's why I want to make a security using the HWID.
-
@hyperphonias How will you generate the code from the hardware ID, will you use a separate authorisation app?
-
@David-Healey The HWID would be generated locally, and an external tool would be used to generate the corresponding authorization token, which the plugin validates at runtime.
-
@hyperphonias said in Protection for my plugins:
external tool
This is on a server or also on the local system?
-
@David-Healey The authorization tool would run locally.
The goal is to keep the whole system offline, without requiring a server-side check
We’re planning to use Ed25519 for signing, similar to what we’ve used in previous projects
We haven’t fully decided on using Ed25519 yet. Any advice or recommendations would be appreciated
-
@hyperphonias said in Protection for my plugins:
The goal is to keep the whole system offline, without requiring a server-side check
Any software you put on a user's system you should treat as if it's already compromised. Giving them the tool that generates the key is a very small step away from giving them a keygen.
I would simplify your life (and your users) and forget about a copy restriction system. You don't need one. It's inconvenient for your users (the people you care about) and not much of an obstacle for crackers (the people you don't care about).
-
@David-Healey I think there’s a misunderstanding here.
The authorization tool would not be distributed to end users.
The user would only provide their HWID, and I would generate the corresponding signed authorization key on my side and send it back to them. The plugin would then only perform local validation using the embedded public key.
These plugins are not publicly released products. They’re sold to a relatively small number of clients, which makes the likelihood of targeted cracking quite low. However, without any form of verification, the likelihood of the files simply being shared between users would be relatively high.
The goal isn’t to stop cracking in general, but to discourage casual sharing of the plugin between friends
-
@hyperphonias said in Protection for my plugins:
The user would only provide their HWID, and I would generate the corresponding signed authorization key on my side and send it back to them. The plugin would then only perform local validation using the embedded public key.
Ah ok, so it's running locally on your system, that changes things.
So the user sends you the ID. You encrypt it with your secret, you send the code to the user, they enter it into the plugin and it decrypts it with the public key.
This sounds very similar to what @Lindon is doing with his RSA key system.
-
Yes, exactly!
I mainly wanted to confirm that this kind of approach is feasible in practice. What I’m really looking for at this stage are a few high-level hints. For example, common ways to generate a reasonably stable hardware ID and whether it’s possible for the plugin to automatically create a local authorization file after validation, like an auto sign-in.
I just need these small details before starting so I can get a clear idea of the overall architecture. Any advice or best practices would be very welcome.
-
@hyperphonias There's a built in function to get a machine ID and you can use the file and file system APIs to create, encrypt, and read and write files.
-
@David-Healey Perfect, i'll search everything
thanks for helping me
