• [20171227]表的FULL_HASH_VALUE值的计算.txt


    [20171227]表的FULL_HASH_VALUE值的计算.txt

    --//sql_id的计算是使用MD5算法进行哈希,生成一个128位的Hash Value,其中低32位作为HASH VALUE显示,SQL_ID则取了后64位。
    --//实际上sql_id使用32进制表示,hash_value使用10进制表示。

    --//我在链接提到http://blog.itpub.net/267265/viewspace-2142512/内容:
    --//如果使用md5sum计算的结果,按照4位一组,大小头对调.就一致了.

    --//实际上表的hash值是如何计算的呢?自己一直想知道oracle如何计算的,前一段时间探究一些crack password工具.做一些简单的探究.

    1.环境:
    SCOTT@book> @ &r/ver1

    PORT_STRING                    VERSION        BANNER
    ------------------------------ -------------- --------------------------------------------------------------------------------
    x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

    SCOTT@book> grant dba to a identified by a;
    Grant succeeded.

    A@book> create table b(c number);
    Table created.

    A@book> select owner,name,namespace,type,hash_value,full_hash_value from V$DB_OBJECT_CACHE where owner='A' and name='B';
    OWNER  NAME NAMESPACE       TYPE   HASH_VALUE FULL_HASH_VALUE
    ------ ---- --------------- ------ ---------- --------------------------------
    A      B    TABLE/PROCEDURE TABLE  3720244077 b6bab9fa1d1610f90401e083ddbe6b6d

    --//这样做的目的很好理解减少破解难度.
    --//按照4位一组,大小头对调.

    $ echo b6bab9fa1d1610f90401e083ddbe6b6d |xxd -r -p | od -t x4
    0000000 fab9bab6 f910161d 83e00104 6d6bbedd
    0000020

    --//拼接 fab9bab6f910161d83e001046d6bbedd.我开始想使用john,不知道如何生成破解字典.先放弃,使用hashcat倒是比较灵活先尝试hashcat.

    2.开始尝试破解:

    R:hashcat>hashcat --help
    ....
    - [ Built-in Charsets ] -

      ? | Charset
     ===+=========
      l | abcdefghijklmnopqrstuvwxyz
      u | ABCDEFGHIJKLMNOPQRSTUVWXYZ
      d | 0123456789
      s |  !"#$%&'()*+,-./:;<=>?@[]^_`{|}~
      a | ?l?u?d?s
      b | 0x00 - 0xff

    --//我实际上以前也猜测开头应该是owner.table这样的模式,后面补0.根据这个规则生成破解码表.
    --//这样规则前面4个字符应该是?u?s?u?b,然后开始不断尝试,终于破解:

    R:hashcat>cat hashcat.pot
    fab9bab6f910161d83e001046d6bbedd:$HEX[422e4101000000]

    --//422e4101000000,想都想不到这个使用7位来计算的.而且oracle计算表的hash值竟然是表的owner在前,表名在后.中间使用点分开.后面补01000000.
    --//应该可以猜测到owner都是一样的,放在后面是有道理的.

    R:hashcat>hashcat64 -a 3 -m 0 fab9bab6f910161d83e001046d6bbedd ?u?s?u?b?b?b?b --force
    hashcat (v3.00-1-g67a8d97) starting...

    OpenCL Platform #1: Advanced Micro Devices, Inc.
    ================================================
    - Device #1: Turks, 766/1024 MB allocatable, 6MCU
    - Device #2:         Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, skipped

    WARNING: ADL_Overdrive6_TargetTemperatureData_Get is missing from ADL shared library.
    Hashes: 1 hashes; 1 unique digests, 1 unique salts
    Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
    Applicable Optimizers:
    * Zero-Byte
    * Precompute-Init
    * Precompute-Merkle-Demgard
    * Meet-In-The-Middle
    * Early-Skip
    * Not-Salted
    * Not-Iterated
    * Single-Hash
    * Single-Salt
    * Brute-Force
    * Raw-Hash
    Watchdog: Temperature abort trigger disabled
    Watchdog: Temperature retain trigger disabled

    fab9bab6f910161d83e001046d6bbedd:$HEX[422e4101000000]
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Session.Name...: hashcat
    Status.........: Cracked
    Input.Mode.....: Mask (?u?s?u?b?b?b?b) [7]
    Hash.Target....: fab9bab6f910161d83e001046d6bbedd
    Hash.Type......: MD5
    Time.Started...: 0 secs
    Speed.Dev.#1...:  1238.5 MH/s (11.94ms)
    Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
    Progress.......: 90869760/95812130439168 (0.00%)
    Rejected.......: 0/90869760 (0.00%)
    Restore.Point..: 0/4294967296 (0.00%)

    Started: Wed Dec 27 10:22:40 2017
    Stopped: Wed Dec 27 10:22:42 2017

    --//反过来验证scott.dept表是否正确.应该是这样"DEPT.SCOTT1".
    --//注意01一定要使用1,开始使用1测试错误.

    A@book> select owner,name,namespace,type,hash_value,full_hash_value from V$DB_OBJECT_CACHE where owner='SCOTT' and name='DEPT';
    OWNER  NAME                 NAMESPACE       TYPE  HASH_VALUE FULL_HASH_VALUE
    ------ -------------------- --------------- ----- ---------- --------------------------------
    SCOTT  DEPT                 TABLE/PROCEDURE TABLE 2152664343 1383925607dd84fd07c34017804f0d17

    $ echo -e -n "DEPT.SCOTT1" | md5sum |sed 's/  -//' | xxd -r -p | od -t x4
    0000000 13839256 07dd84fd 07c34017 804f0d17
    0000020

    --//拼接起来13839256 07dd84fd 07c34017 804f0d17 变成 1383925607dd84fd07c34017804f0d17!!
    --//^_^,正好是前面FULL_HASH_VALUE值对上了.

    --//再拿一个最长字符串owner||name测试看看
    A@book> select owner,name,namespace,type,hash_value,full_hash_value from V$DB_OBJECT_CACHE where owner||name='APEX_030200WWV_FLOW_CUSTOM_AUTH_SETUPS';
    OWNER        NAME                           NAMESPACE       TYPE  HASH_VALUE FULL_HASH_VALUE
    ------------ ------------------------------ --------------- ----- ---------- --------------------------------
    APEX_030200  WWV_FLOW_CUSTOM_AUTH_SETUPS    TABLE/PROCEDURE TABLE 2757059300 ae088e68645bfa46e406e327a45562e4

    $ echo -e -n "WWV_FLOW_CUSTOM_AUTH_SETUPS.APEX_0302001" | md5sum |sed 's/  -//' | xxd -r -p | od -t x4
    0000000 ae088e68 645bfa46 e406e327 a45562e4
    0000020

    --//OK也是正确了.

    --//总结:
    --//表的FULL_HASH_VALUE计算就是table_name.owner加上"1".





  • 相关阅读:
    P3146 [USACO16OPEN]248
    P2590 [ZJOI2008]树的统计
    P3379 【模板】最近公共祖先(LCA)
    P2253 好一个一中腰鼓!
    数组中出现次数超过一半的数字
    字符串的排列
    二叉搜索树与双向链表
    二叉搜索树的后序遍历序列
    从上往下打印二叉树
    顺时针打印矩阵
  • 原文地址:https://www.cnblogs.com/lfree/p/8124863.html
Copyright © 2020-2023  润新知