又是一个不眠的夜晚,其实这篇文档是不应该发表的,因为保密的原则吧,但是我仔细
google了下,没有类似的文章,而且发表的这部分文档也不至于被认为是什么绝密资料,
但是我还是隐藏了很多发现的内核级别可能存在的问题:)单纯从汇编代码的结构来阐述
下linux与freebsd到底那个更好玩一些.或者说那个运行速度会更快一些:)
我想大家看完这个文档以后,或许会知道到底是Linux稳固?还是FreeBSD稳固?
在本文的最后部分,附加了shellcode的问题,但没有专门的论述.
备注:本文观点仅代表个人观点,如有不对的地方,欢迎大家指正:)以提高本人的水平.
--]编译调试
A:编译选项
Linux :gcc -gdwarf-2 ***.c -o ***
FreeBSD: cc -gdwarf-2 ***.c -o ***
为了调试方便,我使用了上面的选项.
--------------------------------------
对于一般书写shellcode的编译选项一般为:
Linux :gcc -static -o *** ***.c
FreeBSD: cc -static -o *** ***.c
B:调试工具
Linux/Unix下面的调试工具为GDB,但是GDB基于内核的调试有些力不从心,因为GDB的调试是
基于用户模式(User mode).
这里我使用了其它的调试工具,所以下面大家看到的调试代码比较特殊,在这里事先声明.
--]Linux的syscall跟踪
写过shellcode的人都知道syscall是写shellcode的必需品:)当然这种概念只在Linux/Unix
的OS下才存在.最近这段时间因为一个"小小的问题"对Linux内核与FreeBSD的内核级别进行了
跟踪和调试,然后发现一个蛮有意思的问题,自己感觉这个问题可能会与Linux下shellcode与
FreeBSD下shellcode的不同有关系,当然也和系统架构存在一些细微的关系.下面的内容是Linux
下面syscall的一些汇编代码.
在Linux下面,Application调用syscall的代码如下:
420D4330 55 PUSH EBP |
420D4331 89E5 MOV EBP,ESP |->堆栈框架
420D4333 83EC18 SUB ESP,00000018 |
420D4336 897DFC MOV dword ptr [EBP]-04,EDI |
420D4339 8B4D0C MOV ECX,dword ptr [EBP]+0c |
420D433C 8B7D08 MOV EDI,dword ptr [EBP]+08 |->syscall参数
420D433F 8975F8 MOV dword ptr [EBP]-08,ESI |
420D4342 8B5510 MOV EDX,dword ptr [EBP]+10 |
420D4345 895DF4 MOV dword ptr [EBP]-0c,EBX
420D4348 E81014F4FF CALL near32 ptr 4201575d
420D434D 81C3835F0500 ADD EBX,00055f83
420D4353 8D77FF LEA ESI,dword ptr [EDI]-01
420D4356 83FE02 CMP ESI,00000002
420D4359 8D75F0 LEA ESI,dword ptr [EBP]-10
420D435C 0F477514 CMOVA ESI,dword ptr [EBP]+14
420D4360 53 PUSH EBX
420D4361 89FB MOV EBX,EDI
420D4363 B81A000000 MOV EAX,0000001c //system call number value
420D4368 CD80 INT 80 //调用0x80
420D436A 5B POP EBX
420D436B 3D00F0FFFF CMP EAX,fffff000
420D4370 89C6 MOV ESI,EAX
420D4372 760E JBE short ptr 420d4382
420D4374 F7DE NEG ESI
420D4376 E8C912F4FF CALL near32 ptr 42015644
420D437B 8930 MOV dword ptr [EAX],ESI
420D437D BEFFFFFFFF MOV ESI,ffffffff
420D4382 85F6 TEST ESI,ESI
420D4384 782A JS short ptr 420d43b0
420D4386 85FF TEST EDI,EDI
420D4388 7426 JE short ptr 420d43b0
420D438A 83FF03 CMP EDI,00000003
420D438D 7721 JA short ptr 420d43b0
420D438F E8B012F4FF CALL near32 ptr 42015644
420D4394 C70000000000 MOV dword ptr [EAX],00000000
420D439A 8B45F0 MOV EAX,dword ptr [EBP]-10
420D439D 8B5DF4 MOV EBX,dword ptr [EBP]-0c
420D43A0 8B75F8 MOV ESI,dword ptr [EBP]-08
420D43A3 8B7DFC MOV EDI,dword ptr [EBP]-04
420D43A6 89EC MOV ESP,EBP
420D43A8 5D POP EBP
420D43A9 C3 RETN
---------------------------------------------------------------------
为了简单分析,我们就看这里的代码:
420D4330 55 PUSH EBP |
420D4331 89E5 MOV EBP,ESP |->堆栈框架
420D4333 83EC18 SUB ESP,00000018 |
420D4336 897DFC MOV dword ptr [EBP]-04,EDI |
420D4339 8B4D0C MOV ECX,dword ptr [EBP]+0c |
420D433C 8B7D08 MOV EDI,dword ptr [EBP]+08 |->syscall参数
420D433F 8975F8 MOV dword ptr [EBP]-08,ESI |
420D4342 8B5510 MOV EDX,dword ptr [EBP]+10 |
420D4345 895DF4 MOV dword ptr [EBP]-0c,EBX
420D4348 E81014F4FF CALL near32 ptr 4201575d
420D434D 81C3835F0500 ADD EBX,00055f83
420D4353 8D77FF LEA ESI,dword ptr [EDI]-01
420D4356 83FE02 CMP ESI,00000002
420D4359 8D75F0 LEA ESI,dword ptr [EBP]-10
420D435C 0F477514 CMOVA ESI,dword ptr [EBP]+14
420D4360 53 PUSH EBX
420D4361 89FB MOV EBX,EDI
420D4363 B81A000000 MOV EAX,0000001c //system call number value
420D4368 CD80 INT 80 //调用0x80
----------------------------------------------------------------------
当然从上面的代码,我们只能看到Linux在更深的一层调用syscall的一个汇编代码过程,换句话
说,可能上面的这些代码都是废话:)OK,我们继续看下面的内容.
--]FreeBSD的syscall
FreeBSD下面的syscall我进行了两次跟进的操作才进入到内部,所以下面使用了两个过程来演示
代码,不过从下面的代码来看FreeBSD的短了很多很多:)
trace into one step:
28080D98: 31C0 XOR EAX,EAX
28080D9A: 53 PUSH EBX
28080D9B: E800000000 CALL near32 ptr 28080da0
-------------------------------------------------------------------
trace into two step:
28080DA0: 5B POP EBX
28080DA1: 81C3AC980600 ADD EBX,000698ac
28080DA7: 8B934C0A0000 MOV EDX,dword ptr [EBX]+00000a4c
28080DAD: 8902 MOV dword ptr [EDX],EAX
28080DAF: 5B POP EBX
28080DB0: 8D051A000000 LEA EAX,dword ptr [0000001c]//system call number value
28080DB6: CD80 INT 80
28080DB8: 7201 JC short ptr 28080dbb
28080DBA: C3 RETN
--------------------------------------------------------------------
从上面的代码来看,FreeBSD的syscall代码比Linux的短了很多很多,但是仅仅是短还是不够的,如果在看
这个文档前你熟悉破解技术 or 溢出技术 or Intel汇编语言.我想可能大家有这样的感觉,FreeBSD的调用
syscall的过程比Linux的要安全了很多很多,为什么这么说呢?请再返回仔细看上面的Linux/FreeBSD的汇
编代码:)下面我们也会大概的论证下,但仅仅是猜测而已:)
--]FreeBSD比Linux安全?
学过破解技术的朋友,都知道通过一些跳转指令来实现对于软件的破解,当然使用跳转指令可能仅仅对一些
简单的软件是有用处.突然发现我上面说的这句话是废话,和本文没有任何的关系,郁闷...看来脑袋里面装的
东西多也不是什么好事情:(
言归正传,我们来大体的分析下为什么说BSD比Linux要安全些!请看下面的代码:
Linux的syscall调用:
420D4336 897DFC MOV dword ptr [EBP]-04,EDI |
420D4339 8B4D0C MOV ECX,dword ptr [EBP]+0c |
420D433C 8B7D08 MOV EDI,dword ptr [EBP]+08 |->syscall参数
420D433F 8975F8 MOV dword ptr [EBP]-08,ESI |
420D4342 8B5510 MOV EDX,dword ptr [EBP]+10 |
-----------------------------------------------------------------------------
420D435C 0F477514 CMOVA ESI,dword ptr [EBP]+14 |
420D4360 53 PUSH EBX |->syscall参数
420D4361 89FB MOV EBX,EDI |
420D4363 B81A000000 MOV EAX,0000001c //system call number value
420D4368 CD80 INT 80 //调用0x80
-----------------------------------------------------------------------------
从上面的代码我们可以看到这样一种情况,这里我们假设调用系统函数write来写输出:)
write(filehandle, buf, buf_length)
其汇编代码的函数调用,基本如下:
push buf_length
push buf
push filehandle
call write
然后进入到write函数后,我们就知道Linux的syscall的一个完整过程如下:
高级语言调用系统函数|
->jump syscall(即系统对系统函数的标识)|
->把syscall的参数赋给寄存器|
->mov eax,0x**(及上面write函数针对syscall的数值)|
->int 0x80|
->返回|
基本过程如上所示,那么如果我们spoof(欺骗)这些传递参数的寄存器呢?假设spoof是成功的,
那么很容易就会把一些坏变量值传递到syscall的系统调用,紧接着系统内核可能在接收到一些
坏信息的时候,处理不当,导致系统出现异常或者系统发生溢出.当然这些仅仅是猜测,本文的很
多内容都是在猜测,至于答案嘛,可能永远都没有...:)
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
FreeBSD的syscall调用:
28080D98: 31C0 XOR EAX,EAX
28080D9A: 53 PUSH EBX
28080D9B: E800000000 CALL near32 ptr 28080da0
28080DA0: 5B POP EBX
28080DA1: 81C3AC980600 ADD EBX,000698ac
28080DA7: 8B934C0A0000 MOV EDX,dword ptr [EBX]+00000a4c
28080DAD: 8902 MOV dword ptr [EDX],EAX
28080DAF: 5B POP EBX
28080DB0: 8D051A000000 LEA EAX,dword ptr [0000001c]//system call number value
28080DB6: CD80 INT 80
28080DB8: 7201 JC short ptr 28080dbb
28080DBA: C3 RETN
从上面的代码我们也可以看到这样一种情况,这里我们假设调用系统函数write来写输出:)
write(filehandle, buf, buf_length)
其汇编代码的函数调用,基本如下:
push buf_length
push buf
push filehandle
call write
然后进入到write函数后,我们就知道Linux的syscall的一个完整过程如下:
高级语言调用系统函数|
->jump syscall(即系统对系统函数的标识)|
->mov eax,0x**(及上面write函数针对syscall的数值)|
->int 0x80|
->返回|
根据我的跟踪分析,发现FreeBSD使用了程序里面的参数变量,这样的情况就是FreeBSD省去了一个寄存器调用
函数参数的过程,这样就禁止了可能存在spoof寄存器的问题,从这点上来看,FreeBSD的确比Linux要安全很多.
------------------------------------------------------------------------------------------------
虽然Linux的这个syscall会调用寄存器保存参数值,可能有其好处(最起码我感觉看代码和分析一些内核的时,
舒服了很多:)),但是如果有些高人能够spoof寄存器,那么可能会引起一些麻烦,当然这样的麻烦还需要和特定的
程序挂钩,不是说spoof就spoof成功的:)
FreeBSD的就优良了很多,我不得不佩服FreeBSD的优点,开始的时候我也经常被FreeBSD这样的调用方式搞的头大
的厉害,但是就这么看啊看的,反而习惯了.在之前的时候,一直是一段时间Linux,一段时间BSD;只有在最近交叉跟
踪的时候,才发现上面这个自己感觉比较有意思的问题:)
--]FreeBSD的程序比Linux的运行速度快?
这个问题很难说,如果从上面的代码来看的话,少了这么多的汇编代码,说FreeBSD比Linux慢估计谁都不会相信的.
当然我没有针对FreeBSD的系统架构与Linux的系统架构进行更深入的对比分析,所以也不敢枉自下如此不清晰的结
论:)如果那位有兴趣,能不能在相同的硬件平台下,对这俩OS做下测试?
再继续罗嗦一个问题,虽然FreeBSD比Linux少了些汇编代码,但是syscall的参数FreeBSD肯定也是获取的,只不过
获取的方式比Linux更直接了一些:)
--]FreeBSD与Linux的shellcode
先废话一下,说到syscall如果不说些shellcode的故事,好像的确是少了那么一点点事情...So,我们来看看FreeBSD
与Linux的shellcode.我书写了一些简单的shellcode,看到网上很多关于shellcode的中文教程都是拿GDB不断调试出
来的,感觉好麻烦:(个人认为既然熟悉GDB调试技术,肯定熟悉汇编,也肯定熟悉syscall,不熟悉找下头文件看看不就得
了...于是我一直用汇编来写这些可爱的shellcode,刚学会几天,不对的地方大家明示:)
到底是先说FreeBSD的shellcode,还是先说Linux的呢?我拿硬币抛了下,至于为什么抛硬币...困了...找点刺激自己
神经的方法:)).好了,硬币抛完了,先说FreeBSD下面的.
编译:nasm -f elf ***.asm
ld -s -o *** ***.o
A: FreeBSD下面的shellcode(hello.asm):
section .text
global _start
_start:
xor eax,eax
cdq
push 0x0a216472
push 0x6f57206f
push 0x6c6c6548
mov ebx,esp
push byte 0xc
push ebx
push byte 0x1
push eax
mov al,0x4
int 0x80
xor eax,eax
push eax
mov al,0x1
int 0x80
------------------------------------------------------------------------------------------------
上面的的汇编代码可以直接编译来获取shellcode,按照前面说的编译办法编译,然后:
objdump -D hello > hello.txt
把获得的机器码copy出来就是一个freebsd下面的shellcode了.
B: Linux下面的shellcode(hello.asm):
global _start
_start:
xor eax,eax
jmp short string
code:
pop esi
push byte 15
push esi
push byte 1
push eax
int 0x80
xor eax,eax
push eax
push eax
mov al,1
int 0x80
string:
call code
db "Hello word!", 0x0a
------------------------------------------------------------------------------------------------
上面的的汇编代码可以直接编译来获取shellcode,按照前面说的编译办法编译,然后:
objdump -D hello > hello.txt
把获得的机器码copy出来就是一个linux下面的shellcode了.
C: 为什么FreeBSD与Linux下面的shellcode不同?
这个问题,我想留给大家先思考下,然后再看我的下文.如果你看了我的下文还是不了解的话...那么可能的情况
是你根本还不会汇编和Unix类型的编程...还有一个情况是,你太笨了:(
C-1: Linux的syscall的系统调用是如下的过程:
高级语言调用系统函数|
->jump syscall(即系统对系统函数的标识)|
->把syscall的参数赋给寄存器|
->mov eax,0x**(及上面write函数针对syscall的数值)|
->int 0x80|
->返回|
那么,我们的shellcode在push参数的时候,就比较随便一些了,因为在后面的系统级别的syscall又对参数进行了二
次的赋值,赋值给各个寄存器,然后才调用syscall.
C-2: FreeBSD的syscall系统调用是如下的过程:
高级语言调用系统函数|
->jump syscall(即系统对系统函数的标识)|
->mov eax,0x**(及上面write函数针对syscall的数值)|
->int 0x80|
看到没有,或者说前面的内容记忆起来了吧?freebsd的syscall调用是在进入系统syscall前就push进来的,所以我们的
shellcode必须得把参数的值先push进来,而不是象linux那样的随意.
--]总结
其实,最后这部分关于shellcode的不同之处,真正要写的话,估计还得整整的一篇内容.但是...人是铁饭是钢,一顿不吃
饿的慌.于是准备做下逃兵,先去添饱肚子,然后美美的睡一觉.顺便做个美梦,在梦中,偶的"老大"又开始欺负偶了...
自由广告区 |
分类导航 |
邮件新闻资讯: IT业界 | 邮件服务器 | 邮件趣闻 | 移动电邮 电子邮箱 | 反垃圾邮件|邮件客户端|网络安全 行业数据 | 邮件人物 | 网站公告 | 行业法规 网络技术: 邮件原理 | 网络协议 | 网络管理 | 传输介质 线路接入 | 路由接口 | 邮件存储 | 华为3Com CISCO技术 | 网络与服务器硬件 操作系统: Windows 9X | Linux&Uinx | Windows NT Windows Vista | FreeBSD | 其它操作系统 邮件服务器: 程序与开发 | Exchange | Qmail | Postfix Sendmail | MDaemon | Domino | Foxmail KerioMail | JavaMail | Winwebmail |James Merak&VisNetic | CMailServer | WinMail 金笛邮件系统 | 其它 | 反垃圾邮件: 综述| 客户端反垃圾邮件|服务器端反垃圾邮件 邮件客户端软件: Outlook | Foxmail | DreamMail| KooMail The bat | 雷鸟 | Eudora |Becky! |Pegasus IncrediMail |其它 电子邮箱: 个人邮箱 | 企业邮箱 |Gmail 移动电子邮件:服务器 | 客户端 | 技术前沿 邮件网络安全: 软件漏洞 | 安全知识 | 病毒公告 |防火墙 攻防技术 | 病毒查杀| ISA | 数字签名 邮件营销: Email营销 | 网络营销 | 营销技巧 |营销案例 邮件人才:招聘 | 职场 | 培训 | 指南 | 职场 解决方案: 邮件系统|反垃圾邮件 |安全 |移动电邮 |招标 产品评测: 邮件系统 |反垃圾邮件 |邮箱 |安全 |客户端 |