能力值：
( LV15，RANK：2473 )
|
-
-
26 楼
当检查到存在DebugObject的时候，bNotInDebugObject=fasle，progress_Anti_CheckNamePart3才能验证通过;
不开调试器正常跑progress_Anti_CheckNamePart3是无法验证通过的，我想这也许你在CRECKME SETP1Dlg.cpp中第1022行，不写成if (checkresulterror > 0)，却写成下面这样的原因吧
if(checkresulterror > 1)
{
ExitProcess();
return;
}
非调试状态下，估计目前你自己的注册码也不能满足checkresulterror = 0
|
能力值：
( LV4，RANK：50 )
|
-
-
27 楼
如果还有时间，我会好好学习源码的
暂时潜水
|
能力值：
( LV12，RANK：260 )
|
-
-
28 楼
厉害！！
这个反anti是用来迷惑敌人的，正如我前面给你回复所说的那样，有一个checkerror必定是要++的。。不开调试直接跑的话，bNotInDebugObject = true,就是说这个结果是写反的！！开调试的话，它反而不加了！
刚刚在添加注册机，没看到你的疑问。。。。
高山仰止！！！！[/QUOTE]
|
能力值：
( LV12，RANK：260 )
|
-
-
29 楼
session兄的只言片语往往即能点醒梦中人。。
|
能力值：
( LV15，RANK：2473 )
|
-
-
30 楼
所以namepart3的ach4DLJ8是没有计算依据的
那么你的注册机里怎么来得到ach4DLJ8是个问题
这个关系到smc解码的key
|
能力值：
( LV12，RANK：260 )
|
-
-
31 楼
我明白你的意思了，你是说着checkerror会导致二义性。
如果真的那样的话，就只能靠穷举了。
但是换个角度，应该在破解的时候发现checkerror在正常的情况下都不可能<1(即至少 ==1),那么这个二义性也就不存在了。
|
能力值：
( LV15，RANK：2473 )
|
-
-
32 楼
正常的情况下checkresulterror=1是事实，不能从progress_Anti_CheckNamePart3来计算出ach4DLJ8，所以注册机里直接用ach4DLJ8作为固定值没有依据
|
能力值：
( LV12，RANK：260 )
|
-
-
33 楼
正常的情况下checkresulterror=1，progress_Anti_CheckNamePart3中ach4DLJ8如果经过加密后的字符串!=namepart3covertresult的话checkresulterror就=2了，此时
if(checkresulterror > 1) //此时条件满足
ExitProcess();
而我发放的经过smc处理后的crackme（非直接编译出）是==namepart3covertresult，此时
if(checkresulterror > 1) //此时条件不满足
ExitProcess();
//开始解SMC
所以我觉得是符合逻辑的。
|
能力值：
( LV15，RANK：2473 )
|
-
-
34 楼
除了progress_Anti_CheckNamePart3中的一次checkresulterror++以外，还有其他的+1吗
我理解的checkresulterror=1就是这一处
|
能力值：
( LV12，RANK：260 )
|
-
-
35 楼
其他地方progress_Anti_CheckNamePart1，progress_Anti_CheckNamePart2，progress_Anti_CheckNamePart4校验错误的话，
checkresulterror++
anti错误的话，checkresulterror++
|
能力值：
( LV15，RANK：2473 )
|
-
-
36 楼
正常情况下progress_Anti_CheckNamePart3中checkresulterror是必加的
ach4DLJ8经过加密后的字符串!=namepart3covertresult
那为什么要用ach4DLJ8，随便换成什么都满足这个不等的条件
所以ach4DLJ8作为固定值没有依据，如果这样的话，还是只能从穷举smc的key上来推算了
|
能力值：
( LV15，RANK：2473 )
|
-
-
37 楼
你列举的这些属于不正常的情况，正常情况这些我们都满足了，没有+
只有progress_Anti_CheckNamePart3在正常情况下会+
|
能力值：
( LV12，RANK：260 )
|
-
-
38 楼
哎哟。。ccfer兄，我没看到第三页我给你的回答，正常情况下ach4DLJ8经过加密后的字符串==namepart3covertresult ，不是!=namepart3covertresult ,在你那边之所以会一直!=namepart3covertresult 是因为你直接编译出来的结果没有经过SMC后，那个时间count会变成另一种值，导致KEY出错，从而!=namepart3covertresult .
编译完要经过smc处理和checksum处理！
|
能力值：
( LV15，RANK：2473 )
|
-
-
39 楼
我这样说看你明白我的意思不：
正常情况下progress_Anti_CheckNamePart3中的等式条件是永远不会成立的
只有在调试情况下才能等式相等
我的疑问是：用这个在特殊条件下才成立的等式来推算出的ach4DLJ8是否可以作为注册机中的固定值呢？
|
能力值：
( LV15，RANK：2473 )
|
-
-
40 楼
我没有编译你的代码调试，我是对你发布的那个程序的做的分析
|
能力值：
( LV12，RANK：260 )
|
-
-
41 楼
不对啊，我这边是成立的。。
我重加打印看看
|
能力值：
( LV15，RANK：2473 )
|
-
-
42 楼
那你28楼的说的必加的checkresulterror是哪里？
|
能力值：
( LV12，RANK：260 )
|
-
-
43 楼
就是那个progress_Anti_IsDebugObject
|
能力值：
( LV15，RANK：2473 )
|
-
-
44 楼
是啊，这个影响的就是progress_Anti_CheckNamePart3中的checkresulterror必加
|
能力值：
![]()
(RANK：1130 )
|
-
-
45 楼
所以说，还是提交一下完整keygen代码，然后再说一下keygen是如何可以从release版本的cm里面推算出来
|
能力值：
( LV15，RANK：2473 )
|
-
-
46 楼
正常情况下bNotInDebugObject=true，你试试这种情况下
ach4DLJ8经过加密后的字符串==namepart3covertresult吗
只有在调试状态下bNotInDebugObject=false，等式才成立
|
能力值：
![]()
(RANK：1130 )
|
-
-
47 楼
用注册机，输入8个d，然后点生成，生成出来的name和key
K0amj4wrddddddddach4DLJ805687679
befa66dc72b94f4a8ffabf15d719f4c3
在cm里面无法注册成功。。。
太复杂了，完全不懂
|
能力值：
( LV12，RANK：260 )
|
-
-
48 楼
这个就是我被扣分的bug. 是因为软件的不稳定。
|
能力值：
( LV15，RANK：2473 )
|
-
-
49 楼
全小于0x58的组合和全大于0x5E的组合永远不行
8个加起来在0x2C0 ~ 0x2F0范围内还有机会成为一个不稳定的解
|
能力值：
![]()
(RANK：1130 )
|
-
-
50 楼
这个解释太匪夷所思了，赛前居然忘记问了。。。。
|
|
|
|
