事情来自某天我在找资料的过程中，看到有些大大提供了事件纪录档的文本说明，所以今天要来试着阅读.evtx文件，用文字编辑器打开，挑战以16进位的格式去阅读，这在一些取证的技术上常常使用，因为网路的攻击者在攻击电脑後可能想要隐藏某些资讯就会去改写日志档，至於到底能改写多少我们又能复原多少，就要来自我们对日志档的理解，虽然为了避免这种状况最好的方式是设定自动备份日志档到某个攻击者不容易察觉的位置，不过总而言之，都看到这了你应该会对这个题目有兴趣吧，所以我还是往下继续讲~

开启文件

首先，为了避免动到真的日志档，笔者习惯会去复制一份到其他位置再开始玩，这里选择复制%SystemRoot%\System32\Winevt\Logs的Setup.evtx，这是Windows更新的日志档，档案不大，我用Sublime Text的HexViewer插件去阅读这个16进位格式的文件，开头大致上长这样：

因为以前打开看到这种纯数字编码就关掉当作看不懂，顶多在登录档有看懂一点点(可以参考第9天第三点更改登入画面的欢迎)，所以从昨天就特别下功夫研究了一会，先不说刚开始找插件还不会用的过程，第一次认真看16进位文件有点畏惧。

这个格式称作Windows XML Event Log (EVTX)，从Windows Vista 开始就用它取代Windows Event Log (EVT)格式了，他主要包括文件标头(file header)、资料块(chunks)、**尾随空值(trailing empty values)**三个部分。

File Header

file header的部分是是指文件开头固定为4096 byte(4kb)的片段，第一段为签名固定是45 6C 66 46 69 6C 65 00(ElfFile)，是Executable and Linkable Format file的意思，格式可以对照参考资料第二点：

举例来说，刚刚的签名就是从第0个byte开始往後占用8个byte，然後我们再看到00000018行(这是16进位，就是第24个byte後)，文件中提到这是指下一个记录标示，一开始一直看不懂这是什麽意思，然後他写占用8个byte，那6100000000000000换过来应该是6989586621679010682，我不懂哪个指标要用到这麽大，但是如果说是61直接换过来就是97~

等等，好像有点眼熟在哪看过，我们回到事件检视器一瞄，这个文件有96笔记录，所以如果说这格栏位是表示现在存了96笔记录，下一笔存进来是第97比这回事好像挺合理的(?

但我怎麽知道61後面的00不用算进去？除非把每个byte倒过来读，於是找到一个以前明明看过却不断被我忽略的东西--大端(Big-Endian)小端(Little-Endian)。

大端：
低记忆体位址 --------------------> 高记忆体位址
高序位的字节 <-------------------- 低序位的字节
小端：
高记忆体位址 --------------------> 低记忆体位址
低序位的字节 <-------------------- 高序位的字节

总之，我们原本预期的6100000000000000的读法被叫做大端，在CPU读取效率比较低因为高低相反，而把每个byte倒过来读就叫小端，这里就是读0000000000000061，人类可读性较差，但对CUP读取比较迅速，两者各有优缺，命名由来请见冷知识，而我们的.evtx档就是Little-Endian的形式！

明明前面在登录档介绍也有出现这个字，只能说东西要真的用到才知道他的重要性，在这之前看到什麽学什麽吧~

於是我们往後看着对照，第32 byte後的80 00读做128是header大小，次要版本是2，主要版本是3，00 10读作4096指定file header了大小，紧接着的0100是指这份纪录档有1个资料块(chunk)。

在124 byte之後的4个byte是前120 byte的CRC-32校验值。

Chunks

到这里file header的内容就差不多结束了，接下来我们转到4096 byte之後，是一个chunk，他有69,632‬个byte，chunk有个512 byte的chunk header，开头一样是一个固定的签名叫45 6C 66 43 68 6E 6B 00(ElfChnk)，签名後会接第一个事件记录的编号和最後一个纪录是件的编号，各占8个byte，在这个范例第一个事件的纪录就是1号(0100000000000000)，最後一笔纪录就是96号(6000000000000000)，第40个byte之後的80000000一样代表header有128个byte大。

这个chunk有点像是纪录的容器，不足一个chunk就会以一个chunk作纪录，这应该也是为什麽你去翻.evtx的时候会看到最小的大小都固定是68kb的原因。

在chunk header後面接着的就是一笔笔的纪录资料，所以4096+512=4608‬个byte=1200(16进位)，我们找到1200 byte位置会看到一个2a2a0000的字串，这是每一笔纪录的开头签名字串，有几笔纪录就会有几个2a2a0000，下面是这些事件纪录的规范：

以这份文件来看，1200位置的确出现2a2a0000，後面f0080000表示这笔纪录含签名有2288个byte大，接着0100 0000 0000 0000表示这是日志的第1笔纪录，再来b902 4b40 5e21 d701是FileTime表示事件写入的时间，接着就是二进位制的XML纪录内容。

最後4个byte会再写一次纪录的大小，这里就是第一笔纪录的开始的4608加他的长度2288减4，我们会在6892 byte，也就是1AEC的地方看到f0080000再出现一次，接着继续2a2a0000表示下一笔纪录，最後一笔纪录也是用其记录大小作结尾，後面就会有尾随空值(trailing empty values)，一直持续00补到文件大小。

好的，今天我们尝试阅读16进位的文件，知道.evtx文件的格式，大概会有时间跟Hash值，还会记录每个区块的大小等等，下一篇…笔者考虑看看要不要写里面的XML文件怎麽看，感觉这又有点挑战性了哈哈，放心，我总会生出东西来研究的！

参考资料：
https://superuser.com/questions/1205975/can-sublime-text-be-used-as-hex-editor
https://github.com/libyal/libevtx/blob/main/documentation/Windows%20XML%20Event%20Log%20(EVTX).asciidoc
https://zhuanlan.zhihu.com/p/144718837
https://codertw.com/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/444383/
https://www.convertworld.com/zh-hant/numerals/hexadecimal.html