如何在应用程序运行之间本地检测用户的 iPhone 时钟进度？
休闲游戏中的一个常见漏洞是人为地提前系统时钟以在游戏中向前跳跃。 iOS 设备上的应用程序如何检测此类用户时钟提前？
- 不得涉及网络通信
- 不得假设应用程序在时钟提前时打开（运行或暂停） 必须
- 检测时钟提前，检测时钟回滚是不够的
理想情况下，该解决方案对于重新启动具有鲁棒性，但这不是必需的。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CACurrentMediaTime& mach_absolute_time
看看这个问题：
iOS：如何测量经过的时间，不受时钟和时区变化的影响？
计算两点之间的秒数时间点，在 Cocoa 中，即使系统时钟中途更改了
CACurrentMediaTime 使用 mach_absolute_time：
http://developer.apple.com /library/mac/#documentation/Cocoa/Reference/CoreAnimation_functions/Reference/reference.html
这里有一个关于如何使用的示例CA当前媒体时间：
http://www.informit.com/blogs/blog.aspx?b=02b4e309-308c-468a-bab1-cebb1404be6a
这里有关于 mach_absolute_time 的更多信息：
http://developer.apple.com/library/mac/# qa/qa1398/_index.html
http://shiftedbits.org/2008/10/01/mach_absolute_time -在 iPhone 上/
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/
我在想，如果那部分 GPS 数据暴露给你，CoreLocation 的东西就可以做到这一点。但这让我开始思考。
我唯一的（牵强的）建议是将某些内容放入后台处理中 - 这必须是出于一小部分特定原因之一，例如在后台跟踪位置。作为其副作用，尝试检测常规计时器上的时钟变化。苹果可能会拒绝它，因为很明显它没有使用位置信息，而这只是利用后台处理的一个原因。
任何不涉及网络的解决方案都很难实现，我想知道为什么您不使用它。
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.
虽然我认为不可能可靠地确定用户是否在没有网络访问的情况下手动将时钟向前调快，但您当然可以可靠地确定他们是否回到了过去。由于我们知道这在物理上是不可能的，因此可以假设他们操纵了时钟来作弊。
我的意思是，这不是触发应用程序内某些操作的通常过程，需要一段时间的等待，退出应用程序并向前转动时钟，重新启动应用程序以获得他们正在等待的任何内容，然后将时钟重置回实际时间？
如果确实如此，那么根据 @smgambel 的建议，您可以在每次启动时存储物理时间和当前时区，并与之前存储的时间和时区进行比较。如果时间落后之前存储的时间，并且设备的时区没有更改，那么您可以放心地假设用户已经操纵了时钟。
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.