10

A common exploit in casual games is to artificially advance the system clock to jump ahead in gameplay. How can such user clock advancement be detected by an app on an iOS device?

  • Must not involve network communication
  • Must not assume app is open (running or suspended) while clock is advanced
  • Must detect clock advancement, detecting clock rollback is not sufficient

Ideally, the solution would be robust against reboots, but that is not a requirement.

David Lee
  • 101
  • 1
  • 3
  • 1
    Don't think it can be done without network communication. The GPS receiver 'could' do this, but I don't think it exposes any of the time stuff in the API. – iandotkelly Aug 19 '11 at 13:41

3 Answers3

11

CACurrentMediaTime & mach_absolute_time

Take a look at this questions:

iOS: How to measure passed time, independent of clock and time zone changes?

Calculating number of seconds between two points in time, in Cocoa, even when system clock has changed mid-way

CACurrentMediaTime uses mach_absolute_time: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreAnimation_functions/Reference/reference.html

Here you have an example on how to use CACurrentMediaTime: http://www.informit.com/blogs/blog.aspx?b=02b4e309-308c-468a-bab1-cebb1404be6a

Here you have a more information on mach_absolute_time: http://developer.apple.com/library/mac/#qa/qa1398/_index.html http://shiftedbits.org/2008/10/01/mach_absolute_time-on-the-iphone/

Community
  • 1
  • 1
Lio
  • 4,225
  • 4
  • 33
  • 40
  • 1
    mach_absolute_time resets on device reboot. It is ok if a user circumvents the cheat detection by rebooting, but it is not ok if rebooting incorrectly flags them as having advanced the clock. – David Lee Aug 19 '11 at 16:59
  • Also, based on Ben Dodson's nice blog post here, http://bendodson.com/weblog/2013/01/29/ca-current-media-time/, this wouldn't work if the device went to sleep for some time between plays since it appears the CACurrentMediaTime (and hence mach_absolute_time since it's based on it?) only count the active device time not the uptime. – stuckj Sep 23 '15 at 17:33
1

I was thinking about the fact that the CoreLocation stuff could do this if that part of the GPS data was exposed to you. However that got me thinking.

My only (far fetched) suggestion is to put something into background processing - which has to be for one of a small specific set of reasons, for example to track location in the background. As a side effect of that, try to detect a clock change on a regular timer. Apple might reject it as it may be clear that its not using the location information and its just a reason to exploit background processing.

Any solution not involving networking is so much harder to implement, I wonder why you're not using it.

iandotkelly
  • 9,024
  • 8
  • 48
  • 67
0

Whilst I don't think it's possible to reliably determine whether or not a user has manually turned their clock forward without network access, you can of course reliably determine if they've travelled back in time. And since we know this to be physically impossible it can therefore be assumed they have manipulated their clock to cheat.

What I mean by this is, isn't the usual process to trigger some action in-app that requires a period of waiting, exit the app and turn the clock forward, re-launch the app to gain whatever they were waiting for and then reset the clock back to the actual time?

If this is indeed the case, then to build on the suggestion by @smgambel, you could store the physical time and current time-zone on each launch and compare with the previously stored time and time-zone. If the time is behind the previously stored time, and the time-zone of the device hasn't changed then you can safely assume the user has manipulated the clock.