views:

187

answers:

6

Hey guys,

I've been reading Stack Overflow for quite some time, but this is my first posted question.

I have this tracking program written in C# which collects information about local computer usage and sends them to a server. The data is XML-formatted, sent once per ~10 minutes.

My problem: no matter how I encrypt the XML data (be it symmetric or asymmetric), someone could always decompile my C# tracking program, figure out the key/certificate/encryption conventions I use and write another program that sends fake reports to the server.

The tracking program works under the assumption that the user running it may be interested in sending fake reports.

Questions: 1) how can I make sure (as sure as possible) that the data is send from the real tracker instead of a clone/faker ? 2) how can I obfuscate the code badly enough that recovering keys/certificates/encryption conventions becomes hell/next to impossible ?

I want to spend little or preferably no money on the solution (so 500$ obfuscators are out of the question. I'm a university student and I'm cheap :)

Thanks in advance.

A: 

1.Another approach: Assuming you don't change your executable often. make a DigSig of your(HASH+Encrypt) your client executable file image and send it along with, that would authenticate your client as the real client and not a modified version.

But this cannot prevent data being sent by a totally different client which can aquire the Digsig of your Executable image.

Vivek Bernard
Diffie-Hellman adds very little extra value without a third party. Quite easy to MitM if everything you need is on the machine.
Mark H
@erickson Yeah. That was stupid. For the OP's scenario, it doesn't matter if its Symmetric/Asymmetric.
Vivek Bernard
+1  A: 

In theory, an application simply cannot secure itself when running in an untrusted environment. So, the answer to the first question is, "You can never be sure that data are sent by the real tracker."

In practice, obfuscation will thwart attackers up to a point. The point is determined by the quality of the obfuscation and the motivation of the attacker. So, the answer to the second question depends on who the attacker is, how capable they are, and what resources they might apply to this problem. Obfuscation that is "hell/next-to-impossible" for an unmotivated layman to to unravel might be trivial for an expert, or someone who can hire an expert.

Here is a list of some C# obfuscators.

erickson
check out .net reflector, one of the best decompilers I've ever seen (and its free)
Matt Briggs
+1  A: 

Will the client user have administrator rights over the machine? It sounds like the kind of app that would be installed by an admin, but used by non-admin users. If so, maybe you could store your key or hash protected from normal users, and run the app in the context of the administrator user. I'm not really familiar with the key store, but I'd expect all versions of Windows (at least XP+) would have this functionality available. If not the key store, then maybe a file located in an encrypted directory belonging to the admin user.

If your target user has local admin rights, then I really don't see how you can stop them.

Joe Enos
"run the app in the context of the administrator". That would be a potential security hole.
jgauffin
How about just in the context of a different non-admin user?
Joe Enos
+1  A: 

It seems fairly hopeless. Your tracker probably relies on Windows to provide the metrics, such as by ultimately calling GetUserName()/GetTickCount()/CollectPerformanceData()/etc. So, a bad guy just has to trap your code (regardless of how obfuscated it is, and without bothering to decompile) at any Windows entrypoint of interest, substitute the fake data, and let your code continue on its merry way.

Life's too short to beat your head against those kinds of brick walls.

joe snyder
+1  A: 

We have been using a hardware solution to provide this required functionality.

I have been working with a product called IronKey, it is a hardware device that is capable of generating digital signatures. When we issue the device we store the public key on our server. when our client application submits data we generate a signature using the private key, once we receive the data we can verify that it was sent from the correct client using the public key.

Rohan West
That proves the report was sent from a box with the dongle, but it doesn't guarantee the data wasn't faked by modified software running on the box.
joe snyder
The data is signed by the device, the client sends both the data and the signature to the server, the server verifies the signature against the data and the signature using the stored public key. If the verification fails then we know that either the data has been faked, or that they are using the wrong private key. The ironkey is not just a dongle, it's provides hardware signing and verification via pkcs11.
Rohan West
@Rohan: he's generating data programmatically every 10 minutes. signing data doesn't guarantee his program wasn't compromised.
joe snyder
@joe: There has to be some human confirmation that the data that they see is the data that is being signed. I agree that the data can be changed where ever it is stored
Rohan West
+2  A: 

As Raph Koster once put it, writing about the battle against hackers in client-server online games,

Never trust the client. Never put anything on the client. The client is in the hands of the enemy. Never ever ever forget this.

Unfortunately, for pretty much any real-world application that requires that the processing power of the client is used, something has to be put on the client, and therefore because available to a malicious attacker. The question that has to be asked - as with any security measure - is how much time and money are you prepared to spend mitigating this risk?

Some people like to point out to people asking about obfuscation or client-side licensing mechanisms, "oh there's no point, it will be broken eventually". But this is to miss the point: that the purpose of such measures is to push that 'eventually' further into the future, to the point that for an insufficiently-determined attacker, it will be 'never'.

For example: if your app sent its data by plaintext email, that would defeat approximately zero attackers. Sending it in rot13 email would defeat maybe 5% of attackers. Sending it encrypted using the username as a key would defeat more. Obfuscating the sending code with a free obfuscator would defeat more. Obfuscating with a commercial-grade obfuscator would defeat more. Requiring each client to have a hardware dongle would defeat 'all but the most determined' attackers, as people like to say - but this would probably be an intolerable cost.

From "I'm a university student" I'm guessing this isn't the most sensitive project ever. Use a free obfuscator and cnrypt the sent data using some user-specific information as the key. That'll probably do.

AakashM