从第一节主目录中我们中可以看到，bin下主要是lithtech的程序，lithtech以data目录为res目录，所以data目录是主资源目录， 其中内容如下：
这里面，跟lt引擎的原理还是大致一样，有map等目录，但进去发现，除了sound目录下面是一堆ogg的音乐等素材可以直接播放， 包含map等目录下面的文件都是自有格式，无法用lt的解析代码进行解析， 所以object.lto （其实就是object.dll）、CShell.dll、cres.dll三个库都是自己实现里面了系列改造，当时HEAD LOCK买了lt引擎，然后自己改造了整体的资源、粒子效果等等。
我想着方便调试，是否可以用lt的 lithtech exe加载这三个dll，这样可以基于源码部分绕开lt exe中的一些干扰，发现确实可以，但是因为lt exe也是改造过的，在这种之中会进行一些主程序的自定义函数调用，导致这种调试不是很顺畅。
没办法，还是采用汇编调试吧。
首先用 pm工具
直接监控整体lt对文件的读写，过滤到对data目录的读写位置。
然后在x64中对对应的汇编位置下端点。注意可能二次启动和一次启动会存在位置的偏移，可以进行计算和核对。
data中 有 B0000 ~ B1061 （94个文件夹）每个文件夹中内容和格式基本都是如此。
一个_.bpf文件，然后带一堆.dat文件。 然后 有 L0000 ~ L1000 (25个文件夹), 其中内容大概如此。
一个 _.lpf文件和一堆.dat文件。
通过UE打开bpf和lpf文件查看如下：
这是一种 FPSF格式文件，经过大量的搜索，发现互联网没有这种公开的格式，我暂时把解读为 Fxx Pxx Safe File的缩写，也就是加密安全文件。
所有的 .dat文件用UE打开查看没有啥任何规律和信息，bpf/lpf是每个文件夹下1个，dat是每个文件夹n个，而且个数不等。
我初步猜测bpf中记录目录相关信息，根据文件大小看，dat中记录了真实的一些资源。 类似 bpf为目录文件列表清单，dat为文件，或者是类似zip的一种打包格式。
也可以理解为类似虚拟机的文件读取存储体系，或者沙盒的文件隔离体系。 在这些数据文件中，自己组织一套自己目录结构。(当然其实没有那么复杂，只是一个资源清单而已)
那么我们现在首要的是要分析这两种格式。 前面我们用了pm来进行文件监控，发现我们的客户端启动后读取了data下面的目录，而且有个现象是他遍历读取了每个文件夹的每个bpf和lpf文件。 那么我们只要断点调试这块的读取逻辑就能解析这个文件格式了。
下一篇记录bpf解析过程。
