一 小猪上路
展开images，bin下拿到主程序kanxue2020

decode_step1：
即“黯然销魂蛋炒饭”的前34个变化，除了代码长没啥，IDA中可F5，每个变化用不同的初始化向量重新生成key，每个变化的256字节置换表都不同的全局变量

decode_step2：
这个是比较难搞的部分，花了很多时间，是个js虚拟机，经高人看了看字节码便指点出这是个叫duktape的js引擎
字节码在byte_2348CB，先加载字节码，然后调用函数h(hexstr(step1_result))计算返回结果

decode_step3：
首先注意到：
.text:00073324 ADD R1, PC, R1 ; "skcipher"
然后调试到里面会遇若干次svc调用，这是带kernel交互的啊，我感到迷茫，从没调试过这玩意
大帅锅同学这时候把调试方法和kernel展开文件准备好了，我学习了一下就继续分析算法了
深入调试得到sub_C0171EE0是setkey,sub_C0171D74是decrypt

这个setkey和encrypt与setp1里的34重蛋炒饭相似度很高啊（记住这个要点，后面step2就靠这个猜想了）

二 杀猪儆猴
decode_step1和decode_step3算法结构相似，只是密钥和置换表不同
我没有逆setkey部分，直接内存中dump出setkey之后的结果，传给decrypt就行了
decode_step1里1～34种蛋炒饭，举例第一次setkey结束的情况：
.text:00018EB8 STR R3, [SP,#0xAF0+key+0x3C] //这是setkey最后一步
.text:00018EBC MOV R11, #0 //从这开始循环解密数据
虽然34种蛋炒饭比较长，但都是相同结构，费些体力就解决了

decode_step3是kernel中前面已经贴了F5的代码，按简介这个就是第36种蛋炒饭了，和decode_step1同理可解决

剩下的最后难点就是decode_step2了：
1.在不知道是js引擎的情况下调试了若干次，晕头转向
2.在知道了是js引擎，但不知道是哪种js引擎的情况下调试了若干次，继续晕头转向
3.在知道了是duktape的js引擎的情况下调试了若干次，仍然晕头转向

这个时候貌似要靠猜想了，第35种蛋炒饭？
咱就假设它和其它已知的35种蛋炒饭一样的算法结构行不？试试看吧
已知的蛋炒饭算法都是异或和循环移位
找来duktape的源码，编译examples\cmdline可以测试字节码，经验证结果是匹配的
在代码里找到void duk__vm_bitwise_binary_op(...)这个函数，把异或和移位操作都打印出log
例如xor的：

重新编译，运行dukcmd -b -i op.bin
测试得到log，列举一段：

这样就可以把key都获取到了
观察字节码可以看到：

_0x2a08，_0x22b3，a这些都是变量名
可以输出查看：

这前面那个256字节的数组sbbbc经验证就是置换表
其实如果自己实现setkey就更好搞了，把ccccckksgh和ffffffdk传给setkey就行了

三 吃蛋炒饭喽
整理前面分析流程，写出代码没几行，大部分都是key数据和置换表
运行得到结果：18542cf63f2508f9632e6f8a49e0c298
而且发现因为没有区分字母大小写而存在多解共512个

dukcmd工具、字节码和keygen见附件

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