22

I have created a mobile application that monitors the accelerometer activity and based on that it rewards the user if a specific pattern is observed. How I can secure the application against the user itself who may try to hack the application to report the pattern I am looking for in order to get the reward?

One more thing is that the reward is given to the winner at the end of the competition at a physical agency. Is it possible that the agent before given the reward check if the user has manipulated the app or not, for instance by observing or compare something in the device?

Noureddine
  • 339
  • 2
  • 6
  • 25
    https://www.aliexpress.com/wholesale?SearchText=phone+swing – Coxy Jun 09 '20 at 06:23
  • @Coxy What's the purpose of these devices? – Num Lock Jun 09 '20 at 12:27
  • 1
    @NumLock one use is for testing fitness tracker apps, the phone swing makes the phone count up steps. It's very useful for developers and QA teams to test their products with a certain number of steps without actually walking about. – Freiheit Jun 09 '20 at 13:11
  • 8
    Are you sure that is a problem for you? When the user is betraying himself, it's his own fault. I see only a problem, when you are rewarding the user in a way that is costly for you. Because when the user reaches a certain fitness goal without actually walking, he knows himself that the achievement is not real achievement but just cheating. – allo Jun 09 '20 at 13:50
  • 10
    @allo Are you sure the user is only cheating themself? I've seen pedometers issued by companies or health insurers to verify that a subject is "healthy" with real incentives for high step counts. – Michael Jun 09 '20 at 16:43
  • 3
    The answers seem not to mention the possibility that someone could build a device to physically move the phone around in the desired pattern. That would be almost impossible to protect against, I would have thought. – N. Virgo Jun 10 '20 at 09:14
  • 1
    Write your application with Malbolge. https://esolangs.org/wiki/malbolge (Not a serious answer) – Almo Jun 11 '20 at 15:09

7 Answers7

69

You cannot.

As soon as the user has the mobile device and your application, nothing stops him from decompiling your application, understanding how it works & what data it sends, and replicating it. They can even cheat using some contraption that rotates the phone around and make your application believe it's a human that is using it.

They don't even need to decompile your application; they just have to put a proxy to intercept the requests and understand the protocol.

From the comments:

If you control the hardware, you can secure the app:

Not quite. Apple controls from the processor to the UI of the iPhone, and jailbreaks are a thing. Even if they are controlling every aspect of it, one day someone jailbreaks and roots the iPhone, and loads your app on it.

Certificate Transparency, Key Pinning

Not useful if the device is rooted. Checksum, digital signature and integrity verification only work if the OS is not compromised. If the user owns the OS and the device, he can disable OS checks, can edit the binary of the app and change the instructions verifying the signature or checksum.

Virtual Machine, Code obfuscation

They make it much more difficult to analyze the code, but code must be executed by the processor. If a disassembler cannot help, a debugger will. The user can put breakpoints on key parts of the code, and in time will reach the function checking the certificate, or the checksum, or any validation checks in place, and can alter anything he wants.

So it's pointless to try?

No. You must weigh the costs and benefits. Only don't count on the defenses to be unbeatable, because every defense can be beaten. You can only make it so hard that the attacker gives up putting lots of resources against your app and receiving a little benefit.

auspicious99
  • 493
  • 3
  • 17
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 8
    fundamentally you are correct. but in a practical approach you could do a few things to raise the difficulty involved in messing with the app. – Pedro Jun 08 '20 at 14:56
  • 23
    you can make harder and harder, but you cannot protect any app from being hacked. Pokemon Go is a good example: it used the phone sensors, had a company with lots of experience and money, and the app got hacked anyway. – ThoriumBR Jun 08 '20 at 15:22
  • 6
    I started by saying you are correct. And you are. But there's still value in making it harder even if impossible is not an option. – Pedro Jun 08 '20 at 15:28
  • 7
    Correct! But as soon as the reward for breaking the system is larger than the cost, it will be broken. Sometimes it will be broken "just for fun," that's why trying to protect a system client-side will mostly not work. – ThoriumBR Jun 08 '20 at 15:31
  • 2
    Also quite true. The impact to a business is quite variable though with the amount of protection in place. From no protection to unbelievably difficult is a large spectrum of potential loss of revenue (and hence motivation to implement security). – Pedro Jun 08 '20 at 15:41
  • You cannot intercept the traffic of an app if it follows basic security principles, like certificate ttansparency, among others. – Pedro Lobito Jun 09 '20 at 01:15
  • 4
    @CONvid19 If it's running on hardware you control, then you can, no matter how good it follows security principles. – Joseph Sible-Reinstate Monica Jun 09 '20 at 01:37
  • 1
    @ThoriumBR: Well, you can, _if you control the hardware_. Take Apple Inc, who can actually control what people run on IPhones via code signing. It takes dedicated hardware and a lot of planning, though - and can still be broken. – sleske Jun 09 '20 at 06:14
  • @JosephSible-ReinstateMonica Even Apple cannot control everything all the time, and jailbreaks are here to prove that. Sony did a good job with the PS3, and took around 4 years to the security to be defeated, but it was defeated too. – ThoriumBR Jun 09 '20 at 11:25
  • 3
    @CONvid19 Nothing stops the user to change a `JNZ` to `JZ` on the code, and proceed when the certificate mismatches. Or editing the binary and pinning his own certificate. Or `NOP` the entire checking function. Client-side security will always fail given enough time and motivation. – ThoriumBR Jun 09 '20 at 11:29
  • @ThoriumBR I meant "control" as in "have physical possession of". – Joseph Sible-Reinstate Monica Jun 09 '20 at 13:52
  • @JosephSible-ReinstateMonica in this case, it's possible. But on OP's case, it would not be much useful if the user does not have the device that will record its own movements... – ThoriumBR Jun 09 '20 at 13:54
  • 1
    @ThoriumBR Right, that's my point. I'm agreeing with your answer. – Joseph Sible-Reinstate Monica Jun 09 '20 at 13:56
  • I guess the question is: when it gets hacked once, is it wide open to everyone via info sharing, or would each user have to hack it themselves? In the latter case I imagine making it harder is still worth it, while in the former case it might not be? – bob Jun 09 '20 at 16:16
  • 1
    @bob hacked once, hacked forever until you release a new version that plugs the hole, or change the protocol, or any other countermeasure. It's hard to keep secrets now. – ThoriumBR Jun 09 '20 at 23:23
  • @ThoriumBR then yeah in this case is seems like it's not worth it to try to prevent. – bob Jun 10 '20 at 12:20
25

While I generally agree with ThoriumBR's answer, there are some things you can do.

For example, you can analyze the user's behavior for discrepancies, such as:

  1. Obviously Replayed Data

    For example, a user could act in a desired way, then capture the sent data and replay the data again at a later time. This can be determined quite easily, given how the noisy sensor data just happens to be the exact same, which would never happen in a real use case.

  2. Obviously Faked Data

    For example, a user could report fake sensor data. This data would likely not be random enough. For example, instead of reporting a location of 48,7849165°N;27,4159014°W, the faked datapoint could be 48,78°N;27,42°W.

  3. Machine-like Patterns

    For example, a user could write a program that automatically sends noisy and "correct-looking" data at always the same time of day. This seems suspicious, as basically no user would be this precise.

Of course, you can't see these examples as an exhaustive list. There're merely here to serve as examples of what kind of patterns you can detect. Training your system to detect anomalies is a lot harder in practice, and will likely be more difficult to implement than just living with the fact that some people will cheat.

Since the question was edited after the answer was published: You could perform a more thorough analysis of the dataset of the winners to see if irregularities occur. This way, you would only have to perform analysis on data sets which actually matter to you as a company.

As Falco mentioned in the comments, adding a disclaimer such as "Your submissions will be analyzed to prevent cheating" may prevent some people from sending in fake submissions.

  • 6
    How could you catch replay attacks without recording, saving & searching the raw data? That sounds quite impractical. – jpaugh Jun 08 '20 at 22:34
  • 6
    @jpaugh thats exactly what we do for our app - its just a lot of data, its not exactly impractical and once you get a model for how "real" data looks, you can spot "fake" data based on the model and discard more of the backing data. – Moo Jun 09 '20 at 00:22
  • @jpaugh It is a difficult, and will require a lot of data being saved. I also don't want to pretend like anomaly analysis is the be-all-end-all, since it requires a ton of data and analytics, and will most likely be too big of a thing to pull off for most little companies trying to release one app or two. –  Jun 09 '20 at 08:53
  • 1
    You can see the pros and risks of detecting and acting on these discrepancies in gaming, where cheating, and the detection and prevention thereof, is not uncommon. There are some high score tables with clearly impossibly high scores (e.g. finishing a level in 0.0001 seconds) and there are some cases where some players are banned for just playing the game normally. – NotThatGuy Jun 09 '20 at 10:12
  • 1
    I think you underestimate the real-life problems with different hardware. "Too exact" data? You don't know what the phone firmware on some phone you never used may do. It isn't even that stupid to denoise inexact location data, because why should apps rely on the fifth place after the comma, when the sensor reading is only accurate to two places? – allo Jun 09 '20 at 13:49
  • The OP has a special case, where there is only one (or a few) winners and they will be physically present and could be sued for cheating. - If you record the data on the device and upload it periodically to the cloud, you only have to check the data for correctness, once a person claims to be a winner and signs the form "I promise I didn't cheat and if I did I owe the company $1000 in damages" when collecting their price and after that check his data. - Most people will not try to cheat, if there is a real risk to be caught after the fact. – Falco Jun 10 '20 at 09:32
  • 1
    @Falco All of this information was added after this answer was written –  Jun 10 '20 at 11:05
  • 1
    @MechMK1 I think this answer could be improved, by adding a small paragraph at the end. Since your proposed solution seems ideal for the OPs situation, since analysis has not to be done on all data, but only on the data sets of the winners - and even just disclosing the information "your data will be analyzed to prevent cheating" should prohibit most cheaters – Falco Jun 10 '20 at 11:08
24

While I agree with the other answers, I find there are a few pragmatic things that are overlooked there.

Full disclosure: I work for a company that builds obfuscation / protection software for mobile applications.

Full, unbreakable protection is not possible for an app running on an attacker-controlled device. However, software exists that aims to raise the bar and makes it less / not worthwhile for a person to carry out an attack.

Typically these solutions cover two aspects

Static protection

This usually includes a bunch of obfuscation techniques aiming to make it difficult for an attacker that wants to analyse a mobile application by looking into the binaries using tools like IDA Pro, Ghidra and Hopper.

Techniques here are control-flow obfuscation, semantic obfuscation (class, method, ... names), arithmetic obfuscation, string encryption, class encryption, ...

These make it very difficult to "peek" inside a binary and figure out what is going on, but don't offer a lot of protection when an attacker looks at the application while it is running on the device itself.

Dynamic protection

These are protection techniques aim to shield an application from analysis or modification while it runs on the device. Popular tools here are debuggers (lldb, gdb, ...) and hooking frameworks (Frida, Cydia Substrate, ...).

Techniques here will try to block / detect the use of these tools, detect tampered execution environments (jailbroken / rooted device, emulators), modifications made to the application and much more.

Conclusion

While it's of the utmost importance to ensure your application was built using the well-defined security practices (obfuscation / protection software will not help you here!), tools exist that can function as a bunch of shells around your application that all together make it much more difficult, and hopefully not worthwhile, to crack your application.

DennisFrett
  • 365
  • 1
  • 6
  • You could also create a virtual machine inside the app, to perform critical operations there, which offers some protection against both static and dynamic attacks. – auspicious99 Jun 09 '20 at 08:23
  • 1
    I find it sad that security by obscurity has to be such an important thing ... Not that it's not useful. I just wish there was a more ... *robust* solution to preventing the user from doing whatever with your code. Guess I should have been a civil engineer rather than software one. Passer-bys are not too likely to rip appart a bridge just to avoid having to pay the toll :-( – Mathieu VIALES Jun 09 '20 at 11:12
  • 1
    @Mathieu VIALES, there are some changes being implemented on that front also. You can have a look at Intel SGX, ARM TrustZone, which are hardware implementations. I also know of hypervisor-based academic ideas that try to provide some meaningful security on malware infected devices. Not a complete solution of course against an attacker-controlled device, but it gives some extra guarantees. – DennisFrett Jun 09 '20 at 11:33
  • @DennisFrett That sounds quite interesting ! I'll make sure to to lookup SGX & trust zone. Sounds quite promising. regarding attacker-controller devices, I guess there won't ever be an actual solution as long as the code in any form is ever present on the attacker's devices :-/ – Mathieu VIALES Jun 09 '20 at 11:46
  • 1
    Nitpick, but: How do you get from "the end user's device" to "attacker controlled"? Both auditing a piece of software and troubleshooting/sandboxing are legitimate, if often tedious, practices. In my book, interfering with unrelated applications on the user's machine would make you the attacker. – Ruther Rendommeleigh Jun 09 '20 at 18:54
  • 1
    I disagree with the sentimemt that all this work for little payoff is a bad thing. Having to install closed source, kernel level software to make sure you dont cheat in a video game is idiotic. I'd rather have to deal with cheaters than deal with malicious software. – zero298 Jun 10 '20 at 01:20
  • 1
    @MathieuVIALES the bridge also isn't owned by the passer-bys, the phone is. So it's mostly their stuff they are tempering with - and while there are some arguments for contracts determining how a software can be used (e.g. not to hack another machine without that owner's consent etc.) a lot of business models / companies try way too hard to control how their software is used on other people's devices. It'd be ridiculous if someone tried to make sure you cannot use a slotted screw driver for philipps screws. – Frank Hopkins Jun 10 '20 at 19:43
  • 1
    @MathieuVIALES Is there a grey area in-between? Sure, but the bridge allegory comes from an extreme point of view, it may be your code but it's their device and they licensed your code on top, so in my book they own like three quarters of the say what to do with the combination of both. – Frank Hopkins Jun 10 '20 at 19:44
6

It is somewhat possible.

Simply send the recorded data off to a remote server that does the pattern checking. Make sure there is a delay between observing a correct pattern and the reward. It will be very difficult to figure out exactly what pattern is being matched.

If you combine this with heuristics that detect replayed activity and ban offenders, there is a good chance you could sustain this kind of model.

8vtwo
  • 372
  • 1
  • 7
  • 1
    This assumes that the user cannot know anything about the pattern, e.g. what activity is supposed to cause it, and little chance of approximating it. When working with real life sensor data, chances are that a slight random modification of recorded data has a good chance of falling within your model's acceptable parameters. – Ruther Rendommeleigh Jun 09 '20 at 18:25
  • They can know what *some* of the pattern is, but not all of it. For instance, if the pattern is simply throwing the phone in the air: by sending the entire data stream off remotely you can also check the data before and after the known event. Such as the "wind up" and the "catch". Then you could check to make sure all these things match appropriately and are unique each time. – 8vtwo Jun 09 '20 at 18:33
  • 3
    That doesn't stop me from, say, recording ten throws, waiting however long for the response, slightly distorting the entire dataset, chopping it up between throws and then sending it back in random order. Afterall, accelerometer readings aren't random white noise. Whatever pattern you expect is constrained by the physics of the activity you want to detect and the precision of the measurements. And you can't easily blacklist users either because you'll get non-matching readings all the time. – Ruther Rendommeleigh Jun 09 '20 at 19:08
  • I think you are underestimating the difficulty of *accurately* distorting the whole dataset and replaying an entirely new data set that correctly matches a normal user's behavior. Using server-side pattern matching gives you an enormous amount of data you can analyze. Everything that happens from opening the app to the target pattern can be scrutinized. Machine learning algorithms are very good at being able to distinguish between real unique patterns and those that have any kind of anomalies. The points at which you "chop" the throws would look suspicious if the transition was not smooth. – 8vtwo Jun 09 '20 at 19:20
  • @RutherRendommeleigh in support of this answer, see the techniques Uber uses to prevent GPS spoofing here https://eng.uber.com/advanced-technologies-detecting-preventing-fraud-uber/ It's a solution commonly adopted in the industry. It's not fool-proof, obviously. – loopbackbee Jun 10 '20 at 07:00
  • @goncalopp I would argue that the types and amount of data that Uber collect, as well as the resources they can throw at the problem, are probably out of scope for OP's scenario. If they *do* require constant location data and the app is complex enough to yield distinct usage patterns, fair enough. On the other hand, you lose users that don't consent to 24/7 surveillance. – Ruther Rendommeleigh Jun 10 '20 at 15:10
3

More frequently in the last years, the suggested secure solution to this problem is called remote attestation.

In short, this means running the security-critical parts of your application in a separate area of the CPU that guarantees its integrity (through key escrow on the hardware) and allows a remote server to confirm it.

As far as I know, there's no practical foolproof way of doing it for a independently developed mobile app as of 2020. But APIs already exist to verify the system hasn't been tampered with and as more and more phones include TPMs/TEEs, I think it's reasonable to expect it to be generally available in the near future. It's currently used in Google Pay, for example.

Important caveats:

  • This prevents your application from running on phones that are controlled ("owned"?) by the end user (i.e: rooted/jailbroken phones). It can be considered a form of DRM, and is controversial (see the related secure boot controversy on PCs)
  • You'll need to extend your TCB to include the CPU manufacturers and OS vendor.

People have a wide variety of opinions regarding these caveats, the two extremes being "irrelevant in practice" to "make the technology worse than useless".

This is copied from my own response here

loopbackbee
  • 5,308
  • 2
  • 21
  • 22
  • 1
    It doesn't matter where software runs - it stills get data from somewhere. Set up a fake motion senser/step counter and your program will very securely process and submit fake data. – Oleg V. Volkov Jun 10 '20 at 20:29
2

Others have answered regarding software protections, but an attack can occur at even the hardware level.

For example if a phone has an accelerometer IC that is on the PCBA, most of these sensors would transmit over a standard SPI or I2C bus with the raw data and no sort of encryption. It could be possible for an attacker to remove the existing sensor and send false data on the data bus. It would be impossible for the phone software to detect any change to normal operating mode as no change was made to the software. Thus it would be impossible to prevent a motivated attacker.

Now some mitigations could exist such as detecting if the device was entered or using a sensor that would encrypt the communication/authenticate the IC as genuine, but given that a cell phone is a commodity product (at least for android) it would be possible to find a phone that did not do this.

Eric Johnson
  • 715
  • 1
  • 6
  • 11
1

On top of all the other answers mentioned, a "simple" way to protect against hacking is simply not having the logic inside your app.

In the app, you only want to do two things.

  1. Read out data
  2. Display data

The moment you try to process data on the device, you're doomed, and the app will be hacked. Instead, send all the raw data to a server (obviously this comes with its own security risks, but those are easier to mitigate). On this server you can do all the processing of the data safely, since it's under your control.

Another advantage of this approach is that it makes it way easier to detect malificent users. You mention this app is to be used for a competition. On your server you can, at the end of the competition, simply compare the movement data to the data of other users. If all users show a pattern with say 8 hours of sleep, and one user shows a pattern that would require them to be awake 24/7, you know it's faked. But on this aspect MechMK1 already gave an excellent answer, just that now you can combine multiple users too.

Daniël van den Berg
  • 113
  • 6