Verify client-side created data

Question

I have a Java applet, which records the whole screen of the user and uploads the images to the server.

If one would be able to (and many people could, I know) falsify the screen recording they could cheat legitimate users of the system out of their money, so there are incentives.

I have been doing some reading on this topic and it seems like any attempt at client-side validation is pretty much useless ie. trusting the client is out of the question. Obfuscation and such only create an inconvenience to malicious users, not an obstacle.

This problem is partially solved by a feature I came up with, which enables the system to be sure that the recording is authentic up to a certain point. After that point in time, however, it becomes ambiguous again. After that point the hacker could overwrite my applet's functions and upload faked screenshots. Or he could switch monitors of his computer, where the new monitor has a fake, but identical-looking screen, open programs etc.

Somehow I need to be 99.9% sure that the recording is authentic.

So far I have come up with something like this: Log all upload times/rates of all screenshots of all users and then if someone is suspected of cheating, compare the upload rates to other users, especially before and after the potential "switch"/"overwrite", the underlying assumption being that overwriting the code slows down the application slightly or switching monitors creates some abnormal delay.

**The question is: is my theory valid? **

Answer 1

Your application looks like it's mainly running client-side because the server only receives those images. You therefore have very little data you can trust. This makes it very difficult to have it tamper proof, or be able to detect the data tampering.

Let's say you expect an untampered client to upload images every second to the server. Assuming the tampering takes half a second, you expect the tampered images to be uploaded every second and a half, but the tampered client can start processing earlier and still hit the 1 second upload rate. You cannot rely on timestamps provided by the client because they can also be forged.

You said you could rely on the upload rates of the other users in order to establish a pattern of know good rates, but what if an attacker or attackers would outnumber legitimate users? There is a difficult theoretical problem about this. A Google engineer described the difficult problem of detecting spam based on user reports and building systems that could resist sybil attacks.

Answer 2

Somehow I need to be 99.9% sure that the recording is authentic.

You need more realistic expectations.

What you are trying to do won't work:

• client-side timing data is for most-states completely dependent on the client not messing with it, and they can, but also the O.S. not choosing that point in time to do things; vast portions of client-timing can be altered, or are fragile enough to generate false-positives when 'legit'. Keyloggers and Performance Benchmarks ... think of it this way. Your error margins from O.S. background tasks vary timing by greater margins than the thresholds of what you're hoping to detect - you can't hope to succeed at that.

• your code is going to run on the client-side. That means it can be reversed. If there's enough money riding on it you might get the attention of some of the groups out there that are good enough to reverse any tricky code within hours - these skills have been a side-effect of the malware arms-race we've had for decades where the malware industry has been fighting similar battles to you, and have had a lot of practice.

• the packets sending client-side timing back to you can be altered, and if there's enough money in it, will be. Encrypting/clever tricks raise the bar a little, but is all just more obfuscation which can be beaten, and if there's money riding on it, will be.

On the otherhand if you succeed at beating the above problems, congratulations, you've beaten one of the biggest challenges in mordern computing... which would be worth a few billion.

Answer 3

What data do you need to be send exclusively as an "image" from client to server? what you need is some tell tale signs someone is messing with your data, so send more than just a 'screengrab'. send the data in more than 1 way (and use TLS connections) so, an image is send as a binary image file and as a raw value set that produces said image.

add some "markings" to your screen grab that are not easy to see. but add an "authentication" mark to it. (which includes the HASH of the image itself).

Add a challenge/response system to your uploading service (so EACH upload should have a response to a specific challenge, that changes for EACH request)

that way you can at least assure you know some things of your "client" and can compare values and prevent replay's

however your goal of +90% is just not achievable though these means. anything above 75% is wishful thinking (and 75% is already high) all you can make sure is that all the request that are being done are recorded and accredited so you can fix them post action if foul play is involved.