用OD追到这步循环，能否写出验算公式
本帖最后由 北极漫步 于 2020-12-12 16:32 编辑0040171C|.8D6424 00 lea esp,dword ptr ss:
00401720|>0FB639 /movzx edi,byte ptr ds:
00401723|.33DB |xor ebx,ebx
00401725|.0FB7D0 |movzx edx,ax
00401728|.8AF8 |mov bh,al
0040172A|.C1EA 08 |shr edx,0x8
0040172D|.33D7 |xor edx,edi ;jxpLoad.0041C060
0040172F|.83C1 01 |add ecx,0x1
00401732|.66:331C55 607>|xor bx,word ptr ds:
0040173A|.83EE 01 |sub esi,0x1
0040173D|.0FB7C3 |movzx eax,bx
00401740|.^ 75 DE \jnz short jxpLoad.00401720
00401742|.5F pop edi ;jxpLoad.0041C060
00401743|.5B pop ebx ;jxpLoad.0041C060
00401744|>5E pop esi ;jxpLoad.0041C060
00401745\.C3 retn
这段代码每次读取一个字节的数据进行处理，处理完将结果存放到eax中开始循环读取下一个字节的内容，是否可以推算出是某种验算方式吗？
我一直以为是CRC16校验，但是找了CRC工具没一个能得到相同的结果。这好像也不是CHEKSUM校验和吧？
小白看了零基础学ollydbg，想动手但奈何对这些不熟悉，想问问这里的循环处理在进行怎样的数据处理。 不太可能了，好比你知道的只是结果2，去推断可能是1+1=2，但还有更多的可能，比如8/4=2。 wzw1021 发表于 2020-12-12 16:32
不太可能了，好比你知道的只是结果2，去推断可能是1+1=2，但还有更多的可能，比如8/4=2。
我已知在循环处理过程中，这段数据长度为4098bytes，每次读取1字节的内容进行处理，结果放在eax中，再继续处理下一个字节的内容，直到所有数据都处理完后将最终的eax数据用于下一步程序进行比较。而这段数据的校验码是明文写在这段4098bytes数据之后的。
当我一步一步F7跟到最后一步时，eax的值和明文存在的校验码就一样了。
所以就想问问是否能根据这段循环处理代码看出这校验原理是什么，或者处理思路。
我大概猜想是两种 CRC16或CHEKSUM16bit。 65CC6600003DB9010700EC8F35C68000E8035802B3009A068CFF0000A3F896005701E2041A0D3808B00400000000000000000000100EF6046C209A292E09F5000000E803400652032003000000004006C405400600000000000000003200440700000000020064C96400BE0A9A10D606B20CF401B004B80B3075F401B004B80B307520032003840384039A019A0100000000000014075C11860100000000000010FBE803581B52036C200000000000000000C8002C010F00000000000000000000004000010001FFFF000000000001000000010000000000000000000405AF0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000D839
这段循环处理的就是这段内容，从65开始读取处理直到末尾的00，中间这段00数据不可省略或更改。处理完D839Z之前的数据刚好是4098bytes。处理完eax输出结果就是D839,如果更改其中任意字符，eax最终输出的结果就不再是D839了。
望有人指点迷津。 伪代码大概长这样，把 0x417760 这个表弄出来就行了，应该不难看出来。。。
int v1; // esi
int v2; // eax
unsigned char *v3; // ecx
unsigned short *table;
v1 = xxxxx 数据长度
v2 = xxxxx 校验初始值，应该为0
v3 = xxxxx 数据指针
table = (unsigned short *)0x417760;
while(v1 --) {
v2 = ((v2 & 0x0f) << 8) ^ table[(*v3 ^ (v2 >> 8))];
v3 ++;
}
return v2; officektv 发表于 2020-12-12 19:05
伪代码大概长这样，把 0x417760 这个表弄出来就行了，应该不难看出来。。。
int v1;...
这对我来说太深奥了，有些难以理解啊。0x417760不应该只作为一个数值与edx*2相加吗？
我觉得我离学编程还是太遥远了 officektv 发表于 2020-12-12 19:05
伪代码大概长这样，把 0x417760 这个表弄出来就行了，应该不难看出来。。。
int v1;...
贴上程序地址。
https://wws.lanzouj.com/iOkeFjbf7ah
程序读取文件后，对文件中的数据串进行校验，我就想知道这验证码是如何算的，因为有其他的资料说明是校验和。但我不知道这校验和到底是CRC16 还是 CHEKSUM16bit，更或者两个都不是。
从这个校验码能够判断是那种校验方式的话，我想去反推文件中其他处的校验码。
对于此段65CC6600003D......0000 (此处共4098bytes) 的校验码 D839 我可以通过下断的方式进行拦截.
https://attach.52pojie.cn//forum/202012/13/090619ue0t16anp0mhpxnp.png?l
其中的SI 38D8是我手动修改一个错误校验码查到它们在此作对比。
于是其中对于65CC....0000 这段数据串，我可以随意修改后，下断在0040171C处F7跟下去得到正确的校验码。
但得到正确的验证码并不是我最终想要的结果。此文件在其他处依然存在第二个校验码，但这第二个校验码不在该程序jxpload.exe进行校验。但我推测他们的校验方式应该是一样的。
对 65CC6600003D.....0000这段4098bytes数据串的校验码是D839 .而第二个校验码正是 65CC。
65CC作为校验码对应被校验的字符串共2048bytes如下：
6600003DB9010700EC8F35C68000E8035802B3009A068CFF0000A3F896005701E2041A0D3808B00400000000000000000000100EF6046C209A292E09F5000000E803400652032003000000004006C405400600000000000000003200440700000000020064C96400BE0A9A10D606B20CF401B004B80B3075F401B004B80B307520032003840384039A019A0100000000000014075C11860100000000000010FBE803581B52036C200000000000000000C8002C010F00000000000000000000004000010001FFFF000000000001000000010000000000000000000405AF0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
所以我想问是否可以根据第一段的校验方式推算出第二段的校验码。当然我现在连第一段的校验方式都不知道。
然后你所说的校验初始值为0，这又该如何看，它不应该是以程序给的值开始算吗？
小白愚钝，望前辈指点迷津。
之前看过几篇追码摸算法的文章，以为有可行性，结果马老师告诉我：大意了啊
页:
[1]