I have a desktop application build on the .Net framework.

If I obfuscate the code, even if somebody reverse-engineers the code and tries to call my API using the altered source, can I know if the API calls are not from the original source code?

If I build my application using code signing does it help?


2 Answers 2


Every time this question came up, I point people to David Auerbach's Chat Wars: Microsoft vs. AOL. The story shows the extent that some very clever people have done to try to do what you're trying to do, and the spectacular failures one after another.

The article may have been written for a different time and technology stack, but the basic facts haven't changed and will never change, no matter what kind of technology you're using to develop your application. Given a sufficiently determined adversary, it is fundamentally impossible to verify that a network request come from your authorized client only.

  • Oh man, that's a great story, well worth a read! The InfoSec world sure was different back then, though, wasn't it? Deliberately exploiting (rather than patching) a buffer overflow in your own product... and at the end of the day, if MS had cared hard enough, they could have maintained compatibility anyhow (the open-source messenger client GAIM, later Pidgin, managed well enough right up until the AIM servers were shut down last year).
    – CBHacking
    Commented Feb 23, 2018 at 3:23

Whether or not you will be able to identify calls from a modified or reverse-engineered form of your code depends on your capacity to recognise whether the calls could have been made by the original code.

For example, if your code is only able to issue a value for a parameter out of a set number of possible values, any call with an unknown value is likely to have been made by some other code than yours.

There is otherwise no possible way to know what has called your API, especially if the call is valid. For example if you are hosting a publicly facing http web service, I can issue curl commands to send GET requests to it, and it wouldn’t be possible to tell I used curl instead of your binary (and even if your binary does something clever like adding headers, I can always sniff them and imitate them later).

For a library, there is no efficient way of preventing another binary to link against it and start using its API.

Obfuscation will just slow down a reverse-engineer. If reversing your binary is sufficiently valuable, someone is bound to overcome your obfuscation sooner or later: code is not everything, they may also dump the memory during execution and see what’s in there, e.g. urls, variable values, etc... It may however divert more dilettante hackers that may just have wanted to poke around it. Please also note is not a means to protect critical information like embedded api keys or credentials, as recently and spectacularly demonstrated by the Retina-X breach, meaning that a reverser can acquire and mimic any mechanism that you would put in place to authenticate your original binary against your API.

Code signing is not a way to protect your code against reverse-engineering. It’s a way to cryptographically ensure that a binary’s integrity was not compromised before acquiring it, i.e. that the binary is exactly the same as that which was compiled by the original authors. It means however that no one should be able to distribute an altered binary and make it pass for a legitimate version you would have distributed yourself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .