1

what's the best way to hide/protect a string that contains my server IP address in C# winforms application?

here is the thing, in order to activate the application I created, the user should fill up some form that contains username and password textboxes and then connect to my server in order to verify his entered details.

now what I want is to hide/protect or maybe somehow encrypt the string that contains the server address so no one can actually change/access it or at least make it very hard to be reversed.. is that possible?

I'm not sure if I'm clear with the question but I hope you guys got the idea..

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
Desolator
  • 22,411
  • 20
  • 73
  • 96
  • Seems kind of pointless if a simple packet sniffer will reveal your server's IP when the request is made. The type of people who would care about your server IP are also the ones that would know to use a packet sniffer. – Marek Karbarz Jul 09 '11 at 18:33
  • its fine if they know the IP. but I don't want them to be able to change it.. that's all what I want.. – Desolator Jul 09 '11 at 18:46
  • That makes no sense. If they change the IP address then your program can no longer contact the server. – Hans Passant Jul 09 '11 at 19:10
  • possible duplicate of [C#: How to Make it Harder for Hacker/Cracker to Get Around or Bypass the Licensing Check?](http://stackoverflow.com/questions/4532540/c-how-to-make-it-harder-for-hacker-cracker-to-get-around-or-bypass-the-licensin) – Ben Voigt Jul 09 '11 at 19:16

2 Answers2

7

This is a ludicrous approach. Security through obscurity is very weak to begin with, and the IP address you're connecting to doesn't just show up in your source code, but in outgoing packets, firewall logs, connection tables, packet captures, etc.

Hiding the peer IP address of a connection is a big area of interest and leads to techniques such as onion routing. Hiding the address in your source code is the least of your worries. And when you do use onion routing, the destination IP address won't even appear in your source code, only some cookie that is meaningful only to the next-hop onion router, so obfuscating source code becomes a non-issue.

EDIT: Based on comments, it's now clear that what's wanted is verification of the identity of the remote computer sending a response. There are ways to accomplish that, but protecting source code is not one of them. IP addresses can be spoofed, and easily. A public key stored in your application binary can be overwritten, or the authentication code can be bypassed completely.

Really, you'd need some vital function in your program to not be included in the installer, but downloaded as part of the authentication process (then the server can choose not to send it if authentication fails). There's still a possibility that the response can be stolen and used to activate additional installs without authentication, but this can only be done by someone who could validly authenticate at least once.

If you're worried about that, then you'd need to use steganography to encode the client's identity in the response. Then when illicit copies start appearing, you know which valid user made the first copy.

Or keep the proprietary parts of your software on your server, and don't ever download them to the client. This is the safest method.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • well I just don't want anyone to change it. its ok if they can see it through the outgoing packets... – Desolator Jul 09 '11 at 18:48
  • @ermac: I don't need to change your code... I just need iptables (or the equivalent) http://linux-tips.org/article/91/rewriting-destination-ip-address – Ben Voigt Jul 09 '11 at 18:51
  • and is there anyway to fix this issue? I really don't want to distribute my application if anyone can just do this trick and bypass all of my checking routines.. – Desolator Jul 09 '11 at 19:01
  • @ermac: I don't know what your application does, but if you want to protect it, and you can require users to have internet access (it sounds like you're already requiring that), you can put all the calculations into a web service, and give out just a thin client. The difference between this and an authentication server, is that in this case all the processing is done on your server. If a hacker takes the network access out of your program, there's nothing left, because the client never did anything useful (except maybe a fancy display). – Ben Voigt Jul 09 '11 at 19:08
  • well tbh, I don't want to put any codes on my server. there will be lots of load and users won't be happy with that. so i suppose all I can do for now is to do several checking routines.. and try to trigger them from different locations.. of course I have to obfuscate the application and maybe add some code integrity routines as I call it "booby traps" like if some parts of the codes altered or changed the program will fail to run.. maybe md5 checksum validations.. then pack it with thamida ugh.. hopefully it will be hard enough to prevent the simple crackers from playing with my application. – Desolator Jul 09 '11 at 19:39
1

Why do you need to obscure the IP address of your server?

Presumably, your application is going to contact your server and await some response before activating. In which case, I don't think that hiding an IP address is the way to do it. Not least because IP addresses are potentially volatile. Instead, you should simply use mutual authentication between the client and server. I'd suggest:

  1. Use DNS to resolve your server's IP address. Don't worry about the fact that this can be sniffed and even spoofed.
  2. Use standard public/private key cryptography.

The application encrypts the data to the server using the public key. The server then decrypts that with the private key. A fake server wouldn't be able to decrypt the data and a fake application wouldn't be able to encrypt the data.

The server then encrypts the response using the private key and the application decrypts it using the public key.

The best way to implement public/private keys is to use certificates. Install the private certificate on the server. Have the application installer install the public certificate (usually a .cer file, generated from the private certificate) and mark it as non-exportable (to prevent someone copying it to another machine).

EDIT: Ben made a valid point that I was just in the process of investigating. Better than installing the certificate may be to embed it in an assembly that you ship with your application and sign that assembly with a strong name (.snk file). This will ensure that the certificate can be used to encrypt/decrypt the traffic but cannot be modified (because the assembly won't load if it's tampered with).

Then use the CryptoAPI to encrypt/decrypt your data.

Oh, and you might choose to use HTTPS to communicate with your server, too.

Don't try to roll your own encryption/decryption. You won't be as good as the people that have already done it, or the people that try to crack it.

Steve Morgan
  • 12,978
  • 2
  • 40
  • 49
  • This doesn't help either, if the "public key" can be overwritten in the client. – Ben Voigt Jul 09 '11 at 18:57
  • The certificate can still be modified. Strong names prevent tampering without the user's knowledge... but if the user intends to use the modified copy they don't help at all. – Ben Voigt Jul 09 '11 at 19:10
  • Valid comment, Ben. I've suggested putting the certificate in a signed assembly. However an alternative would be to put the certificate thumbprint in a signed assembly (directly in the source code would do, as long as the assembly is signed) and use that to resolve the certificate from the certificate store. – Steve Morgan Jul 09 '11 at 19:10
  • Read the comments on [this answer](http://stackoverflow.com/questions/4532540/c-how-to-make-it-harder-for-hacker-cracker-to-get-around-or-bypass-the-licensin/4532558#4532558). In fact, that whole question is full of good information. Code signing doesn't prevent cracking, it just makes the user aware of it. – Ben Voigt Jul 09 '11 at 19:12
  • Ben, sorry, we cross-posted. The loader will not load a .NET assembly that has been tampered with (you get a FileLoadException). So, if the certificate is embedded in a signed assembly or the thumbprint of an installed certificate is embedded in a signed assembly, I don't think you can get the application to load it. – Steve Morgan Jul 09 '11 at 19:13
  • Now, distributing an improperly-signed assembly with the application, and using the `FileLoadException` as part of the startup logic, might really give a cracker fits until they figure out what's going on. This isn't a new idea, for example, Microsoft played similar tricks in kernel mode with "PatchGuard". But as long as hackers and crackers are [this smart](http://uninformed.org/index.cgi?v=all&a=28), one should assume that software on the user's computer is totally under the user's control. – Ben Voigt Jul 09 '11 at 19:26