minieap icon indicating copy to clipboard operation
minieap copied to clipboard

fake-dns1 参数不起作用

Open yjcn opened this issue 7 years ago • 15 comments

image 配置文件里明明加入了fake-dns1 image 抓包发现只有fake-dns2 具体抓的包已发到你邮箱里

yjcn avatar Feb 28 '17 03:02 yjcn

  1. fake-dns1 影响的是在 8021x.exe 之前数据中的 DNS 地址,与 fake-dns2 不同。如果要模拟图中的情况,可以用 --fake-dns2="61.150.47.1;210.27.80.2"

  2. 邮件中问到心跳的问题,找 key 的逻辑在 https://github.com/updateing/minieap/blob/master/packet_plugin/rjv3/packet_plugin_rjv3_priv.c#L529

updateing avatar Feb 28 '17 05:02 updateing

1.现在加了--rj-option=79:02 --fake-dns2="61.150.47.1;210.27.80.2" 两个参数和3个包的长度和基本结构都和官方linux相同了,但是仍然提示 "需要使用管理员指定的客户端!"可能某些字段还是有问题 2. image 找key这部分没有看懂,type是如何确定的? mentohust里找key的部分倒是挺明白的

yjcn avatar Mar 01 '17 05:03 yjcn

  1. 能给出完整的对比吗?
  2. 这部分流程是这样的
    • 1. 将 success 数据包中的 extension 部分解析为字段列表(解析的方法是从开头查找 00 00 13 11 这个模式,找到后根据其后两个字节的特征来判断这是哪种属性,进而应用特定方法计算出字段的长度,然后将这个长度的内容填入 RJ_PROP 结构体并继续查找上述模式)
    • 2. 在上述字段列表中找到符合如下特征的字段:
      • header2.type 为 1
      • 字段大小非 0. 注意到 header2.len 包括两个字节的字段头部长度,故这一条是要求 header2.len > 2 综上所述,这就是查找 00 00 13 11 01 xx(其中 xx > 0x02)这个模式。
    • 3. 若找到了这样的字段,则将其内容的前四个字节解码并设置为 echokey.

相较于 MentoHUST 写死位置的方法,这个方法应该更加灵活,即使 echokey 在 success 中的位置有变化也能够找到。

updateing avatar Mar 01 '17 08:03 updateing

官方的linux客户端的三个包 image image image minieap的三个包 image image image

yjcn avatar Mar 01 '17 08:03 yjcn

image 这是服务器发回的success包 可以看到里面只有两个type为01的字段,但是这两个字段的长度都是01,并没有长度大于2的啊??

yjcn avatar Mar 01 '17 14:03 yjcn

抱歉,上条回复忽略了 type == 1 的时候长度的特殊计算方式……

这里

else if (_tmp_prop->header2.type == 1) {
        /* Type 0x1 means there is no length info, we have to search for next 00 00 13 11 */
        uint8_t* _next_magic = find_byte_pattern(_magic, sizeof(_magic),
                                                buf + _read_len, buflen - _read_len);
        _content_len = _next_magic ? (_next_magic - (buf + _read_len)) : buflen - _read_len;
    }

长度不是直接读出的,是找到下一个 00 00 13 11 后计算出来的。在你的截图中,前一个字段的 length 是 0, 后一个的长度非 0.

updateing avatar Mar 02 '17 10:03 updateing

嗯嗯 那这样的话 image 图里面红色圈圈里的就是echokey了,我看了一下,mentohust里面的偏移量也对着呢,找出来的echokey应该也是对的 我看了下官方的客户端里面的第一个心跳包 image image 里面echono部分对应的数据每次都不一样,echono应该是随机的,我看minieap里echono也是选择的随机的

yjcn avatar Mar 02 '17 14:03 yjcn

不知道你这里的心跳问题是不是跟 #10 相同…… 也许可以用一样的分析方法试试。

updateing avatar Mar 03 '17 12:03 updateing

image 我看分析了一下发现算法没问题就是echokey+echono和echono,主要就是echono不对,我在mentohust里也试了一下,把echono改成随机初始化,发现还是心跳超时,会不会echono也在success包里??很迷啊?

yjcn avatar Mar 03 '17 13:03 yjcn

找一下官方客户端中 echono 的规律试试?比如从固定值开始,或者颠倒取反后能在 success 中找到……

updateing avatar Mar 03 '17 14:03 updateing

我看了下确实每次echono的值是不一样的,并不是固定值,echono或者将其颠倒取反,在success包都没有找到

yjcn avatar Mar 04 '17 02:03 yjcn

除此之外还有个想法,就是如果学校是用“认证 - DHCP - 再认证”这个方式做认证和分配地址的话,缺失后面那一次认证可能会造成问题(因为服务端不知道你的 IP 地址了)

这只是个猜想,并不能证明……

updateing avatar Mar 04 '17 04:03 updateing

二次认证对应的就是这种情况吧,ip信息在第二次认证时候告诉服务器了,如果不加ip信息的话自助系统里ip为0.0.0.0然后就不会计费,之前学校升级锐捷的原因就是有人靠卖装mentohust的路由器号称免流量,我把ip信息加到认证包里了,锐捷自助系统里ip记录也正常,就是官方客户端是第一次认证不加ip信息,我是两次认证都有ip信息

yjcn avatar Mar 04 '17 06:03 yjcn

能否只用这个发心跳包呢,mentohust可以认证但是心跳不行,想尝试一下mentohust认证这个心跳

iLayPark avatar Mar 20 '17 02:03 iLayPark

这个项目的心跳能用?算法跟 MentoHUST 一样的。

要是实在想尝试,在 eap_state_machine.c 里 recv_handler 把收 Request-Identity、Request-MD5-Challenge 的处理逻辑删掉,把 trans_to_start_sent 里发包的逻辑删掉就好了。

updateing avatar Mar 20 '17 02:03 updateing