「“其他”」的归档

WannaCry勒索软件中,利用了NSA泄露工具中的“永恒之蓝”漏洞,关于这个漏洞,之前已经有一些分析,在我看的文章中,http://blogs.360.cn/360safe/2017/04/17/nsa-eternalblue-smb/说得最详细,该文章中针对win7 32位的系统的漏洞触发过程进行了分析。

但是在整个网络上,我没有看到关于64位系统的分析,因此我在该文章的基础上,对win7 64位的触发,以及触发后的shellcode的行为进行了分析整理成此文。

其中若有疏漏,还请大家指教。最后感谢武汉科锐,感谢钱老师的悉心教学,钱老师严谨的治学作风和渊博的知识深深的影响着我,使我受益终身。

 

搭建测试环境

因为样本的原有行为,是随机产生IP地址,并对目标进行发包。这非常不方便我们测试。因此,需要先在特定的位置断下,将IP地址改为我们的测试目标,并拍快照记录。

具体步骤如下:

1. 在0x00407982处下断,该处为拼接IP字符串,在此处将该字符串修改为自己的测试目标值。

2. 单步(如果不单步可能会因为多线程的原因造成测试不成功,因此推荐单步)至下方的线程创建函数,并在该线程回调处下断点。

3. 在上一步的线程回调函数中,有两处关键点,一处为该样本的第一波发包攻击,攻击结果为:在远程电脑上安装一个后门;第二处为第二波发包攻击,攻击结果为:利用第一波攻击安装的后门,在远程电脑上的系统进程中注入一个dll。他们的调用位置如下图所示:

   

漏洞的原理

在Srv.sys中的SrvOs2FeaListToNt函数中,会有以下调用关系:


SrvOs2FeaListToNt

call SrvOs2FeaListSizeToNt

call SrvOs2FeaToNt

其中在SrvOs2FeaListSizeToNt中因为有一个DWORD*转WORD*并赋值的bug,造成在SrvOs2FeaListToNt的一个循环中,SrvOs2FeaToNt被调用的次数会多于预期,而造成SrvOs2FeaToNt中的一个memmove拷贝越界。

可以看到,运行到下图时,对大小为0x11000:

 

通过!pool指令查看:

 

而实际运行时:

不过,越界覆盖后,最终pool中的地址+0xa8处的数据,会作为一个指针被当作数据接受缓冲区,这是为什么,这其中的原理我没有完全搞明白,还请熟悉的朋友指教。

定位第一轮发包的shellcode触发点

尝试定位shellcode,要知道一个前提,这在其它报告中也已经提到,那就是

该样本的第一次发包,会安装一个后门,该后门的实现方式是在srv模块中,挂钩SrvTransaction2DispatchTable表中的一个表项,可以通过命令.

我之后就是利用这一点,来检验自己的测试机是否已经被触发漏洞,并一步步定位到触发点的(见下文分析).

kd> dps srv!SrvTransaction2DispatchTable查看:

挂钩前:

</pre>
fffff880`0301e760 &nbsp;fffff880`03088780 srv!SrvSmbOpen2

fffff880`0301e768 &nbsp;fffff880`0304fb20 srv!SrvSmbFindFirst2

fffff880`0301e770 &nbsp;fffff880`03085f40 srv!SrvSmbFindNext2

fffff880`0301e778 &nbsp;fffff880`03051650 srv!SrvSmbQueryFsInformation

fffff880`0301e780 &nbsp;fffff880`0307ad20 srv!SrvSmbSetFsInformation

fffff880`0301e788 &nbsp;fffff880`0304f670 srv!SrvSmbQueryPathInformation

fffff880`0301e790 &nbsp;fffff880`03088cb0 srv!SrvSmbSetPathInformation

fffff880`0301e798 &nbsp;fffff880`0304d420 srv!SrvSmbQueryFileInformation

fffff880`0301e7a0 &nbsp;fffff880`0304e080 srv!SrvSmbSetFileInformation

fffff880`0301e7a8 &nbsp;fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7b0 &nbsp;fffff880`03088ae0 srv!SrvSmbIoctl2

fffff880`0301e7b8 &nbsp;fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c0 &nbsp;fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c8 &nbsp;fffff880`0307b4f0 srv!SrvSmbCreateDirectory2

fffff880`0301e7d0 &nbsp;fffff880`0306f460 srv!SrvTransactionNotImplemented

fffff880`0301e7d8 &nbsp;fffff880`0306f460 srv!SrvTransactionNotImplemented
<pre>

挂钩后:

</pre>
fffff880`0301e760 &nbsp;fffff880`03088780 srv!SrvSmbOpen2

fffff880`0301e768 &nbsp;fffff880`0304fb20 srv!SrvSmbFindFirst2

fffff880`0301e770 &nbsp;fffff880`03085f40 srv!SrvSmbFindNext2

fffff880`0301e778 &nbsp;fffff880`03051650 srv!SrvSmbQueryFsInformation

fffff880`0301e780 &nbsp;fffff880`0307ad20 srv!SrvSmbSetFsInformation

fffff880`0301e788 &nbsp;fffff880`0304f670 srv!SrvSmbQueryPathInformation

fffff880`0301e790 &nbsp;fffff880`03088cb0 srv!SrvSmbSetPathInformation

fffff880`0301e798 &nbsp;fffff880`0304d420 srv!SrvSmbQueryFileInformation

fffff880`0301e7a0 &nbsp;fffff880`0304e080 srv!SrvSmbSetFileInformation

fffff880`0301e7a8 &nbsp;fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7b0 &nbsp;fffff880`03088ae0 srv!SrvSmbIoctl2

fffff880`0301e7b8 &nbsp;fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c0 &nbsp;fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c8 &nbsp;fffff880`0307b4f0 srv!SrvSmbCreateDirectory2

fffff880`0301e7d0 &nbsp;fffff880`053e2060

fffff880`0301e7d8 &nbsp;fffff880`0306f460 srv!SrvTransactionNotImplemented
<pre>

可以发现第0xe项会被hook。这个表项的hook是由一段shellcode代码所完成的,具体如何定位到shellcode的入口,见以下分析。

 

因为已知漏洞会在srvnet! SrvNetWskReceiveComplete中完成触发,只是不确认win 7 64位的shellcode写入点是否与前辈win 7 32位地址一样(通常不一样),因此一开始通过下断点并打印内存情况摸索规律:

</pre>
kd&gt; u

srvnet!SrvNetWskReceiveComplete+0x15:

fffff880`02d3cdc5 488bca &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;rcx,rdx

fffff880`02d3cdc8 498bf8 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;rdi,r8

kd&gt; ba e1 srvnet!SrvNetWskReceiveComplete+0x15 "dq r8 r8+0x48;gc"
<pre>

得到以下结果:


fffffa80`049236b0 &nbsp;00000000`00000003 fffffa80`042fd800

fffffa80`049236c0 &nbsp;fffffa80`042fd800 000059b4`918947fc

fffffa80`049236d0 &nbsp;fffffa80`049237f0 00000000`00000810

fffffa80`049236e0 &nbsp;fffffa80`04923710 fffffa80`00000000

fffffa80`049236f0 &nbsp;00000000`00000438 fffffa80`0568d730

……

fffffa80`04a9b010 &nbsp;00000000`0000ffff 00000000`0000ffff

fffffa80`04a9b020 &nbsp;00000000`00000000 00000000`00000000

fffffa80`04a9b030 &nbsp;00000000`ffdff100 ffdff020`00000000

fffffa80`04a9b040 &nbsp;ffffffff`ffdff100 00000000`10040060

fffffa80`04a9b050 &nbsp;00000000`ffdfef80&nbsp;ffffffff`ffd00010

经过比对,发现以上标红内容特殊,是x86报告所记录的溢出时机断点。因此重启环境,下条件断点:


kd&gt; ba e1 srvnet!SrvNetWskReceiveComplete+0x15 ".if(poi(@r8+0x48) ==&nbsp;0xffffffffffd00010){}.else{gc}"

结合以上所知的,SrvTransaction2DispatchTable会被shellcode挂钩,因此在该表项处下断点:

kd&gt; ba w8 srv!SrvTransaction2DispatchTable+0x8*0xe

经过验证,在以上第一个断点触发后,继续运行,会触发第二个断点:

但是,当步入ffffffff`ffd00b77后,栈已经被破坏,难以定位到该段shellcode的触发点。

 

在我所看到的其它的分析文章中,均没有提及具体是个位置转移到shellcode的,因此只有自己定位。

 

考虑到shellcode一般均需要间接call,因此,通过寻找SrvNetWskReceiveComplete中的间接call,并下断点排查。最终,定位到shellcode触发点srvnet!SrvNetCommonReceiveHandler+0xb7:


kd&gt; u srvnet!SrvNetCommonReceiveHandler+0xb3

srvnet!SrvNetCommonReceiveHandler+0xb3:

fffff880`028017e3 89742420 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;dword ptr [rsp+20h],esi

fffff880`028017e7 41ff5208 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call &nbsp;&nbsp;&nbsp;qword ptr [r10+8]

fffff880`028017eb 8be8 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;ebp,eax

fffff880`028017ed 488b0d1cc90100 &nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;rcx,qword ptr [fffff880`0281e110]

fffff880`028017f4 493bcf &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cmp &nbsp;&nbsp;&nbsp;&nbsp;rcx,r15

fffff880`028017f7 740b &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;je &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;srvnet!SrvNetCommonReceiveHandler+0xd4 (fffff880`02801804)

fffff880`028017f9 0fba612c09 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bt &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dword ptr [rcx+2Ch],9

fffff880`028017fe 0f82be840000 &nbsp;&nbsp;&nbsp;jb &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;srvnet! ?? ::FNODOBFM::`string'+0x1341 (fffff880`02809cc2)

在该处下断点验证:


kd&gt; bp srvnet!SrvNetCommonReceiveHandler+0xb7

确实可以截取到shellcode的进入入口:

第一轮shellcode的行为分析

为了测试方便,可以下以下条件断点,这样运行win7测试机器后,断下的地点就是shellcode的入口:


ba e1 srvnet!SrvNetWskReceiveComplete+0x15 ".if(poi(@r8+0x48) ==&nbsp;0xffffffffffd00010){bp&nbsp;srvnet!SrvNetCommonReceiveHandler+0xb7;gc}.else{gc}"

进入shellcode后,该样本在进行奇怪的jne和call之后(我认为是防止静态分析以及弄乱栈),修改了第0C0000082h号MSR:

</pre>
ffffffff`ffd00201 31c0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xor &nbsp;&nbsp;&nbsp;&nbsp;eax,eax

ffffffff`ffd00203 4090 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xchg &nbsp;&nbsp;&nbsp;eax,eax

ffffffff`ffd00205 7408 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;je &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ffffffff`ffd0020f

ffffffff`ffd0020f e8a7000000 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call &nbsp;&nbsp;&nbsp;ffffffff`ffd002bb

ffffffff`ffd002bb b9820000c0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;ecx,0C0000082h

ffffffff`ffd002c0 0f32 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rdmsr

ffffffff`ffd002c2 48bbf80fd0ffffffffff mov rbx,0FFFFFFFFFFD00FF8h

ffffffff`ffd002cc 895304 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;dword ptr [rbx+4],edx

ffffffff`ffd002cf 8903 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;dword ptr [rbx],eax

ffffffff`ffd002d1 488d050a000000 &nbsp;lea &nbsp;&nbsp;&nbsp;&nbsp;rax,[ffffffff`ffd002e2]

ffffffff`ffd002d8 4889c2 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;rdx,rax

ffffffff`ffd002db 48c1ea20 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;shr &nbsp;&nbsp;&nbsp;&nbsp;rdx,20h

ffffffff`ffd002df 0f30 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;wrmsr

ffffffff`ffd002e1 c3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ret

ffffffff`ffd00214 c3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ret

srvnet!SrvNetCommonReceiveHandler+0xbb:

fffff880`02cec7eb 8be8 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov &nbsp;&nbsp;&nbsp;&nbsp;ebp,eax
<pre>

这样,利用系统原有的系统调用,样本有机会时系统运行到其准备好的shellcode(ffffffff`ffd002e2)处,经实测,在该处下断点会系统崩溃,但是在其后1条指令处下断点,则不会崩溃:


kd&gt; bp ffffffff`ffd002e5

此处开始的shellcode,会寻找内存中的PE格式、定位PE文件头、定位服务表项的位置,最终将服务表项进行hook,但是代码流程的细节需要亲自调试才能看清楚。在此我就不截图了。

 

病毒样本的第二轮发包攻击

先在后门处下断点:

</pre>
kd> dps srv!SrvTransaction2DispatchTable

fffff880`03302760  fffff880`0336c780 srv!SrvSmbOpen2

fffff880`03302768  fffff880`03333b20 srv!SrvSmbFindFirst2

fffff880`03302770  fffff880`03369f40 srv!SrvSmbFindNext2

fffff880`03302778  fffff880`03335650 srv!SrvSmbQueryFsInformation

fffff880`03302780  fffff880`0335ed20 srv!SrvSmbSetFsInformation

fffff880`03302788  fffff880`03333670 srv!SrvSmbQueryPathInformation

fffff880`03302790  fffff880`0336ccb0 srv!SrvSmbSetPathInformation

fffff880`03302798  fffff880`03331420 srv!SrvSmbQueryFileInformation

fffff880`033027a0  fffff880`03332080 srv!SrvSmbSetFileInformation

fffff880`033027a8  fffff880`03353660 srv!SrvSmbFsctl

fffff880`033027b0  fffff880`0336cae0 srv!SrvSmbIoctl2

fffff880`033027b8  fffff880`03353660 srv!SrvSmbFsctl

fffff880`033027c0  fffff880`03353660 srv!SrvSmbFsctl

fffff880`033027c8  fffff880`0335f4f0 srv!SrvSmbCreateDirectory2

fffff880`033027d0  fffffa80`040a3060

fffff880`033027d8  fffff880`03353460 srv!SrvTransactionNotImplemented

&nbsp;

kd> ba e1 fffffa80`040a3060
<pre>

接着,触发第二轮攻击,等待断点触发。以下是行为分析。

 

  shellcode的行为分析

第二轮发送的包,为SMB2协议的包,其timeout项,被作为控制flag。

该域经过计算后,它只有三种值,分别对应了“检查”、“卸载”和“执行程序”,计算公式如下:

域的解析判断部分如下:

在经过ping包后,会执行exec包,执行的程序也包含在(拼接后并解码后的)SMB2包中。其行为为:

1. 找ntoskrnl的基址:

2. 通过hash,找出关键的系统调用

3. 通过遍历PID,获取EPROCESS,在通过比对进程EPROCESS中进程名的HASH值,获取指定的进程PID

 

最后,利用apc注入,将自带的dll注入到指定系统进程中,apc注入看雪中已有相关文章。

Apc的回调函数地址是:

也就是刚才拷贝的apc注入的shellcode,用于内存加载dll,并执行其唯一的导出函数PlayGame,该shellcode及dll我均已经dump出,大家可以从附件下载:

PlayGame运行后,会释放并执行母体,溢出攻击到此结束,但是悲剧将在新的机器上循环上演。

Comments 沒有留言 »

漏洞背景

Samba是在Linux和UNIX系统上实现SMB协议的一个软件,2017年5月24日Samba发布了4.6.4版本,中间修复了一个严重的远程代码执行漏洞,漏洞编号CVE-2017-7494,漏洞影响了Samba 3.5.0 之后到4.6.4/4.5.10/4.4.14中间的所有版本,,确认属于严重漏洞,可以造成远程代码执行。

环境搭建

靶机环境    :                Linux-mint 17 镜像网上随便下内核版本3.13.0-24-generic x86_64

samba版本:                4.1.6-Ubuntu

然后配置smb服务配置
vim /etc/samba/smb.confg

参考其他人分析在末行加入

但是我自己测试 只需要就可以


重新reload smb的配置文件 重启服务
/etc/init.d/samba restart
/etc/init.d/samba reload
有的机器上需要关闭防火墙

/etc/init.d/iptables stop

看当前靶机ip

攻击机环境: kali2017-amd64 .iso         :https://www.kali.org/downloads/  直接安装镜像即可,linux kali 自带metasploit框架,利用起来非常的方便

Exploit_CVE-2017-7494(msf-ruby)        :https://github.com/hdm/metasploit-framework/blob/0520d7cf76f8e5e654cb60f157772200c1b9e230/modules/exploits/linux/samba/is_known_pipename.rb

在攻击机上扫描目标靶机是否445 端口是否打开,因为samba服务开启需要开启445端口

可以看到445和139端口open开启

把down下来的ruby脚本is_known_pipename.rb拷贝至kali机器上的/usr/share/metasploit-framework/modules/exploits/linux/samba/目录下

启动启动msfconsole,并选择使用is_known_pipename模块:

设置目标机ip等,看下配置选项:


开始进行攻击:

可以看到尝试着在靶机的共享目录下上传一个随机字符串生成的so文件,然后就会回连一个shell,看出ip就是靶机的ip

获取一个组ID为root的shell终端。

漏洞代码分析:

官方给出的漏洞补丁可以看出


漏洞出现在source3/rpc_server/srv_pipe.c 的475行中也就是发生在is_known_pipename函数中对传进来的管道名称进行了过滤的处理,如果管道名称中含有了“/”的字符进行了过滤,其实更严格的话应该是判断首个字符串是不是‘/’来判断是否需要过滤,后续会有介绍,那么根据补丁来进行分析肯定管道名称带有’/’会触发漏洞,所以跟进代码看一下

再跟:

继续:

 

以samba-4.5.9.tar.gz源码为例分析:

可以看出参数pipename参数传递过来就是module_name,如果首字符是’/’的话也就是管道的名称的首字符是’/’也就是传过来的是绝对路径的时候,就会跳到load_module函数中,在跟进去就是会加载上传上来的so,而且导出函数

会以SAMBA_INIT_MODULE的函数名进行导出,然后进行执行导出函数,在代码中搜一下可以

#define SAMBA_INIT_MODULE “samba_init_module”

所以上传的so必须要是以samba_init_module函数名导出才可以加载,(但是后续分析ruby exp上传的so在dlopen的时候就会结束,但是会得到反弹shell不知道为什么)

动态gdb跟踪调试:

下载 samba-4.5.9.tar.gz    链接:https://download.samba.org/pub/samba/stable/samba-4.5.9.tar.gz

./configure … –enable-debug

make

安装好对应的依赖,进行编译,因为本机的smbd服务正在运行,要首先stop系统对应的smbd的服务,然后在调试debug的smbd进程

关掉本机的smbd服务

然后进行调试debug版的smbd程序,在源码目录中的bin中smbd,以交互模式和设置配置文件路径进行启动
已经知道是在srv_pipe.c:is_known_pipename函数中,下断点,攻击机这时候发起攻击,因为为了调试所以直接就指定靶机的共享目录  /tmp

在exp  set SMB_SHARE_BASE /tmp

靶机这gdb 跟进:

 

然后跟进函数中:

打印module名称就是从攻击机上上传上来的恶意的so的名称,然后进入到load_module函数中:

然后通过do_smb_load_module->load_module函数中,最后在load_module中加载so,并且导出函数并且执行下图为加载上传的so文件:

然后加载执行,但是这个恶意的so中无论是gdb调试还是正常的运行中都会在dlopen之后退出,然后回弹一个远程shell,不再执行导出函数和执行函数的步骤,这块还不懂怎么回事,希望厉害的人可以解答一下,so就在附件中。

临时解决方案:

在samba的配置文件global节点中添加nt pipe support = 0,即关闭pipe支持(依赖pipe的功能受影响),然后重启服务。

参考链接:

Msf复现Samba远程代码执行漏洞

http://www.4hou.com/technology/4983.html

http://bobao.360.cn/learning/detail/3900.html

http://bobao.360.cn/news/detail/4180.html

https://github.com/omri9741/cve-2017-7494

https://wiki.samba.org/index.php/Build_Samba_from_Source

https://github.com/samba-team/samba/commit/04a3ba4dbcc4be0ffc706ccc0b586d151d360015

 

Comments 沒有留言 »

Comments 沒有留言 »

很早就听闻Ghost的大名,界面简洁,响应速度极快,同时支持多人管理,一直以来没想着把玩,这次记起来就做了这个教程,如有纰漏,欢迎指正。
这是完成后的  http://ghost.jt4b.com

什么是Ghost?

Ghost 是一套基于 Node.js 构建的开源博客平台(Open source blogging platform),
具有易用的书写界面和体验,博客内容默认采用 Markdown 语法书写,目标是取代臃肿的 WordPress。

Linux下Node.js的安装

下载最新的nodejs,这里强烈推荐下载官方已编译好的版本,自行编译比较麻烦,而且容易遇到各种诡异的问题。

wget https://nodejs.org/dist/v5.3.0/node-v5.3.0-linux-x86.tar.gz

下载后解压

tar -xzvf node-v5.3.0-linux-x86.tar.gz

解压后将文件夹放到你认为合适的地方

关联全局

ln -s /home/jt4b/node-v5.3.0-linux-x86/bin/node /usr/local/bin/node
ln -s /home/jt4b/node-v5.3.0-linux-x86/bin/npm /usr/local/bin/npm
ln -s /home/jt4b/node-v5.3.0-linux-x86/bin/n /usr/local/bin/n

这样你就直接能在控制台输入指令了
输入

node -v
npm -v

查看版本

QQ截图20160201202940

安装成功

Ghost的安装以及遇到问题

这里下载的是Ghostchina制作的Ghost 0.7.4中文集成版

wget http://dl.ghostchina.com/Ghost-0.7.4-zh-full.zip
unzip -uo Ghost-0.7.4-zh-full.zip

解压后进入目录,执行

npm install --production

这时居然报错了,运行npm start看看,可以看到

报错

看来是Ghost并不支持最新版本的node,怎么办呢?还好node附带一个非常方便的管理模块n
输入

n 0.10.28

就可以轻松切换到0.10.28版了 (推荐用0.10.21)

此时再执行

npm install --production

就安装成功了。
接下来配置数据库,GHOST默认使用的是SQLite3,这里我们使用MySQL。
创建一个名为ghost的数据库,打开Ghost目录下的config.js,如果没有就拿config.example.js复制一份出来重命名为config.js
Production部分将其修改为

database: {
            client: 'mysql',
            connection: {
                host     : '127.0.0.1',
                user     : 'test',
                password : 'test',
                database : 'ghost',
                charset  : 'utf8'
            },
            debug: false
        }

开启的端口可以自行设置config.js找到如图位置修改

QQ截图20160201201746
这里我将其修改为5555端口 保存后可以输入

npm start

QQ截图20160201203952

可以看到顺利启动了,浏览器输入 http://ip:5555 已经能顺利访问。

但这还不行,因为当你结束会话时,任务就会结束。所以此时就要用到forver了

npm install forever -g

安装forver CD进Ghost目录
运行

NODE_ENV=production forever start index.js

这时Ghost就挂载到forver上了,如果想关闭可以通过

forever stop PID

指令进行。

Nginx反向代理设置

这时已经可以通过IP:5555访问我们的Ghost了,可这样并不便捷也不美观,这里我要将其绑定到我的二级域名ghost.jt4b.com上
控制台输入

vi /usr/local/nginx/conf/nginx.conf

将下列代码添加进去

server {
                listen 80;
                server_name ghost.jt4b.com;

                location ~ {
                proxy_pass http://ip:5555; //自行修改
       }
                access_log /home/wwwroot/jt4b.com/log/ghost.log combined; #access_log end
                error_log /home/wwwroot/jt4b.com/log/ghost.log crit; #error_log end
       }

这里我启用了日志,不想启用可以改成

access_log off; #access_log end
error_log /dev/null; #error_log end

保存后

nginx -s reload

重启nginx
稍等片刻后打开ghost.jt4b.com可以看到已经挂载成功了。

QQ截图20160202014406

Comments 沒有留言 »

来知乎混了一段时间,对于这个人数不算少的群体产生了点儿疑问。 1.对于大多数人来说,就算身边有一个极端爱国的人士,恐怕也会感觉“这人有点儿奇怪”,对于老百姓来说,政治本来就不是生活的主要部分,更遑论极端地爱着日本国了=_=。另,据我出国留学的姐姐说,外国人比中国人更不关心政治。 那么问题来了,在中国的土壤上,中国的百姓群体中,怎么会出现这种极端关心政治的“精神外国人”?这是我第一个不太理解的地方。 2.据我的不完全观察和统计,精日群体普遍对我国政府,甚至是我民族有一种敌视,甚至仇视的态度。不知这是不是我的错觉,如果不是,那么问题来了。 我不知道日本的道德标准怎样,但窃以为“君子绝交不出恶言”无论在哪都是种美德,就算由于一些原因敌视中国政府可以理解,但对于我国人民的敌视就让人有些困惑了,想出国没什么不可以,窃以为想改国籍也属于个人选择,但没必要做到这样吧?那些整天嘴边挂着“贵国,贵民族”的人是什么心态?这是我第二个不理解的地方。 3.就算由于政治原因厌恶我国政府,向往民主,那美国应该更合适啊,无论国力还是体制,美国都比日本要优秀,就算不哈美,世界上大把大把的民主发达国家,为何没有像“精日”一样形成一个有一定规模的群体呢?这是我第三个不了解的地方。 另外,我无意挑衅日本人民(或者说不是主要目的),只是单纯地对这个问题有些好奇,希望有人能帮我解答。

著作权归作者所有。
商业转载请联系作者获得授权,非商业转载请注明出处。
作者:字芥川
链接:https://www.zhihu.com/question/28575864/answer/73385267
来源:知乎

有些答案真是揣着明白装糊涂啊。精日和普通的对日文化or二次元爱好者,你当别人看不出吗?我在知乎也关注了结识了几个在日留学的大V,他们对日本文化和生活中优秀的部分自然肯定,但对其中不足也不否认。既不需要对日本美化,也无需靠贬低中国替日本抬高身价。我怎么没见有人说他们都是精日?呵呵,你们自己装鸵鸟,就说别人是树靶子,你眼拙也当别人不知道你是什么生物么?我来告诉你,为什么会有人被称为精日:有些人,谈及南京大屠杀,基本就是日本右翼的说辞,甚至有过之而无不及,仿佛侵略屠城是天然正义;中国似乎死的有点少了嘛;加强版可以见精神坂大留学生关于天津爆炸的微博奇葩言论。作为二战战败国,国际秩序所要打压的对象,日本的旧天皇体制是绝对受到批判的;而在某些生物眼里,宛若维新志士一样,似要山呼天皇万岁;喜爱日本优越发达的生活条件,我权且当你是嫌贫爱富也罢,单纯追求个人生活惬意也罢,都无可厚非。但是从简单的物质条件直接“升华”到人性,从而强行批判乃至发泄仇恨一般攻击中国,你们的想象力是如此的跃进迅速,你们的逻辑是如此跳跃和令人赞叹;把一个战败国的突破现国际秩序行为拔高到无以复加,你难道不觉得你在打你美国爸爸的脸么?美帝的原子弹是白放的咯?当天上的流星么?嗯,我到的确挺希望那里来一场“流星雨”的。不要装了,你以为别人都是傻子么。普通的个人出于生活和兴趣的喜好,和你们上升至民族,国家,乃至人种的“喜好”,能一样么。至于精日典型,知乎上多了去了。有山西某大学梦中留学坂大的“精神留学生”,有以自称洗地专业人士的护照爱好者;也有没去过日本就认日本作精神故土的“前世盛唐日本人”。更好笑的是,某些中国很有良心的“国际主义反法西斯”战士的对日态度,仿佛几十年前战败国和法西斯肇乱者是中国一样,中国纪念反法西斯都可以伤及他们精神母国的情感。我说,连日本人也不好意思颠倒法西斯对战两方吧。你们不是洗地,你们简直就是在给日本整容换皮。防卫省怎么没把你们招募进去呢。嘛,不过也是,发了这么多帖子,连归化都没成功(去没去过日本我就更不知道啦哈哈),何谈入防卫省效力呢?多说一句,知乎可以算得上是在华对日态度最亲善的社区了。(此处内容被知乎官方认定不友善hhhh,看过的网友可以在评论区贴出~你跟我说大家都是看走眼了?是啊,我的确是看走眼了。你说这好好的人不做,为嘛要去做**呢。

Comments 沒有留言 »

其实这是09年的东西了,比较简单的变形壳,是我当时申请LCG时的考题。最近无意中被我从邮箱内翻出来了,同时又联想到最近fly兄的unpack论坛永久关闭的消息,权当对逝去青春的祭奠了。

考题

111

脱文
1.修复 oep stolen code
到OEP很简单 ESP定律 shift+f9 2次只接到OEP
有2种方法修复oep stolen code 1种去掉花指令 把代码补到OEP前 2就是整理代码后直接此处DUMP
整理下代码大概是

004C5C0D    55              push    ebp
004C5C11    8BEC            mov     ebp, esp
004C5C16    83C4 F0         add     esp, -10
004C5C1C    B8 D8D44900     mov     eax, 0049D4D8
004C5C24    E8 8305F4FF     call    004061AC
004C5C29    A1 DCF44900     mov     eax, dword ptr [49F4DC]
004C5C31    8B00            mov     eax, dword ptr [eax]
004C5C36    E8 5529F9FF     call    00458590
jmp     0049D7F4               //跳向的是FOEP

我比较懒选择后者 修复后DUMP下来
2.dump iat and fix

首先OD加载 停在

004C5087 >  60              pushad                                   ;

前几句就有花 但是总体看上去是PESPIN 先设置 除了Invalid or privileged instruction之外其他全选
按2次SHIFT+F9 下断 bp LoadLibraryA SHIFT+F9 取消断点后 ALT+F9回程序领空

004C5A4D    85C0            test    eax, eax                         ; kernel32.7C800000
004C5A4F    0F84 28060000   je      004C607D
004C5A55    50              push    eax
004C5A56    E8 C5FCFFFF     call    004C5720
004C5A5B    2BD2            sub     edx, edx
004C5A5D    F9              stc

004C5A4D 处停下 向下到 004C5AA6 处F4 CTRL+F9 到达

004C579E    60              pushad
004C579F    0BFF            or      edi, edi
004C57A1    75 16           jnz     short 004C57B9
004C57A3    8B9D D9224000   mov     ebx, dword ptr [ebp+4022D9]
004C57A9    2D 01000000     sub     eax, 1
004C57AE    8B0483          mov     eax, dword ptr [ebx+eax*4]
004C57B1    0385 D1224000   add     eax, dword ptr [ebp+4022D1]
004C57B7    EB 72           jmp     short 004C582B
004C57B9    8B9D D5224000   mov     ebx, dword ptr [ebp+4022D5]
004C57BF    8A47 FF         mov     al, byte ptr [edi-1]
004C57C2    24 7F           and     al, 7F
004C57C4    8885 2B234000   mov     byte ptr [ebp+40232B], al
004C57CA    FF37            push    dword ptr [edi]
004C57CC    8F85 34234000   pop     dword ptr [ebp+402334]
004C57D2    2BC9            sub     ecx, ecx
004C57D4    80BD E5264000 C>cmp     byte ptr [ebp+4026E5], 0CC
004C57DB    75 05           jnz     short 004C57E2
004C57DD    74 01           je      short 004C57E0
004C57DF    68 8BEC8B3B     push    3B8BEC8B
004C57E4    03BD D1224000   add     edi, dword ptr [ebp+4022D1]

花指令有点多 清理下后就清楚多了
F4运行到 004C57EF E8 1B0B0000 call 004C630F
向下

004C5833   /76 35           jbe     short 004C586A
004C5835   |03BD C9224000   add     edi, dword ptr [ebp+4022C9]
004C583B   |3BF8            cmp     edi, eax
004C583D   |76 2B           jbe     short 004C586A

改为

004C5833   /EB 35           jmp     short 004C586A
004C5835   |03BD C9224000   add     edi, dword ptr [ebp+4022C9]
004C583B   |3BF8            cmp     edi, eax
004C583D   |EB 2B           jmp     short 004C586A

向下

004C5877    C3              retn 处F4

继续向下看
分析下去 来到

004C5B20    FF6424 FC       jmp     dword ptr [esp-4]

这里壳开始猥琐IAT了 住手 – -||!
修改为

jmp      004C5B73
004C5B73    8902            mov     dword ptr [edx], eax

这样就跳过了IAT加密 拿IMREC dump下地址就填004C5C0D 抓取后发现指针全为真
FIXED主程序后正常运行 over~~~~~

注:因为是以前的东西,win7以上系统可能会存在兼容问题
原题文件

脱壳后文件

Comments 沒有留言 »

1.半条命3

11029270_531550

2.月姬重制Remake and 月姬2

3ad60ff7905298227c54a308d7ca7bcb0846d48f

3.全金属狂潮

t015bb04e2c7728f45a

Comments 沒有留言 »

Comments 沒有留言 »

标 题: 【原创】VEH-硬件断点+dll劫持内存补丁
作 者: 我是小三
时 间: 2013-06-26,08:28:34
链 接: http://bbs.pediy.com/showthread.php?t=174263

学习加密三内存补丁一节时做的。高手莫要见笑. 下面是用了加密三中的CrackMeNet.exe做的示范.

代码:

//设置硬件断点函数
void SetHwBreakpoint()
{


//添加VEH  参数1=1表示插入Veh链的头部,=0表示插入到VEH链的尾部
AddVectoredExceptionHandler(1, VectoredHandler);

//寄存器相关的结构体
CONTEXT _ConText = {CONTEXT_DEBUG_REGISTERS};

//得到当前线程
HANDLE hThread = GetCurrentThread();


// 得到指定线程的环境(上下文)
GetThreadContext(hThread, &_ConText);


//给调试寄存器值
if (0X0 == _ConText.Dr0 && 0X0 == _ConText.Dr1 && 0X0 == _ConText.Dr2)
{
_ConText.Dr0 = 0X00401489;
_ConText.Dr1 = 0X0;
_ConText.Dr2 = 0X0;
_ConText.Dr3 = 0x0;

_ConText.Dr7 = 0x405;


// 设置线程的环境(上下文)
SetThreadContext(hThread, &_ConText);
}


if (0X0 != _ConText.Dr0 || 0X0 != _ConText.Dr1 || 0X0 != _ConText.Dr2 || 0X0 != _ConText.Dr3)
{
MessageBox(NULL,"设置硬件断点成功..", "(^_^)", MB_OK);
}
else
{
MessageBox(NULL,"设置失败,", "提示", MB_OK);
}

}

代码:

// VEH回调函数
LONG WINAPI VectoredHandler(
PEXCEPTION_POINTERS ExceptionInfo
)
{


//判断是否为我们设置的异常地址
if(ExceptionInfo->ExceptionRecord->ExceptionAddress == (PVOID)0X00401489)
{
MessageBox(NULL, "成功触发异常", "(^_^)", MB_ICONINFORMATION);

// 修改当前异常中断的EIP
ExceptionInfo->ContextRecord->Eip = 0x00401721;//指向要执行代码的内存地址

// 处理异常.
return EXCEPTION_CONTINUE_EXECUTION;
}

return EXCEPTION_CONTINUE_SEARCH;
}

代码:

ALCDECL MemCode_connect(void)
{

SetHwBreakpoint();//调用设置硬件断点

GetAddress("connect");
__asm JMP EAX;
}

代码:

00401474  |.  6A 10         push 10                                  ; /AddrLen = 10 (16.)
00401476  |.  8D85 B0FDFFFF lea eax,[local.148]                      ; |
0040147C  |.  50            push eax                                 ; |pSockAddr
0040147D  |.  8B8D 00FEFFFF mov ecx,[local.128]                      ; |
00401483  |.  51            push ecx                                 ; |Socket
00401484  |.  E8 43050000   call <jmp.&WS2_32.#4>                    ; \connect
00401489  |.  8985 04FEFFFF mov [local.127],eax                      ;  --设置异常地址
0040148F  |.  83BD 04FEFFFF>cmp [local.127],-1

代码:

00401721  |.  8BF4          mov esi,esp                              ;  ---异常发生后直接跳到这里执行.
00401723  |.  6A 00         push 0                                   ; /Style = MB_OK|MB_APPLMODAL
00401725  |.  68 887A4100   push CrackMeN.00417A88                   ; |Title = "Crackne net-2"
0040172A  |.  68 987A4100   push CrackMeN.00417A98                   ; |Text = "Registration successful !"
0040172F  |.  8B15 90B14100 mov edx,dword ptr ds:[41B190]            ; |
00401735  |.  52            push edx                                 ; |hOwner => 001D016C ('Pediy - Crackme (net) 20061204',class='myWindowClass')
00401736  |.  FF15 D0D34100 call dword ptr ds:[<&USER32.MessageBoxA>>; \MessageBoxA

 

名称:  3.jpg
查看次数: 3
文件大小:  16.7 KB
bin.rar.
vs2008_src.rar.

 

 

在08年初有想过剑走偏锋,利用类似debug api的方法来规避部分游戏检测机制,事实证明和之后的一些人想到一块去了。

Comments 沒有留言 »

他想要做笔免费的买卖。即不用花钱,又可以攫取上帝的心。便宜地登上天堂的同时又免费获得了慈善家的称号。但即便如此,他仍然不是一无是处。不可救药的是那些因无知而作恶的人。

Comments 沒有留言 »