悬赏结束了，APK尚未被破解。————2020.6.27

如果有人想试试这个加固来保护你的APK，可以私信我（免费）【提供APK即可】

公布一下算法吧，如果有兴趣继续研究的，可以作为参考（有爆破点的，想一想你就会发现）：
最后，发这个帖的本意还是在于脱壳

============================

本人研究了一个APK加固，想找人研究一下强度，做了一个crackme，如果你能破解掉，会显示一个红包口令（RMB500元），如果能告诉我一些你的思路，那就非常感谢了。
如果红包24小时未被领取会失效，我会再次续上（最多续7天）。
如果红包被人领了，我会编辑帖子说明，并不再续红包。
附件内有APK，或者某盘下载：
链接: https://pan.baidu.com/s/1O6u4shUydA-xKu6_Yv5gIw 提取码: vdc4

=== 2020.6.24更新 ===
进行到第5天，我觉得红包什么的已经显得没那么重要了。
不如我们把重心放到壳上面？
本人目标是做一个无法被脱壳的终极壳，个人认为dex已经实现无法脱壳（原Java/smali代码已经不存在了），so还有几个点还需要再加强一下。
坐等大神出现。

=== 2020.6.23更新 ===
帖子浏览量不再上升的话，后面就不再多公布信息了，有兴趣的应该都下载了，没兴趣的看最后结果就行了。最后一天结束后可能会直接公布密钥算法。
其实密钥算法不复杂，因为这个crackme主要是为了看一下壳的强度，不过大家的兴趣貌似都在红包口令上。/手动笑哭

=== 2020.6.22更新 ===
原红包口令已失效，由于支付宝限制，口令不能重复，现口令变更为：APK中显示的口令后面加个1
这里分享一点个人对加密数据的一点心得：
由于现在各种hook框架泛滥，所以加密数据时要注意尽量避开这些雷区，否则无论你的算法写得多复杂，都有可能一运行就被人知道了密钥，甚至都不需要破解分析，比如：
Java的重灾区：String类，MessageDigest类，Cipher类（所有内置的加密算法），等等，这些常用类很可能被hook，如果你用这些类来处理加密数据，有可能直接被拿原文。即使你使用了各种方法来反hook，别人也可以直接修改系统达到打印出原文的效果。
所以Java层的加密数据，尽量要使用原生类型（int,byte....这些）来进行计算，然后尽量自己写算法，没错，就算是 b=b+1 都比 b=((Cipher)aes).doFinal(b) 来得更安全。
C代码的重灾区：各种字符串操作的函数很容易被hook。相对来说，如果能把加密数据的算法写进native层那安全性会上升一个档次。但是native层的逆向现在也不稀奇了，即使有ollvm高强度混淆，也可能会被轻易破解。
以上是一些个人心得，供仅参考。

=== 2020.6.21更新 ===
原红包口令已失效，由于支付宝限制，口令不能重复，现口令为APK中显示的口令
再透露一点信息，so的混淆主要分两块：一是ollvm的混淆，二是我自己写的一点简易混淆，双重叠加，所以如果直接进行静态分析起来可能会比较累。
另外，直接打开so静态分析的人可能看到了，data段很大，分析过其他加固的人可能猜到了，这里很像是放了被加固的代码

=== 2020.6.20更新 ===
原红包口令已失效，由于支付宝限制，口令不能重复，现口令变更为：APK中显示的口令后面加个1
透露一点这个加固壳的信息：
这个加固程序是原创开发的，没有采用任何第三方的开源库，所以市面上的一些套路可以在这里不是很适用。
文件名有包含vmp，但实际上目前并没有加上vmp技术。这么做是因为两点：一是打一下心理战，二是后面有计划增加vmp
这个壳分两部分：dex壳和so壳。dex壳由于直接将dex转成了native代码，所以原始的dex是无法复原的（就是dex不用脱，看到的代码就是最终代码了）。so壳暂时不讨论更多，如果静态打开so的话，首先看到的就是混淆后的壳代码。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课