Preventing reverse-engineering of client application

Question

I have a web service which is used by a Flash client. Both the service and the Flash client is produced by me (read: my company). The Flash client communicates with the server over HTTPS.

One of the issues we have seen lately is that people decompile the Flash client and then create their own clients to interact with the server. This is not a huge issue, since the server has a lot of "controls", but it is annoying.

I know about Flash obfuscation, but my question is a bit more generic: Assuming you distribute client software to work with your web service, what measures would you take to limit the risk of people tampering with your client software?

Answer 1

Obfuscation might look as the first obvious step, but obfuscation has to protect something in the code and that something cannot be webservice functionality because that is reverse engineered by intercepting the traffic even if it is SSL encrypted. Certificate pinning can prevent simple SSL interception by trusting a predefined certificate.

You can symmetrically encrypt communication data and store the key in the client then use obfuscation to make access to that key and encryption algorithm harder. And you can also protect the obfuscation by making decompilation harder. An example flash obfuscator and anti-decompiler is SWFencrypt and BISguard.

The previous are static source code protections but they don't guard against live/dynamic attacks. One way of protecting from these attacks is for the client to use integrity checks on memory and resources. There are also some anti reverse engineering techniques that can make live debugging harder.

The other way to prevent against live attacks is to use software that looks for any system tampering that may be used for client software tampering. This is the realm of rootkit-like anti-cheat engines like Punkbuster, Warcraft's Warden and Valve's VAC.

A different kind of protection is code signing and memory signing (down to the memory page) on closed platforms like iOS and Android. This way, you can limit static modifications to the client's binary and dynamic ones to its memory and the OS.

Even the old CAPTCHA can be used as protection against automation but it hurts user friendliness. You can also detect automation on the server, through user behavior and usage patterns then couple it with CAPTCHA to reduce false positives.

Aside from technical protections, you can use with legal means and even incentives. Provide the best client so users won't be inclined to hack yours or write their own. Or make it so that a custom or hacked client won't give the hacker a far greater advantage. Legal means are not my strength and will vary by country, but I've heard about lawsuits on reverse engineering. Legal threat might deter companies and individuals from selling or providing custom clients.

Finally, you can turn the whole problem on its head and make the webservice easily accessible through flexible APIs and protect against abuse on the server. You might also charge small fees for the superior functionality your hackers are craving for. :)

Answer 2

Fundamentally you cannot secure your client. At best you can obscure and obfuscate in order to make it more difficult for an attacker to modify the client.

You mention that it is not a security issue because the server is properly secured, but merely an annoyance. It may be more annoying to try to obscure your client than to let a few modified clients make bad requests that are rejected by the server.

It really depends on your threat models. In most clients that I have worked on, I did not bother with any obscurity or obfuscation, since the server was fully secured and there would be nothing gained by modifying the client.

Now, if we are talking about trying to protect a client itself (i.e. because of IP concerns, you don't want someone stealing the client) it may make more sense to devote time to making this difficult to accomplish (while still keeping in mind that you will never be able to fully secure a client - at best you can cause unmotivated attackers to give up and delay motivated attackers).

Answer 3

None. If they don't decompile your app, they will just put it through a proxy with it's own SSL certificate. Your client can't provide security for your backend.

Answer 4

what measures would you take to limit the risk of people tampering with your client software?

There's a balance here that only you can measure. Assuming your protection doesn't bother valid users, then you only have to balance the value, to you, of protecting the software against the value to the attacker of breaking the protection.

If you're talking about software or service that's not very expensive and the clients aren't the type to go beyond simple means, then obfuscation might be enough.

If you're talking about a service or software that's either very expensive, or is otherwise valuable if misused, and the clients are determined to use the service with their own software, then you're going to have to use much more rigorous means.

In the first case, tools already exist.

in the second case the best option is to use Adobe Air, which permits signed applications that don't run in the browser. You can verify using public key cryptography that you are 1) talking to your application and 2) that the application hasn't been altered. It's complicated if you have to thwart very diligent attackers (and, honestly, nothing is absolutely impenetrable) but with careful design and frequent forced updates you can eliminate the majority of attacks by simply making it a lot of work to attack.