潜藏在UPX壳中的隐患
2015-06-02 15:30
267 查看
楔子
今天在写<反病毒工具系列-OllyDBG>时,在示例中准备演示如何为一个加有标准UPX壳的程序脱壳.因为笔者接触到的”最危险”的病毒都使用了原版upx.学习手脱UPX壳是十分重要的.就在此时突然发现这种行为是多么的危险.通常一个程序被认为加了UPX壳的直观依据:
过去的手法
人们遇到UPX壳通常会直接在主机环境中用upx自己的解压缩工具直接解压缩或者手动脱壳.但是这样的行为十分危险.你如何知道对方是真的UPX壳呢?
因为它的开头吗?
潜藏的威胁
UPX解压工具可能拥有某些漏洞.因为UPX解压工具把目标文件当成一个普通的需要加载到内存并解压的文件.反病毒人员通常会把popad后即UPX自解压段结束的时候视为可能有威胁的时候,而在这之前默认为安全的时间.这种默认行为导致了漏洞的产生.在这个被人为特权运行的范围内,黑客可能借助此干出任何事情就像你直接运行它那样.
而这个伪装自己绕过反病毒工程师调试的程序,通常是一个有着严重威胁的程序,而反病毒工程师却对它的运行状态一无所知,以为尽在自己的掌握之中.
最大的威胁就在最熟悉的事物中.防范由此导致种种危机的方法,早就被前人实践了,就像下面这样:
Google的一项名为BeyondCorp的行动,其基本假设是——内部网络实际上跟互联网一样危险,废弃防火墙:Google决定不再区分内外网
祸患常常在被认为最安全的地方发生,最好的防止方法就是不要人为设置所谓的”安全”之时之地.
相关文章推荐
- sequelize的使用
- 图片如何实现滑动效果
- Ctrl + C无效 SIGINT -- trap
- HDU 2112
- 计算机视觉和图形学中的摄像机内参数矩阵详解
- 源码阅读 4 Hummingbird-for-Android
- iOS程序在后台进行任务的方法
- jQuery学习笔记2--表格内容筛选
- C# windows store socket:unknown system invalid operation exception 在意外的时间
- [SQLite3]connection string的连接池参数引发的错误
- Android如何在初始化的时候获取加载的布局的宽高
- 关于python的threading.Thread.daemon 与 multiprocessing.Process.daemon的疑问
- shell 脚本if 逻辑判断判断
- [系统级] 线程入口函数作为类成员
- ireport中的几个小问题
- 在Ireport4.0.1下实现PDF中文报表
- 天气预报数据API
- MiniTwitterSimulate的登陆页面
- linux free 命令中的 buffer & free
- Python:itertools模块