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?

  • 25
    – Coxy
    Commented Jun 9, 2020 at 6:23
  • 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
    Commented Jun 9, 2020 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
    Commented Jun 9, 2020 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. Commented Jun 9, 2020 at 16:43
  • 4
    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
    Commented Jun 10, 2020 at 9:14

7 Answers 7


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.

  • 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
    Commented Jun 8, 2020 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
    Commented Jun 8, 2020 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
    Commented Jun 8, 2020 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
    Commented Jun 8, 2020 at 15:31
  • 4
    @CONvid19 If it's running on hardware you control, then you can, no matter how good it follows security principles. Commented Jun 9, 2020 at 1:37

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
    Commented Jun 8, 2020 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
    Commented Jun 9, 2020 at 0:22
  • 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
    Commented Jun 9, 2020 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
    Commented Jun 9, 2020 at 13:49
  • 1
    @Falco All of this information was added after this answer was written
    – user163495
    Commented Jun 10, 2020 at 11:05

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.


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.

  • 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 :-( Commented Jun 9, 2020 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. Commented Jun 9, 2020 at 11:33
  • 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. Commented Jun 9, 2020 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
    Commented Jun 10, 2020 at 1: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. Commented Jun 10, 2020 at 19:43

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.

  • 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. Commented Jun 9, 2020 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
    Commented Jun 9, 2020 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. Commented Jun 9, 2020 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
    Commented Jun 9, 2020 at 19:20
  • @RutherRendommeleigh in support of this answer, see the techniques Uber uses to prevent GPS spoofing here eng.uber.com/… It's a solution commonly adopted in the industry. It's not fool-proof, obviously.
    – watchowl
    Commented Jun 10, 2020 at 7:00

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

  • 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. Commented Jun 10, 2020 at 20:29

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.


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.

You must log in to answer this question.

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