四川电信天翼飞Young客户端协议简要解析

  • 内容
  • 评论
  • 相关

提示:文章适用于四川地区天翼飞Young 3.09客户端。仅给出其协议交换期间的分析,没有算法说明。(我也没有阅读过之前版本的算法,因此如果有什么奇怪的地方还请见谅)

这份客户端是在今年早些时候拿到的,然而当时并没有去管他,因为那时候模拟PPPOE都还是问题。当然自从上次把CHAP模拟搞完了以后翻垃圾的时候翻到了这个东西,于是就想折腾下。正好有个四川的小伙伴,我也就试试看能不能帮个忙。

四川地区天翼客户端使用的是NDIS驱动模式,而且比较蛋疼的是他主客户端计算出账号以后这个鸟驱动还要改一次账号,非常蛋疼。当时想的是我CHAP模拟写完了的话抓账号应该非常容易。然而让我感到奇怪的是对于每次的登录操作,CHAP模拟都抓到了两个不同账号(客户端计算的账号不一样),这说明客户端是连续进行的两次拨号。最开始我以为是因为我CHAP返回了Failure导致客户端更换到“兼容算法”再次进行拨号,直到我拿到四川小伙伴发来的抓包我才发现。。。

“他妈的都是套路。”

话不多说,先来说下总结:

1.点击登陆,客户端计算第一次账号,格式为 ~ghca + 时间戳的HEX形式8位 + F + 309 + PIN + 原本帐号。原本账号为大写(即便你账号有小写字母)

2.调用RasDialA以后,如果BAS使用CHAP with MD5,则飞young客户端的NDIS驱动开始工作,修改客户端的账号。去掉~ghca以后,将时间戳的8位进行算法操作得到新的8个字符,替换原来时间戳部分。

3.服务端收到了驱动修改过的账号后,返回错误信息,包括一个SALT,用于真正的账号计算。

4.驱动调用客户端进行第二次拨号。此时,客户端账号为 ~ghca + 时间戳HEX8为 + E + 309 + PIN + 原本账号。

5.驱动使用接收到的SALT,将时间戳HEX8位进行变换。此时~ghca不会被去除。

6.服务器返回真实登陆情况

 

账号格式:

四川电信的账号格式为 ~ghca + 时间戳HEX形式8位 + 标识符(D/E/F) + 版本号(309) + PIN + 原本账号。

例如 ~ghca 5739EBB9 F 3090 1E115098F4033EE 7638 1231231 (这里是为了方便阅读区分因此加了空格。)

你可能会奇怪我为什么会把PIN部分最后四位独立开。看下面我抓到的账号你就会明白了。

fy

最后两行,第一个是在事件查看器里面显示的账号(~被我去掉了),也就是他客户端调用RasDial函数的时候所使用的账号,“5739EBB9”很明显的16进制时间戳的意思。第二个是驱动转换后的账号。图中的账号都是我为了阅读方便加了空格。

我之前说到过,四川的每次登陆,实际上都是两次拨号,上图中上面的部分是第一次拨号时驱动转换后的账号,中间部分是第二次拨号驱动转换后的账号。(请注意:中间部分的账号并不清楚来源为何,根据抓到的真实数据标识符为D的账号是没法登陆的。实际上第二次登录的账号应该为标识符E且带有~ghca开头,我会在下面说明)。非常有意思的情况是,第一次拨号,PIN的前面部分是全部为大写,而第二次拨号时则全部为小写,而且,PIN部分的最后四位总是大写字母。(或许可以猜测下最后四位是不是MD5之类的HASH算法算出来的一个Signature值)

上面是我CHAP模拟出来的数据,我们再来看看真正登陆的时候的数据是什么样子:

第一次拨号的账号:c1

这里可以看出来第一次都是这鸟样子,而且服务器返回了Failure,消息内容为32个0.

c1f

于是到了第二次拨号的时候,账号就成了这样子:

c21

咯,账号标识符变成E了,而且~ghca还在。后面的Authentication Success表明了这才是真正的账号。

想到之前Netkeeper这类东西靠在CHAP Failure或者PAP Failed的Message里面传递消息的情况,我就天真的以为这32个0就是真正的消息,告诉客户端“用~ghca”来拨号。然而。。。。。客户端依然返回了标识符D的账号。从头到尾没有出现一个~ghca

这就比较尴尬了。我TM好像没漏掉啥啊?难道客户端有毒?

直到换了一个姿势去看抓到的数据包。。。。。。。

这是我最开始的过滤规则

c12

换个姿势:

c22

然后,这个是CHAP Failure的包:

c23

这个是服务端返回的PADT包:

c24

好像有啥不对???

c25

(左边CHAP Failure,右边PADT,注:0xc223表示CHAP协议域,而04 01 00 24中04表示CHAP 失败,Identifier为1,00 24为消息长度(换算十进制也就是36,包括前面的04 01 00 24在内,因此实际Message为32字节))

我草泥马。。。。。你们四川电信真他妈会玩。PADT里面发SALT老子也是不得不服

那么问题就很明显了,这个NDIS驱动起到的作用应该是:

1.检查是否为CHAP,如果为CHAP则继续操作,否则不管事儿

2.如果客户端下发的账号标识符为F,表示为第一次拨号,去掉~ghca并替换时间戳为算法后的字符串

3.拦截服务器返回的PADT包,提取SALT

4.传递salt给客户端,调用客户端进行第二次拨号。

这就比较尴尬了,SALT是从服务器来的,如果要欺骗账号的话,目前的情况看来只有中间人这条路好用了。(有算法的就是另一回事了好吧 = =)

也就是说,要么你来个中间设备抓真实帐号,要么嘛,你也可以上NDIS和光华冠群的驱动打一架。嗯。

当然目前的情况这客户端貌似没壳,会玩逆向的同学或许可以试试 =。=

(完)

 

评论

13条评论
  1. Gravatar 头像

    riddle tom 回复

    我试过pppoe中间人.虚拟机里开ghca拨号,然后pppoe-relay仅中继第一次连接,然后第二次连接的时候直接用自己架的pppoe服务器套路帐号,用套路到的帐号依旧拨不上。我估计问题是这东西可能连第二次的challenge都利用了……狗子心机婊

    • Gravatar 头像

      crazychen 回复

      @riddle tom 你可能要用套路到的第二个账号,就是标识符为E的账号,他那个应该是看标识符返回salt与否的。这里因为我不是四川的用户,也不是太清楚具体的情况。至于CHAP-FAILURE的PACKET的话我不清楚是不是NDIS驱动做了手脚,但是如果真的做手脚的话他应该不至于还把SALT丢到TERM-REQ里面去。。。。。

      • Gravatar 头像

        riddle tom 回复

        @crazychen 它的的确确在CHAP_FAILURE上作了手脚.如果你开虚拟机然后用wireshark抓的话你会发现CHAP_FAILURE的确是一大串SALT.本来我也以为SALT很特殊.甚至是这一大串0代表验证成功.后来真正抓包才发现根本不是那么回事....

      • Gravatar 头像

        riddle tom 回复

        @crazychen 我估计很可能第二次拨号的challenge也被利用了.第一次拨号的所有内容我都中继了.如果第二次我中继的话,认证会成功

        • Gravatar 头像

          crazychen 回复

          @riddle tom 只有两次拨号,第一次返回salt,你应该要拦截第二次的帐号才是。第二次的账号为~ghca + TIMEPIN + E309 + pin + ACC

          • Gravatar 头像

            riddle tom

            @crazychen 我拦截的就是第二次的帐号.用自己的pppoe-server拦截的.另外的,"X309"其实是版本号.最近新公厕的3.10就是310.

  2. Gravatar 头像

    riddle tom 回复

    另外的,CHAP-FAILURE那个信息其实是被过滤了的。如果你用中间人攻击的话,salt其实是放在CHAP-FAILURE里的

  3. Gravatar 头像

    riddle tom 回复

    Win的客户端我调试了快一个月了,估计是我火候不到位.失败.正在分析mac的

  4. Gravatar 头像

    riddle tom 回复

    下午尝试了一下,保留版本和标识符为D309,拨号只会返回SALT,就算我把除了用户名和标识符以外的字段全部置0,依旧可以返回SALT.如果F309,那就认证失败.和我预想的差不多

  5. Gravatar 头像

    林峰 回复

    南昌的 事件查看器 查看不了账号!

  6. Gravatar 头像

    vvb 回复

    http://182.140.243.67/ 上的mac客户端没有这些套路,实测可以离线生成可用账号
    ~ghca585E975C2023EF0878DB501A3AC701A7xxxxxxxxxxxx

  7. Gravatar 头像

    vvb 回复

    而且通过无线路由把网络分享出去用手机应用拨号也是不一样的,win上的这个拨号器是套路最深的

发表评论

电子邮件地址不会被公开。 必填项已用*标注