因为没有被match给amount，所以我们的加固就会主动的 folk或者主动生成这样的一个isolate的process，然后就会去检测这个这个 park PID以及 park PID mount里面的这个 max的信息有没有被I mount掉，但是最新版本的magic它会做一个优化，也就是说即便是在isolate的process，也无法去检测magazine的有关特征，那是怎么做到的？

主进程首先会后可Linux里面的一个set contest这样的一个接口，那这个 set context的接口执行之前的时候，先执行my site context，这个 my side context是进行一个sock的通信，它会与magic t matches d守护进程进行通信。当然这个 Mexico发现这个已经进程是一个isolated process，然后主动的去I mount掉，所以就会导致这个 isolated process。即便是在这样的环境下，也无法检测到有这个max的挂载信息。那现在我们主要是讲了这个三类框架的这样一个大体的原理以及使用的方法。

现在我们讲了第一部分及过签工具的这个种类以及原理，第二部分就是讲了框架的种类以及原理。那第三部分我们就会在安全加固当中会针对这比较具有代表性的以及成熟的这些工具进行这样的一个对抗，那我们是怎么对抗的？首先我们看一下过签工具的对抗，过签供应对抗，我们知道这个过签后的APP它会插入一些代码，这些代码会对安卓的一些API一些接口，进行拦截，进行一些hook，然后去修改成所释放的APK的这一个路径，那改成这个路径之后，我们它就会实现这样的一个被释放的apk的这样一个正常的加载，那我们所以就会进行三种类型的检测。

第一种类型我们就会检测这个 Apk的路径，那这个 APk的路径是不是安卓正常的一个系统路径，还是被这个过签工具所生成的新的APP所hook之后的这样的一个假的路径，这样的一个路径检测是非常的有效的，但是有一个前提条件，就是我们得需要找到这所有的过签工具，然后对所有的过签工具的这样一个路径的一些修改，以及他们所实现的这个路径的这样的一个地址，然后进行充分的调研，才能够覆盖到所有的这样的过签工具。

第二个就是我建议所有的开发者在实现open或者是read write等这样的一些读写操作的时候要一定使用svc的调用，因为在分数的情况下，普通的应用是很难通过svc hook进行拦截的。所以说很难对svc进行hook的话，就不会导致我们使用svc调用的这些 APP破解者可以拿到。第三就是hook检测，因为现在一些常见的过签工具，他们所使用的hook方法就是，主要是对其进行hook到为入口，主要是对这个 so的native层进行hook等等这样的hook的一些检测方法，也可以从根源上去解决这些问题。