我们试试重签名

依然正常运行（

(Java API)
java/security/MessageDigest java.security.MessageDigest

getInstance (Ljava/lang/String;)Ljava/security/MessageDigest; MessageDigest.getInstance(hashType)

static MessageDigest   getInstance(String algorithm)
Returns a MessageDigest object that implements the specified digest algorithm.

update ([B)V void update(byte[])

void   update(byte[] input)
Updates the digest using the specified array of bytes.

digest ()[B byte[] digest()

byte[]   digest()
Completes the hash computation by performing final operations such as padding.

(Android API)

getPackageManager ()Landroid/content/pm/PackageManager; PackageManager getPackageManager() Context#getPackageManager()

getPackageName ()Ljava/lang/String; String getPackageName() PackageManager#getPackageName()

getPackageInfo (Ljava/lang/String;I)Landroid/content/pm/PackageInfo;

signatures [Landroid/content/pm/Signature;
toByteArray java/lang/CharSequence
charAt (I)C

64AA803AC24577A543458181D4351A4D

下面用 AndBug 给几个校验用的 Java 方法下断点（native 的我就不动态分析了, 不方便

就这大概就是基础校验逻辑了.....
等会动态分析

（话说这玩意好像能自动去验证… 妈耶等会测试下😂

唯一的区别是这是 libcore.so 里的逻辑，不是托管于 JVM 上的代码

https://www.freebuf.com/sectool/111532.html #emmm #reveng

https://www.cnblogs.com/sunzn/archive/2013/01/27/2878422.html

Android 编程下获得应用程序的签名

当然是 JNI 的可是我不会 JNI 233333....

（之前好像对 radare2 没啥印象

0xf7f8d3a0 libcore.so!_JNIEnv::CallObjectMethod(_jobject*, _jmethodID*, ...)@plt
0xf7f8d3f0 libcore.so!_JNIEnv::CallCharMethod(_jobject*, _jmethodID*, ...)@plt
0xf7f8d420 libcore.so!__android_log_print@plt
0xf7f8d380 libcore.so!_JNIEnv::CallStaticObjectMethod(_jclass*, _jmethodID*, ...)@plt
0xf7f8d390 libcore.so!_JNIEnv::CallVoidMethod(_jobject*, _jmethodID*, ...)@plt
0xf7f8d3e0 libcore.so!toMd5@plt
0xf7f8dcf0 libcore.so!byteToHexStr
0xf7f8dd70 libcore.so!toMd5

(其实也不是全部逻辑都是 JNI 调用 Java API)

如你们所见 好像是 MD5 对比校验
这不是直接用 Java MessageDigest API 的
我去看看 Android NDK

(不过废话那么多干什么，这基本可以猜出来了)
（何况猜不出来也没关系，虽然这次我是为了看调戏破解的消息来的，drakeet 也说了那部分是托管代码
(尝试一下，如果 com.drakeet.purewriter.Ww.ww) 这个 Java 方法校验失败返回 true drakeet 会讽刺一下破解者，反之他不知道这是破解版
, 直接修改托管于 JVM(准确的说不是 JVM.... 不是重点, 因为编译为 JVM 字节码的语言太多) 上的逻辑即可规避反破解逻辑

（另外根据代码搜索我只找到了 com.drakeet.purewriter.Ww.www 这个 native 方法使用 libcore.so ）

其实看了看符号表/字符串资源，这个 libcore.so 的功能似乎只包括反破解，没有其他功能了
(排除数目最多 C++ 异常处理的符号，就只剩 toMd5 啊, strcmp 啊, loadSignature 这些明显与校验签名有关的)

(这是 drakeet 的说法)

所以我当然是来解密鄙视文案的

那么问题来了：
看看 libcore.so 符号表没有什么与解密相关的东西
所以如果解密经手 Java API 的话，分析反而会更简单（至少是在我这里）
AndBug 给 Java 密码工具类打断点就行了....