本发明涉及一种APP重打包验证方法和装置，属于Android系统领域。
背景技术：
因为Android的开放性以及google play在国内的无法正常工作，Android平台的恶意应用问题一直非常突出。各个应用商店和论坛的应用管理非常混乱，其中二次重打包添加广告甚至添加恶意代码是国内恶意应用泛滥的重要原因。另外，对android应用的非法调试往往也需要利用二次重打包技术，防止和检测应用重打包具有非常重要的安全意义。二次重打包技术，往往通过逆向apk代码，修改或添加代码逻辑，而后利用恶意者自己生成的密钥对重新对修改的apk代码进行签名打包，发布到apk商店或论坛，危害重大。
现有技术一般通过第三方的终端监测或者专门的检测中心实现对重打包应用的检测，适合第三方安全软件商以及应用商店应用检测机构。业务运营商因为缺少对终端环境的把控，使得应用本身很难检测旗下应用是否被重打包，重打包应用往往对应用和业务逻辑进行调试，添加广告外链，损害业务运营商的用户体验和业绩。
技术实现要素：
为了解决上述问题，本发明通过提供一种APP重打包验证方法和装置。
本发明采用的技术方案一方面为一种APP重打包验证方法，包括以下步骤：为APP设置若干流程标记，所述流程标记用于激活并输出检校信息；验证本地系统是否为定制系统，所述定制系统用于支持APP运行，接受APP发出的检校信息并验证；启动APP，APP基于流程标记激活并输出检校信息，所述定制系统接收并验证检校信息，基于验证结果修改APP的访问权限。
优选地，所述流程标记基于APP接口调用记录激活检校信息输出指令，该检校信息输出指令用于调用数字签名信息，整合数字签名信息和流程标记ID，标记整合之后的信息为检校信息。
优选地，所述APP输出系统识别指令至本地系统，基于本地系统的系统ID验证本地系统是否为定制系统。
优选地，所述定制系统基于流程标记ID读取预设的数字签名信息以验证检校信息。
优选地，所述定制系统接收并验证检校信息，如果检校结果为不通过则生成验证反馈信息并发送至APP服务器的客服单元。
优选地，所述定制系统接收并验证检校信息，如果检校结果为不通过则生成图形化的异常提醒信息并输出。
本发明采用的技术方案另一方面为一种APP重打包验证装置，该装置用于执行以下步骤：为APP设置若干流程标记，所述流程标记用于激活并输出检校信息；验证本地系统是否为定制系统，所述定制系统用于支持APP运行，接受APP发出的检校信息并验证；启动APP，APP基于流程标记激活并输出检校信息，所述定制系统接收并验证检校信息，基于验证结果修改APP的访问权限。
本发明的有益效果为建立一个流程运行检测机制，通过在APP设定流程的节点，当检测APP运行流程经过该流程节点的时候，发出对应流程的签名信息到系统进行验证，系统基于验证结果对APP运行进行控制，在系统层面对APP进行验证和控制处理，能够独立验证被修改的APP并增加对APP运行的控制能力。
附图说明
图1所示为基于本发明实施例的一种APP重打包验证方法的步骤的示意图。
具体实施方式
以下结合实施例对本发明进行说明。
基于发明的实施例1，一种APP重打包验证方法，包括以下步骤：为APP设置若干流程标记，所述流程标记用于激活并输出检校信息；验证本地系统是否为定制系统，所述定制系统用于支持APP运行，接受APP发出的检校信息并验证；启动APP，APP基于流程标记激活并输出检校信息，所述定制系统接收并验证检校信息，基于验证结果修改APP的访问权限。
APP在运行的时候，会依据设定的流程/步骤逐步的运行，通过执行不同的指令，调动不同的资源来完成运作；在这些流程中，通过增加若干个节点，当APP的流程/步骤到达这些节点的时候，则输出检校信息（主要基于各种数字签名信息，也可以是截至该节点位置的运行记录，即目前为止进行何种操作，例如读取何种资源，调用何种接口等记录）到系统，系统根据预设的资料和检校信息进行比对验证；设置节点的方式为在APP增加标记，该标记用于检测APP是否运行到某个节点（或者作为程序运行环节的一部分，即某个步骤完成之后，不是直接下一个流程而是激活这个标记），当该标记被触发之后，会激活一个读取程序，读取APP内置的签名信息等用于验证完整性的检校信息并输出到本地的系统（即APP运行的平台），本地系统基于验证结果决定对APP的支持，如果验证不通过则拒绝APP对本地系统资源的访问。
所述流程标记基于APP接口调用记录激活检校信息输出指令，该检校信息输出指令用于调用数字签名信息，整合数字签名信息和流程标记ID，标记整合之后的信息为检校信息。
APP在运行过程中，一定会进行各种接口的调用，流程标记通过检测接口调用的情况，确定APP运行所处的流程，当然确认APP运行到某个流程的时候，则激活检校信息输出指令，该指令会调用数字签名信息，并且整合流程标记ID（用于标识现在所处的流程，因为不同流程，其经历和内容都不一致，可以针对性的输出不同的数字签名信息，本地系统也能据此读取对应的用于验证的信息）。
所述APP输出系统识别指令至本地系统，基于本地系统的系统ID验证本地系统是否为定制系统。
APP在运行的第一步就是发送一条系统识别的指令，通过本地系统的ID比较，可以知道APP现在运行的系统是否为所需的定制系统（定制系统存储有验证信息）。
所述定制系统基于流程标记ID读取预设的数字签名信息以验证检校信息。
所述定制系统接收并验证检校信息，如果检校结果为不通过则生成验证反馈信息并发送至APP服务器的客服单元。
定制系统可以将检校结果发送到APP的服务器的客服单元（例如支付宝，则发生到阿里巴巴公司与支付相关的客服），告知APP的正牌供应商，发现有被重打包的APP，同时将该重打包的APP的相关的版本，来源，异常位置等信息反馈给APP的正牌供应商。
所述定制系统接收并验证检校信息，如果检校结果为不通过则生成图形化的异常提醒信息并输出。
定制系统还有通过发出一个图形化的信息，例如出现一个提醒框在显示器上，那么在APP运行至某个环节，会出现一个提醒信息说明正在使用的APP存在风险。
基于发明的实施例2，一种APP重打包验证装置，该装置用于执行以下步骤：为APP设置若干流程标记，所述流程标记用于激活并输出检校信息；验证本地系统是否为定制系统，所述定制系统用于支持APP运行，接受APP发出的检校信息并验证；启动APP，APP基于流程标记激活并输出检校信息，所述定制系统接收并验证检校信息，基于验证结果修改APP的访问权限。
基于发明的实施例3，包括签名服务，APP，应用系统和验证模块四个模块。其中，签名服务是系统可信的后台服务，提供签名接口给APP调用，签名服务主要对当前调用该接口的安装信息（app的开发者公钥，APP摘要值，包名），运行信息（apk加载资源，apk权限）等应用信息进行签名，签名密钥由系统维护，存放在安全芯片或可信执行环境等安全场景下。应用系统在主要业务逻辑（即APP流程）运行前通过调用验证模块设置检测点，验证不通过则表示当前应用被重打包，可以拒绝APP访问或告警后台。APP需要与应用系统后台一致，在执行主要业务逻辑运行前调用签名服务接口以便供验证模块。APK信息是指APK的开发者公钥/证书，摘要值，包名，版本号等应用信息，可能有一至若干个，在发布APP前部署到验证模块。验证签名信息，与密钥/密钥链对应，包括验证数字签名的公钥（证书）或公钥链（证书链）。
第一步，（1）设置检测点：在主要业务逻辑执行前设置若干检测点，检测点即应用系统调用验证模块或者由APP调研签名服务，检测点基于业务逻辑设计（例如支付宝包括开启，输入金额，确认等业务，根据重要程度设置流程点）。（2）密钥和信息供给：签名服务模块与验证模块通过线下或线上协商密钥。密钥使用符合相关非对称算法的密钥；签名的密钥对可以跟app对应，即不同的app临时生成不同的公私钥对，但公钥必须通过固化在设备中的设备密钥签名，形成密钥链。系统厂商向业务开发商公开签名对应的公钥（证书）或设备公钥（证书），验证模块把该公钥（证书）作为验证签名信息。验证模块通过线下方式获取APK信息和验证签名信息。
第二步，APP特定业务逻辑处调用签名服务接口。签名信息包括签名服务模块返回的时间戳，相关的签名公钥或证书链（存在设备密钥时，设备私钥对签名公钥相关信息签名形成证书）以及app开发者的公钥和系统层可获取的应用信息。签名服务模块对应用的签名服务进行签名响应，签名内容包括对开发者app的公钥提取和应用信息获得，时间戳。响应给app签名值，时间戳，开发者公钥，应用信息，签名的公钥或证书链。
第三步，APP在特定业务逻辑检查点处提交签名值和签名信息进行报告，应用系统在对应的业务逻辑检查点请求验证模块进行验证。
第四步，验证模块对签名信息和签名值进行验证。首先，使用验证签名信息验证签名公钥。若签名信息包含证书链，则逐级验证证书链的公钥，直至验证签名公钥；否则签名信息只包含签名对应的公钥，对把该公钥与验证签名信息的公钥比对。签名公钥验证不通过则直接返回给应用系统检验不通过错误码。其次，验证签名值。使用签名公钥对签名值进行验证，比对签名信息的摘要。不通过则直接返回给应用系统检验不通过错误码。最后，比对签名信息的时间戳，开发者公钥，应用信息，当时间戳是许可时间且开发者公钥/app摘要值与APK相符，则通过验证，返回验证正确码。否则当时间戳不在许可范围内，或者开发者公钥/app摘要值与APK不相符时，则说明验证不通过，返回错误码，app公钥，应用信息，时间戳，应用系统接收验证模块的返回码，当验证通过，则执行后续业务逻辑。否则验证不通过，把app公钥，应用信息，时间戳进行后台记录告警或者拒绝后续业务逻辑运行。
以上所述，只是本发明的较佳实施例而已，本发明并不局限于上述实施方式，只要其以相同的手段达到本发明的技术效果，都应属于本发明的保护范围。在本发明的保护范围内其技术方案和/或实施方式可以有各种不同的修改和变化。