四川电信天翼飞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和光华冠群的驱动打一架。嗯。 当然目前的情况这客户端貌似没壳,会玩逆向的同学或许可以试试 =。= (完)