工欲善其事，必先利其器。在无线渗透或者是无线攻击中，并不是任何支持linux的网卡都支持无线工具的。推荐过一款网卡 ：

‘AWUS036H’我用过这款网卡，是RT8187芯片的。确实不错，完美的支持工具。当然，也可以选用RTL3070芯片。

其实除了不兼容工具外，选好网卡还有个很重要的因素就是质量问题，质量不好的可能不稳定，造成断开，或者是蓝屏，嗅探抓包时出现丢包等状况。

SetupManager是vold.rp.apk的核心模块，首先设置时间启动MsgPushService，然后创建需要用到的对象，这些类的功能在构造方法中执行，因此在创建对象的时候就已经调用。SetupManager中的功能模块有（主要的）：

ROOT模块（RootManager）
推广模块（PushManager）
寄生到系统底层模块（SysVoldInstaller）携带“地狱火”手机病毒母包的APP应用运行后会释放android.system.vold.v50.apk（v50为版本号：v36~v50，版本号还在持续递增），病毒母包安装后使用DES加密算法解密出android.system.vold.v50.rp.apk（下面简称为vold.rp.apk），vold.rp.apk调用startService启动MsgPushService，MsgPushService的onCreate方法创建TestNotifier、SetupManager、VersionClean、RootModule四个对象。

近日，360安全中心收到多起用户反馈，手机中了一种难以清理的病毒，某些用户尝试自行清理掉病毒，发现删除病毒文件vold.apk后，会再次重现。通过分析，发现此病毒已经寄生到系统底层，定时恢复APK实现自我保护。随着反馈用户数量急剧上升，360急救箱已下发紧急查杀方案，全面支持清理该手机病毒。

通过分析，我们发现在手机病毒发展史上，首次利用了在Android系统中通过修改系统Boot Image、替换系统核心文件的方式实现自我保护的病毒，目前感染量已过百万，因此我们命名它为：“地狱火”手机病毒。此病毒寄生于系统boot分区、替换系统vold文件、回写APK病毒母包。后面，我们来分析下这个源自系统底层的威胁。

以上截图众多中毒网友们的求助内容，可见此病毒传播量巨大，而且大多数用户不清楚如何中毒的，此病毒会下载诱导扣费的APP应用，对手机用户影响严重。

注入这种技术就是将代码或DLL注入到另外一个正在运行的进程中，以实现隐藏自身或其他目的。

常见病毒根据其需求会选择不同的注入方式，但每种注入方式都是值得我们了解和学习的。

本系把常见病毒的注入方式分门别类地进行汇总，在每个类别中选择一个有代表性的病毒，逆向分析该病毒的注入方式，并展示给各位读者，以供大家学习和参考。

作为本系列的第一篇，笔者将介绍利用WriteProcessMemory()函数进行的DLL注入。作为该类注入方式的代表DesktopLayer.exe也很具有分析价值，下面开始进入正文。此外，笔者忠心希望本系列能给读者一点启发和帮助，但由于笔者知识有限，才疏学浅，文中不当或错误之处还请各位读者包容和指正。样本被加了UPX 2.90壳。UPX壳最主要的目的是减小程序的体积，其特点是较高的压缩率和较快的解压速率，与TMD、VMP这类壳的设计理念完全不同，这类壳更注重对代码提供保护的壳。UPX是免费软件，其官网上可以找到每个UPX版本的加壳程序和相应脱壳程序

IOS App的开发者们经常会出现这类问题：
当一个新版本上线后发现存在一个严重的bug，有可能因为一个逻辑问题导致支付接口存在被薅羊毛的风险，这个时候能做的只能是赶快修复完安全问题并提交到appstore审核，在急忙推送用户尽快更新，避免为此导致的严重安全后果买单。

为了解决此类问题遍有了实现给App应用”实时打补丁”这类方案，目前大致有两种主流的“热修复”的项目。

根据基本原理可以分为下面两种，

原理同为构建JS脚本与Object-C语言之间转换的桥梁。

WaxPatch(Lua调用OC)

JSPatch(Javascript调用OC)

”热修复” 技术虽然极大的减少了开发者更新补丁的时间与商业成本，但却将Apple努力构建的安全生态系统——Apple Store对上架App的严格审查规则置于高风险下。通过这种技术可以在上线以后直接更新App原生代码，从而从某种意义上绕过了Apple Store的审查规则。
这段js补丁本来是要在屏幕打印222 这几个数字,但是App在更新补丁时并没有使用Https安全传输，也没有对传输数据进行防篡改，如以下几种场景：

传输过程没有使用Https

传输过程使用了Https，但是对Https的证书没有做正确校验。

传输过程没有使用Https，也没有对数据做防篡改。

难道官方是这样修复的，改了检查方法执行的方法checkEnableEvalExpression，这个方法是在request.xx(x)这种代码执行的方式后加入的判断，主要是为了杜绝参数名上面的代码执行，不过好在这个地方我们不需要这种方式执行代码。经过研究我还是通过三目运算符绕过了这个检测，POC：6月3号的时候我给struts2官方提交了这个新的高危漏洞(CVE编号CVE-2016-4438)，影响所有使用了REST插件的用户，无需要开启动态方法执行（不包括struts 2.5）,此后的几天网上不断有关于s2-033的分析与绕过出来，但是他们大都错误的认为需要开启动态方法执行才能触发漏洞，其实并不需要。正如官方回复这个漏洞说的

很明显有两个关键点：第一个是REST Plugin,另一个是Dynamic Method Invocation is enabled.（也就是开启动态方法执行），看到这里需要满足两个条件，感觉有点鸡肋啊……

直接下载回来源代码调试，载入官方的演示包struts2-rest-showcase.war，我们先随便访问一个连接/struts2-rest-showcase/orders/1,很快定位到关键代码我们看到methodName直接进入到了ognlUtil.getValue方法，对struts2历史漏洞有点熟悉的同学都知道，这个就是最终导致代码执行的地方。不多说，直接上POC：但是如果真的只是这样这个漏洞真的是比较鸡肋的，因为动态方法在这里默认是不开启的，那我们接着分析，有没有可能不用开动态方法都可以执行任意代码了，答案是肯定的。这个地方能不能代码执行主要是这个地方的限制