将状态存储在golang二进制文件中

Question

I am Developing an onpremise solution for a client without any control and internet connection on the machine.

The solution is to be monetized based on number of allowed requests(REST API calls) for a bought license. So currently we store the request count in an encrypted file on the file system itself. But this solution is not perfect as the file can be copied somewhere and then replaced when the requests quota is over. Also if the file is deleted then there's manual intervention needed from support.

I'm looking for a solution to store the state/data in binary and update it runtime (consider usage count that updates in binary itself)

Looking for a better approach.

Also binary should start from the previous stored State

Is there a way to do it?

PS I know writing to binary won't solve the issue but I think it'll increase the difficulty by increasing number of permutation and combinations for places where the state can be stored and since it's not a common knowledge that you can change the executable that would be the last place to look for the state if someone's trying to mess with the system (security by obscurity)

Answer 1

Is there a way to do it?

No.

(At least no official, portable way. Of course you can modify a binary and change eg the data or BSS segment, but this is hard , OS-dependent and does not solve your problem as it has the same problem like an external file: You can just keep the original executable and start over with that one. Some things simply cannot be solved technically.)

Answer 2

如果您的其余API在您的控制之内，并且可以肯定地成为您要获利的部分，那么您将在此处过滤许可的某种证书认证或API密钥，然后可以继续使用API您可以控制的一面，然后再将它放在平面文件或DB等文件中就无关紧要，因为您可以控制它。

Answer 3

Here is a solution to what you are trying to do (not to writing to the executable which) that will defeat casual copying of files.

A possible approach is to regularly write the request count and the current system time to file. This file does not even have to be encrypted - you just need to generate a hash of the data (eg using SHA2) and sign it with a private key then append to the file.

Then when you (re)start the service read and verify the file using your public key and check that it has not been too long since the time that was written to the file. Note that some initial file will have to be written on installation and your service will need to be running continually - only allowing for brief restarts. You also would probably verify that the time is not in the future as this would indicate an attempt to circumvent the system.

Of course this approach has problems such as the client fiddling with the system time or even debugging your code to find the private key and probably others. Hopefully these are hard enough to act as a deterrent. Also if the service or system is shut down for an extended period of time then some sort of manual intervention would be required.