|
For me, the protections I usually stick to for my things are:
- Any sensitive functions or workflow is not coded in any managed language.
- Any sensitive functions or workflow is not hard-coded into the client at all.
- Validation requires an internet connection and is handled remotely.
- No simple jump/call bypass for the validation because required data is returned if validated.
I use a streaming setup with a client <> server communication approach. My client applications are 'stupid' in the sense that they are just enough to turn on, but they lack key functions and data required to make them operate. When they boot up, a validation handshake is performed with the server where some type of data is collected from the client machine, be it a login (username/password) or other random data like hardware ids etc. and is sent to the server for validation. If valid, the server will send back important information required for the client to run. It could be something basic like a key, or something intense like run-time ready code that can be compiled on the fly and so on.
A client can't just be manipulated with a single byte patch in this case as regardless if you make it assume it validated, it will not have the needed data to run without the server giving it back.
Not a fool proof method but a lot more work is required in order to bypass the protection entirely so it helps keep the skids away.
|