hive中的subkeylist的结构详解。。

系统 2039 0

在网上找了一圈。。也没有找到相关的资料。。一点都没有。。。  还有有大米公开的代码供参考。。。 赶紧把学习的成果记录下来。。

CM_KEY_NODE 的结构:

 +0x014 SubKeyCounts      : [2] Uint4B                 //SubKeyCounts[0] 子键的个数

 +0x01c SubKeyLists       : [2] Uint4B              //SubKeyLists[0] 子键列表相差本 BIN 的偏移

这里的subKeyList是一个偏移。。指向 CM_KEY_INDEX结构。。最复杂的也是这个结构。。

他有好几种变形。。。

可以是:

lf 结构

    + lf

    +lh

li 结构

ri 结构

可以根据 signature判断当前的index 属于那种结构。。对于每一种结构都有对应的 格式

struct lf_key {

  short id;         /* 0x0000 Word ID: ASCII-"lf" = 0x666C or "lh" = 0x686c */
  short no_keys;    /* 0x0002 Word number of keys          */
                    /* 0x0004 ???? Hash-Records            */
 
 union {

    struct lf_hash {
      long ofs_nk;    /* 0x0000 D-Word Offset of corresponding "nk"-Record  */
      char name[4];   /* 0x0004 D-Word ASCII: the first 4 characters of the key-name,  */
    } hash[1];

      /* WinXP uses a more real hash instead (base 37 of uppercase name chars)  */
      /*   padded with 0's. Case sensitiv!                         */

    struct lh_hash {
      long ofs_nk;    /* 0x0000 D-Word Offset of corresponding "nk"-Record  */
      long hash;      /* 0x0004 D-Word ASCII: the first 4 characters of the key-name,  */
    } lh_hash[1];
  };

};

/* 3.x version of the above, contains only offset table, NOT
 * any start of names "hash". Thus needs 'nk' lookups for searches.
 */
struct li_key {

  short id;         /* 0x0000 Word ID: ASCII-"li" = 0x696C */
  short no_keys;    /* 0x0002 Word number of keys          */
                    /* 0x0004 ???? Hash-Records            */
  struct li_hash {
    long ofs_nk;    /* 0x0000 D-Word Offset of corresponding "nk"-Record  */
  } hash[1];
};


/* This is a list of pointers to struct li_key, ie
 * an extention record if many li's.
 * This happens in NT4&5 when the lf hashlist grows larger
 * than about 400-500 entries/subkeys??, then the nk_key->ofs_lf points to this
 * instead of directly to an lf.
 * The sub-indices this points to seems to be li (yes!) in NT4 and 2k.
 * In XP and newer they point to lh which is more efficient.
 * Likely to happen in HKLM\Software\classes (file extention list) and
 * in SAM when many users.
 */
struct ri_key {

  short id;         /* 0x0000 Word ID: ASCII-"ri" = 0x6972 */
  short no_lis;    /* 0x0002 Word number of pointers to li */
                    /* 0x0004 ???? Hash-Records            */
  struct ri_hash {
      long ofs_li;    /* 0x0000 D-Word Offset of corresponding "li"-Record  */
  } hash[1];
};

 

当subkey的数量大约500时。。是ri结构。。ri结构保存了li结构或lf结构的索引。。

 

枚举一个Key的subKey的code:

 

Code

 

如果没有ri结构:找到subkey的 CM_Key_NODE结构的过程是这样的:

                                                  index.hash[i].ofs_nk

1.subKeyList--------》index结构----------------------------》key_Node

 

有ri结构:

                                                         rikey->hash[r].ofs_li                            index.hash[i].ofs_nk   

subkeylist ----------------> ri_index--------------------------------->li/lf结构----------------------------------》 Key_node

 

真日啊 。。。费劲。。

 


 

 

 

 

 

 

 

 

hive中的subkeylist的结构详解。。


更多文章、技术交流、商务合作、联系博主

微信扫码或搜索:z360901061

微信扫一扫加我为好友

QQ号联系: 360901061

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧,狠狠点击下面给点支持吧,站长非常感激您!手机微信长按不能支付解决办法:请将微信支付二维码保存到相册,切换到微信,然后点击微信右上角扫一扫功能,选择支付二维码完成支付。

【本文对您有帮助就好】

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描上面二维码支持博主2元、5元、10元、自定义金额等您想捐的金额吧,站长会非常 感谢您的哦!!!

发表我的评论
最新评论 总共0条评论