I am thinking of implementing something like this into my own software.

The thing I have issues with though, is making the operations secure enough.

Another concern is the amount of data needed to implement for example 16 bit ckeck words instead of bytes. And having 6 or 8 instead of just 4. These could also be CRC16 values of some data.

That makes the key very long…

Any thoughts on that?

No solution is “100% immune” to cracking. Even phoning-home/dialing-in can be spoofed, as a clever user can do the following:

1. Packet-sniff a legitimate handshake with the real authentication server.
2. Reverse-engineer the authentication protocol.
3. Develop a custom server that emulates the protocol.
4. Reconfigure the network (DNS and routing) to redirect authentication requests to the emulated server.
5. Run the program as-is (i.e., no patches) in said environment until it receives the response it expects.

You can introduce some cryptography to this process, but it will only frustrate an attacker, not completely defeat him. Of course, patching–which, “sane” or not, is commonplace–completely undermines key checking, with or without phoning home.

Just a quick query… you state that the seed is 64-bit integer, however it is stored as 8 hex digits, which I thought could only represent a 32-bit number. Have I confused myself here? Or is this a mistake in the article?

Thanks again,
Karl :)

Dialing in is 100% immune to keygens, so pirates will have to create a patch tool, which any sane individual will refuse to download and run. Nothing you can do to stop patch tools: the more you try, the more of a challenge it is for them – frankly some kid will do it just to prove he’s better than you.

The “inline” directive will not *force* the compiler to inline your code, only tell it that it’s *allowed* to inline it. In the words of Danny Thorpe (the guy who added the “inline” feature to the Delphi compiler), the compiler “can disregard it if it thinks you’re wrong or stupid”. (One example he gave was if inlining made your call site so complicated that you needed too many temps and blew your registers. In that case, the compiler might choose to make the call instead of inlining.)

And the entry point might still exist. If every call is inlined, then the smart linker will remove the standalone function; but if any of the calls aren’t inlined, then the entry point will still exist. Granted, “inline” could make the code more resistant to cracking — even if the entry point still exists, some of the callers might use the inlined version instead. But if the check method is complicated, it probably gets more likely that the compiler will call the central function instead of inlining. (You can always look at the x86 code in the debug view to see whether it got inlined or not.)

There’s more in-depth details about “inline” in the “Function inlining” section on this blog post (my notes from Danny’s BorCon presentation, clear back when the feature was introduced): http://blog.excastle.com/2004/09/13/dannys-whats-new-in-the-diamondback-compiler-session/