CN105956456B - 一种对Android***进行四重联合签名验证的实现方法 - Google Patents

一种对Android***进行四重联合签名验证的实现方法 Download PDF

Info

Publication number
CN105956456B
CN105956456B CN201610266983.2A CN201610266983A CN105956456B CN 105956456 B CN105956456 B CN 105956456B CN 201610266983 A CN201610266983 A CN 201610266983A CN 105956456 B CN105956456 B CN 105956456B
Authority
CN
China
Prior art keywords
signature
dynamic link
link library
carries out
signing messages
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610266983.2A
Other languages
English (en)
Other versions
CN105956456A (zh
Inventor
陈丹伟
刘畅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing Post and Telecommunication University
Original Assignee
Nanjing Post and Telecommunication University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nanjing Post and Telecommunication University filed Critical Nanjing Post and Telecommunication University
Priority to CN201610266983.2A priority Critical patent/CN105956456B/zh
Publication of CN105956456A publication Critical patent/CN105956456A/zh
Application granted granted Critical
Publication of CN105956456B publication Critical patent/CN105956456B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开了一种对Android***进行四重联合签名验证的实现方法，该方法包括：第一重：使用Android API得到当前应用程序的签名信息，使用一种散列算法将签名信息提取出摘要，然后传入动态链接库中进行加盐和加密，再与网络位置上的签名信息进行对比；第二重：使用反射功能读取应用内部隐藏APK的签名，与使用Android API得到的签名信息进行签名校验；第三重：在Jni中利用反射机制对getPackageInfo方法获取的签名信息与保存在动态链接库中的签名信息进行对比，将对动态链接库的摘要信息再做一次重复验证，如果动态链接库中被改变，那么提示用户去正规渠道重新下载应用；第四重：利用NDK编译一个binary可执行文件，在其中利用***中预留的apk与保存在bianry中的hash进行对比。

Description

一种对Android***进行四重联合签名验证的实现方法
技术领域
本发明涉及一种对Android***进行四重联合签名验证的实现方法，属于信息安全技术领域。
背景技术
随着智能手机的普及和移动互联网技术的发展，手机成了人们日常生活中不可缺少的一部分。在众多的智能手机操作***里面，Android***以其开源、自由、免费等特点占有着很大的市场占有率。随着Android***的流行和个人开发者的日渐增多，针对Android平台的安全攻击手段也层出不穷，增加了造成经济损失和隐私泄露的风险。因此，如何在Android平台上编写出安全的应用已成为当今Android开发者需要研究的方向。
Android***是一个开放平台，这意味着用户可以自行安装各种来源的安装文件。使用baksmali、smali等工具可以对Android应用进行反汇编和汇编。但是，攻击者往往可以利用反汇编工具将App反汇编，加入反汇编的恶意代码后使用smali等工具进行整合打包。面对纷繁复杂的Android安装途径，如何防止被篡改关键业务逻辑和重打包成了一个关键问题。而本发明能够很好地解决上面的问题。
发明内容
本发明目的在于针对上述现有技术的不足，提供了一种对Android***进行四重联合签名验证的实现方法，该方法实现了对Android平台的应用程序进行多重签名验证，能够很好地防止应用程序被篡改及重打包，从而保证了应用程序的安全性。
本发明解决其技术问题所采取的技术方案是：一种对Android***进行四重联合签名验证的实现方法，包括：
第一重：使用Android API得到当前应用程序的签名信息，使用一种散列算法将签名信息提取出摘要，然后传入动态链接库中进行加盐和加密，再与网络位置上的签名信息进行对比。
第二重：使用反射功能读取应用内部隐藏APK的签名，与使用Android API得到的签名信息进行签名校验。
第三重：在Jni中利用反射机制对getPackageInfo方法获取的签名信息与保存在动态链接库中的签名信息进行对比。在这个基础之上，我们将对动态链接库的摘要信息再做一次重复验证，如果动态链接库中被改变，那么提示用户去正规渠道重新下载应用。
第四重：利用NDK编译一个binary可执行文件，在其中利用***中预留的apk与保存在bianry中的hash进行对比。
其中，所述的第一重签名验证，使用的是android.content.pm.PackageManager类getPackageInfo()函数，获取PackageInfo，再从中提取signature对象。
其中，所述的第一重签名验证中，使用的散列算法是一种类似MD5的自定义算法，可将signature对象提取出32位的16进制的摘要。
其中，所述的加盐和加密操作，是将上一步获取的32位摘要传入动态链接库中之后进行的操作，加盐是指将原来的32为摘要与一段随机的n位随机数相关联，加密采用的是改进的MD5算法。
其中，经过加盐和加密的摘要需要传回Java层，与服务端的值进行对比。
更具体地，用户可能在设备没有连接网络的情况下安装完成；所以本发明使用广播接收器来监听网络连接情况，如果网络连接并且SharedPreferences中的未联网验证的value是true，则在下一次网络连接时进行签名验证。
其中，所述的第二重签名验证中，使用的是Java层面getPackageInfo方法得到的签名信息与使用getPackageArchiveInfo方法获取的本地保存的空apk File的签名信息进行对比。
其中，本地的空apk File保存在应用程序安装文件的/resets/raw/中。
其中，本地的空apk File是一个仅仅经过开发者签名的没有任何内容的空apk文件，目的在于与本地签名进行对比。
其中，所述的反射机制，反射的是PackageParser类，PackageParser类在AndroidSDK中被标记成了hide属性，但可以通过反射机制获取这个类的名称。
其中，在高于Android 5.0的***上，采用getPackageArchiveInfo()方法来读取上述隐藏apk File的签名信息。
其中，本发明采取判断判断Android API LEVEL的方式，自动判断设备的***版本号，来决定使用哪一种方式获取本地空APK FILE的签名信息。
其中，所述的第三重签名验证中，采用的反射机制是在Jni中实现的，反射的是Java层的与第一重中类似的getPackageInfo签名对比算法,但完全用native C在动态链接库中实现。
其中，所述的第三重签名验证中，获取了签名摘要之后，直接与与存在动态链接库中保存的签名摘要进行对比。
其中，所述的第三重签名验证中，在生成动态链接库后，会对动态链接库进行提取，然后进行混淆和加密，最后再与原来的动态链接库进行替换。
其中，所述的对动态链接库的混淆，是修改ELF头的链接视图的e_shoff，e_shensize等字段，修改方式是nop，经过这样的操作，使用IDA等软件无法打开动态链接库。
其中，所述的对动态链接库的加密，是将想要保护的函数放入到特定section中加密后再打包成Apk，在运行时解密so。这里利用了gcc的_attribute_属性机制，使用了secction子项。
进一步地，利用section子项，把函数或者数据放入指定名的输入段，jstringencrypt(JNIEnv*)_attribute_((section(".test")))；，在jni中把encrypt()函数放到.test section里面。
更具体地，对动态链接库加密的步骤是：首先，在动态库编译好之后，在外部轮询shstrtab(String Header String Table)，这个shstrtab的位置在so header的shoff处开始，长度是shnum。然后，使用e_shnum作为count计数，用strcmp对比shname跟.test，一致之后，将这部分section的内容保存起来。最后，使用加密算法加密保存起来的内容，然后写回so。
更具体地，首先从Elf32_Ehdr(so header)中读取shoff、shnum、shstrtab等offset，然后读取String table中的字符串shstrtab，存放进str，读取section header,存放进shdr。根据shdr->sh_name在str中的位置，与.test循环对比。根据shdr->sh_offset与shdr->sh_size字段的索引，把.test中的内容保存到tmpSection。将tempSection右移4位后取反，也就是*tmpSection＝～(*tmpSection>>4)，最后把加密过的tmpSection保存到so中。根据前面段落的分析，section字段是可以修改的，并不影响so的运行，那么直接把shdr->addr写入e_shoff，将shdr->sh_size、addr写入e_entry。
进一步地，在对动态链接库进行加密之后，在应用程序运行时对动态链接库进行实时解密。解密的流程是，读e_shoff/e_entry获取加密Section的addr和offset，用mprotect()对.CODE段的内容增加读写权限，然后将这部分section使用之前加密算法的解密方法进行解密，最后定义void decrypt()_attribute_(constructor)；保证decrypt()首先被调用。
进一步地，如果校验失败，通过反射Toast的方法对用户进行提示。
其中，所述的第四重签名验证中，采用的是在ELF可执行文件中进行签名校验。
更具体地，这个ELF可执行文件使用C语言编写，使用NDK编译。
更具体地，这个可执行文件，使用文件操作读取应用程序安装目录/data/app/下的apk安装文件的CERT.SF，从而获取签名信息；然后将签名信息与预先放置在ELF中的字串进行对比。
更具体地，这个ELF可执行文件中会在应用程序确定能够获取root权限之后自动通过脚本安装到/system/xbin/中去。
进一步地，由于不同版本的应用安装文件保存位置不同，本方案会针对Android版本来对base.apk的路径进行判断，以便正确读取签名信息。
进一步地，对于ELF可执行文件的启动，将唤醒操作写入到debuggerd中去，以便能够在开机启动debuggerd的时候自动后台运行ELF可执行文件。
附图说明
图1是本发明的方法流程图。
图2是动态链接库中的签名校验和对校验算法/HASH算法的加密示意图。
图3是动态链接库的加密流程图。
图4是利用ELF可执行文件进行签名验证的流程图。
具体实施方式
如图1所示，本发明提供了一种对Android***进行四重联合签名验证的实现方法，该方法包括如下步骤：
步骤1；在Java层利用getPackageInfo对签名进行提取，然后获取服务器上的预留信息，进行对比。使用的散列算法是一种类似MD5的自定义算法，可将signature对象提取出32位的16进制的摘要。其中，所述的加盐和加密操作，是将上一步获取的32位摘要传入动态链接库中之后进行的操作，加盐是指将原来的32为摘要与一段随机的n位随机数相关联，加密采用的是改进的MD5算法。经过加盐和加密的摘要需要传回Java层，与服务端的值进行对比。
步骤2：利用Java层面getPackageInfo方法得到的签名信息与使用getPackageArchiveInfo方法获取的本地保存的空apkFile的签名信息进行对比。第三，在Jni中利用反射机制对getPackageInfo方法获取的签名信息与保存在动态链接库中的签名信息进行对比。第三，利用反射机制，将Java层的签名功能放入动态链接库中。
步骤3：对动态链接库进行加密。如图2，利用section子项，可以把函数或者数据放入指定名的输入段。具体操作如下。
jstring encrypt(JNIEnv*)_attribute_((section(".test")))；，就能够在jni中把encrypt()函数放到.test section里面。本发明在动态库编译好之后，按照以下步骤操作：
(1)轮询shstrtab(String Header String Table)，这个shstrtab的位置在soheader的shoff处开始，长度是shnum。
(2)使用e_shnum作为count计数，用strcmp对比shname跟.test，一致之后，将这部分section的内容保存起来。
(3)使用加密算法加密保存起来的内容，然后写回so。
具体来说，首先从Elf32_Ehdr(so header)中读取shoff、shnum、shstrtab等offset，然后读取String table中的字符串shstrtab，存放进str，读取section header,存放进shdr。根据shdr->sh_name在str中的位置，与.mytext循环对比。根据shdr->sh_offset与shdr->sh_size字段的索引，把.mytext中的内容保存到tmpSection。将tempSection右移4位后取反，也就是*tmpSection＝～(*tmpSection>>4)，最后把加密过的tmpSection保存到so中。根据前面段落的分析，section字段是可以修改的，并不影响so的运行，那么直接把shdr->addr写入e_shoff，将shdr->sh_size、addr写入e_entry。JNI中进行的操作是构建加密section，以及构建constructor来动态解密；而外置Shell添加模块进行的操作是，对经过打包的so文件进行提取然后进行混淆和加密，具体流程如图3。
进一步地，对动态链接库进行解密。解密是在应用程序运行时加载动态库的时候进行的，步骤是，读e_shoff/e_entry获取加密Section的addr和offset，用mprotect()对.CODE段的内容增加读写权限，然后将这部分section使用之前加密算法的解密方法进行解密，最后定义void decrypt()__attribute__(constructor)；保证decrypt()首先被调用。
步骤4：编写ELF可执行文件；这个可执行文件，使用文件操作读取应用程序安装目录/data/app/下的apk安装文件的CERT.SF，从而获取签名信息；然后将签名信息与预先放置在ELF中的字串进行对比。这个ELF可执行文件使用C语言编写，使用NDK编译。这个ELF可执行文件中会在应用程序确定能够获取root权限之后自动通过脚本安装到/system/xbin/中去。由于不同版本的应用安装文件保存位置不同，本方案会针对Android版本来对base.apk的路径进行判断，以便正确读取签名信息。具体工作流程如图4。
对于ELF可执行文件的启动，将唤醒操作写入到debuggerd中去，debuggerd是init.rc中的一个启动项，将ELF文件交予它来启动可以保证开机启动。如此就能够在开机启动debuggerd的时候自动后台运行ELF可执行文件。
特别地，发明人注意到debuggerd并非在所有设备上都是shell脚本，在有些机器上是可执行文件，所以，采用转接的方式，将原本的debuggerd一律保存成debuggerd_origin，并且创建新的debuggerd文件，里面执行两个操作，第一是启动本方案中提到的ELF可执行文件，第二是执行debuggerd_origin。
本发明具有如下优点：采取多重签名验证，本地和网络验证中加入对动态链接库的混淆和加密操作，并且加入了动态链接库中的验证和ELF可执行文件中的验证，使得攻击者对应用程序的重打包操作极为困难，大大提升了应用程序的安全性。
虽然上文描述了本发明的具体实施方式，但是熟悉本技术领域的技术人员应当理解，我们所描述的具体实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。

Claims (9)

1.一种对Android***进行四重联合签名验证的实现方法，其特征在于，包括：
第一重：使用Android API得到当前应用程序的签名信息，使用一种散列算法将签名信息提取出摘要，然后传入动态链接库中进行加密，再与网络位置上的签名信息进行对比；
第二重：使用反射功能读取应用内部隐藏APK的签名，与使用Android API得到的签名信息进行签名校验；
第三重：在Jni中利用反射机制对getPackageInfo方法获取的签名信息与保存在动态链接库中的签名信息进行对比，将对动态链接库的摘要信息再做一次重复验证，如果动态链接库被改变，那么提示用户去正规渠道重新下载应用；
第四重：利用NDK编译一个binary可执行文件，在其中利用***中预留的apk与保存在binary中的hash进行对比。
2.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：在第一重签名验证，使用的是android.content.pm.PackageManager类getPackageInfo()函数，获取PackageInfo，再从中提取signature对象；所述的第一重签名验证中，使用的散列算法是将signature对象提取出32位的16进制摘要；所述的加密操作，是将上一步获取的32位摘要传入动态链接库中之后进行的操作，加密采用的是改进的MD5算法；经过加密的摘要应传回Java层，与服务端的值进行对比。
3.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：所述方法使用广播接收器来监听网络连接情况，如果网络连接并且SharedPreferences中的未联网验证的value是true，则在下一次网络连接时进行签名验证。
4.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：在第二重签名验证中，使用的是Java层面getPackageInfo方法得到的签名信息与使用getPackageArchiveInfo方法获取的本地保存的空apk File的签名信息进行对比；本地的空apk File保存在应用程序安装文件的/resets/raw/中；本地的空apk File是一个仅仅经过开发者签名的没有任何内容的空apk文件，然后与本地签名进行对比。
5.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：在第三重签名验证中，所述的反射机制，反射的是PackageParser类；采用的反射机制是在Jni中实现的，反射的是Android提供的getPackageInfo函数；获取了签名摘要之后直接与动态链接库中保存的签名摘要对比。
6.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：对动态链接库的混淆，是修改ELF头的链接视图的e_shoff，e_shensize字段，修改方式是nop，经过这样的操作，使用IDA软件无法打开动态链接库；对动态链接库的加密，是将想要保护的函数放入到特定section中加密后再打包成Apk，利用gcc的__attribute__属性机制和section子项，把函数或者数据放入指定名的输入段实现加密和运行时解密。
7.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：对动态链接库加密的步骤是：首先，在动态库编译好之后，在外部轮询shstrtab(String Header String Table)，这个shstrtab的位置在动态链接库header的shoff处开始，长度是shnum，然后，使用e_shnum作为count计数，将这部分section的内容保存起来，最后，使用加密算法加密这部分内容，写入动态链接库中。
8.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：所述方法包括：首先从Elf32_Ehdr(动态链接库header)中读取shoff、shnum、shstrtab存放进str，读取section header,存放进shdr，根据shdr->sh_name在str中的位置，与.test循环对比，根据shdr->sh_offset与shdr->sh_size字段的索引，把.test中的内容保存到tmpSection，将tempSection右移4位后取反，最后把加密过的tmpSection保存到动态链接库中，在对动态链接库加密之后，在应用程序运行时对动态链接库进行实时解密；解密的流程是：读e_shoff/e_entry获取加密Section的addr和offset，用mprotect()对.CODE段的内容增加读写权限，然后将这部分section使用对应的解密方法进行解密。
9.根据权利要求1所述的一种对Android***进行四重联合签名验证的实现方法，其特征在于：在第四重签名验证中，采用的是在ELF可执行文件中进行签名校验；所述ELF可执行文件使用C语言编写，使用NDK编译；所述ELF可执行文件，使用文件操作读取应用程序安装目录/data/app/下的apk安装文件的CERT.SF，从而获取签名信息；然后将签名信息与预先放置在ELF中的字串进行对比；所述ELF可执行文件中会在应用程序确定能够获取root权限之后自动通过脚本安装到/system/xbin/中去；是针对Android版本来对base.apk的路径进行判断；对于ELF可执行文件的启动，将唤醒操作写入到debuggerd中去。
CN201610266983.2A 2016-04-26 2016-04-26 一种对Android***进行四重联合签名验证的实现方法 Active CN105956456B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610266983.2A CN105956456B (zh) 2016-04-26 2016-04-26 一种对Android***进行四重联合签名验证的实现方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610266983.2A CN105956456B (zh) 2016-04-26 2016-04-26 一种对Android***进行四重联合签名验证的实现方法

Publications (2)

Publication Number Publication Date
CN105956456A CN105956456A (zh) 2016-09-21
CN105956456B true CN105956456B (zh) 2019-02-19

Family

ID=56915880

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610266983.2A Active CN105956456B (zh) 2016-04-26 2016-04-26 一种对Android***进行四重联合签名验证的实现方法

Country Status (1)

Country Link
CN (1) CN105956456B (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106971098B (zh) * 2016-10-11 2020-06-02 阿里巴巴集团控股有限公司 一种防重打包的方法及其装置
CN106502668B (zh) * 2016-10-20 2019-08-23 武汉斗鱼网络科技有限公司 一种实现Android JNI反射的接口封装方法及***
CN106788973A (zh) * 2016-12-19 2017-05-31 四川九洲电器集团有限责任公司 一种签名方法和发送设备
CN107729746B (zh) * 2017-11-28 2020-06-12 苏州浪潮智能科技有限公司 一种基于数字签名的已安装应用程序防篡改方法及***
CN109960666B (zh) * 2017-12-22 2021-05-11 北京安天网络安全技术有限公司 反射与aidl获取并清理缓存方法及***
CN108259182B (zh) * 2018-01-08 2021-01-05 中国人民大学 一种Android应用重打包检测方法及装置
CN108629184A (zh) * 2018-05-18 2018-10-09 北京智游网安科技有限公司 一种ios用的sdk安全检测方法
CN109472148B (zh) * 2018-11-15 2021-04-02 百度在线网络技术（北京）有限公司 加载热补丁的方法、装置和存储介质
CN111353148B (zh) * 2020-02-07 2022-10-14 贝壳技术有限公司 一种确定应用程序是否被重打包的方法及设备
CN112134905B (zh) * 2020-11-20 2021-02-09 深圳市房多多网络科技有限公司 基于安卓***的签名方法、装置以及设备
CN112529423A (zh) * 2020-12-15 2021-03-19 青岛海尔科技有限公司 目标资源的获取方法及装置、存储介质、电子装置
CN114662062A (zh) * 2020-12-23 2022-06-24 北京奇虎科技有限公司 应用程序的篡改检测方法、装置、设备及存储介质
CN112613037A (zh) * 2020-12-29 2021-04-06 北京永新视博数字电视技术有限公司 一种代码校验方法及装置
CN112699398A (zh) * 2021-01-28 2021-04-23 厦门立林科技有限公司 一种安卓应用关键数据的保护装置、方法、设备及可存储介质
CN112861191B (zh) * 2021-04-23 2023-01-10 腾讯科技（深圳）有限公司 一种应用程序监控方法及装置
CN114301655B (zh) * 2021-12-20 2023-03-24 天翼爱音乐文化科技有限公司 基于Android的数据安全传输方法、***、装置及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103530559A (zh) * 2013-09-27 2014-01-22 北京理工大学 一种Android***的完整性保护***
CN104268468A (zh) * 2014-09-25 2015-01-07 福建升腾资讯有限公司 一种对Android***动态链接库保护方法及***

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8892904B2 (en) * 2012-09-13 2014-11-18 Intel Corporation Hardware enforced security governing access to an operating system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103530559A (zh) * 2013-09-27 2014-01-22 北京理工大学 一种Android***的完整性保护***
CN104268468A (zh) * 2014-09-25 2015-01-07 福建升腾资讯有限公司 一种对Android***动态链接库保护方法及***

Also Published As

Publication number Publication date
CN105956456A (zh) 2016-09-21

Similar Documents

Publication Publication Date Title
CN105956456B (zh) 一种对Android***进行四重联合签名验证的实现方法
KR101471589B1 (ko) 공통중간언어 기반 프로그램을 위한 보안 제공 방법
CN105683990B (zh) 用于保护动态库的方法和装置
EP1542112A1 (en) Open type general-purpose attack-resistant cpu, and application system thereof
CN103617401B (zh) 一种数据文件保护方法及装置
CN106022098A (zh) 一种应用程序的签名验证方法和装置
CN104680061A (zh) 一种Android环境下应用程序启动中代码签名验证的方法和***
WO2023029447A1 (zh) 模型保护方法、装置、设备、***以及存储介质
Gora et al. A flexible design flow for software IP binding in FPGA
CN103971034A (zh) 一种保护Java软件的方法及装置
US7552092B2 (en) Program distribution method and system
CN109241707A (zh) 应用程序的混淆方法、装置和服务器
Ozkan et al. Security analysis of mobile authenticator applications
CN109150834A (zh) 一种嵌入式设备license授权管理方法
CN107315945B (zh) 一种电子设备的磁盘解密方法和装置
US8745375B2 (en) Handling of the usage of software in a disconnected computing environment
van Schaik et al. Sok: Sgx. fail: How stuff get exposed
CN108923910A (zh) 一种移动应用apk防篡改的方法
Crăciun et al. Malware in the SGX supply chain: Be careful when signing enclaves!
CN112115430A (zh) 一种apk的加固方法、电子设备及存储介质
Aldoseri et al. Symbolic modelling of remote attestation protocols for device and app integrity on Android
Sun et al. Selwasm: A code protection mechanism for webassembly
Lloyd et al. Security analysis of a biometric authentication system using UMLsec and JML
CN104091101A (zh) 一种基于数字水印和java本地调用的数据加解密方法及***
Kumbhar et al. Hybrid Encryption for Securing SharedPreferences of Android Applications

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant