How can I locally detect iPhone clock advancement by a user between app runs?

Question

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

Answer 1

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/

Answer 2

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.

Answer 3

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.