13518219792
1、Xposed：Java层的HOOK框架，由于要修改Zgote进程，需要Root；
我们提供的服务有：成都网站建设、成都网站设计、微信公众号开发、网站优化、网站认证、孟连ssl等。为上千企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的孟连网站制作公司
2、CydiaSubstrator：本地层的HOOK框架，本质上是一个inline Hook；
3、dexposed框架
4、AndFix框架；
5、Sophix 框架；
6、AndroidMethodHook框架；
7、Legend框架：在AndFix框架的基础上，在方法进行替换前进行了方法的备份；
8、YAHFA框架；
9、EPIC框架；
10、VirtualXposed：Virtual APP与Xposed的一个结合。
扩展资料
使用框架的原因
因为软件系统很复杂，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮助完成一些基础工作，只需要集中精力完成系统的业务逻辑设计。
而且框架一般是成熟，稳健的，可以处理系统很多细节问题，比如，事务处理，安全性，数据流控制等问题。
还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，可以直接享受别人升级代码带来的好处。框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。
框架开发
框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。
由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，从而使构件间的通信简单。
框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。
这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架的设计。
框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。
参考资料来源：百度百科-框架
Binder Hook可以Hook掉 当前App 用到的系统Service服务。
以LocationManager为例，在获取一个LocationManager时分为两步。第一，获取IBinder对象；第二：IBinder对象通过asInterface()转化为LocationMangerService对象。最后初始化LocationManager，application层用到的都是LocationManager。
Hook的大致原理是：ServiceManager在获取某个Binder时，如果本地有缓存的Binder，就不再跨进程请求Binder了。我们可以在缓存中加入自己的Binder，使得ServiceManager查询本地缓存时得到一个自定义的CustomBinder对象，不再跨进程向系统请求。并且ILocationManager.Stub.asInterface(CustomBinder)方法返回我们自定义的Service对象。
这里面有两个地方需要用到自定义的对象。由于我们只Hook其中一部分的功能，其他功能还需要保留，所以用动态代理的方式创建自定义的Binder和自定义的Service。
在理解后面的内容前你需要了解这些知识点：
Activity等类在获取系统Service时，都是调用getSystemService(serviceName)方法获取的。
Context 的 getSystemService() 方法调用了 SystemServiceRegistry 的 getSystemService() 方法。
SystemServiceRegistry 中有一个常量 SYSTEM_SERVICE_FETCHERS，这是一个Map。保存了ServiceName和对应的ServiceFetcher。ServicFetcher是用于创建具体Service的类。ServiceFetcher 的关键方法是 createService() 方法。
在 ServiceFetcher 的 createService() 方法中，调用了 ServiceManager.getService(name) 方法。以 LocationManager 对应的 ServiceFetcher 为例，它的createService()方法源码如下：
假如我们要修改 LocationManager 的 getLastKnownLocation() 方法（下文都是）。我们要做的就是让ServiceManager.getService("location")返回我们自定义的Binder。先看一下这个方法简化后的源码：
sCache是一个Map，缓存了已经向系统请求过的Binder。如果我们需要让这个方法返回我们我们自己的binder，只需要事先往sCache中put一个自定义的Binder就行了。
在put之前，需要先创建出一个自定义的Binder。这个Binder在被 ILocationManager.Stub.asInterface 处理后，可以返回一个自定义的 LocationManagerService。
先看一下Binder的 asInterface() 的实现：
如果把 queryLocalInterface()方法返回一个自定义的Service，使得走if语句内部，不走else，那就算是Hook成功了。
假设我们想让系统的LocationManager返回的位置信息全是在天安门(116.23, 39.54)。那我们需要使得 LocatitionManagerService 的 getLastLocation() 方法 返回的全是 (116.23, 39.54)。
由于我们不能直接拿到系统的这个Service对象，可以先用反射的方式拿到系统的LocationManagerService。然后拦截getLastLocation()方法。
原生的Binder对象在调用 queryLocalInterface() 方法时会返回原生的Service对象。我们希望返回3.1中的自定义Service。所以这里拦截 queryLocalInterface() 方法。
有了自定义的Binder后，将它注入到ServiceManger的sCache变量中就完成Hook了~
当onClick被调用的时候，Toast和Log都会显示天安门的坐标(116.23, 39.54)。证明Hook成功！
你甚至可以用Binder Hook的方式Hook掉 ActivityManager 。
前面插件化一和二说了下插桩式加载未安装的APK，主要是重写了getResource和getClassloader两个方法来实现的。以及每个组件要实现一个接口，通过接口注入上下文来达到它的生命周期。
那么插桩式和hook式的实现方式有什么不同呢？
插桩式是怎么加载到插件中的class文件呢，是通过将将APK转化成插件的Classloader，然后想要加载插件的class文件，我们的去拿这个插件的classloader去loadClass。所以是有一个中间者的。
hook式呢是将插件apk融入到了我们的宿主apk，那直接在里面就可以直接loadClass了，在不用这个插件的ClassLoader了，这样的话对于插件和宿主就没什么区别了，不像插桩式有一个中间者。
那么要实现hook式 就要知道android中一个class文件式怎样被加载到内存中去的。其实就是通过PathClassLoader来加载的。
那么我们先看下ClassLoader
任何一个java程序都是由一个或者多个class组成的，在程序运行时，需要将class文件加载到JVM中才可以使用，负责加载这些class文件的就是java的类加载机制。CLassLoader的作用就是加载class文件提供给程序运行时使用，每个Class对象内部都有一个ClassLoader来标示自己是有那个classLoade加载的。
Android app的所有的java文件都是通过PathClassLoader来加载的，那么它的父类是BaseDexClassLoader，还有一个兄弟类是DexClassLoader，那么他们有什么区别呢。
从上面可以看出这两个类的构造函数不同。(在26的源码中DexClassLoader中的optimizedDirectory也废弃了)
PathClassLoader：用于Android应用程序类加载器。可以加载指定的dex，以及jar、zip、apk中的classes.dex
DexClassLoader：加载指定的dex以及jar、zip、apk中的classes.dex。
可以看到创建ClassLoader的时候需要接收一个CLassLoader parent的参数，这个parent的目的就在于实现类加载的委托。
某个类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，一次递归，如果父加载器可以完成加载任务，那么就返回，只有当父加载器无法完成加载任务时，才自己去加载。
因此我们自己创建的ClassLoader：newPathClassLoader("/sdcard/xx.dex",getClassLoader()),并不仅仅只能加载我们的xx.dex中的class。
需要注意的是，findBootstrapClassOrNull 这个方法，当parent为null的时候，去这个BootCLassLoader进行加载，
但是在Android当中的实现：
所以new PathClassLoader("/sdcard/xx.dex",null),是不能加载Activity.class的。
上面分析了加载了一个class，是利用了双亲委托机制，那么要是都找不到那就开始调用自己的findCLass方法
在ClassLoader类中findClass：
任何ClassLoader的子类，都可以重写loadClass和findClass。如果你不想使用双亲委托，就重写loadClas修改实现，重写findClass则表示在双亲委托机制下，父ClassLoader都找不到class的情况下，定义自己去查找一个class。
而我们的PathClassLoader会自己负责加载Activity这样的类，利用双亲委托父类去加载activity，而我们的PathClassLoader没有重写findClass，是在它的父类里面。因此我们可以看看父类的findClass是如何实现的。
可以看到加载PathClassLoader加载class，转化为从DexPathList中加载class了，那么我们看看DexPathList中的findClass
那么从上面分析得到
到这里我们想要加载一个插件的apk ，其实最终加载的是一个dex文件(先说class文件，加载资源后面说)，有没有办法吧这个dex文件给转化成一个 Element 对象，给放到 Elemeng数组 当中，这样直接就可以加载我们插件中的类了。
1、首先我们肯定是要得到插件APK的的中DexPathList对象中的dexElement数组
2、插件的dexElements数组我们拿到了，那么是不是要开始拿我们系统里面的 ，我们反射获取，和上面的一样。
3、上面我们获取到了系统和我们插件的dexElement数组，然后我们将这个数组合并到一个新的数组里面去，并且给注入到系统里面
至此，加载插件的一个流程基本就完成了。但是上面只是处理了class文件，没有处理资源。资源的话我们也是采用hook的方式去实现
在宿主的Application中hook这个方法，然后去重写getAsserts和getResources两个方法：
然后在插件的BaseActivity中继续重写getAssets和getResources两个方法
这样就可以完成hook式加载一个未安装的APK了。至此基本就完成了插桩式和Hook式插件化的基本实现。(后面几篇是优化)。
用注解吧 打个@SuppressLint("ClickableViewAccessibility") 这个警告是说,有可能会和点击事件发生冲突如果你在touch中返回了true,那么就不会响应onClick事件了你必须调用一下view.performClick(),才会触发 view.setOnTouchListener(new View.OnTouchListener() { @SuppressLint("ClickableViewAccessibility") @Override public boolean onTouch(View v, MotionEvent event) { // TODO Auto-generated method stub return false; } });
源码的执行是按照一定流程思路进行的，hook就是在源码的执行流程之间插入一步操作，起到拦截，替换的作用；被改变的对象称为hook点，一般将不易发生变化的类作为hook点；
学习hook必须了解代理模式，可以参考我这篇文章： 反射和动态代理
首先需要知道startactivity的流程： Android进阶解密①——activity的启动过程
我们知道startActivity会通过mInstrumentation这个类，我们可以将这个类作为hook点；
自定义一个Instrumentation，在activity的工作过程中通过反射替换原来的Instrumentation，将原来的Instrumentation传到代理类里面，通过method invoke保证原来的功能不变，然后可以添加自己的自定义操作；
首先拿到activity原来的Instrumentation对象，通过原来的Instrumentation构建出一个InstrumentationProxy对象，将Proxy设置给activity，然后只要在startActivity()之前调用这个方法替换就可以了；
首先我们可以用Xposed框架来hook计数传感器的队列函数dispatchSensorEvent()，这个函数在android.hardware.SystemSensorManager$SensorEventQueue这个类中。随后在微信运动每次询问行走步数的时候，我们先获取当前步数，然后在目前的步数的基础上加1000步，然后将信息返回给微信运动。微信运动就会误以为我们运动了1000步，从而达到了欺骗的效果。
关键代码如下：
首先hook android.hardware.SystemSensorManager$SensorEventQueue这个类的dispatchSensorEvent()函数：
final Class? sensorEL = findClass("android.hardware.SystemSensorManager$SensorEventQueue",lpparam.classLoader);
XposedBridge.hookAllMethods(sensorEL, "dispatchSensorEvent", new XC_MethodHook()
接着我们在记步传感器把步数信息返回给微信运动之前，将返回的步数加上1000步：
protected void beforeHookedMethod(MethodHookParam param) throws
Throwable {
XposedBridge.log(" mzheng Hooked method: " + param.method);
((float[]) param.args[1])[0]=((float[]) param.args[1])[0]+1000*WechatStepCount;
WechatStepCount+=1;
…
另外我们还可以使用一些传感器的接口获取一些数据的信息：
Sensor ss = ((SparseArraySensor) field.get(0)).get(handle);
XposedBridge.log(" SensorEvent: sensor=" + ss);
比如说x就代表开机以来行走的步数，timestamp是获取步数时候的时间戳等。
另外，我们不仅在android上可以hook计步器，在iOS上也是可以通过越狱后hook iHealth的API接口达到同样的作弊效果，有兴趣的同学可以继续研究。
