DateTime 十六进制格式解密答案

【问题标题】：DateTime hex format decipherDateTime 十六进制格式解密
【发布时间】：2013-10-11 07:22:55
【问题描述】：

我正在研究一个小谜题。我有一些时间戳，我知道它们是时间戳，但无法弄清楚它们是如何编码的。

3ebf5b89 means 08-October-2013 hour 8 AM but minute I can't provide neither second 
3ebd5f09 means 09-October-2013 hour 8 AM Unknown minute/second.
3ea15d09 means 11-October-2013 hour 8 AM Unknown minute/second but before half past hour.

关于编码的任何想法？

奇怪的是，随着时间的流逝，日期似乎变得越来越低。

如果我转换为十进制并从小日期中减去大日期，我会得到一个以秒为单位转换的值，大约是两个日期之间的天数，每天有 5 小时的误差。

乐：

我设法获得了更准确的时间戳：

3ea02d09 - Oct 11th, 2013 at 17:10 (hour:minute)
3ea7ff89 - Oct 12th, 2013 at 14:28
3ea7cf09 - Oct 12th, 2013 at 15:34

【问题讨论】：

你确定那些是时间戳吗？
@sara 是的，两者都使用某种自定义算法加密。不幸的是，我无法弄清楚它们。
你能给我们一些关于这些来自哪里的提示吗？
@MattJohnson 运行嵌入式 linux 的考勤设备
您是否可以随意在 sql 数据库中手动添加条目或修改条目，看看它是如何从另一端出来的？看看如果你加一会发生什么会很有趣。如果它是加密的，我们应该会失败，不（与未来看起来是 n 秒或 ms 的日期相反）？另外，最后一位数字是始终为“9”还是仅在这 6 个示例中？

标签： date timestamp hex

【解决方案1】：

好像时间戳是以 Pi 为基准来计算时间的！？

3ea7ff89 - 10 月 12 日时 14 分 28 3ea7cf09 - 10 月 12 日时 15 分 34

差异：12416 ~ 66 分钟如果我们将它除以 60，每分钟 60 秒，然后我们将它除以 66，得到分钟差 3.13535353535 非常接近 Pi。如果我们使用 pi 来反转公式： Pi*66*60=12440 在您的时间戳中未传递的秒数的错误范围内。

【讨论】：

你写到 12416 大约是 66 分钟。我同意，但似乎 -12416 大约是 66 分钟。 3ea7ff89 - 10 月 12 日时 14 分 28 3ea7cf09 - 10 月 12 日时 15 分 34 请注意，10 月 12 日 14:28 的值高于 10 月 12 日 15:34 的值。除非 opc0de 不小心把这两个互换了……
这似乎有些牵强，理智的程序员是否有理由将 pi 与日期/时间条目混合在一起？我不是数学家，但我想不出它为什么会发生。

【解决方案2】：

我想知道那些转换为十进制的十六进制与Unix Epoch时间有一些关系：

这些十六进制数字正在转换为一些有效的日期，但与您提到的不同：

Hex 3ebf5b89 = Decimal 1052728201 = Mon, 12 May 2003 08:30:01 GMT

Hex 3ebd5f09 = Decimal 1052598025 = Sat, 10 May 2003 20:20:25 GMT

Hex 3ea15d09 = Decimal 1050762505 = Sat, 19 Apr 2003 14:28:25 GMT


Hex 3ea02d09 = Decimal 1050684681 = Fri, 18 Apr 2003 16:51:21 GMT

Hex 3ea7ff89 = Decimal 1051197321 = Thu, 24 Apr 2003 15:15:21 GMT

Hex 3ea7cf09 = Decimal 1051184905 = Thu, 24 Apr 2003 11:48:25 GMT

【讨论】：

也试过了，但没有多大意义

【解决方案3】：

我尝试使用二进制形式的输入，并在值和相应的 UNIX 时间戳之间使用按位 XOR (the poor man's cipher) 运算符。

这是我目前所得到的：

(1381507800 ^ 0x3ea02d09) = 0110110011111 00000001111 11 010 001

(1381584480 ^ 0x3ea7ff89) = 0110110011111 11010110001 11 101 001

(1381588440 ^ 0x3ea7cf09) = 0110110011111 11010010010 11 010 001

16 位 + 2 位保持稳定。
前 13 位加上后 3 位（如果组合成 16 位）让我想到了某种旋转左移。

请注意，我的时区是 UTC+1，因此我的 UNIX 时间戳可能不准确。如果您能在系统上获得相应的时间戳以进一步推动这一领先优势，那就太好了。

【讨论】：