OD完美破解锐捷客户端!
众所周知,锐捷客户端使用起来很方便,所以在各大高校的拨号网络中都使用锐捷的拨号客户端!但其有一个很“奇怪”限制!那就是限制多网卡使用!这让很多人很是纠结!为什么说他奇怪?因为在我们看来,我是开钱买号,然后用账号拨号上网的!根本没有任何不规矩的行为!你凭什么限制的网卡?举个简单例子!我开一个虚拟机想建一个局域网都不行!只要虚拟机的网络一开!锐捷客户端立马给下线(凭什么?)!当然,出于具体运营商的要求,人家为了禁止别人共享上网而出此下策!这我们不禁要问:我就算几台共享上网,还不是一个账号拨号,均分指定的带宽,你运营商凭什么要限制?凭什么限制我的合法使用权利?
好了,牢骚发完,进入正题!
网上有众多锐捷客户端多网卡限制破解方法与工具(众怒难犯!),但大多数看起来很是复杂!不适合非计算机专业的朋友使用,本方法是直接修改客户端的机器指令,不使用任何第三方工具,大家只要将这个破解的客户端放在锐捷的安装目录替代原有文件即可!
特别说明:64位不能使用!具体解决办法,请参考下文的32位破解思路!自行破解!因为64位与32位一般初始化不一样,但程序核心都不会差别太大。在复制替换原有文件,请备份原有文件,假如不能破解,好还原回来!
说明下:我使用锐捷客户端版本为:RG-SUV4.60-0811(我校的4.6版本),本机系统为winXP(32位)
下面给出下载地址:
http://pan.baidu.com/share/link?shareid=2705932312&uk=1392767659
使用方法:直接将下载的文件覆盖到你自己的锐捷客户端安装目录!!
下面说下破解流程:(写给有兴趣的朋友参考!不感冒的朋友,下载文件直接使用即可!下面没必要看,当然可能因为版本差异,会导致破解失效,所以失效的朋友可参考下文)
工具:PEID、OD 笔者环境:winXP32位
声明:下文只供大家交流学习!
一、破解防调试
首先,在我们安装完锐捷客户端后,会自动启动一个进程SuService.exe看名字都知道这是它的服务进程,大家没事别碰(就算想碰也不一定碰的了),然后我们的桌面也会自动生成的快捷方式(对应程序:RuijieSupplicant.exe)!大家点击快捷方式直接就进行拨号上网了(有点废话!)。
接着当然是用peid查看软件信息,软件是用VC++写的,没有加壳!所以省了脱壳的步骤!直接进入破解环节!
笔者表示被这个快捷方式给骗了!刚开始一直以为那就是客户端管理软件,殊不知用OD载入后发现,一运行OD就直接终止了,但惊奇的是哪个拨号界面既然还在!这说明桌面的快捷方法对应的程序根本不是客户端管理软件!!打开任务管理器,发现进程中多了一个进程:8021x.exe! 笔者将它结束,拨号界面(也就是客户端管理软件)立马也关掉了!这说明8021x.exe才是真正的客户端软件!也就是说我们要破解的就是8021x.exe这个程序!桌面的快捷方式只是起到一个迷惑的作用,我们点击它后,它就调用8021x.exe,然后结束自己的进程!剩下的所有工作当然全部交给了8021x.exe!
进入安装目录,我们直接找到8021x.exe,同样,用peid查看,也是vc++写的,无壳,下面也是OD载入,OD运行,OD直接给终止,好家伙,真行!这时,遇到这种情况我们就需要考虑OD终止的情况了,可能导致程序终止的原因有:
1:程序检查到调试工具,直接退出!
2:程序自检查,发现非规定启动,便直接退出!
这里,个人当时觉得第2种情况的可能性大一点,然后直接验证,验证方式:在安装目录,直接点击8021x.exe运行,发现运行不了!然8021x.exe本就是客户端运行支持的程序,先前已经验证了!但为什么我们直接运行这个程序就运行不了?这就是说明8021x.exe是第2种情况!直接的说,就是8021x.exe要想运行就必要RuijieSupplicant.exe调用!
下面就总结下我们点击桌面快捷方式后锐捷的执行流程:
点击快捷方式win调用RuijieSupplicant.exe程序,RuijieSupplicant.exe启动后,又调用8021x.exe,然后结束自己,8021x.exe维护所有的工作!但8021x.exe必须的RuijieSupplicant.exe调用才能正常运行!但我们要调试的程序是8021x.exe,但这个程序不能直接打开!怎么办?如何才能调试?
所以,知道问题的关键下面我们就是对应的解决,我们都知道程序是死的,只会按照预先编译好的指令执行!所以先前我们说过,8021x.exe启动后会检查调用状态!所以其必然有一个判断过程,大致如下:
if(非正常启动)
call 退出 ;a位置
else
call 进入程序初始化
所以根据上面的大致流程思想,我们要做的就是找到那个"if"也就是所谓的关键跳!怎么找?当然是通过下API断点!我们知道程序要结束一般都会调用ExitProcess函数,所以我们直接下ExitProcess断点!然后OD运行果然,OD停在这个断点处!好,接着查看堆栈调用!为什么?因为大家都知道,ExitProcess是API函数也就是程序必须要调用才会执行,这说明8021x.exe调用这个函数,既然调用,那么我们顺藤摸瓜通过堆栈调用就可以跟踪到8021x.exe的调用该函数位置!也就是上面流程中a的位置,那么我们往上找就能找到关键跳了!
如图:
由此看出jnz就是关键跳!非正常启动就不跳,然后直接调用ExitProcess退出!所以我们只要让它跳就可以所以将jnz改为jmp无条件跳转!修改保存!然后运行新的这个保存文件!OD运行!界面出来了也就说8021x.exe正常运行了!我们破解完成了60%,因为现在我们已经可以通过OD直接调试了!
二、破解多网卡
下面就是破解多网卡限制,在破解之前,我们还是得想想8021x.exe它的运行原理,大致如下:在启动时开启一个定时器,指定时间检查网卡状态,如果发现有多可IP就判断为启动了多网卡!然后执行断开操作!流程如下:
TimerProc()定时器回调函数中
{
if(检查到多网卡) ;关键跳
call 断开连接;
else
正常返回
}
所以破解其实很容易了!因为只要知道了它的大概原理就能找出相应的破解方法!!这里就有很多种,比如:
1:下对话框断点,因为它断开后会弹出提示对话框!只要找到弹出位置就可以往上找到关键跳点!
2:下遍历网卡或是IP地址的断点(抱歉,不知道API),然后也能到关键跳
3:下SetTimer断点!因为8021x.exe要定时检查,肯定有定时器!!所以,我们只要找到这个开启定时器的位置就可以……
这里,笔者采用第3种,好不容易(真的,这个方法太囧了!)找到了SerTimer调用位置,如图:
00424E3B53pushebx;回调函数入口地址
00424E3C68 60EA0000push0EA60 ;巡回时间,这里可以看出他的巡回时间为60S
00424E41 |. 6A06push6;定时器ID
00424E43 |.53pushebx;窗口句柄
00424E44 |. FF1544005200 calldword ptr[<&USER32.SetTimer>]; 调用SetTimer
到这里,破解已经可以说已经完成!我们可以在空代码段写入回调函数,然后将pushebx中的ebx改为我们自定义回调函数的地址!也可以将0ea60改为无限大!当然,最容易就是全部NOP掉!这里,有人可能会认为nop掉了settimer后面的killtimer怎么办?程序肯定有一段代码是kill定时器的!如果改了Set,会不会异常?答:不会!从锐捷客户端使用时就可以看出,它的Kill是写在定时器的回调函数中!所以定时器都没有启动,回调函数自然也不会启动!所以不会异常!也就是流程大致如下:
TimerProc()定时器回调函数中
{
if(检查到多网卡) //关键跳
call 断开连接
Killtimer;
else
正常返回
}
另外说明一个问题,也就是说在开启wifi之类共享网络时,本机已测试可以正常使用,如图:
但是在关闭wifi时,锐捷客户端竟然会断开如图:
即如下图关闭internet共享后就锐捷才会断开:
这里由于是在关闭wifi时才断开,不影响wifi的正常使用,本来不打算继续破解了,但拷贝到其他机子测试,有时正在wifi时就会断开并弹出如上对话框,但关闭wifi后必定会弹出!但在我的机子测试,只有关闭wifi时才会弹出(估计开发人员的BUG),算了,于是继续破解!但接下破解这个“代理检测”可真不是很容易,足足花了两昼夜的功夫,才勉强称得上是破解了,虽然个人认为还是不完善,但多台机子重新测试后,没发现任何问题,故就不在这个软件上花太多功夫!有兴趣的朋友请继续研究!下面进入正题:
以下是破解的遇到的所有问题,没兴趣的朋友可直接跳到 :三破解代理检查
首先,在破解之前,还是先想想这个检查的大致原理,由于本机只有在断开wifi时才断开网络连接,这让我一时还不知道从何下手,我真的估计这是锐捷的bug,不然我使用wifi时你不断开,我不使用wifi时你竟然才断开(纠结)!恰恰弄反了,这虽然是好事,但却在调试中增加了难道,估计是我本地的机子的一些设置恰好和锐捷判断使用代理的条件弄反了!就不管是bug了,还是先调试看看,但调试前,我们必须要明白,这种程序一般都会用到多线程,或是定时器来执行某些巡检工作,一旦发现有“违规”的行为,就进行处理!
好,经过几次测试之后,初步可以确定这个“代理检测”是使用多线程来检测!这对OD来是比较不愿看到的!因为多线程在OD中调试很复杂,知道这一点,我们马上就会想到一个破解点,那就是在检测线程还没开始前就结束掉!于是顺着这个思路,就下:CreateThread创建线程断点,找到“代理检测”线程的地方,然后破解。可真正调试过程中发现这个思路可能行不通(放弃了),因为这个8021x.exe共有20+个线程,看起来虽然不多,可要识别每个线程的功能,就要花费很多时间,更别说是在汇编代码下,笔者试了半天,最后还是放弃!虽然放弃了,但还是确定了某些线程的大致功能!这点后面的调试还是有作用的!
找线程点不行,就换个思路进行调试,在OD中通览一下8021x.exe的汇编码,发现这个程序用到了iphlpapi库,这个库提供很多接口主要用于操作网卡之类的设备,既然如此,那么那么8021x.exe锐捷在断开连接时一定会调用该库提供了API,于是就查找iphlpapi的帮助文档,发现一个函数IpReleaseAddress()这个函数是释放从DHCP服务器中获取的IP,锐捷可能调用的是这个函数!于是下这个IpReleaseAddress断点,测试……果然,OD停了下来,于是找到如下图的位置:
0042C4C2 |. 8D443004leaeax, dword ptr [eax+esi+4]
0042C4C6 |.50pusheax
0042C4C7>|. E8849F0D00call<jmp.&IPHLPAPI.IpReleaseAddress>; 断开连接
0042C4CC |.85C0test eax,eax
0042C4CE |. 751Djnzshort 0042C4ED
0042C4D0 |. 68C0975200push005297C0;
0042C4D5 |. E846370300call0045FC20
经过多次测试发现只要断开连接,不管是自动还是被动(检查到代理)断开,都会来到这个点,也就是
call<jmp.&IPHLPAPI.IpReleaseAddress>;
于是通过堆栈跟踪发现这个如图的位置:
0042CE09> 83F802cmpeax, 2
0042CE0C750Cjnzshort 0042CE1A;case=2
0042CE0E8BCBmovecx, ebx
0042CE10E8 9BFAFFFF call0042C8B0; 跳到断开连接代码段
0042CE155Epopesi
0042CE165Bpopebx
0042CE17C20800retn8
0042CE1A> 83F803cmpeax,3;case=3
0042CE1D. 750Cjnzshort 0042CE2B
很明显这是一个switchcase语句,经过多次测试,发现程序在进行认证前也会来到这个位置,因为它要确保释放掉IP,然后重新获取,但认证前,它的case值=3,也就是说,它不会执行case=2里面的代码,但断开连接时就会执行case=2里面的代码,也就是如下流程:
……
switch(eax)
case2:call 处理断开
case3:call 处理认证
……
所以,只要我们把jnzshort 0042CE1A改为jmp short 0042CE1A就可跳过断开处理,本以为就这样结束了,可程序还是会断开!,于是继续调试,这时出现了一个诡异的问题:我在这段代码头下了断点,又在这段代码必定会执行到的又下了个断点,然后进行测试,发现程序检查到使用代理后就停在了这段代码头的那个断点处,于是点运行,又来到了第2个断点处,于是接着运行,经过多次测试,这时出现了两种情况,只要在第二个断点处停上5~6秒,程序就不会断开,也就是说:这段代码只有在检测到使用代理时后的5~6秒内执行完毕,那么程序就不会断开,并且某段检查代理的线程就会结束掉,以后就不会在检查是否使用了代理!于是,下面的工作就是让程序在检查到代理后,在这段代码出停留5~6,故使用Sleep将上面的代码进行如下修改:
0042CE09> 83F802cmpeax, 2
0042CE0C750Cjnzshort 0042CE1A;case=2
0042CE0E8BCBpush1770
0042CE10E8 9BFAFFFFcall dwordptr[<&KERNEL32.Sleep>];程序睡6秒
0042CE155Enop
0042CE165Bnop
0042CE17C20800nop
0042CE1A> 83F803cmpeax, 3;case=3
0042CE1D. 750Cjnzshort 0042CE2B
本以为大功告成,但运行后还是不行,依旧还是会断开!这时,头已经很大了,脑袋里根本不知道下一步怎么办,于是就停下了思考仔细总结下调试得到的一些信息:
1、程序使用多线程,其中控制连接与检查代理可能是分开的
2、程序断开都会走上面的那段代码段!
3、上面的代码段只要是case=2时,走完后都会结束检查代理的线程
4、检查到代理后,为什么5~6秒内走完上面代码就能避免断开?
5、使用Sleep停了6秒为什么不行?
经过总结才恍然大悟,原来这个程序是多线程的,在OD调试本来会忽略掉有些线程!也就是说,你在调试这个线程时,另一个线程可能已经结束!于是猜想锐捷在检查到代理后,通知某个线程负责释放IP,同时通知某个线程进行检查到断开处理,故我们在释放IP的线程跟踪调试时,另一个线程已经断开,所以,依旧还是会断开!看来还是行不通,于是接着下各种断点,把各种能想到的断开连接的断点都用了,都还是不行!没办法,只有看能不能从弹出的对话框下手,这种方法一般的软件都会有相应的防范措施,因为既然弹出提示使用代理的对话框,上面肯有某处是判断出使用了代理的代码出,只要找到这个代码处就完成任务了,可在调试中,虽然找到了弹出对话框的地方,但往上根本不能跟踪,因为如果别人使用全局变量,然后根据这个变量判断是否弹框,就算可以跟踪带判断点,也无法找到变量的赋值点!所以,放弃了这种方法!又开始总结信息,并想想下一步 如何做……
终于,最后找到了破解的最终思路,顺利的完成了破解,如下:
三、破解代理检测
因为程序是多线程,肯定有一个线程在不停的检查网卡的各种状态,一旦判断到使用了代理,这个检查线程就会通知某个线程进行相应的处理,然后结束自己。那么程序的线程如何通知另一个线程?当然是发消息了,于是下PostThreadMessageA断点,该断点在线程发消息时被调用,果然顺利跟踪到如下图的代码段:
00478B5A> 83F80Ccmpeax, 0C
00478B5D. 752Djnzshort 00478B8C
00478B5F. 8B0D 74DF5600movecx, dword ptr[56DF74];case=12判断使用了代理
00478B65. 8B5130movedx, dword ptr [ecx+30]
00478B68. 6A7Epush7E
00478B6A. 6A00push0
00478B6C. 68 74040000push474
00478B71.52pushedx
00478B72. EB12jmpshort 00478B86
00478B74> A174DF5600moveax, dword ptr[56DF74]
00478B79. 8B4830movecx, dword ptr [eax+30]
00478B7C. 6A7Fpush7F; /lParam = 7F
00478B7E. 6A00push0; |wParam = 0
00478B80. 68 74040000push474; |Message = MSG(474)
00478B85.51pushecx; |ThreadId
00478B86> FF15 24005200call dwordptr[<&USER32.PostThreadMessageA>]; 发消息
00478B8C> 8B0D 74DF5600movecx, dword ptr[56DF74];
00478B92. 81C1 480C0000addecx, 0C48
但判断到使用了代理后,case=C,往下执行就会调用USER32.PostThreadMessageA向某个线程发送(1140号)消息,程序就会断开连接!于是将上面的jnz short00478B8C改为jmp short 00478B8C让它永远也不向某个线程发消息!
破解完成!
这个多线程的程序很难调试,并且要有VC++的一些知识,知道相应的API,否则调试难上加难,锐捷这货,首先做了防调试处理,又进行进行多种常见的防调试处理,又何必呢?又不是收费软件?但凡程序都会破解的一天,就算是那些采用数据包检查的技术,因为只要你有客户端,总会判断异常的地方,而这个地方也总会被找到,所以,程序应该是把心思放在如何提高质量上而不是防逆向上!
PS:抱歉,请原谅我先前的大话,个人认为这个程序还不算完美破解,只是破解防调试、多Ip检查,至于代理检查,个人还没弄不明白它的执行流程,故可能会忽略掉某些东西,导致破解失效,但经过大量检查,至今还没有出现任何问题,如有问题,请高手自行调试!
最后说一下:咱是为了学习而研究!也奉劝某运营商,魔高一尺道高一丈,行不义之举,只会令人不齿,当然了,你如果又要升级锐捷认证,咱们也没辙!
好了,本文结束,至于玩wifi之类的自行百度!这里就不在赘述!