java/security/MessageDigest
getInstance
(Ljava/lang/String;)Ljava/security/MessageDigest;
update
([B)V
digest
()[B
getPackageManager
()Landroid/content/pm/PackageManager;
getPackageName
()Ljava/lang/String;
getPackageInfo
(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;
signatures
[Landroid/content/pm/Signature;
toByteArray
java/lang/CharSequence
charAt
(I)C
64AA803AC24577A543458181D4351A4D

使用保护技术已经很明显了....

( 说实话，之前 Native 在我眼前是无解的，现在已经没有那么黑箱了

byteToHexStr
charAt
checkSignature
free
loadSignature
toMd5

( 之前，虽然我也不知道顺序有什么规律

Java_com_drakeet_purewriter_Ww_www
Java_com_drakeet_rebase_tool_JPEGs_getLocalUrl
Java_com_drakeet_rebase_tool_JPEGs_getRemoteUrl

( 我好像不了解 JNI 啊?

没错，和 @drakeet 说的一样，保护是使用 C++ 实现的所以更安全....
对那些只会 Lua 的小白来说是这样的

64AA803AC24577A543458181D4351A4D 这个是什么我不清楚
...

GCC: (GNU) 4.9.x 20150123 (prerelease)
Android clang version 3.8.256229  (based on LLVM 3.8.256229)
gold 1.11

编译器信息

我还是下个老牌 edb 去

https://github.com/eteran/edb-debugger
edb 可以说是很经典的了(

可能还没有那个 iApp 的加固厉害，那个至少使用了黑科技每次打包（使用 javascript 开发的）iApp 应用时把密钥藏原生库里, 代码藏在 lib.so 里(so 只是一个障眼法，你可以无视它的扩展名)
但也是终于逃不过内存 dump,后来发现连脚本的混淆都没做 🌑

JavaScript 有那么难混淆吗？？？？

所以既然校验逻辑简单的话，不如多花点时间拿汇编或者更不知名能编译为机器代码的语言写，说不定破解难度更高( 逃
(.....

pushd capstone
./make.sh
sudo ./make.sh install
popd

🌚 #backend #emmm 居然还有这么酷的命令.... ..

#China #android https://www.zhihu.com/question/264149822

所以我觉得这么做其实也不算（在不损害用户体验的基础上）特别用心的代码保护？...
要是做绝了就没意思了，比如某些游戏，加几层虚拟机保护 🌚......
卡的一比

膜 cracker dalao( #dalao

(也未必，drakeet 不一定把使用的保护技术全写出来了

参考博文