BlackHat之路第八期：文件夹病毒专杀工具。

第八期来得迟了点，其实这个工具8月份完成了80%，9月份主要是重构优化了一下。

点击下载此文件

预备知识：
一个ICO文件，其实是由不同尺寸的BMP文件组成的，即可以将ICO理解为一个BMP数组，{48*48,36*36,24*24…}
windows会根据需要，选择适当大小的图片。比如，“平铺”选择的是48*48的，“列表”选择的是16*16的

工具原理：
1·遍历文件夹，扫描“是PE&会显示图标”的文件，选择其ICON_GROUP的第一个图标资源作判断
2·枚举该图标里的所有尺寸的图片，与Pattern中的相应尺寸的图片 比较每个像素的RGB，容差在某个范围内，则认为HIT
3·当该图标的某个尺寸的图片的所有像素HIT的百分比在某个范围内，则认为图标HIT，即认为是文件夹图标病毒

优势：
相比 通过提取文件CRC来判断一个文件夹病毒，通过图标来判断更为可控，更为迅速。而且，调整好几个阀值之后，理论上不会误报。

后续开发计划：
增加免疫功能；增加修复功能；增加实时监控功能

说明：
由于我目前收集的样本数有限，所以Pattern比较少，检测效果可能不是很好。以后我会扩充Pattern。

BlackHat之路第七期：Worm_downad扫描器

这个东西是想练练手的，因为觉得自己大部分是分析别人写的东西，所以觉得自己也应该写点东西出来。
这个东西主要有两个功能：扫描网内的机器，猜测密码以及判断是否有MS08-067攻击的漏洞。

做的过程中还是学到不少东西的。内网连接，怎么猜密码，怎么利用管道，怎么利用漏洞等等。

下载地址：
点击下载此文件

MPEG-2 0Day攻击原理和预防。

MS08-067带来的Worm_downad的硝烟还没有完全散去，最近又惊爆一个新的0 Day漏洞，喜欢上网看图片和视频的网民们要小心了，说不你正看得眼冒金星的时候，病毒已经在悄悄地侵入你的电脑。

这个漏洞发生在windows系统的BDATuningModelMPEG2TuneRequest视频组件中。当用户浏览被挂马的网页时，恶意代码就会调用MPEG2视频组件的msvidctl.dll模块，从而溢出执行ShellCode。

说起来有意思的是，这个漏洞归根到底是由于微软工程师犯了一个“程序员的错误”。本来是应该传递一块buffer的指针过去，但是结果却传递了这个指针的指针，也就是MOV变成了LEA。这个大部分程序员都曾犯过的错误就这样成了本次0Day的罪魁祸首。
阅读全文 »

Robolet萝卜游侠破解杂记。

萝卜游侠，是这个东东，http://www.robolet.com/，应该是网游自动脚本类工具。
一个朋友要破网络验证，于是我就破破看。

出于保护软件的目的，只讲个大概流程和要点。
这个东东是我见过的极少的不通过加猛壳来保护自身的网游类工具，我不知道官方是舍不得买猛壳的钱还是……反正岂一个汗字了得。

1·下载包下载下来的exe A并不是最后运行的主程序，第一次点击后，会把主程序 B释放出来，释放的位置是几层随机命名的文件夹里面。

2·B运行的时候会校验当前目录有没有B.rsys文件，搞笑的是只检验文件的Handle是否存在，不看文件的内容。

3·B运行后，出现的主窗口是B生成的，但是点击登录后，运行的却是另一个地方的Code，这个地方是A的目录下的一个dat文件C。这里又出现搞笑的地方了，这个Dat其实是一个Dll，只是把后缀改成了dat而已。

4·调了几次后发现，A、B、C的Code基本上一样，只是几部分Code分开运行了而已。A释放B，B调用C。比如登录那部分的代码，是通过LoadLibrary来调用C.dll里的登录函数。

5·找到登录函数后，基本上就是明文的登录验证了，原理大同小异，获得用户名和密码后，作为querystring传给一个网页，通过返回值来判断是否注册、是否付费、费用是否到期。几个JNZ、JZ改成JMP或是NOP掉就可以了：

6·后续操作就是优化的问题了，这里就不说了。

总结：我觉得这种“保护”方式真的蛮逗的，如果直接调试下载下来的exe，发现会直接跟飞了，如果你怀疑程序使用了反调试或是自校验，那你就走入了误区。其实只要打开FileMon看一下就知道了。这样的东西居然卖钱，再汗一下。

BlackHat之路第六期：一次网站逆破经历。

最近博客高产，实属不容易。偶尔静静思考，写点东西，总比打游戏来得好。
读书不可有太多实在的意义，写文章也是。

一个网络上的朋友，从黑鹰安全网出来的，黑了一个aspx的网站，拿到了页面和bin。在看雪上发了个帖子，征人破解。说是一些页面打开直接空白，怀疑加入了域名校验的功能。我正好想练练手，所以接了下来。

2个小熬夜，搞定。结果是，改动的地方不多，分析的过程比较曲折。
阅读全文 »

[转]SEH的反调试原理。

1. 首先利用异常处理例程来进行反跟踪，很多CM都是首先安装好一个异常处理例程，然后故意制造一
个异常，如果 xor eax, eax; mov eax, 1 或者 mov eax, 0 jmp eax 之类的,然后程序抛出异
常，在onllydebug下用shift + F7 或者 shift + F8 进入 ntdll.KiUserExceptionDispatcher,单步
跟踪后最后系统调用用户模块中的异常处理例程. 很多CM都是在异常处理例程编写一个算法来重新将
EIP定位到一个会造成异常的指令地址，重复这个过程几次，这样给调试者一种很难跟踪的假象，这种
一般只要用 shift + F9 (OnllyDebug:该组合键是将异常交给用户程序的异常处理例程来处理，如果
我们想弄清楚异常处理例程到底在做什么，我们可以在异常处理例程下个断点来查看其实现过程。

PS: 见过一个CM是用异常处理例程是每次INT3异常对应一条MSAM语句，这条语句就是注册码生成用的
，所有有时候有必要跟踪异常处理例程。如果整个注册算法很大的话…….

2.未处理异常用于反跟踪的原理 [要是早知道这个我就不会一值很困惑了。。。]
根据MSDN的描述，UnhandledExceptionFilter在没有debugger attach的时候才会被调用。所以，
SetUnhandledExceptionFilter函数还有一个妙用，就是让某些敏感代码避开debugger的追踪。比如你
想把一些代码保护起来，避免调试器的追踪，可以采用的方法：
[a]. 在代码执行前调用IsDebuggerPresent来检查当前是否有调试器加载上来。如果有，就
退出。
. 把代码放到SetUnhandledExceptionFilter设定的函数里面。通过人为触发一个
unhandled exception来执行。由于设定的UnhandledExceptionFilter函数只有在调试器没有加载的时
候才会被系统调用，这里巧妙地使用了系统的这个功能来保护代码。

第一钟方法很容易被绕过。看看IsDebuggerPresent的实现：
0:000> uf kernel32!IsDebuggerPresent
kernel32!IsDebuggerPresent：
281 77e64860 64a118000000 mov eax,fs:[00000018]
282 77e64866 8b4030 mov eax,[eax+0x30]
282 77e64869 0fb64002 movzx eax,byte ptr [eax+0x2]
283 77e6486d c3 ret
IsDebuggerPresent是通过返回FS寄存器上记录的地址的一些偏移量来实现的。（［FS: ［18］］:30
保存的其实是当前进程的PEB地址）。在debugger中可以任意操作当前进程内存地址上的值，所以只需
要用调试器把［［FS:［18］］:30］:2的值修改成0，IsDebuggerPresent就会返回false，导致方法1
失效。
对于第二种方法，使用［［FS:［18］］:30］:2的欺骗方法就没用了。因为
UnhandledExceptionFilter是否调用取决于系统内核的判断。用户态的调试器要想改变这个行为，要
破费一番脑筋了。
Kwan Hyun Kim提供了一种欺骗系统的方法：
How to debug UnhandleExceptionHandler

http://eparg.spaces.msn.com/blog/cns!59BFC22C0E7E1A76!1208.entry

3.提供几个CM的链接地址
[使用多次异常和未处理异常来反跟踪]

http://bbs.pediy.com/showthread.php?threadid=8155

[使用中断异常产生对应的注册算法，需要很大的耐性。。。。]

http://bbs.pediy.com/showthread.php?t=27224

[利用未处理异常，还没弄明白。。]

http://bbs.pediy.com/showthread.php?t=12217

[SetUnhandledExceptionFilter 的讨论 ]

http://bbs.pediy.com/showthread.php?t=9023

附一段SEH反调试的VC代码：
[code]
int main()
{
bool bIsInDebugger = true ;

try{
// 非法内存访问,会引发异常
int *p = NULL;
*p = 0;
}catch(...)
{
// 对异常进行处理
// 如果应用程序接管异常, 我们认为当前程序没有被调试
bIsInDebugger = false ;
}

if ( bIsInDebugger == true )
{
exit();
}else
{
cout<<"Hello World"< }

return 0;
}
[/code]

BlackHat之路第五期：一个简单的PE Append感染型病毒的手工修复。

PE_DOWNEXEC.O是上周刚发现的新的感染型样本，该病毒会感染exe文件，并新加一个节，节名为hhqg，然后病毒会修改exe文件的eip，指向这个新节，执行完毕后重新跳回原来的eip。

下面我们将手工修复被病毒感染的文件。

OD载入，我们在text段加上内存访问断点：

然后按F9，执行到以下位置：

因此断定004012A0这个位置为eip。
下面我们来看看这个新节做了什么事情。
OD重新载入，单步到以下位置，发现一个函数：

F7进入，继续单步，发现函数：

F7进入，单步：

F7进入，单步：

F7进入，单步：

好，到这里我们发现了关键代码，新节里调用了Loadlibrary和GetProcAddress，先后获得了WinExeC和URLDownloadToCacheFileA函数，我们查看栈里面有什么内容：

好，这里就真相大白了，新节的目的就是从网上下载一个exe文件，然后调用winexe执行。

下面我们来手动修复。
使用LoadPE载入这个被感染的文件，选中这个新节，删除掉：

然后修复原来的EIP：

点击保存、确定。

到这里还没有完成，这样的exe是不能运行的，我们必须对EXE重建：

好了，这样简单的手工修复就完成了，点击运行，ok没问题，而且因为没了新节的代码，执行速度也快了很多：

BlackHat之路第四期：API Hook做自定义的弹出对话框。

Windows自定义的弹出对话框太丑了，而由于对话框是通过调用MessageBox这个API，由Windows生成一个Model窗口产生的，所以我们没办法为这个Windows生成的窗口自定义皮肤。

所以可以通过Hook MessageBox这个API来自定义对话框。
这里的Hook有两种，一个是Inline Hook，一个是IAT Hook。
前者是修改当前进程空间里的API所在内存，后者是修改当前进程的导入表中的函数指向地址。

我这里使用的是前者，因为由于杀毒手调用了很多dll，如果为每个dll修改导入表，显得麻烦了点，所以直接修改进程空间内的API比较方便。
因此，把当前进程空间内的MessageBox函数的前几个操作变为“跳转到指向我们的自定义函数的地址”，就可以产生我们想要的对话框了。
当我们的程序调用MessageBox时，就会自动跳转到我们自己的对话框函数。

这个跳转的指令如下：
{0xB8, 0x0F, 0×10, 0×40, 0×00, 0xFF, 0xE0}
后面再跟上我们自己的函数地址。
首先用GetProcAddress获得MessageBox的地址，然后VirtualProtect修改内存页属性，再调用WriteProcessMemory修改内存。完工。

但是，需要注意的是，这个我们自定义的函数，需要考虑得和MessageBox API一样全面，函数参数数目、参数类型等等。

另外，还有一个方法能实现自定义对话框，就是消息Hook。这里就不详述了。

效果：
hook前

hook后

BlackHat之路第三期之后续：第一个注册机的注册算法分析

http://blog.sina.com.cn/s/blog_59acc8e20100c8xk.html

数字五笔2008通用注册补丁。

数字五笔是老爸使用的一个输入法，因为老爸不会拼音也不会五笔，难得找到一个好用的根据笔画来打字的输入法，但是没购买的版本每次都提示购买。挺难为他的。
所以找时间爆破了一下，内存补丁法。

在安装了数字五笔的机器上，将该工具放到system32目录下，运行，然后随便输入一个注册码点击注册，便可以成功注册。

下载：
点击下载此文件

声明：请勿用作商业用途。