-
-
[原创] T7 decode
-
发表于: 2024-8-29 22:27
-
从主函数输入用户名和序列后，容易定位到.text:00401120的函数是在checkserial
一开头call了一个函数，进去分析后不难得到是使用scanf把serial当做16进制数据读取，重命名为serial2hex。
接着qmemcpy可以分析出序列号长度67byte（134位16进制），提供的序列号长度也确实是134
然后开始异或操作，异或的数据静态看不清楚，利用调试发现edi是当前函数的地址401120, 跟程序自身代码异或，异或的部分长度是697
而serial长度67，所以用了取余
接下来第二轮，看起来花里胡哨的 
但是仔细化简发现，第一轮就是serial[0]^[1]^[2]^[3]...[5]接着不难发现v4就等于serial从第0位自身异或到65位
第三轮，把v4^[66]作为秘钥，逐个将0~65项异或一遍，而第66下标项则相当于把v7存储起来，这个在后续复原中至关重要（也就是，所有67个数据异或到一起作为第三轮秘钥加密前66项，而最后一项保留这个秘钥） 
serial的前置工作搞定了，终于看到跟name有关的部分
又是熟悉的各个字节异或 
经过计算得出一个重要的数据（我写成了name after and），它决定了怎么切分serial 
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
【solved】 大家可能注意到python代码注释有涉及到一个魔改为CC的说法，这是我调试遇到的一个很奇怪的问题：所有从指针取值，第0位读出来都是CC，第1位开始就正常 比如check函数前两位 0x83 0xEC，我调试的时候看见第0次是0xCC，第1次是0xEC，后续也完全正常。非常奇怪，有没有大佬能解答一下？
最后于 2024-8-30 20:28
被XaraMysteria编辑
，原因：
|
|
|
你下断点了。程序原本的字节被替换成0xCC了 |
|
|
是的，我也看了作者的wp，现在明白了，谢谢您 |
