0

I'm developing a program in C#. It connects to the internet to see if this copy is valid.

Currently I'm just sending the licence key and getting a response (0 or 1) if the key is valid.

The problem is that some users just fake the data with some packet capturing tool and replay it. So the application is very easy to crack. How can I prevent this?

Here is what I essentially want to prevent:

  • Network replay attacks
  • Authentication "emulators"

It should be impossible to find out what data is sent. Maybe I should add the current time and then encrypt the packet ? So it's always different ?

Attention: Please don't warn me that it's easy to crack the application itself by modifying it. I know that. This question is only about the network part.

undefined
  • 33,537
  • 22
  • 129
  • 198
user1392060
  • 187
  • 1
  • 1
  • 6
  • 1
    https ftw dont secure it yourself use existing security protocols – undefined Jul 11 '12 at 02:56
  • 1
    "It should be impossible to find out what data is sent." You're asking for the impossible – Polity Jul 11 '12 at 02:56
  • 1
    @Polity - That is exactly what SSL and HTTPS provide. – Hogan Jul 11 '12 at 03:01
  • @Hogan - SSL and https provides good security for network sniffers but its still perfectly possible to catch the actual data being sent from the local machine. – Polity Jul 11 '12 at 03:04
  • 1
    @Polity - "This question is only about the network part." I believe this quote of the OQ shows that is what the user was asking -- Which you said was impossible. – Hogan Jul 11 '12 at 03:06

2 Answers2

3

If you use SSL or HTTPS then you don't have to worry about users cracking the data packets. This is easy because the libraries already exist and are easy to implement. With C# and IIs for example it is just a matter of installing the certs and changing a few configuration items. (Maybe a recompile with some slight code changes).

Hogan
  • 69,564
  • 10
  • 76
  • 117
  • Unfortunately it is not really difficult at all for users to examine their *own* SSL traffic using something like Burp proxy or other tools. – President James K. Polk Jul 11 '12 at 11:29
  • @GregS - and how exactly would they decrypt it without the server side private key? – Hogan Jul 11 '12 at 11:53
  • 1
    @GregS I guess if you don't get access to the application (that's a big if), then SSL would be a good choice for such a thing. What will probably happen is that somebody strips out the security and distributes the application. – Maarten Bodewes Jul 11 '12 at 20:47
  • @Hogan: the proxy performs what is essentially a man-in-the-middle attack. They cheat by creating their own server private key, which you can then load into wireshark for example or just let the proxy save off the traffic directly. But as owlstead notes, different apps may be more or less accommodating. All browsers that I'm aware of can be coaxed into making the connection to the proxy. – President James K. Polk Jul 12 '12 at 00:31
  • @GregS - This isn't a browser it is a client program. He is making the connection to his server and checking the name (strongly named) of the cert. If the name of cert does not match then auth does not pass. Better yet he can install the cert in the client program and not even request it via a potentially proxied connection. We are making the assumption that the client program can't be changed. Of course, that can be solved too via hardware dongles that contain the cert (as John Browne would be happy to explain since that is one of the products his company sells.) – Hogan Jul 12 '12 at 02:28
  • I'm not saying your answer is wrong and I didn't downvote it. Even if it is a client program it may rely entirely on .NET default functionality. If for example the malicious user creates his own CA certificate and signs a "fake" cert with the expected name, the app may not complain but .NET may display a standard GUI warning that the malicious user will happily click through. Maybe his app will prevent this, maybe not. – President James K. Polk Jul 13 '12 at 13:44
  • @GregS - Your point is well taken because there are many ways to implement security that is not secure. Care and vigilance is always required. – Hogan Jul 13 '12 at 14:38
0

Assuming you actually want to prevent license abuse there are far better ways to do this. The "phone home" approach is easy to roll yourself, but as you've noticed it's full of holes.

Disclaimer: I work for a company that makes commercial tools to solve these license management and copy-protection issues. There are other similar products available from a variety of vendors.

This isn't that different from thinking about how to do setup for your application. Choices are roll your own or buy an existing 3rd party toolset. Rolling your own at first blush make seem cheaper, but that's perhaps only because you haven't really discovered all the true requirements to create something robust and reliable. The 3rd party tool vendor needs to charge for their products, but they've spent years discovering all the issues with particular problem set and have solved the problems. So that eliminates work for you and leaves you free to focus on where your application can add value.

The difference is if you get setup wrong your users will be irritated; if you get copy protection wrong your product will be pirated.

In any event, reducing license validation checking to a binary "either/or" condition is extremely easy to crack--doing that check over the net makes it 10 times easier (record playback attack). Modern approaches encrypt the executable and the license is contained in the key to decrypt it (this is an oversimplification since the actual methodology includes a lot more complexity to make it virtually impossible to get around). Only by having a valid license can the executable be decrypted on program load and run.

If you want to do it the way you've described, consider this: Have the app use a predictable, changing value (such as a lookup from a table of random numbers coupled with some external value like time) to create some kind of hash. Have the server implement the same code. The server sends the hash to the app, which compares it to its own hash. If they match, the app is allowed to run. If they don't, it errors out. Since the hash is different on ever startup attempt, recording it over the network won't allow the user to get it to run the next time it tries to start.

John Browne
  • 700
  • 4
  • 6
  • If you don't remove that "impossible to get around" I will certainly mod this down. – Maarten Bodewes Jul 11 '12 at 20:50
  • Hi, thats also a good idea. Hashing with some outside factors seems nice. Thanks :) – user1392060 Jul 12 '12 at 04:24
  • Ok, I modified it but I think you're bullying a little bit. The small part I'm referring to is the way the key is retrieved. I believe it's impossible to circumvent, unless you know a way to crack ECC. – John Browne Jul 16 '12 at 15:56