GPU恐成最大帮凶未来病毒运行技术前瞻.docx

上传人:b****2 文档编号:13903476 上传时间:2023-06-19 格式:DOCX 页数:8 大小:23.24KB
下载 相关 举报
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第1页
第1页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第2页
第2页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第3页
第3页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第4页
第4页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第5页
第5页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第6页
第6页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第7页
第7页 / 共8页
GPU恐成最大帮凶未来病毒运行技术前瞻.docx_第8页
第8页 / 共8页
亲,该文档总共8页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

GPU恐成最大帮凶未来病毒运行技术前瞻.docx

《GPU恐成最大帮凶未来病毒运行技术前瞻.docx》由会员分享,可在线阅读,更多相关《GPU恐成最大帮凶未来病毒运行技术前瞻.docx(8页珍藏版)》请在冰点文库上搜索。

GPU恐成最大帮凶未来病毒运行技术前瞻.docx

GPU恐成最大帮凶未来病毒运行技术前瞻

GPU恐成最大帮凶未来病毒运行技术前瞻

在正常情况下,这些怀有恶意性质的软件,会悄悄地插入你的系统进程中,并在后台执行一些不可告人的操作。

从硬件角度来分析,传统计算机系统中,只有CPU能完成这样的任务。

原因首先是CPU可以执行任意类型的代码,可编程性极强;其次,CPU是系统的核心,拥有执行任务相当高的权限;其三,现代CPU性能都很不错,多核心技术的普及让这些怀疑恶意性质的软件即使运行起来,用户也很难察觉——因为你的CPU某些核心往往不会满载,NVlDIA,已经分别针对其GPU发布了相应的SDK(softwaredevelopmentkits,软件开发包),用于帮助程序员执行可以在GPUJL运行的通用代码。

这些代码甚至可以使用传统的C语言来编写,比较常见的有NVIDIA和CUDA或者AMD的Stream。

目前,最新一代的GPU(比如支持DirectX11的NVIDIAGeForceGTX500系列),已经允许CPU和GPU上运行的代码完全相同(如NVIDIA所推出的CUDA-X86计划)。

在这种情况下,GPU通用计算被广泛应用于各类计算任务中。

当然,这部分计算任务还包括那些“雄心勃勃”的恶意软件代码编写者。

考虑到通用计算的巨大潜力,做出“恶意软件编写者们将利用现代GPU的强大性能,来为自己牟利”的预测就是很自然的事情了。

所谓加壳,就是将自己真正需要运行的内容保护起来。

打比方来说,炸弹外面包上鲜花,然后放在邮包里,邮包放在旅行箱里,旅行箱被放在运输飞机的某一处。

在加了三层壳子后,炸弹看起来像个正常的旅行箱,但一旦飞机上天,爆炸后的后果就不堪设想。

恶意软件往往将自己伪装成正常执行的程序,骗取系统或者反病毒软件,甚至是用户本人的信任,最终实现其不可知的目的。

而多态性,是指恶意软件在执行时,不将自己全部暴露在内存中——如果全部暴露,就可能难以逃脱反恶意软件的扫描。

因此,恶意软件将自己的一小部分暴露在内存中,然后在需要的时候再暴露另一部分。

简而言之就是“化整为零,按需调用”。

这个看起来相当“有效率”的方法,带来了恶意软件非常难以防御的特性。

因为程序不是人,它们只能机械地执行扫描和对比的任务。

如果反病毒程序已经确定了几种恶意软件“变身”的方法,那么只要恶意软件下次改变一下暴露顺序,或者掩盖一下自己的执行目标,反病毒软件就可能无法侦测。

迄今为止,这些所有的恶意软件都利用了目前程序执行环境的复杂性,尽可能隐秘地逃脱反恶意软件的侦测。

更糟的是,大部分研究反恶意软件的安全研究人员们只关注于IA-32架构,因为绝大多数恶意软件都运行在X86系统上。

但令人担心的是,GPU通用计算的来临,为恶意软件的编写者们带来了一扇机会之窗,因为大多数安全研究者对于GPU的执行环境和指令集架构并不熟悉。

利用GPU通用计算,恶意软件可能会有效对抗现有的防御手段。

计算机理论浅析OA系统的应用实施

所谓OA,即办公自动化(OfficeAutomation),是办公工作处理的自动化,它利用先进的技术,使人的各种办公业务活动逐步由各种设备、各种人机信息系统来协助完成,达到充分利用信息,提高工作效率和工作质量,提高生产率的目的。

然而很多企事业单位的OA系统开发建设完成后,没有有效的措施保障系统的推行,引发使用者的抵触,或者只重视系统软硬件建设,忽视信息化本身对于信息数据的需求,忽视了信息的收集、整理与利用,对数据、文档等资料的数字化转化没有引起足够的重视,使OA系统成为空壳,无法顺利应用实施。

针对以上种种问题,本文拟从制度、数据、人员等方面对OA系统的实施提出一些建议。

1建立健全规章制度,单位领导牵头推广,各部门协调配合

OA系统往往涉及单位各个部门及人员,涉及面较广,其引入的新的管理理念和模式,很大程度上改变了员工传统的作业习惯,在推广过程中,难免要遇到各种阻力,因此,要从制度上、人员上加以保证。

首先,通过将OA系统的实施制度化,制定OA系统运行的规定及一整套实施细则,明文要求系统的使用,尤其要切断非必要的传统纸质信息流转形式;同时,在人员方面,单位领导要带头坚持使用,不使系统卡在某些关键的审批环节,而各部门之间也要充分协调配合,利用OA的信息共享平台,把行政管理和业务实施在OA平台上开展起来,以促进系统迅速、切实地应用起来。

2重视数据迁移与数据共享

信息系统建设中有一句老话,“三分技术、七分管理、十二分数据”。

如今的OA系统建设的核心,就是要打破传统的信息孤岛现象,对数据资源进行统一规划,并制定统一的数据标准和建立整个OA系统共享的中心数据库。

在OA实施推进的过程中,需要整合旧系统遗留的历史数据,存在结构复杂或不规范、数据量浩大、数据不全或者有误等多种情况,如果不能对这些已有数据进行正确的整理和迁移,常常会让新的OA系统成为空壳,无法支持业务的顺利开展。

而整理数据的工作量往往耗时费力,为此,建议成立专门的数据项目组、单独立项、专业实施。

同时,针对企事业单位存在的一个业务部门要同时管理多套信息系统进行信息上报的情况,OA系统作为日常办公的基本业务平台,允许用户方便地自定义各种业务流程和表单,和其他系统进行数据整合,生成各种统计报表;预留良好的接口,方便信息数据的导入导出,从而能最大限度地减少使用者的重复劳动。

机会还是威胁GPU通用计算的发展

接下来,让我们先暂停一下对恶意软件的恐惧,进入GPU的世界。

GPU通用计算最近几年来飞速发展,当GPU本身可编程性和灵活性大大提高后,很多人开始着手探索如何利用GPU架构进行大规模的并行计算,毕竟GPU拥有系统中最为强劲的浮点计算能力,仅仅作为3D计算显然相当可惜。

但GPU通用计算需要专用API才能在GPU上完美运行。

一般的图形APIMDlrectX和OpenGL等,都不能很好地进行通用计算。

对传统GPU来说,无论是GPU本身设计还是调用方式都尽可能为GPU需要执行的图形计算优化。

因此你如果想利用GPU庞大的计算资源,那些需要计算的数据和变量,必须映射为图形学对象,算法处理必须被表述为像素和顶点处理的形式,假装是在进行图形计算一样。

这种“假装”的形式让程序员感到很束缚。

因为传统GPU缺乏方便的数据类型,基本的计算函数,以及一个一般化的内存访问模型,使得它对于习惯于工作在传统编程环境下的程序员们来说没有多少吸引力。

进入DirectX10时代后,NVIDIA提出了CUDAfComputeUnifiedDeviceArchitecture)这样一个相当富有创造力的通用运算API架构。

有了这个API之后,程序员就不需要在自己的大脑中“映射”各种数据,APl作为沟通桥粱已经承担了数据转换、程序编译等任务。

这样一来,GPU就能很好地发挥计算效能。

与此同时,AMD也提供了对应自家GPU产品的通用计算方法,被称为Stream。

CUDA由一个C语言的极小扩展集和一个运行库组成,这个运行库提供的函数能够控制GPU,以及设备专有函数和相应的数据。

从相对宏观的角度看,一个CUDA程序由两部分组成,一个运行在CPU上,另一个称之为“kernel”,是运行于GPU上的并行化部分。

不过GPU上的kernel是不能独立运行的,它只能依赖于CPU上的父进程调用,因此,它不能被作为一个独立的程序直接初始化。

CUDA中的kernel在运行时被划分为多个线程来执行,这些线程被组织成多个线程块,然后交由GPU的CUDACore--也就是常说的流处理器来执行。

在GeForceGPU中,每个处理单元会包含8个SIMD流处理器组。

这8个SIMD流处理器组会根据一个线程调度器的调配,令多个线程块尽可能高效率、最大化地运作,保障整个GPU的运行效率。

除了编程执行外,CUDA还提供了用于在主机和GPU问进行数据交换的函数,所有的I/O动作都通过PCI-E总线进行。

不仅如此,存储器操作还可以通过DMA进行,这样就可以大幅度提高CPU和GPU工作的并行程度。

在内存一致性方面,主机的分页锁定内存中的一个块可以被映射到GPU的地址空间里,使得在CPU上运行的普通程序和GPU上运行的kernel能够直接访问相同的数据。

总的来说,无论是CUDA还是Stream,都是尽可能利用GPU性能的API。

恶意软件要运行得有效率,就绕不开这两个API。

下面就让我们来看看恶意软件是如何在GPU上捣鬼的。

上文说过,运行于GPU上的kernel必须依赖CPU上的父进程。

恶意软件也是如此,那些能利用GPU超强性能的恶意软件往往包含两个部分--GPU部分和CPU部分。

说得更细致一些,那就是恶意软件在执行时,会裁入GPU端的设备代码,分配CPU和GPU都可以访问到的一块内存区域,先初始化数据,然后调度GPU代码开始执行。

当然,和所有利用GPU的程序一样,恶意软件可以在GPU和CPU之前来回转换,或者单独让GPU运行或者只让CPU运行,也可以同时在GPU和GPU并行执行。

当然,恶意软件编写者不仅仅看中了GPU的计算能力,他们还需要更自由、不被监视的执行空间。

恰好,在GPU这里,恶意软件可以与CUDA库静态链接,成为一个独立的可执行程序,这样一来,恶意软件就不需要在被感染的系统中安装额外软件。

更令人难以接受的是,目前GPU端的代码执行,以及CPU和GPU之间的通讯,都不需要管理员特权。

这意味着,恶意软件可以在任何用户权限下成功运行——它不需要任何权限,也没人监控它。

这就令恶意软件隐蔽性更高、更容易被运行起来。

束手无策?

恶意软件如何利用GPU资源

前文已经描述了恶意软件感染系统的方式,并且说明了它利用GPU进行并行加速的可能性。

接下来,研究人员将通过实例来模拟这个过程。

在模拟中使用的原型代码不仅仅证明了恶意软件利用GPU的可行性,而且已经确信对现有的分析检测系统构成了不容忽视的挑战。

研究人员选择使用NVIDIACUDA来部署源代码,当然攻击者可以很容易地使用其他GPU代码版本,甚至还能在不同GPU之间进行转换。

目前攻击者只要掌握了CUDA和Stream,就能基本上掌握100%的GPU恶意软件攻击范围。

还有更令人恐惧的——OpenCL是一个跨平台的GPGPU框架,致力于提供统一的API,如果它得到广泛引用,那么就连插入不同版本的代码也完全没有必要,只要平台支持OpenCL,就可能被恶意软件利用你电脑中的GPU加速运行。

1.自脱壳GPU加速

前文已经简单介绍了恶意软件的加壳技术。

当然,飞机上放炸弹的例子只是用于破坏性的炸弹。

在软件这里,经过多层加壳伪装后的代码,需要脱壳解秘,才能变成真正的恶意代码危害系统。

一般情况下,恶意软件设计有自脱壳程序,这个程序在运行时会首先解包被隐藏的代码,然后将控制权移交给已在主机内存中变形为真实代码的恶意软件。

当然,一种恶意软件可能不止使用一种加壳程序,使用不同的变换方法或者改变解包程序的代码,攻击者可以容易地制造同一个恶意软件的全新变种,还能有效地躲避检测程序。

目前传统恶意软件的自脱壳算法都不特别复杂,因为要考虑到CPU的计算能力,一旦显著拖累系统,恶意软件不但容易被察觉,还给自己的运行带来了不利影响。

但利用GPU强大的并行计算能力后,恶意软件的作者能够利用极其复杂的加密算法给恶意软件加壳,这些复杂的加密算法最终将被GPU大规模并行架构快速而有效地处理。

这种高强度的加壳、脱壳操作,为现有的恶意软件分析检测系统制造了不容忽视的障碍。

许多反恶意软件中用于检测自动脱壳的部分有先天缺陷,没办法应对基于GPU的自解包恶意软件。

比如常用的PolyUnpack,在脱壳时依赖单步执行和动态反汇编,但这种技术在GPU上的动态和静态分析还很不成熟,当然也没有获得恶意软件分析系统的支持。

另外一些反恶意软件的脱壳系统,比如Renovo,依赖于在虚拟机中监控恶意软件的执行过程,但显而易见的是,目前的虚拟机还仅仅只能做到虚拟图形设备而已,只能执行简单的3D计算,根本不能执行GPU通用计算任务,也没有这方面的功能。

这样一来,利用虚拟机监控恶意软件的脱壳也将成为泡影。

当然,还有一些检测软件脱壳的技术比如omniUnDack,这种技术理论上可能会对恶意软件在GPU中的操作起到一定的检测作用,但实际上它在应用中还是和虚拟机联合部署的,也就是说,实际应用中也不能检测到GPU中的脱壳运行情况。

2.运行时多态技术

不过,前一页研究人员的演示可能并不能让人信服,有人肯定会说,无论加壳脱壳的设备是CPU还是GPU、无论壳算法多么复杂,最终都将恶意代码直接存放在主机内存中。

这样一来只要反恶意软件扫描系统内容,就能很轻松地发现恶意软件执行意图并给予相应防御措施。

实际上这种情况只能代表部分恶意软件的运行方法。

正像本文开头解释“运行时多态”技术时说的那样,恶意软件在运行时,往往不会暴露自己的全部代码,它可能重新加壳,或者只是按需分配、重复加壳脱壳那些当前需要的代码。

不仅如此,恶意软件开发人员还会控制解码部分的粒度,也就是每次解码的数最,这个数量越小,在内存中暴露真实代码的区域就越小,被侦测的可能性也就越低,也越难以被发现和防御。

这种代码分割算法给反恶意软件带来了明显的困扰。

在加入了GPU后,这些重复脱壳加壳的算法,都使用GPu执行,并且整个需要脱壳和加壳的部分代码也全部存在GPUAc。

CPU的职责仅是在每个部分的代码执行前和执行后,将控制权交还给GPu上的调度代码,去做按需的解密变换和加密变换。

也就是说,在执行期间,控制权在CPU和GPU之间不断地转换。

同样,GPU和CPU也拥有一个可以同时访问的内存区域用于保持数据一致性和及时刷新。

不仅如此,在这种技术中,解密密匙被保存在较为保密的、无法从CPU端访问的CUDA设备存储器当中,更有甚者,在每个部分执行后的重加密过程中,还可以使用随机生成的不同密匙,这导致了恶意软件能够在存储器中以不可预测的方式不断地发生变异。

而这些解密方法和变异都是不能被检测或者预测到的,将直接导致目前依赖抽取密钥和相应加密解密区域等方法的反恶意软件运行失败。

当然从理论上来说,虽然原始代码的完整抽取仍然是可能被分析人员做到的,但是如果考虑现有的反调试技术,这种有GPu从旁协助的运行时多态会使得整个逆向工程分析过程变得异常地漫长和艰难。

未来更危险?

GPU上恶意软件的发展方向

在先前的章节中,研究人员为我们展示了恶意软件将自己在CPU和GPU之间分离执行的具体方式。

虽然现代GPU的性能已经足够强大,但是目前的技术仅仅使用了其中的一小部分。

未来恶意软件作者可能会开始广泛利用GPU的图形和通用计算能力。

GPU提供了,大规模并行处理的能力,可以被用来加速CPU负载较重的运算。

例如,一些恶意软件开发人员往往使用僵尸网络进行大规模的密码暴力破解,而这正是GPU通用计算的专长。

通过对GPU通用计算的支持,僵尸电脑的能力可以很容易地获得延伸,可以使用被感染主机的GPU来分摊密码破解的负载。

这不仅带来了整体破解效率的显著提升,而且还隐藏了正在进行的恶意活动——因为GPU的工作无法被实时监控,无法鉴别正在运行的代码,所以难以确认GPU上是否有密码破解程序的代码出现。

另外,由于GPU的加入,在这种计算任务中,CPU几乎不会占用,所以CPU负载监视程序对于检测恶意活动也无能为力。

除了恶意软件在GPU上的运行外,还有其他的一些危险也可能和GPU挂钩。

比如GPU的帧缓冲区,屏幕上所显示的内容往往存放在帧缓冲区内。

不过目前系统对帧缓冲区的访问没有施加限制,这可能会带来一系列攻击手段。

比如,GPU上运行的恶意代码能够周期性地访问这一缓冲区,将用户屏幕上出现的私人数据收入囊中,这个做法比现有的屏幕截图的手段更加隐蔽。

而更老练的恶意软件甚至会试图在用户访问虚假网站时,在屏幕上显示错误的或者具有迷惑性的信息,例如偷偷将用户浏览器地址栏中,那些可能会引起用户怀疑的恶意地址,替换成看起来正常的地址。

不过有一个好消息是,目前帧缓冲区还存在读写保护,因此一些对帧缓冲区的恶意行为很难轻易实施。

但由于厂商们一直在尝试提升GPU通用运算SDK和图形API(如OpenGL,DirectX)的互通性,所以未来有可能存在对屏幕帧缓冲区拥有完全访问权限的kernel。

这种要求主要来自于那些需要直接访问屏幕像素的程序,例如3D变换,视频编码与解码等。

因为这样一来就可以大大减少cPU和GPU间的数据交换。

所以,将来发布的硬件会不可避免地具备这一特性。

更恐怖的是,未来的GPu通用架构将使得部署基于GPU的恶意软件成为可能,也就是说,恶意软件将主要在GPU上运行,与在CPU上运行的程序没有任何关联。

不过令人庆幸是,这种问题可能在短期内都不会出现。

因为现有图形硬件架构很难支持独立GPU程序的多任务运行,任意时刻只支持一个任务占用GPU。

这就意味着一旦有任何独占GPU的运算任务存在,那么负责屏幕内容渲染的程序无法运行,显示器上显示的内容会被冻结。

虽然这些在现在看来不太现实,有很多技术障碍需要克服,但是在将来,图形硬件将具备下一代恶意软件所需要的功能,这会彻底释放GPU的能力。

当然,我们现在也无需悲观。

毕竟当前GPU还无法脱离CPU对系统进行控制。

我们现在还有充分的时间,对未来GPU可能进行的破坏行为进行研究,预防。

同时,也有不少杀毒软件开始采用能够利用GPu运算能力的杀毒引擎,显然这也将大大提升电脑的反病毒能力。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2