测试环境: 调试器: IDA6.5 手机及系统版本: image.png .SO层脱壳 一:.如何到达壳入口点? 1.我是通过对dvmLoadNativeCode函数下断，分析它执行流程最后到达壳入口（如果您有更好的办法还请告知，感谢中...）,函数dvmLoadNativeCode是执行加载so文件的操作。 ,是一个函数地址，如下图 image.png 该函数为： image.png 6.得到了libprotectClass.so在内存中基址与INIT_ARRAY文件偏移，将它们相加即可得到so壳入口了 二:so如何脱壳？ 1.到达壳入口后我们单步跟踪看看，到修改代码属性这里 image.png image.png R0为要修改的开始地址 2.准备解密代码,跟进该函数。 （样本就是上传了，想玩玩的去XX加固保官网下载去吧） 资料下载 http://yunpan.cn/cAFzDYcB6weWY （提取码：6e74）
概述 现在使用Proguard进行混淆的代码，也很容易被破解，所以就出现了加固工具，让反编译的难度更大。但是有了加固技术，就会有反加固技术，正所谓道高一尺魔高一丈。 经过加固后的apk，通过 dex2jar反编译： 腾讯乐固： ? 360加固： ? 从上面可以看出，经过加固后的apk，通过常规方法反编译无法获取到源码。 下载地址： https://vxposed.com/ 脱壳 Step1: 将 VirtualXposed、 FDex2和需要脱壳的应用都安装到手机上。 Step6: 在 VirtualXposed中运行要脱壳的应用。 Step7: 脱壳后的dex文件： ? Step8： 通过 dex2jar对 脱壳的dex进行反编译： ? 从上图就可以看到脱壳后的dex文件被成功的反编译。
个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程，多款云服务器20元起。
但是有了加固技术，就会有反加固技术，正所谓道高一尺魔高一丈。 经过加固后的apk，通过dex2jar反编译： 腾讯乐固： legu.png 360加固： 360jiagu.png 从上面可以看出，经过加固后的apk，通过常规方法反编译无法获取到源码。 下载地址： https://vxposed.com/ 脱壳 Step1: 将VirtualXposed、FDex2和需要脱壳的应用都安装到手机上。 Step8： 通过dex2jar对 脱壳的dex进行反编译： shelling-dex2jar.png 从上图就可以看到脱壳后的dex文件被成功的反编译。 e.printStackTrace(); XposedBridge.log("文件写出失败"); } } } 参考链接 【手机端】腾讯乐固，360加固一键脱壳
实战脱壳360加固 正文共： 1741字 7图 预计阅读时间： 5分钟 1、最近一直在搞工控设备方面的漏洞挖掘，其中遇到一个应用程序进行渗透时遇到请求参数被加密或者签名的情况， 在请求数据被修改后提示异常 ， 导致无法有效地进行漏洞挖掘，因此把最近关于脱壳的方法做个记录，逆向反编译应用进行查看 2、通过查壳和上面分析是360加固，经过加固后的apk，通过常规方法反编译无法获取到源码 3、配置环境并启动 if (retval.toInt32() > 0) { /* do something */ } } }); 7、上面利用脚本配置好后进行脱壳如下 8、可以看到下面是我们脱壳的dex文件
实战脱壳360加固 正文共： 1741字 7图 预计阅读时间： 5分钟 1、最近一直在搞工控设备方面的漏洞挖掘，其中遇到一个应用程序进行渗透时遇到请求参数被加密或者签名的情况， 在请求数据被修改后提示异常 ， 导致无法有效地进行漏洞挖掘，因此把最近关于脱壳的方法做个记录，逆向反编译应用进行查看 ? 2、通过查壳和上面分析是360加固，经过加固后的apk，通过常规方法反编译无法获取到源码 ? 3、配置环境并启动frida服务 ? 4、端口转发 ? if (retval.toInt32() > 0) { /* do something */ } } }); 7、上面利用脚本配置好后进行脱壳如下 8、可以看到下面是我们脱壳的dex文件 ?
目录简述（脱壳前学习的知识、壳的历史、脱壳方法） 第一代壳 第二代壳 第三代壳 第N代壳 简述Apk文件结构Dex文件结构壳史壳的识别Apk文件结构 ? Dex文件结构 ? 壳史 第一代壳 Dex加密 Dex字符串加密资源加密对抗反编译反调试自定义DexClassLoader 第二代壳 Dex抽取与So加固 对抗第一代壳常见的脱壳法Dex Method代码抽取到外部（通常企业版 ）Dex动态加载So加密 第三代壳 Dex动态解密与So混淆 Dex Method代码动态解密So代码膨胀混淆对抗之前出现的所有脱壳法 第四代壳 arm vmp（未来） vmp壳的识别 1.用加固厂商特征 第二代壳内存重组法Hook法动态调试定制系统静态脱壳机内存重组法 Dex篇 ZjDroid http://bbs.pediy.com/showthread.php? 静态脱壳机 分析壳so逻辑并还原加密算法 http://www.cnblogs.com/2014asm/p/4924342.html ?
网站漏洞修复办法与详情 目前官方并没有对此漏洞进行修补，建议程序员对php的版本进行升级到5.3以上，或者切换服务器到linux系统，对上传目录uoload进行无PHP脚本运行权限，或者对网站目录进行安全加固防止 如果您对代码不是太熟悉的话，可以付费找专业的网站安全公司来处理，国内也就SINE安全，绿盟，启明星辰比较专业一些，关于Metinfo漏洞的修复以及加固办法，就写到这里，希望广大的网站运营者正视起网站的安全
第二步 打开模拟器,准备安装软件: 1.需要脱壳的软件 2.XP 框架.(直接在模拟器应用商店搜索即可) 3.易开发. 4.MT 管理器.(推荐),当然你用别的文件管理器也行. 打开要脱壳的软件.点击悬浮窗 ? 数据就会在: /data/data/应用包名/dump/ 目录下 ? 你在这个文件夹里会没有权限,移动到 SD 卡的根目录 ? 好了完成了! ?
0x00APK加固简介与静态脱壳机的编写思路 1.大家都知道Android中的程序反编译比较简单，辛苦开发出一个APK轻易被人反编译了，所以现在就有很多APK加固的第三方平台，比如爱加密和梆梆加固等。 2.一般的加固保护通常能够提供如下保护：加密、防逆向、防篡改、反调试、反窃取等功能，编写静态脱壳机须要信息有加密后的原始DEX数据、解密算法、解密密钥、要想获得这些信息我们首先要解决的问题是过反调试、动态分析解密流程 2.反编译加固后APK，APK中的AndroidManifest.xml文件的入口被修改，如图2所示。 ? 图2 3.入口类中主要会调用librsprotect.so中的3个函数，如图3所示。 图18 2.以上就是简单实现一般APK加固静态脱壳机的编写步骤，由于该加固核心so文件使用UPX默认加壳并未做变形处理，导致so被轻松的静态脱卓，而so模块中的反调试手段比较初级且模块化，可以非常简单的手工
我们别着急关 OD，我们试运行一下我们脱壳后的文件，发现脱壳后的 crackme 并没有显示出来，说明我们需要对脱壳后的文件进行修复。 我们脱壳后的入口虚拟地址（VA）为 004011cb，但是这里填入的是一个相对虚拟地址（RVA）。 我们点击“修复转储文件”，在出现的保存窗口中我们选择 “dump.exe”，也就是刚才脱壳后的文件。 我们点击“修复转储文件”，在选择 “dump.exe” 进行保存。 这次我们运行 dump_.exe 文件，可以看到我们脱壳后的 crackme 运行起来了。 我们较为详细的分析了对 ASPACK2.12 的脱壳过程，和脱壳后对导入表的修复过程。希望大家能够举一反三，从中学到更多的知识。
0x01 APK加固前后对比 整体来看一下原始APK包和加固后的APK包结构相关变化 图1所示加固后的APK包变化如下: 新增2个文件夹： assets文件夹中增加3个文件 data dx pk lib 从图4看到AndroidManifest.xml中的application新增了如下项做为壳的入口 android:name="com.edog.AppWrapper"该类为壳的入口，继续分析AppWrapper APK中assets文件夹中的data文件与classes.dex放在修复程序同一个目录中，然后运行修复程序。 去掉AndroidManifest.xml中的壳入口，将修复后的classes.dex重新打包反编译，成功运行，如图9所示能正常反编译源码，至此，分析完毕。 ? 函数->在dvmResolveClass hook函数中修复指令->结束。
手工修复导入表结构实现手工修复导入表结构1.首先需要找到加壳后程序的导入表以及导入了那些函数，使用PETools工具解析导入表结构，如下。 地址为0x00000800的位置，长度是0x000000A8定位过去看看，程序中只保留了一个LoadLibraryA和GetProcAddress这两个关键函数，通过这两个关键函数即可定位到所有的函数入口 图片正常我们脱壳后，程序输入表会保留原始的带壳状态下的结构，如下。图片使用X64DBG对其进行FixDump修复后，其结构表现如下，看样子是完全重构了它的输入表结构。 图片其中导入函数开始位置是 40e0ec 结束位置是 40e22C 长度是 00000140图片图片脱壳修复时，填入对应地址，删除无效指针，即可自动新建一个新的导入表。 图片我们首先使用X64DBG，并配合ESP定律，快速脱壳并修复程序，保存后，接着就是在文件末尾创建一段空款区域。
手工修复导入表结构 实现手工修复导入表结构 1.首先需要找到加壳后程序的导入表以及导入了那些函数，使用PETools工具解析导入表结构，如下。 地址为0x00000800的位置，长度是0x000000A8定位过去看看，程序中只保留了一个LoadLibraryA和GetProcAddress这两个关键函数，通过这两个关键函数即可定位到所有的函数入口 正常我们脱壳后，程序输入表会保留原始的带壳状态下的结构，如下。 使用X64DBG对其进行FixDump修复后，其结构表现如下，看样子是完全重构了它的输入表结构。 其中导入函数开始位置是 40e0ec 结束位置是 40e22C 长度是 00000140 脱壳修复时，填入对应地址，删除无效指针，即可自动新建一个新的导入表。 我们首先使用X64DBG，并配合ESP定律，快速脱壳并修复程序，保存后，接着就是在文件末尾创建一段空款区域。
360加固? fa?! ? 我以为上帝关上了我的门,还会留个窗给我,结果还是无情地把窗给我锁上了 ? 0x01 zjDroid脱壳 刀不锋利马太瘦,你拿什么工具和我斗。 我们已经知道不论是利用什么方法加固apk 若要让软件要正常运行,就必须让程序最终加载原dex文件,这样的话,如果我能dump出内存中已经加载的dex 就可以无视在加载dex前的一大堆解壳操作 而ZjDroid 层的代码作者并没有开源 编译,运行 踩坑注意:这个工具的so文件似乎在5.0以上的安卓系统不起作用,所以我特意刷了一个4.4的安卓再去安装ZjDroid 在手机的Xposed中启用此插件,然后打开需要脱壳的 查看软件的入口 打开指定类 未加壳的dex成功被加载了! 我现在看到的是原dex的代码,而不是壳dex的代码! ?
01 概述 — 由于近期很多朋友问关于Android加壳与脱壳技术，这两天我就对目前主流的脱壳工具和加壳方法做了研究，就对目前的脱壳方法做个汇总和方法记录。 其实对于加壳的方案很多加固尝试都做了什么防动态调试等等措施，所以整体来讲，Android的加壳技术也提升了不少。 接下来运行脱壳程序进行脱壳，这里比较简单了，直接运行脱壳程序，参数就是进程名，如下： ./drizzleDumper com.thsseek.welove ? ，后面有机会尝试手动脱壳测试。 还有其他厂商的加固，如梆梆，腾讯，爱加密等，如果有兴趣也可以一一进行尝试。
修复建议 （1）严格过滤用户输入的数据，禁止执行非预期系统命令。 修复建议 （1）对用户访问角色的权限进行严格的检查及限制。 修复建议 （1）在进行页面跳转前校验传入的URL是否为可信域名。 修复建议 （1）删除phpinfo 函数。 （2）若文件无用可直接删除。 修复建议 （1）关闭不安全的传输方法，只开启POST、GET方法。
APP脱壳 通过用jadx工具(还有jeb、androidkiller等工具)查看APP解压后的dex文件，通过工具展示的信息，可以看到该dex文件的入口类Application类已经被处理过了，也就是该 APP用了第三方加固软件，进行加固保护过的。 2、将app拖到反编译工具，如jadx工具上，通过工具可以看出Application的入口类是否被替换，还有是否存在加固厂商的特征。 这也是为什么很多加固工具的主要逻辑都是通过替换APP入口Application，并自实现这两个函数从而达到加固的效果。通过上面的分析该APP采用的360加固进行最App做加固。 下面通过frida框架和frida_dexdump脚本(通过暴力搜索dex035)对该360壳进行脱壳操作，可以很顺利的脱掉该APP的360加固保护，最终解密出多个dex文件。
插件脱壳（ps:脚本小子除外），这些都需要我们自己写脚本的；至于正向开发那就更没得说了，无论是你想实现自己的加固方案还是要做涉及到底层的开发都需要写到 so 层里面去，而这前提是你的会 c 或者 c+ 然后说起进阶技能吧，就是在基础技能之上开始进入逆向精彩的地方--加固和脱壳之间的对抗，个人总结要学习、研究的知识点如下： 1、了解安卓 apk 包的架构，能解析 apk 的各种文件，例如 dex、xml 文件 2、了解动态加载的技术 3、学习安卓第一代壳(落地加载壳)的加固方案然后自己动手实现 4、学习 frida 的使用方法，会使用 frida 编写简单的脱壳机 5、有碎片时间可以阅读一下安卓源码 6、学习安卓第二代壳(不落地加载壳)的加固方案有条件就自己实现一下 7、针对第一代壳和第二代壳的加载点无论是使用动态调试还是 hook 的方法脱壳修复 8、了解第三代壳(函数抽取式壳)和第四代壳 (vmp 我个人始终认为，不会自己写加固代码，就不会真正的脱壳，更不要说修复了， 其实，大家写的加固方案加载 dex 点基本都差不多，你会写了，也知道了加载点在哪儿，脱壳点也就一清二楚了。
企业尤其是规模较大的企业经常需要采用第三方供应链提供的应用安全开发及加固服务，安全人员需要对其安全性进行校验，移动应用脱壳就是其中的必经步骤。 而市面上现有的自动脱壳工具不能解决DEX虚拟化的加固方案，并且厂商自定义的解释器会定期更换Opcode映射表，导致很多自动脱壳服务无法完整有效的还原DEX代码。 基于这个洞察，腾讯安全科恩实验室根据多年安全攻防研究经验，推出先进的自动化脱壳方案，支持恢复常见的DEX加密和指令抽取等类型的加固。 ApkPekcer的脱壳方案解决了opcode handler识别的难点，自动化还原被DEX-VMP保护的代码，提高了脱壳的完整度和自动化程度。 ApkPecker能够输出高质量漏洞扫描报告，提供高品质漏洞信息以及漏洞触发完整路径，精准定位漏洞并提供修复建议，帮助移动安全人员解决现有痛点，提升应用安全性。
小程序安全针对小程序不同业务场景提供包括小程序安全加固、小程序安全扫描、小程序渗透测试功能，通过分析仿冒程序，挖掘风险漏洞、保护核心代码等方法保护小程序业务安全、数据安全，降低客户业务风险和资金损失。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
网站备案
对象存储
云直播
实时音视频
