nanolog分析的中间的总结

如果目标是转nanolog为CTF格式，最重要的应该是meta的定义的转换的问题了。
目前我是稍有气馁。
感觉这不是一个好的方向。
如果领导能给连续的时间，完全开发自定义的binary，原本不需要面对这些困难。
但是，我们不能考虑这些事情。
目前能做的，是思考如何完成这个不太可能完成的任务。

二者之间的差别

前面的分析，虽然还在进行中，许多问题，仍然需要进一步分析。
但可以看到，nanolog的注册id，并不是自定义的，而是在runtime生成的，有一定随机性。每次运行的结果都是不同的。
所以logid，是没有办法拿来做meta的event type id的。
但也发现一些相对静态的东西。

比如，NANO_LOG中，用户写入的信息，比如源代码名称和行号，这些相对而言是稳定的。
我想，可以做一个联合查询的数据库，根据这些信息，将nanolog与meta 的 event对应起来。

这个计划先放在这里。再想想有没有需要补充的办法。

当然，如果强行重新定义一套宏，加入事件的定义，也是一个好方法。
这个方法，只要团队同意，还是可以搞的。因为性能分析，只需要很少的点加入 ｐｒｏｂｅ就可以了。