从内存导出，经UNFOXALL V3.0反编译：

THISFORM.TEXT1.VALUE = EVALUATE(ALLTRIM(THIS.KEYDB) + '.sn')
THISFORM.ZCNO1.NAME = USER.NAME
THISFORM.ZCNO1.MYSN = EVALUATE(ALLTRIM(THIS.KEYDB) + '.sn')
  THISFORM.ZCNO1.MYJM
LOCAL MSN
M.MSN = EVALUATE(THIS.KEYDB) + '.key')
IF UPPER(THISFORM.ZCNO1.SNJM(M.MSN)) == UPPER(THISFORM.ZCNO1.ZCNO)
    IF USED(THIS.KEYDB)
       SELECT (THIS.KEYDB)
       USE
    ENDIF
    = MESSAGEBOX('已注册！',48,'提示')
     THIS.RELEASE
    RETURN .F.
ELSE
    RETURN .T.
ENDIF
ENDPROC
*------
PROCEDURE Destroy
IF USED(THIS.KEYDB)
    SELECT (THIS.KEYDB)
    USE
ENDIF
RELEASE XTZC_TF
ENDPROC
*------*
问题：
在VFP中ZCNO1应该是个什么东东？ZCNO1.MYJM好像是一个过程，对用户名和序列号进行计算结果赋给了ZCNO1.ZCNO；ZCNO1.SNJM(授权码)进行反运算，两者相等则为已授权。

未得到关于ZCNO1.ZCNO和ZCNO1.SNJM()任何代码，请指明可能的原因，运行库为VFP7R.DLL。
请赐教！

此程序的壳为ASPACK 2.1，脱壳后显示为POWERBASIC 8.0。在论坛中发现好多类似的关于VFP的求助，均未有一个满意的结果。随着各位VFP大侠的隐退，狼又回来了！

今天看了一下VFP的资料，感觉二楼代码中的ZCNO应为类，可是为什么找不到这个类的方法的代码呢？
可能1：在内存中为捕获解码后的内容；
可能2：调用的类方法为其他语言所写。对VFP不熟，不知道是否有此可能。如果此种可能存在的话，如何区分这个类是VFP还是其他语言所写呢？

期待大侠到来！

自娱自乐吧，自己再跟一贴。

今天终于得到了完整的APP文件，反编译后注册相关的类代码还是不可见，可能是引用了其他语言的类的原因吧，除此之外的都是可见的，不可能是原作者去掉了编译信息。

AMING曾写到：
标 题:都是作者偷懒惹的祸！ (1千字)
发信人:- Aming -
时 间:2002-1-20 22:11:26
详细信息:

    作者没有将调试信息去掉，Method 有源代码的存在，导致被人轻易发现。对大多数面向对象的语言来说，总是对象与事件对应的，表单的空壳都可以给别人轻易得到（VB、DELPHI、VFP等），我们最关心的是代码泄露问题。
    表单代码加密的方法大概有以下几种：
    1、去掉调试信息。
    经过这种方法处理后的表单，在VFP的设计环境中看不到代码的存在，且修改后的表单不能正常保存，直至反编译者的硬盘充满为止。但经过重新编译再打开表单就可以看到所有代码。 Compile Form *.SCX
    2、重复步骤一，把“重新编译可见代码”的后门堵上。
    方法 A：修改代码指针，表单照样正常运行，但无论你怎么再重新编译，照样看不到代码；
    方法 B：在 Method 中设下“陷阱”，表单可正常运行且不会让别人看到代码，但只要反编译者企图用重新编译表单的方法来获取源代码的话，表单会自动破坏，再次打开表单时VFP会说是一个无效的编译表单然后退出；
    方法 C：在表单中加入伪事件，也就是平常所说的Anti技术了，可以令REFOX反编译时内存溢出，UNFOXALL在反编译时出现蓝屏，使用VFP重新编译时VFP出现非法操作；
    方法 D：给编译后的表单作“手术”，采用明文类REFOX8 I+的代码偏移，理论上可做 4295033104 种（位）不同的偏移，不进行（懂得）复位计算的反编译者当然无从下手了。^_^
        当然，你可以把A、B、C、D整合在一起用，这样肯定会令反编译者大感头疼，即使对手是一个很有经验的反编译者。最后，祝VFP作者们好运！
                                            Aming
                            于广州寒冷的夜，想着 Lynn 和惦着 YY 的夜

矛与盾同时存在，彼此好运！

2008.9.21 00：08

lz是个vfp菜c