我为什么开始搞这个“编年史NTR”？
兄弟们，这事儿说来气人。我前阵子给一个老客户做了个小项目，都完事儿了准备收钱。结果他们财务非要走一个老掉牙的工时系统，美其名曰“编年史”。我提交完记录一看，妈的，系统给我自动抹掉了三天工时，理由是我网络波动，记录提交晚了。找到他们，他们就跟我扯皮，说这是系统自动记录的，没法动。少了几千块钱，我当时就懵了，谁家钱是大风刮来的？
我琢磨了好几天，越想越不爽。既然他们不给我改，我就决定自己动手，把这破系统的“历史”给修正过来。这就是《编年史NTR最新版本》的由来——目标明确：把那三天的记录给我硬塞回去，让它看起来比他们自动生成的记录还真实，而且必须是原生的，不能带任何“补录”的标记。
具体实践：怎么绕过那老壁虎的防御？
我跑去折腾他们的接口。老系统嘛我猜防御肯定很烂。我先是抓包，发现他们提交工时记录的接口，参数简单得像幼儿园作业。但问题是，他们用了个很原始的时间戳校验，不是简单改个时间就能糊弄过去的，服务器那边会对比你请求时间和记录时间。第一次尝试，我直接改了时间字段，啪叽，被秒拒了，日志显示“请求时间戳早于服务器历史记录校验起始点”。
失败了不要紧，咱们得找新的突破口。
我坐下来仔细分析了他们系统的逻辑。这个“编年史”的特点是，它对未来时间的提交很警觉，但对历史时间的提交，反而依赖客户端提供的时间戳来做初步判断。我的核心思路是：找到一个可以伪装历史请求，但服务器又不会触发深度校验的“安全时段”。
我开始准备我的工具箱：
- 一个能拦截和重写请求的中间人代理（我用的是自己改写过的版本，能更好地处理Session）。
- 一套用于生成伪造请求头的脚本，主要用来模拟旧版浏览器的请求习惯，避开他们可能有的新版浏览器指纹校验。
- 一份完整的成功Session令牌，确保服务器认为我是一个“合法的用户”。
我启动了脚本，开始进行“时间回溯提交”。我没有尝试去破解他们后台的时间戳生成逻辑，因为那太费劲。我直接采取暴力试探，用成功Session，以毫秒级的速度批量提交了不同偏移量的历史记录。我把请求时间戳反复往前推，从一天前到四天前，每次都调整几分钟的差距。
那两天我简直就是个神偷，眼睛死死盯着日志。前前后后折腾了六次，有几次系统提示成功了，但刷新一看，记录还在，但时间又被系统自动修正到当前时间了，功亏一篑。我气得差点把键盘砸了。
最终成果与意外发现
最终成功的那一次，我发现了一个怪异的现象。我把时间戳修改逻辑往后推了12个小时，同时伪装了一个他们不再使用的老旧浏览器内核标识。我猜可能是因为这个老旧标识，触发了系统里一个“兼容性处理”的旧逻辑。这回提交，数据真的被吃进去了，而且没有那个可耻的“补”字标记！
我赶紧刷新界面，那三天工时妥妥地躺在我的记录里，看起来就像从来没出过错一样。钱追回来了，心里痛快了。
这回实践最大的收获不是钱，而是我发现这套所谓的“编年史”系统，它对旧数据的校验机制几乎没有！它所有精力都放在防止未来数据被提前录入，而对历史数据修改的防护，完全是零。只要你伪装得像一个“被系统忽略”的老请求，就能插进去。所以说，老系统一旦有了漏洞，那真是四处漏风。咱们搞技术，有时候就得学会这种“逆向操作”，在规则之内，找到一个没人管的角落，插一脚进去，让历史为我服务。