<br>计算机爱好者<br>云计算<br>云存储<br>网络技术<br>非洲酋长<br>可爱的胖子<br>十年攻城狮

    818 KP环境虚拟机光驱无法使用问题

    [busuanzi]
    字数统计: 705字   |   阅读时长≈ 3分

    协议分析 1

    1
    2
    3
    4
    5
    6
    ffffffc1f040ba80 3007336273 S Bo:1:006:2 -115 31 = 55534243 05000000 80000000 80000c5a 002a0000 00000080 00000000 000000
    ffffffc1f040ba80 3007337444 C Bo:1:006:2 0 31 >
    ffffffc1c45959c0 3007337452 S Bi:1:006:1 -115 128 <
    ffffffc1c45959c0 3007341513 C Bi:1:006:1 0 128 = 00364180 00000000 2a2e1f17 f1772b23 2b480100 030015a4 00102b48 2b480001
    ffffffc1f040ba80 3007341528 S Bi:1:006:1 -115 13 <
    ffffffc1f040ba80 3007342666 C Bi:1:006:1 0 13 = 55534253 05000000 48000000 00

    请求号5a，两者有差距，但是大部分内容，都是保留字段，体现到抓包中，有可能就是随机值，所以不做参考

    协议分析 2

    1
    2
    3
    4
    5
    6
    S Bo:1:007:2 -115 31 = 55534243 06000000 08000000 80000c4a 01000010 00000008 00000000 000000
    C Bo:1:007:2 0 31 >
    S Bi:1:007:1 -115 8 <
    C Bi:1:007:1 0 8 = 0006045e 00020000
    S Bi:1:007:1 -115 13 <
    C Bi:1:007:1 0 13 = 55534253 06000000 00000000 00

    通过对比，这里也不一样，一个是00020000 一个是02020000（kp）
    请求号 4a，也不在scsi协议中
    后确认为ata协议
    #define GPCMD_GET_EVENT_STATUS_NOTIFICATION 0x4a

    协议分析 3

    1
    2
    3
    4
    5
    6
    ffffffc1f040ba80 3007372795 S Bo:1:006:2 -115 31 = 55534243 0e000000 02000000 80000c51 00000000 00000002 00000000 000000
    ffffffc1f040ba80 3007373816 C Bo:1:006:2 0 31 >
    ffffffc1cef0ad80 3007373830 S Bi:1:006:1 -115 2 <
    ffffffc1cef0ad80 3007377180 C Bi:1:006:1 0 2 = 0020
    ffffffc1f040ba80 3007377195 S Bi:1:006:1 -115 13 <
    ffffffc1f040ba80 3007378588 C Bi:1:006:1 0 13 = 55534e53 0e000000 00000000 00

    请求号51
    该请求，在scsi.h中并未发现对应字段，并且非银河麒麟系统，也没发起这个请求
    经过一番周折，最终找到了51请求（在cdrom.h中，隶属于atapi， 属于ata协议）
    #define GPCMD_READ_DISC_INFO 0x51

    代码分析（湖南麒麟）

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    /* requires CD R/RW */
    static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information *di)
    {
            struct cdrom_device_ops *cdo = cdi->ops;
            struct packet_command cgc;
            int ret, buflen;

            /* set up command and get the disc info */
            init_cdrom_command(&cgc, di, sizeof(*di), CGC_DATA_READ);
            cgc.cmd[0] = GPCMD_READ_DISC_INFO;
            cgc.cmd[8] = cgc.buflen = 2;
            cgc.quiet = 1;

            if ((ret = cdo->generic_packet(cdi, &cgc)))
                    return ret;

            /* not all drives have the same disc_info length, so requeue
             * packet with the length the drive tells us it can supply
             */
            buflen = be16_to_cpu(di->disc_information_length) +
                         sizeof(di->disc_information_length);

            if (buflen > sizeof(disc_information))
                    buflen = sizeof(disc_information);

            cgc.cmd[8] = cgc.buflen = buflen;
            if ((ret = cdo->generic_packet(cdi, &cgc)))
                    return ret;

            /* return actual fill size */
            return buflen;
    }

    从代码看2是正常场景

    协议分析

    1
    2
    3
    4
    5
    6
    ffffffc1f040ba80 3007372795 S Bo:1:006:2 -115 31 = 55534243 0e000000 02000000 80000c51 00000000 00000002 00000000 000000
    ffffffc1f040ba80 3007373816 C Bo:1:006:2 0 31 >
    ffffffc1cef0ad80 3007373830 S Bi:1:006:1 -115 2 <
    ffffffc1cef0ad80 3007377180 C Bi:1:006:1 0 2 = 0020
    ffffffc1f040ba80 3007377195 S Bi:1:006:1 -115 13 <
    ffffffc1f040ba80 3007378588 C Bi:1:006:1 0 13 = 55534e53 0e000000 00000000 00

    看最后一行，前面的55534e53 ,这里应该是55534243，协议的标志魔数（USBS的ASCII码），但是这里错了一个e。
    这让我联想到我们的只读功能，会进行修改数据

    排查代码后，发现果然是这样，光驱只读功能，在处理51请求时，对于获取到的数据修改第3字节数据，但是当前场景只返回2字节，所以走了异常逻辑，导致修改了下个返回的第三字节

    修改