背景

  有人发帖悬赏1200块钱，解密lua脚本。我个人对lua还是比较熟悉的，cocos2d游戏的lua脚本一般都是lua加载的地方已经完成解密了。所以，盲猜的话解密真心应该不会难。我的初心是想看看这些人怎么从这些东西上赚钱，并非想赚钱。说话个人感受，纯粹做技术的，技术变现能力都很差的。

解密过程

  悬赏人贴了哥script_encrypt的函数，其实，看上去发帖人自己也懂啊。看下这个函数：

  看GetMCKernel是个单例函数，result+32是调用成员函数。又找了一下可能的函数，盲猜就是这个函数了：

  本着调用试试看的态度，通过ndk编译一个程序，直接调用这个函数：

  结果就完成了，部分lua代码如下：

  整个过程不足半个小时，然而，故事没有结束。

加密过程

坑

  发帖人的意思，你确实解密搞定了，不过，你给的脚本我没法直接用，必须加密回去，不然不买单。哪怕我告诉他，你可以直接修改script_decrypt将明文结果直接返回就能用了（怕被二次利用）。我顿时一口老血在胸。这钱想赚不这么简单啊，都是套路。我可只想了解下你们怎么通过破解赚钱啊，小老弟。
  发帖人又许诺，加密回去给你追加800块（钱真多，够砸死我的）。好吧，我决定卖把力气。
  回头翻了下这个程序的函数，这个so只有lua的解密代码，没有加密的代码（g_table这个全局变量只被引用了一次）。

huffman压缩

  huffman压缩，貌似自学的时候学过，可如今早就忘掉了。于是来到百度时刻，哈夫曼编码的词条定义：

  通过理解源程序，我去github上搜索了几个huffman压缩的项目代码，了解了huffman压缩文件的原理。摘自github上项目的代码：

  上边代码的大意是：先读取源文件，根据读取的字符来生称词频表"_infos"，然后通过这张表来初始化huffman树。然后再次阅读ida反编译的代码，大致猜到g_table这个置换表是用来加密“_infos”这个表的。

古典加密之置换加解密

  既然g_table是张置换表，也就是通过索引得到字符，反过来就是通过字符得到索引。
  so代码中，置换解密过程如下：

  逆“置换”加密过程就比较简单了：

  至此，我们就能对_infos进行加密过程了，也就是我们能够加密词频表了。

huffman树的生成

​  在so中，这棵树的代码比较乱，我选择“调一调”的方式来处理，因为这个函数使用c++代码，比较难还原。

​  这里想说下，这个huffman树的生成并不是唯一的（至少从我用github的项目上的来的经验，不确定跟原理是否冲突，至少我通过学习知道可能有前序、中序、后序）。也就是说每个人的代码可能生成不同的huffman树，所以，我才选择调用so中的函数来生成这棵树的。

​​  至此，有了huffman树了。如果要加密文件，还差最后一步，字母保存路径。

huffman压缩

​​  huffman压缩是将字符保存在叶子结点，路径来保存字符顺序的压缩算法。“0”选择左子树，“1”选择右子树，csdn上的压缩原理图：

​​  了解了最基本的原理后，既然解压是解压的路径，那么压缩也是压缩的路径。每个0或是1代表一个bit位，坑爹的是，so程序解密过程，我发现7个bit位（也就是最后一个bit位肯定为0）来写一个字节。这个过程是我不断试错得出的结论，也许作者也不是有意为之，毕竟大家代码都互相抄，总有一个人写的不一样。

​​​  左图是github代码，count==8，右边是我分析完的代码，perCount==7。不过，显然左边的github上是对的，右边的7个bit留一个0bit位确实给我留下大坑，表现就是加密的结果跟原始的完全不一致。

收尾

​​​  通过完成_infos词频表初始化、huffman树构建、路径压缩7bit分析，整个huffman的加解密我都懂了。还原加密算法也就不是难事了。整个lua文件其实有三部分组成，从后往前解析，最后一个dword（lua源码中对字符unique后的字符个数，乘以4就是_infos表的大小），中间部分是infos词频表，前边lua字符路径信息。

感受

​​​  网上赚钱还是很不容易的，中间还有插曲，悬赏人要我搞个图形界面，并且要我先搞定加密才能把解密的钱给我，我感觉被“骗”。不过倔脾气上来，入了套就走到底。1200没啥吸引力，我到底也没有知道悬赏人怎么拿这玩意变现。其实我也想自己自己赚点钱，不用被上班的996给约束，做一个自由职业者。
​​​  编辑的时候图片还是好的，发布图片就挂了。不知道怎么回事。想了解的看pdf吧。自己好久没有写东西记录了，记录下这个过程。

阿里云助力开发者！2核2G 3M带宽不限流量！6.18限时价，开 发者可享99元/年，续费同价！