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

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

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

//onCrackmeClicked中的Java源码生成密钥的算法如下：
MessageDigest sha1 = MessageDigest.getInstance("SHA1");
String s = "检测到你改签名了，你得把这个过了，不然就不让你继续。";
byte[] sigHash = new byte[] {(byte)0x6d,(byte)0xf2,(byte)0x47,(byte)0xa8,(byte)0xe0,(byte)0xc8,(byte)0x3a,(byte)0xb3,(byte)0xde,(byte)0x58,(byte)0x85,(byte)0x1e,(byte)0x17,(byte)0xc3,(byte)0xa9,(byte)0x50,(byte)0xd6,(byte)0x97,(byte)0x26,(byte)0x1d}; //这是APK签名的SHA1
byte[] seeda = ("这是计算密钥用的seed" + s + "随便加个salt香不香").getBytes("UTF-8");
Random rnd = new Random(seeda.length + sigHash.length);
for (int i = 0; i < 100; i ++) {
    int x = rnd.nextInt(seeda.length);
    int y = rnd.nextInt(seeda.length);
    byte b = seeda[x];
    seeda[x] = seeda[y];
    seeda[y] = (byte)(b ^ sigHash[i % sigHash.length]);
}
sha1 = MessageDigest.getInstance("SHA1");
byte[] b = sha1.digest(seeda);
byte[] buf = new byte[32];
for (int i = 0; i < buf.length; i ++) {
    buf[i] = (byte)(b[i % b.length] ^ sigHash[i % sigHash.length] ^ rnd.nextInt());
}
//将buf转成16进制的小写字符串就是密钥了。

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

本人研究了一个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的话，首先看到的就是混淆后的壳代码。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！