App加密:常用加密方式和爱加密原理

摘要:对app加密可以防止应用在运营推广过程中被反编译, 恶意篡改、注入扣费代码、盗取数据等,保护应用的安全性、稳定性,同时对开发者的应有收入提供有力保障。

软体加密




伪加密

伪加密是Android4.2.x系统发布前的加密方式之一,通过java代码对APK(压缩文件)进行伪加密,其修改原理是修改连续4位字节标记为”P K 01 02”的后第5位字节,奇数表示不加密偶数表示加密。

虽然伪加密可以起到一定防破解作用,但也会出现问题,首先使用伪加密对其APK加密后市场无法对其进行安全检测,导致部分市场会拒绝这类APK上传;其次,伪加密的加密方式和解密方式也早已公布导致它的安全程度也大大降低;再次,Android4.2.x系统无法安装伪加密的APK;最后伪加密只是对APK做简单保护,在java层源码加壳保护、核心so库、资源文件、主配文件、第三方架包方面却没有任何保护处理。注意:高版本不支持这样的方法,所以还是不要尝试使用这样的加密方式了。

混淆保护

把原来有具体含义的类名,变量名,方法名,修改成让人看不懂的名字。

运行时验证

运行时验证,主要是指在代码启动的时候本地获取签名信息然后对签名信息进行检验来判断自己的应用是否是正版,如果签名信息不是正版则提示盗版或者直接崩溃。当然你可以把必要的数据放在服务器端。

破解:找到smali文件中,判断是否相等的部分。改为常量true,即失效。

总之,反编译一些apk之后,只要是java代码写的总会有smil文件。对于smil文件,如果耐心读的话,还是可以查看到一些关键代码的。

第三方加密工具

相较于应用来说,游戏apk因为采用cocos2d-x 或者 unity3D,采用的是c++ 和c# 编写的跨平台程序,在apk采用JNI的方式。所以没有smali,可以防止静态被破解apk包。

当然游戏包apk 在运行的时候,会把.*so加载到内存中。动态也是可以在内存中抓取相应的数据。只不NDK 相对于smali破解来说,根部不是一个层级的关系。

难道真的就没有好的加密方式吗。想做一个应用非要把核心部分使用ndk这么复杂的东西嘛。

其实,我们完全可以借助第三方工具。下文就以爱加密gameChange.apk为例展开篇幅。

1.jpg

该classes.dex是我原来的代码。没有混淆,没有任何的加密保护。反编译的话,真的是一丝不挂的漏了出来。

代码没有加密被反编译

该classes.dex是经过爱加密处理之后的,反编译之后发现莫名其妙的代码。其实这两个类是,运行使用jni加载so库的代码。

加密后的类库

NativeApplication 类,加载exec.so和execmain.so ,里面应该是固定的代码,是对源码

代码1

SuperApplication继承自Application,程序主入口:

代码2

在加密之后的apk包中,多了一个assets目录,该目录下,有一些ijiami.dat,其实这个就是我们原来的classex.dex

ijiami.dat

基本原理是在jni层, 使用DexClassLoader动态加载技术完成对加密classex.dex的动态加载,内存中解密classex.dex,完成动态加载。

//PS:使用DexClassLoader动态加载技术

可以使用Android DexClassLoader完成DEX的动态加载,DEX文件可以附属在assert或raw目录也可以运行时从网络下载。

我们知道DexClassLoader加载的类是没有组件生命周期的,也就是说即使DexClassLoader通过对APK的动态加载完成了对组件类的加载,当系统启动该组件时,还会出现加载类失败的异常。为什么组件类被动态加载入虚拟机,但系统却出现加载类失败呢?

通过查看Android源代码我们知道组件类的加载是由另一个ClassLoader来完成的,DexClassLoader和系统组件ClassLoader并不存在关系,系统组件ClassLoader当然找不到由DexClassLoader加载的类,如果把系统组件ClassLoader的parent修改成DexClassLoader,我们就可以实现对apk代码的动态加载。

总结一下,爱加密的加密步骤:

1.把原来的classex.dex 用未知的加密算法实现加密成assets/ijiami.dat

2.把事先写好的jni代码和相应的classex.dex替换到原有的位置

3.程序安装完运行起来以后,先运行爱加密的加壳程序,在jni里面动态加载原来的classex.dex代码,从而达到加壳保护的目的.

*源classex.dex 隐藏起来了,在静态的时候就没有办法对其破解。

*至于动态运行,最好还是在自己代码里面下工夫了。比如内存加密啦。

APP的影响

由于申请加密之后,爱加密需要增加自己资源(两个so,一个classex.dex文件和三个bin文件)只增加了198.1KB的容量,对于我们动辄上百MB的游戏app而言,这点都不算事儿。


  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
AppSecret加密通常使用的是对称加密算法,下面是一个简单的示例代码和步骤: 1. 选择一种对称加密算法,比如AES 2. 生成一个随机的密钥,一般是一个固定长度的字符串,比如32位的随机字符串 3. 将要加密的数据和密钥一起进行加密,得到一个密文 4. 将密文和密钥一起发送给接收方 5. 接收方使用密钥对密文进行解密,得到原始的数据 以下是一个Python代码示例,使用pycryptodome库实现AES加密和解密: ```python from Crypto.Cipher import AES import base64 # 加密函数 def encrypt(text, key): cipher = AES.new(key.encode(), AES.MODE_ECB) padded_text = padding(text) ciphertext = cipher.encrypt(padded_text.encode()) return base64.b64encode(ciphertext).decode() # 解密函数 def decrypt(ciphertext, key): cipher = AES.new(key.encode(), AES.MODE_ECB) padded_text = cipher.decrypt(base64.b64decode(ciphertext)).decode() return unpadding(padded_text) # 填充函数 def padding(text): padding_size = AES.block_size - len(text) % AES.block_size padding_text = chr(padding_size) * padding_size return text + padding_text # 去除填充函数 def unpadding(text): padding_size = ord(text[-1]) return text[:-padding_size] key = '32位随机字符串' text = '要加密的数据' # 加密 encrypted_text = encrypt(text, key) print('加密后的数据:', encrypted_text) # 解密 decrypted_text = decrypt(encrypted_text, key) print('解密后的数据:', decrypted_text) ``` 注意:上面的示例代码只是一个简单的示例,实际使用时需要考虑更多的安全因素,比如密钥的保护和管理,以及加密算法的选择等。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序邦

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值