关于防止android apk被反编译的技术我们前面已经讲了四种. 加壳技术 运行时修改字节码 伪加密 对抗JD-GUI 如果有不明白的可以查看我的博客的前四篇中关于这四种技术的介绍.接下来我们接着介绍另一种防止apk反编译的技术-完整性校验. 一.完整性校验原理 所谓完整性校验就是我们用各种算法来计算一个文件的完整性,防止这个文件被修改.其中常用的方法就是计算一个文件的CRC32的值或者计算一个文件的哈希值.我们在防止apk被反编译的方法中也可以采用这种方法.我们知道apk生成的classes

转载自http://drops.wooyun.org/tips/6840 在现在的移动安全环境中,程序加壳已经成为家常便饭了,如果不会脱壳简直没法在破解界混的节奏.ZJDroid作为一种万能脱壳器是非常好用的,但是当作者公开发布这个项目后就遭到了各种加壳器的针对,比如说抢占ZJDroid的广播接收器让ZJDroid无法接收命令等.我们也会在”安卓动态调试七种武器之多情环 - Customized DVM”这篇文章中介绍另一种架构的万能脱壳器.但工具就是工具,当我们发布的时候可能也会遭到类似ZJD

我们可以利用DexClassLoader来实现动态加载dex文件,而很多资料也只是对于DexClassLoader的使用进行了介绍,没有深入讲解dex的动态加载机制,我们就借助于Android4.4的源码来探索.先从一个简单的动态加载dex文件开始 具体实现细节可以参考这篇文章AndroidDex数据动态加载技术 Android4.4的源码在百度网盘分享: Android 4.4源码下载 先是我们要封装到text.jar文件中的很简单的调用函数,只是简单的产生Toast: /* * 对外接口 *

当我们的项目代码过大时,编译运行时会报Unable to execute dex: method ID not in[0, 0xffff]: 65536)错误.当出现这个错误时说明你本身自己的工程代码中含有的太多的方法,或者你的工程lib文件夹下引用的第三方插件jar包有太多的方法,这两者的方法加起来已经超过了65536这个数目.而谷歌规定单个dex文件中的方法不能超过65536的限制. 那么这个时候,我们就需要分包处理解决.一般情况下的解决方案就是把整个项目工程包括jar,区分开来分解成两个d

代码动态调试: 代码动态调试技术,一般是通过观察程序在运行过程中的状态,如寄存器内容,函数执行结果,内存使用情况等等,分析函数功能,明确代码逻辑,查找可能存在的漏洞 工具:IDA 条件:AndroidManifest.xml里的Android:debuggable="true" 步骤: 1)如果AndroidManifest.xml里的Android:debuggable="false",尝试修改为true,再使用Apktool重新签名,安装,如果成功就可以进行调试

直接修改dex破解 一．编写一个简单的验证程序 (1)MainActivity: protected void onCreate(BundlesavedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Buttonbutton ; finalEditText text1,text2; button=(Button)findViewById(R.id.button

apk实际是一组文件的压缩包,修改为zip或rar后直接解压可以看到其内部内容,其中classes.dex就是java代码编译后的结果 dex2jar可以实现对该文件的反编译 dex2jar镜像地址:sourcefore  github 操作步骤 1.先到官网下载dex2jar,下载后解压到某个目录下 2.将dex文件拷贝到该目录下 要求和d2j_dex2jar.bat在同一目录 3.命令行模式下切换到该目录运行以下命令 d2j-dex2jar classes.dex 找到该目录下会发现多了一个

1. 首先使用调试JNI_OnLoad函数的方法,先将apk以调试状态挂起,使用IDA附加上去. 2. 然后在libdvm.so中的dvmDexFileOpenPartial函数上下一个断点 3. 然后我们点击继续运行,程序就会在dvmDexFileOpenPartial()这个函数处暂停,R0寄存器指向的地址就是dex文件在内存中的地址,R1寄存器就是dex文件的大小 4. 然后我们就可以使用ida的script command去dump内存中的dex文件了. static main(void

在CentOS 7上使用Tripwire监控和检测修改的文件 Tripwire是一个免费的开源入侵检测系统(IDS). 它是用于监视和警告系统上文件更改的安全工具. Tripwire是一个功能强大的IDS,可以保护您的系统免受不必要的更改. 您可以使用它来监控您的系统文件,包括网站文件,因此当有不需要的文件更改时,Tripwire会检查您的系统,如果设置正确,可以通过电子邮件提醒您. 在本教程中,我们将向您展示如何使用CentOS 7系统上的Tripwire监控和检测系统文件中的任何更改. 我们

一.常规 JAVA 软件破解流程 先讲一下常规jar包的破解流程. 1. 快速定位.          1) 通过procmon监控相关软件,查看程序都访问了些啥.         2) 用jd-gui反编译 jar 包,得到源码.         3) 搜索关键字以定位. 这种定位方法只是千万种中的一种,根据不同软件的不同执行特性再具体实施不同的定位方案. 2. 修改破解. 1) 用 dex2jar 将 JAR 包转成 Dex 文件.         2) 再将 Dex 解出 Smali. 

最近做一个模块,需要将apk里面加载的dex文件dump出来,所以需要配置让dalvik不要把dex文件优化成odex. 1. 配置build.prop 主要是通过修改文件/system/build.prop里面的配置. (1) dalvik.vm.dexopt-flags 本参数控制Dalvik虚拟机的程序代码校验和优化.可填写的值有m.v和o.m为标准选项,可以是m=y或m=n.若m=y则启用不安全代码的校验和托管代码的优化.兼容性和安全性最高.v为校验选项,可与o并存.可以是v=a或v=n

0x01 先说总结: 参照https://www.cnblogs.com/jiaoxiake/p/6818786.html 最后说的步骤, 参考:https://www.52pojie.cn/thread-586058-1-1.html 通过DexExtractor将加固后的apk还原odex,拖到jeb里面继续分析,odex-dex步骤没完成. 0x02: 同事小哥在找分析一个apk,找里面一点逻辑,发现apk被梆梆加固了. 正常apktool反编译无法找到清单文件里面注册的服务. 找了下li

一.找坑:谷歌规定单个dex文件中的方法不能超过65536的限制 我们编写项目过程中在工程的lib文件夹下引用的第三方插件jar包太多或者项目过大,编译运行时就有可能报出com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536错误.看到这个错误说明你的方法加起来已经超过了65536这个数目.但是谷歌规定单个dex文件中的方法不能超过65536的限制. 如下图所示,Android Studio 中的

1．DexHeader结构体占用0x70字节,源码位置 dalvik\libdex\DexFile.h文件中269/* 270 * Direct-mapped "header_item" struct. 271 */ 272struct DexHeader { 273    u1  magic[8];           /* dex版本标示 */ 274    u4  checksum;           /* adler32检验 */ 275    u1  signature[k

那些不靠谱的工具 先来说说那些不靠谱的工具,就是今天吭了我小半天的各种工具,看官上坐,待我细细道来.IDA pro IDA pro6.6之后加入了dex动态调试功能,一时间普天同庆.喜大普奔.兴奋之后你才会发现IDA这东西在动态调试方面真的是很挫,就算他是静态反编译之王,我也不得不说他的动态调试功能还非常需要加强.先说说使用ida调试dex的方法. IDA pro调试dex流程: 1.  用apktool反编译apk,添加android:debuggable="true",重打包apk

Android程序的dex文件的动态调试确实是个大问题,网上也有一些教程但是不是特别的详细,今天用到了IDA动态调试Android的DEX文件,特此记录一下. IDA 6.6新添加了对dex文件的调试支持,但是功能还是很弱的说,因为IDA动态调试Android程序的DEX文件时,查看变量很不方便,可以说然并卵. @根据android的官方文档,如果要调试一个App里面的dex代码,必须满足以下两个条件中的任何一个: 1.App的AndroidManifest.xm中Application标签必选

本文博客地址:http://blog.csdn.net/qq1084283172/article/details/77942585 前面的博客<Android平台dalvik模式下java Hook框架 ddi 的分析(1)>中,已经分析了dalvik模式下 ddi 框架Hook java方法的原理和流程,这里来学习一下ddi框架代码中涉及到的 dex文件的注入和调用.将一个Android的so库文件跨进程注入到另一个进程中,在so库文件的实现里,我们可以做很多的事情,例如:inline Ho

*本篇文章已授权微信公众号 guolin_blog (郭霖)独家发布 DEX文件就是Android Dalvik虚拟机运行的程序,关于DEX文件的结构的重要性我就不多说了.下面,开练! 建议:不要只看,跟着我做.看再多遍不如自己亲自实践一遍来的可靠,别问我为什么知道.泪崩ing..... 首先,我们需要自己构造一个dex文件,因为自己构造的比较简单,分析起来比较容易.等你简单的会了,难的自然也就懂了. 0x00■  构造DEX文件 首先,我们编写一个简单的Java程序,如下: public cl

本人前端用惯了Hbuilder,修改了eclipse项目中的文件后,由于是外部编辑器修改过的,eclipse不会自动部署更新,一般按F5刷新项目,或者在 preferences > general > workspace 设置更新,但这个方法也需要等7.8秒才能被部署更新.本节介绍用gulp解决这个问题. 先睹为快,猛戳链接下载Demo :http://pan.baidu.com/s/1o8pmrH4 由于是在gulp环境下才能运行,不熟悉gulp的同学,可以参考这个比较详细的教程:http:

# Additionally, comments (such as these) may be inserted on individual  # lines or following the machine name denoted by a '#' symbol. # # For example: # #      102.54.94.97     rhino.acme.com          # source server #       38.25.63.10     x.acme.c

Linux系统中的每个文件和目录都有访问许可权限,用它来确定谁可以通过何种方式对文件和目录进行访问和操作. 文件或目录的访问权限分为只读,只写和可执行三种.以文件为例,只读权限表示只允许读其内容,而禁止对其做任何的更改操作.可执行权限表示允许将该文件作为一个程序执行.文件被创建时,文件所有者自动拥有对该文件的读.写和可执行权限,以便于对文件的阅读和修改.用户也可根据需要把访问权限设置为需要的任何组合. 有三种不同类型的用户可对文件或目录进行访问:文件所有者,同组用户.其他用户.所有者一般是文件的