博图V14项目如何加密防止别人更改程序

博图V14项目如何加密防止别人更改程序,第1张

加密分为两种方式:程序块加密和CPU加密。这里以14版本的软件为例,不同版本的方法都差不太多。

首先我来介绍一下如何对程序块进行加密。打开软件,进入项目视图,到“程序块”内找到想要加密的程序块,单击右键,选择属性。3在d出的块属性窗口下,选择常规列表里的“保护”选项,单击保护选项内的“保护”按钮,d出“专有技术保护”对话框。默认情况下,块是没有保护的,这时你单击“定义”按钮,就可以给块添加相应的密码保护了。在这里还可以将块绑定到固定的CPU或存储卡上,防止别人拷贝。4那么如何取消块的保护呢?这里设置的比较隐晦。还是打开刚刚加保护的块,单击保护选项内的“保护”按钮,d出“专有技术保护”对话框。这时你会发现它勾选了一个“隐藏代码(专有技术保护)”选项。你需要勾掉这个选项,然后输入密码,点击确定,这样保护就取消了5如何对CPU加保护呢打开软件,进入“项目视图”,选择“设备视图”。在”设备视图”内找到需要加密的PLC,双击后,能看到这个PLC的常规选项。6找到常规选项下的,防护与安全,单击后你可以在这里设置CPU的密码。密码分为四级保护,默情况认下是无任何保护的,具体每一级的作用程序内都有相应的说明。在“防护与安全“ 选项下还可以设置通讯的保护功能这里就不一一介绍了,感兴趣的同学可以自己研究一下。

360软件----优化加速---启动项-----右键选中不想要的启动项目----删除----这样它的开机启动注册表项就删除了。

安装或升级软件都可能会自动修改启动项目,但360会提示你允许还是阻止。

如果想要一个办法可以永远自动阻止任何程序修改开机启动项,呵呵!只能开玩笑的说说。当你设置好启动项后,不要升级和安装任何软件,也不要上网。

一种android应用程序防篡改的方法、系统及计算机存储介质,基于内存检测的动态防篡改的检测方案,检测到恶意代码注入时进行即时反制,自动恢复成原始的程序,更加有效和准确地进行应用程序的自我保护,同时也保障用户的安全使用。

根据本发明一方面,提供了一种android应用程序防篡改的方法,包括:

检测当前函数的第一标志是否为第一预定标志;

比较所述当前函数的内存结构与原函数的内存结构,判断所述当前函数是否被篡改;

如果所述当前函数被篡改,则将当前函数恢复为原函数。

示例性地,所述检测当前函数的第一标志是否为第一预定标志包括:在dalvik运行模式下,检测当前函数的修饰符是否为acc_native。

示例性地,所述检测当前函数的第一标志是否为第一预定标志包括:在art运行模式下,检测当前函数的access_flags是否标识为被xposedhook。

示例性地,所述比较所述当前函数的内存结构与原函数的内存结构包括:通过获取所述当前函数的xposedhookinfo,并将其转换为method结构,比较所述当前函数的method结构与所述原函数的method结构。

示例性地,所述转换为method结构包括:在dalvik运行模式下,通过获取当前函数method的insns即xposedhookinfo,将其转换为method结构。

示例性地,所述转换为method结构包括:在art运行模式下,通过获取当前函数method的entry_point_from_jni,将hookinfo->original_mathod转换为artmethod结构。

示例性地,所述判断所述当前函数是否被篡改包括:如果所述当前函数的method结构与原函数的method结构中除了修改过的值,其余的值都相同,则确定当前函数被注入代码。

示例性地,在dalvik运行模式下,修改过的值包括:method结构中的accessflags,以及nativefunc、insns、registerssize、outssize中的至少一个;其余的值包括:clazz、methodindex、name、shorty中的至少一个。

示例性地,在art运行模式下,修改过的值包括:artmethod类结构中的access_flags_,以及entry_point_from_jni_、entry_point_from_quick_compiled_code_、dex_code_item_offset_中的至少一个;其余的值包括:declaring_class_、dex_method_index_、method_index_中的至少一个。

示例性地,将当前函数恢复为原函数包括:将检测到被篡改的当前函数的内存空间替换为备份的原函数内存空间。

根据本发明另一方面,提供了一种android应用程序防篡改的系统,包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述方法的步骤。

根据本发明另一方面,提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被计算机执行时实现上述方法的步骤。

根据本发明实施例的一种android应用程序防篡改的方法、系统和存储介质,采用非接触式的方法,基于内存检测的动态防篡改的检测方案,检测到恶意代码注入时进行即时反制,自动恢复成原始的程序,更加有效和准确地进行应用程序的自我保护,同时也保障用户的安全使用。

附图说明

通过结合附图对本发明实施例进行更详细的描述,本发明的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本发明实施例的进一步理解,并且构成说明书的一部分,与本发明实施例一起用于解释本发明,并不构成对本发明的限制。在附图中,相同的参考标号通常代表相同部件或步骤。

图1是用于实现根据本发明实施例的一种android应用程序防篡改的方法的示意性流程图;

图2是用于实现根据本发明实施例的在dalvik运行模式下检测当前函数是否被篡改的示意性流程图;

图3是用于实现根据本发明实施例的在art运行模式下检测当前函数是否被篡改的示例的示意性流程图;

图4是用于实现根据本发明实施例的在dalvik运行模式下恢复原函数的示例的示意性流程图;

图5是用于实现根据本发明实施例的在art运行模式下恢复原函数的示例的示意性流程图。

具体实施方式

为了使得本发明的目的、技术方案和优点更为明显,下面将参照附图详细描述根据本发明的示例实施例。显然,所描述的实施例仅仅是本发明的一部分实施例,而不是本发明的全部实施例,应理解,本发明不受这里描述的示例实施例的限制。基于本发明中描述的本发明实施例,本领域技术人员在没有付出创造性劳动的情况下所得到的所有其它实施例都应落入本发明的保护范围之内。

dex文件是android应用程序的可执行文件,如前所述,例如,基于xposed的开源框架下,动态注入的恶意代码,把原有函数的method结构体进行了拷贝,保存到一个新的地址a指向的内存空间,同时修改原函数的修饰符,修改原函数的入口指向一个回调函数,回调函数内容包含被注入的代码和原函数的代码(即a所指向的程序),保存原函数的代码是为了运行被注入的代码之后能够运行原函数的逻辑。这样原函数被调用时则会执行回调函数,原函数原有的运行逻辑或参数就被篡改了。

具体来说,例如:在dalvik运行模式下,首先通过拷贝当前函数相关信息保存到hookinfo实现原函数的备份,接着修改当前函数的method修饰符为acc_native(accessflags与0x00000100进行或运算),修改当前函数的nativefunc指向hook回调方法,以及替换当前函数的method->insns指向hookinfo,最后修正当前函数的registerssize及outssize;在art运行模式下,首先通过拷贝当前函数相关信息保存到hookinfo->original_method实现原函数的备份,接着修改当前函数的artmethod->access_flags_(与0x10000000进行或运算),以标志此函数为被注入的函数,替换当前函数的entry_point_from_jni_指向hookinfo,修改entry_point_from_quick_compiled_code_指向hook回调函数,最后修改dex_code_item_offset_为0。

这种对android应用程序的动态注入篡改程序是无法被现有的基于静态文件检测的方法所检测的。

因此,本发明实施例提出了一种android应用程序防篡改的方法。参考图1来描述用于实现本发明实施例的一种android应用程序防篡改的方法100。

首先,在步骤s110,检测当前函数的第一标志是否为第一预定标志;

在步骤s120,比较所述当前函数的内存结构与原函数的内存结构,判断所述当前函数是否被篡改;

在步骤s130,如果所述当前函数被篡改,则将当前函数恢复为原函数。

根据本发明实施例,步骤110可以进一步地包括:第一标志包括当前函数的修饰符或access_flags访问标志;第一预定标志包括acc_native或被xposedhook。

在一个实施例中,在dalvik运行模式下,检测当前函数的修饰符是否为acc_native。

在另一个实施例中,在art运行模式下,检测当前函数的access_flags是否标识为被xposedhook。

根据本发明实施例,步骤120可以进一步地包括:所述比较所述当前函数的内存结构与原函数的内存结构包括:通过获取所述当前函数的xposedhookinfo,并将其转换为method结构,比较所述当前函数的method结构与所述原函数的method结构。

根据本发明实施例,步骤120还可以进一步地包括:所述判断所述当前函数是否被篡改包括:如果所述当前函数的method结构与原函数的method结构中除了修改过的值,其余的值都相同,则确定当前函数被注入代码。

在一个实施例中,参见图2,图2示出了用于实现根据本发明实施例的在dalvik运行模式下检测当前函数是否被篡改的示例的示意性流程图。具体来说:

在dalvik运行模式下,首先通过获取当前函数method(标识为curmethod)的insns即xposedhookinfo,将其转换为method结构(标识为originmethod);

然后,比较所述当前函数中curmethod与originmethod的内存结构,如果除去修改过的值,其余的值都相同,就确定所述当前函数函数被xposed注入了代码。其中,修改过的值包括:method结构中的accessflags,以及nativefunc、insns、registerssize、outssize中的至少一个;其余的值包括:clazz、methodindex、name、shorty中的至少一个。

在另一个实施例中,参见图3,图3示出了用于实现根据本发明实施例的在art运行模式下检测当前函数是否被篡改的示例的示意性流程图。具体来说:

在art运行模式下,首先通过获取当前函数method(标识为curmethod)的entry_point_from_jni_即xposedhookinfo,将hookinfo->original_mathod转换为artmethod结构(标识为originmethod)。

然后,比较所述当前函数中curmethod与originmethod的内存结构,如果除去修改过的值之外,其余的值都一样,就可以判断该函数被xposed注入了代码。其中,修改过的值包括:artmethod类结构中的access_flags_,以及entry_point_from_jni_、entry_point_from_quick_compiled_code_、dex_code_item_offset_中的至少一个;其余的值包括:declaring_class_、dex_method_index_、method_index_中的至少一个。

根据本发明实施例,步骤230可以进一步地包括:将检测到被篡改的当前函数的内存空间替换为备份的原函数内存空间。

在一个实施例中,参见图4,图4示出了根据本发明实施例的在dalvik运行模式下恢复原函数的示例的示意性流程图。具体来说:在dalvik运行模式下,恢复当前函数method(标识为curmethod)为原函数originmethod的内容。

在另一个实施例中,参见图5,图5示出了实现根据本发明实施例的在art运行模式下恢复原函数的示例的示意性流程图。具体来说:在art运行模式下,恢复当前函数method(标识为curmethod)为原函数originmethod的内容。

本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。

根据本发明实施例,还提供了一种android应用程序防篡改的系统,包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现上述方法的步骤。

此外,根据本发明实施例,还提供了一种计算机可读存储介质,在所述存储介质上存储了程序指令,在所述程序指令被计算机或处理器运行时用于执行本发明实施例的android应用程序防篡改方法的相应步骤。所述存储介质可以包括只读存储器,可擦除可编程只读存储器等各种存储器,或上述存储介质的任意组合。

根据本发明实施例的android应用程序防篡改方法、系统以及存储介质,基于内存检测的动态防篡改的检测方案,检测到恶意代码注入时进行即时反制,自动恢复成原始的程序,更加有效和准确地进行应用程序的自我保护,同时也保障用户的安全使用。

尽管这里已经参考附图描述了示例实施例,应理解上述示例实施例仅仅是示例性的,并且不意图将本发明的范围限制于此。本领域普通技术人员可以在其中进行各种改变和修改,而不偏离本发明的范围和精神。所有这些改变和修改意在被包括在所附权利要求所要求的本发明的范围之内。本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。

此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

以上所述,仅为本发明的具体实施方式或对具体实施方式的说明,本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。本发明的保护范围应以权利要求的保护范围为准。

android应用程序被恶意篡改,除了反编译修改静态代码再重打包的方式进行静态篡改,还包括动态篡改,即原始应用程序安装之后,对原有程序动态注入恶意代码,在程序运行过程中改变程序的运行路径及运行参数。现有的应用程序防篡改的方法一般是基于安装包的静态文件校验,如对应用程序的存储文件进行校验生成验证文件再打包到安装包中的方法,或通过对apk进行解压修改classes.dex执行文件重新打包的方法。这种基于静态文件校验的方法的不足之处在于无法检测程序被动态篡改的情况,例如程序被动态注入恶意代码,基于静态文件的检测方法就并无法检测出程序被篡改。这些恶意行为可能造成用户隐私被窃取、被远程 *** 控等安全问题。

因此,现有技术中存在无法检测动态注入的恶意代码,以及应用程序安全性低的问题。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/yw/11563883.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-17
下一篇 2023-05-17

发表评论

登录后才能评论

评论列表(0条)

保存