0

I'm going to write a Client/Server application. There are some ambiguous concepts in this that I was not able to get answer to after many hours of searching.

As we all know one of the major caveats of the .Net framework is that the DLL files can be decompiled and reverse-engineered on the client's machine.

Now my question is can I put some of the DLL files required by the Client on the Server?

And if true, will it be completely secure or it will still be open to getting reverse-engineered/decompiled by crackers?

EDIT: The question is different as it asks for the security in the context of a Client/Server application.

Vahid
  • 5,144
  • 13
  • 70
  • 146
  • possible duplicate of [Protect .NET code from reverse engineering?](http://stackoverflow.com/questions/506282/protect-net-code-from-reverse-engineering) – Matías Fidemraizer May 06 '15 at 09:27
  • @MatíasFidemraizer I wouldn't say it is - this explicitly mentions the use of client/server and discusses the exposure of code rather than protecting against actual reverse engineering. – aevitas May 06 '15 at 09:31
  • @aevitas See what OP says: **As we all know one of the major caveats of the .Net framework is that the DLL files can be decompiled and reverse-engineered on the client's machine.**..... Even if it's a n-tier solution I see how it's the never ending issue asked many times in SO and every Q&A and forum in the world... – Matías Fidemraizer May 06 '15 at 10:00

2 Answers2

1

For the client to use the dll files, it will have to download them from your server to the client. Thus making reverse engineering possible once again. It does not solve anything basically.

I think your goal should be to keep the client as thin as possible, doing most of your logic server-side. While I do not know the details of your client/server application, one could think of using a webservice which the client calls to access the server. That way you only have to make sure that client authentication to the webserver is solid and that you do sanity checks against any incoming input from clients.

pyrocumulus
  • 9,072
  • 2
  • 43
  • 53
  • So maybe this way is better? http://stackoverflow.com/questions/30016708/is-the-security-of-this-net-application-flawed – Vahid May 06 '15 at 09:30
  • 1
    @Vahid yes that is basically the same process. Making sure as little as possible important code is on the client itself. – pyrocumulus May 06 '15 at 09:34
1

That depends completely on your implementation - if you stream the modules to the client at some point, they can be dumped and reversed. If you keep the functionality purely on the server's end, and only return results to the client, you'd be a lot safer.

General rule of thumb with any software, and not just .NET, is that whatever is present can be reverse engineered. I wouldn't say that's "one of the major caveats of .NET" personally.

Basically, if you want to protect yourself against reverse engineering by going with a client/server model, there are a few rules of thumb that apply:

  • The server should never trust the client
  • Keep as much of your actual implementation on the server's end
  • Do not stream modules to your client
  • Use proper authentication and rate limit requests so your server can not be used to simply "dump" responses from
aevitas
  • 3,753
  • 2
  • 28
  • 39
  • So I guess the implementation here is what you mean? http://stackoverflow.com/questions/30016708/is-the-security-of-this-net-application-flawed – Vahid May 06 '15 at 09:34
  • @Vahid More or less - though you should keep in mind that it still isn't bullet proof. Having said that, just providing the server with data it requires to do its work and returning the result of said work afterwards is good practice. – aevitas May 06 '15 at 09:35
  • Thank you so much Aevitas, can you please post the cons of that approach on that question, it doesn't have an accepted answer yet. – Vahid May 06 '15 at 09:37
  • @Vahid I would, but it wouldn't answer the question asked. – aevitas May 06 '15 at 10:16
  • I meant the linked question. – Vahid May 06 '15 at 12:23