聊一聊万恶的锁首
当手持8倍镜的98K都不能在使用程序时干掉万恶的锁首时，内心是十万头羊驼奔跑的场景，那我们就来聊一聊市面上常见的锁首方式。
① :设置OpenHomePage、Internet Explorer\Main等注册表选项 ② :修改桌面快捷方式后缀 ③ :锁定CommandLine的值(修改桌面快捷方式其实也是锁定CommandLine的一种形式) ④ :针对使用CEF核的浏览器Hook CreateBrowser来过滤和替换指定URL ⑤ :注入Explorer.exe ⑥ :Http/Https本地代理(中间人) ……
方法手段各异其他更多方法就不再赘述,笔者大概总结了15种以上的方法可以修改主页,但是由于存在和其他锁首程序的对抗(主要是锁定时机的问题),其他方法就不再赘述,如果感兴趣我们可以一起讨论。
我们这里就大概聊一下上面几种方法的优缺点,主要是锁定时机的掌握,以及简单谈一谈对抗锁首的代码实现和一些个人想法。
最早的时候我们看到的大部分都是设置注册表来锁定主页,但是这个方法很容易被杀软盯死,并且别的程序也可以容易的修改你设置过的值. 方法一就跳过.
(方法二)紧跟其后的便是修改桌面快捷方式的后缀 ,本来我们干干净净的快捷方式大概是酱紫的”C:\ProgramFiles(x86)\Google\Chrome\Application\chrome.exe”. 然后恶心人的事情就来了 ,一不小心突然就变成了”C:\ProgramFiles(x86)\Google\Chrome\Application\chrome.exe”http://www.xxxx.com/?id=1234xxx ,这种方法在目前网吧环境使用还是特别多。
其实我们用ProcMon看一下或者OD调一下就能看到方法一二三其实原理都是一样的:早先的时候浏览器(IE, Chrome或者是国产的个版本浏览器)在启动之后会去主动调用GetCommandLineA/W,来确认要展示给用户的第一个网页是什么(并不是第一个访问的ip地址,后面会继续提到).
我们知道前三种方法原理都一样的时候我就能确认一个目标了:就是谁在最后修改CommandLine,谁就掌控了主动权,是的你没看错,就是越晚越好.为什么这样呢?
比如程序A修改了CommandLine,但是在程序B在程序A修改之后,在浏览器调用(GetCommandLineA/W)访问网页之前又再次修改了CommandLine的值,那么A修改的就无效了。
所以针对CommandLine时机的抢占,在应用层做是做好的,毕竟越晚修改越好嘛。
再看方法四,由于国内厂商很多套用CEF,所以我们也可以通过Hook CreateBrowser来修改第一个要访问的URL,但是由于libCEF各版本不同,做兼容很麻烦.这里也就只当是一个思路跳过了。
笔者曾经分析过市面一款免费的锁首工具(一X锁业),发现他虽然是进内核修改程序的CommandLine,虽然能够干掉很多通过修改注册表来锁首的程序,但是却有一个致命的错误,他是在浏览器OEP代码执行之前就修改了CommandLine的值(时机太早了),那么我们要对抗他的锁首就非常简单了.
既然是在OEP之前就修改了CommandLine,那么我们在他修改完之后再修改回正常的URL就行了,这里要考虑的就是执行代码的时机问题了,这里我想到了2个可以在OEP之前执行我们自己代码的方法
1:AppInit_DLLs 注册表注入,让Kernel32::LoadAppInitDlls去Load我的DLL,然后修改浏览器的命令行参数 2:自写一个简易的调试器,接管浏览器的OEP,来修改URL
大部分的杀毒软件也是非常细心的,Hook了GetCommandLinA/W,来过滤URL,发现试图有锁首的URL就咔咔提着40米长的大刀上去了.
于是也就衍生了通过跳转来躲避杀软的首页保护,比如先跳到一个白名单URL(例如:BAT这样的大厂.com 然后再360度转体再跳回来),这样杀软就不敢修改了.
这其中还有部分浏览器自带URL过滤,例如某四个数字牌子的浏览器.
这种方法到目前为止还是行之有效的,但需要锁首作者细细研究了.
笔者曾经遇到过2个甚至是3个程序同时抢占CommandLine的情况,于是,就发生了惨烈的一幕:
例如我启动IE,程序A发现URL不是他的计费ID就眼疾手快结束了Explorer创建的IE进程,然后重新CreateProcess修改了浏览器的CommandLine.
哇,这个时候程序B看不下去了,我的设置的小尾巴你竟然敢修改掉,二话不说,干掉了程序A创建的IE进程,再次CreateProcess.
就这么来来回回半个小时,IE被蹂躏了N次,用户都能看到浏览器界面长什么样子.只能弱弱喊一句:”网管!!!”
那么
你骚任你骚,我补我的刀. 你强任你强,我艹我的羊.
你锁首程序最终还是要让浏览器访问网络吧?你再骚也不能给用户骚个404出来吧?
那么下文我们再回到第六种方法.
我们可不可以过滤网络访问的请求?答案是可以的.
为了兼容XP笔者这里使用的TDI.
Http部分:
假想情况:
假想我们电脑被锁定的主页为http://www.234x.com?/id=123456,我们想让他变成干净的www.234x.com
当我们通过TDI在内核中收到Http的80端口请求时,这个时候我们就能做事了.
1:判断当前访问80端口的进程是不是要过滤的进程 2:检查in_addr是不是要过滤的ip(黑白名单)(这里要特别注意的是一个网站多个对应IP的情况) 3:真假时机(部分浏览器会在浏览器启动时先访问baidu或hao123等网站,提前加载.这个时候如果你修改了网络访问,也是无效的,等浏览器的程序界面展示出来的时候还可能是带上计费ID的URL) 4:检查重入问题(这个特别关键,如果不加判断,那么你就永远只能停留在主页上了,需要适时放过,具体更多的细节就不写了,如果你有需要自行研究吧.) 5:修改目标IP,将IP地址指向127.0.0.1 和修改目标端口, 将端口指向本地监听端口
当上面的问题都考虑之后我们在ConnectFilter里面就能这样做了.
内核部分:
1:判断端口
2:检查in_addr(部分代码)
3:白名单进程判断
这里不贴代码了,适当合理的检查可以很大程序增加过滤效率和误判率
4:白名单IP过滤(重入判断)
这里的白名单过滤并不是为了放过某些Addr,而是为了解决重入问题,例如当我们打开百度或其他搜索引擎之后,根据过滤规则我们可能会过滤掉带计费ID的URL,然后我们在搜索框中输入了”HelloWorld”去搜索,这个时候由于我么已经修正过了URL,所以当浏览器再次发起Http/Https请求的时候就需要直接放过了,不能再修正URL了,如果不放过请求,你将永远停留在搜索主界面.
5:修正IP到127.0.0.1,修正目标端口到本地应用程程序监听的端口
然后到这里内核的工作就做完了.
应用层部分:
1:启动一个TCP监听并将端口发送给内核
启动一个TCP监听,用来响应内核修改完IP和Port之后,浏览器发起的connect
内核层将目标端口修改为三环传入的指定端口
2:设置相应的跳转URL
例如:将www.234x.com/?id=123456跳到www.234x.com
2:三环程序在accept之后给浏览器发送302,将www.234x.com发送给浏览器
然后三环事情就做完了.
接下来的事情就又到了内核层处理重入问题了(内核部分步骤4),这个时候浏览器将继续访问234x的ip和80/443端口.整个流程最重要的重入处理就不再多写了(我是很痛恨锁首的,好气…).
以上就是修正Http的流程,但现在很多锁主页的程序开发人员都将URL指定为Https了,那么Https的我们应该怎么办呢?
依旧是上面的假设要修正234x的首页.
内核部分:
参照Http处理流程,流程相同
应用层部分:
相比Http的跳转,Https多了一个加解密的过程,但是事实上我们如果只做首页修正而不是做搜索的计费ID修正,解密的部分我们是不用关心的.我们要做的依旧就是在三环等待内核修改浏览器要访问的ip和端口之后,给浏览器发送加密后的302数据.
1:生成本地www.234x.com的证书
具体过程可自行百度openssl,不再赘述
2:ssl初始化,导入证书,与socket绑定等
3:同Http应用层部分,在accept之后SSL_write给浏览器发送302
TDI过滤的利与弊:
弊:
笔者在搜集了市面几种锁首之后通过TDI过滤网络请求,基本都干掉了多款使用以上12345种方法锁首的程序.但并不是完美的.还存在一个致命的问题就是Chrome和FireFox加入了证书检测,在使用中间人的时候浏览器会提示证书错误,禁止访问网络(当然用户可以选择信任,继续访问).当然,部分锁首作者可能会去使用NDIS。
利:
当然我们最终的目的是我们可以有一个稍微干净的上网环境。
在不考虑锁首程序在应用层甚至是在内核层为修改CommandLine而争的头破血流的情况下,使用TDI修正首页访问还是很安逸的,我们可以将浏览器的首页访问强制修正为干净的清爽的不带肮脏交易的URL上去。
结语:
我想有一个干净的上网环境！
谢谢！