ChinaUnix.net 首页 | 博客 | Linux | 论坛 | 人才 | 培训 | 知识库 | 资料 | 读书 | 手册 | 精华 | 下载 | 沙龙 | 搜索
Linux首页 | Linux论坛 | 论坛精华 | 开源新闻 | 技术文章 | 专题专栏 | 新手指南 | 迁移方案 | 产品方案 | 开源项目 | 开源图书 | 软件下载 | 人才招聘 | Linux博客
  搜索

  产品与方案
·中科红旗全面打造现代化邮政体系
·红旗助力“网上审批服务” 推动电子政务
·红旗正版化开创呼和浩特网吧建设新起点
·红旗Linux助信息产业部邮件服务器“快跑”
·中标普华Linux 为电子政务信息化保驾护航
·中标普华Linux助力基金产业
·中标普华Office率先支持UOF标准
·中标普华邮件系统助力西藏政府信息化建设
·红旗Linux助力国库集中支付系统改革
·红旗助中信卫星 掀起GIS通信应用风暴
·红旗软件助力烟草总局 全面建设“数字烟草”
·红旗助力“信访阳光工程”打造畅通信访渠道
·红帽联合FIS发布下一代实时核心银行平台
·红旗助力金盾 打造全无忧出入境信息系统
·红旗Linux全力打造中国邮政总局名址信息库
·爱尔兰证交所从Unix迁移到红帽企业Linux
·一流的意大利银行选择使用红帽企业Linux
·PLUS Finanzservice选择使用红帽企业Linux
·红帽助力TransACT Communications 公司
·法国零售业巨头Lapeyre采用Redhat Linux
·旅游预订网站选择使用红帽企业Linux
·马哈拉施特拉邦政府的红帽解决之道
·美国联邦政府案例
·红帽为慕尼黑展览会提供现代化集群系统
·Yuba郡用开源软件和红帽产品提高了效率
·红帽企业Linux助印度理工建立高性能计算中心
·采用红帽Linux 将系统维护时间缩短了65%
·从UNIX迁移到Linux使Peñoles公司获益非浅
·Hikal公司用红帽企业Linux开展任务关键的ERP项目
·KDE3.5.4新版本发布
·芝加哥商业交易所从Unix向Linux迁移
·南方基金管理有限公司成功案例 Red Hat Linux
·广东北电通讯设备有限公司成功案例
·挪威国家石油公司从UNIX迁移到红帽Linux,成本减半
·中央电视台CCTV动画部案例 Red Hat Linux

  图书

鸟哥的Linux私房菜基础学..


Linux程序设计.第3版


Linux设备驱动开发详解


  下载
·Endian Firewall
·linux kernel(Linux 内核)
·CentOS
·Fedora Core 6
·Scientific Linux
·Slackware 11.0
·Gentoo Linux
·ubuntu-6.10-i386服务器版本
·ubuntu-6.10-amd64服务器版
·ubuntu-6.10-i386桌面版
·ubuntu-6.10-amd64桌面版
·Engarde Linux
您的位置: Linux时代 > 技术文档 > 内核研究 >

简析Linux与FreeBSD的syscall

日期:2006-10-17 作者:7all 来自:bbs.cciss.cn


  --]概述

  又是一个不眠的夜晚,其实这篇文档是不应该发表的,因为保密的原则吧,但是我仔细

  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的不同之处,真正要写的话,估计还得整整的一篇内容.但是...人是铁饭是钢,一顿不吃

  饿的慌.于是准备做下逃兵,先去添饱肚子,然后美美的睡一觉.顺便做个美梦,在梦中,偶的"老大"又开始欺负偶了...

本文被浏览



 相关新闻

Linux 2.6 新增的 vsyscall 系统服务调用机制2005-02-01 13:46:52


 相关评论
关于我们 | 联系方式 | 广告合作 | 诚聘英才 | 网站地图 | 免费注册

Copyright © 2001-2006 ChinaUnix.net All Rights Reserved

感谢所有关心和支持过ChinaUnix的朋友们

京ICP证041476号