将apk上传到阿里云进行快速加固，下载下来可以发现最新的加固和参考资料(1)中的类似,libdemolishdata.so的位置放在了assets\ali中，不过格式不变。

但很可惜该资料中并没有给出将阿里云抽取到libdemolishdata.so二进制代码还原回dex的方法，修改代价高(伸手党做不成了)，所以需要继续分析(本文在参考资料(1)的基础上分析，建议先阅读参考资料(1))。

想着动态调试太麻烦于是直接开始猜，用winhex打开libdemolishdata.so，如图:

可以发现位于0x10(表示由0x10-0x10+3构成的DWORD，下同),0x20,0x30的位置的内容恰好是fixfunc调用的内容。

那么可以推测0xC表示待修复方法个数。

用baksmali输出method(java -jar baksmali.jar list methods dex文件地址),可以发现0x18,0x28,0x38对应着三个被修改为"native"方法的methodIdx。

学习了参考资料(2)后，可以发现0x1c，0x2c,0x3c作为offset指向的内容恰好是DexCode格式，所以关键是修复codeoff。

又尝试上传了一个有multidex的apk，可以猜出libdemolishdata.so其他全部信息的含义(过程省略)，如下(所有名称都是我为了方便随便命名的)

文件宏观组成如下

AliCheckSumInfo的组成比较简单，如下(可能用于检验加固后的内容是否被修改)

AliFixFuncInfo则由三部分组成，如下

分析到这里可以说是很开心，以为只要在dex文件中找到codeOff改掉即可，然而codeOff是Uleb128类型的，这是一种变长类型，一旦改掉，需要修复很多偏移信息。

于是想到我们可以修改baksmali读取到的codeOff啊，再smali回去即可。

可以想象(伸手党放心，这部分附件有成品)，先增加几个类，用于读取 libdemolishdata.so，在读取dex文件的函数中将 libdemolishdata.so 的内容复制在存储dex内容的byte[]末尾,然后修正读取到的accessFlag(去除native标记【0x100】)，修正读取到的codeOff(获取到相对于当前AliFixFuncInfo的偏移后要加上AliFixFuncInfo相对于libdemolishdata.so文件头的偏移和前文中的byte[]中libdemolishdata.so信息的偏移)，这样就可以了。

附件中modifiedJava.zip是修改后的java源代码(仅修改的部分，修改前的baksmali程序的java源代码可在github下载，编译采用javac -cp 编译好的.jar;. ***.java，然后将新生成的*.class用压缩软件复制到jar内对应目录即可)；

bakdemolish-2.2.1.jar是修改编译后的成品(使用说明：

1.正常dex和修复后dex都用正常baksmali即可，不要用这个。

2.操作命令同正常baksmali，如java -jar bakdemolish-2.2.1.jar d classes.dex。