这是[信安成长计划]的第 20 篇文章
0x00 目录
0x01 安全描述符的结构
0x02 两个结构的不同点
0x03 真正的查询方案
0x04 参考文章
0x01 安全描述符的结构
在上一篇文章中，我们在取 DACL 的时候，对安全描述符的结构产生了疑问，在查到的资料中都在说使用 _SECURITY_DESCRIPTOR 结构，但是因为符号不是最新的等等原因，造成了错位，最后发现应该 +0x30
而在我们去分析内核实际操作的时候发现，应该使用的是 _SECURITY_DESCRIPTOR_RELATIVE 结构，采用相对偏移的方法来进行
事实证明这是正确的，也能够更加合理的解释为什么 +0x30 的位置才是真正 DACL 的位置
0x02 两个结构的不同点
通过对比可以很明显的发现，两个结构的差异主要出现在后面的四个成员中，前三个成员的偏移和大小都是一致的，只有在取后面内容的时候所需要的方式是不同的。
在 _SECURITY_DESCRIPTOR 中，取 DACL，可以直接使用 +0x20 偏移的方式来进行
在 _SECURITY_DESCRIPTOR_RELATIVE 中，取 DACL，需要先 +0x10 偏移，从中取出一个相对的偏移，在我们的测试环境中，这个值是 0x30，然后在将这个偏移值加过去，也就是 +0x30 的偏移得到 DACL
0x03 真正的查询方案
本来以为这样就结束了，但是在最后整理的时候，发现了一个我们一开始就漏掉的信息
我们选取的方案是使用 _SECURITY_DESCRIPTOR_RELATIVE 结构，从中取出偏移值以后，再将其加上
而在最后面，有一个漏掉的信息，一个非常眼熟的 +0x20 的操作
所以，我重新看了一下整个的逻辑，发现了获取 DACL 时真正的逻辑
注意下面的这个跳转，这个跳转指令的上面是对 Control 等的操作，这些值的偏移和大小在两个结构中都是一样的，所以不存在任何的冲突
而这个判断条件用来判断了 Control 中所存储的值，如果是正数就跳转，跳转以后就会直接取 +0x20 的位置，然后将其返回给 DACL
接着，我去查找了相关的资料，得到了下面这样的信息，如果未设置的话，就说明是存储的是绝对的偏移
而这个值正好是 0x8000，在判断 cx 的时候，最高位为 1，代表是一个负数，所以，如果判断 Control 为正数的话，就直接拿偏移进行了获取
所以最终的逻辑应该是这样的，根据 Control 的情况来判断使用什么样的方式
一定一定一定要把逻辑看清楚
0x04 参考文章
1.https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-control
2.https://docs.microsoft.com/en-us/windows/win32/secauthz/absolute-and-self-relative-security-descriptors