• 标 题:VFP的简单加密,可能很多朋友都已经掌握了。此文仅针对初学者。 (6千字)
  • 作 者:- Aming -
  • 时 间:2002-9-20 10:54:09
  • 链 接:http://bbs.pediy.com

以下来说说如何简单加密VFP[非加密编译],使得Refox和Unfoxall都不能识别。其实这
都是利用Refox和Unfoxall的BUG来实现的,因为他们都是基于设计机制的反编译器,而不是
基于运行机制。这只是一种简单的加密方法,可能很多朋友都已经掌握了。此文仅针对初学
者。
    以附件中的Crackme3.exe为例。
    工具:Refox8以上、Unfoxall 2.1以上,UltraEdit32
    让我们温习下APP的结构:
    1、用UltraEdit打开Crackme3.exe,移动光标到文件尾部最后4个字节,为 1D 99 00 00
这就是EXE中APP文件的实际长度了(包含标志信息),即APPSIZE=39197,那么APP在EXE的偏移
为EXESIZE-APPSIZE=46877-39197=7680 (0x1e00)。
0b710h. | 83 41 00 00 00 00 00 00 00 1D 99 00 00          | .A...........    |
                                    ~~~~~~~~~~~
    2、将光标移到1e00h验证第一步的结果,果然没错,出现了APP的特征了!

01e00h. | FE F2 FF 20 02 03 00 01 00 C4 98 00 00 6E 98 00 | ... .........n.. |
          ~~~~~ ~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~~~~~~~ ~~~~~~~~
            A  B    C    D    E        F          G
01e10h. | 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .V.............. |
          ~~ ~~~~~~~~~~~
                H
01e11h. | 00 00 00 00 00 00 00 0C 7F 20 20 73 63 72 65 65 | ........  scree |
                              ~~~~~ 
                                I
A: VFP 特征
B:加密标志FF不加密
C:VFP版本,20 是表明VFP为6.0或7.0
D:文件总数为3
E:主文件在文件列表的序号
F:文件列表的结束位置[98C4h+1E00h=B6C4h]
G:文件列表的开始位置
H:文件列表的长度
I:检校和 FoxChkSum

原文件:
0b660h. | DF 9B 71 E2 4B BE E3 7B BE F6 1B 08 00 3B 62 61 | ..q.K..{.....;ba |
0b670h. | 63 6B 75 70 73 5C CF EE C4 BF 5C 72 65 62 5C 64 | ckups\....\reb\d |
0b680h. | 65 66 65 5C 63 72 61 63 6B 6D 65 33 5C 00 63 6F | efe\crackme3\.co |
0b690h. | 6E 66 69 67 2E 66 70 77 00 63 3A 5C 77 69 6E 64 | nfig.fpw.c:\wind |
0b6a0h. | 6F 77 73 5C 74 65 6D 70 5C 00 63 72 61 63 6B 6D | ows\temp\.crackm |
0b6b0h. | 65 33 2E 66 78 70 00 33 63 72 61 63 6B 6D 65 2E | e3.fxp.3crackme. |
0b6c0h. | 67 69 66 00 06 29 00 00 00 49 00 00 00 00 00 00 | gif..)...I...... |
                        ~~~~~~~~~~~ ~~~~~~~~~~~
                            A1          B1
0b6d0h. | 00 20 00 00 00 00 00 00 00 00 00 00 00 00 49 00 | . ............I. |
                                                    ~~~~~~
                                                      B2
0b6e0h. | 00 00 30 87 00 00 2B 00 00 00 3C 00 00 00 00 00 | ..0...+...<..... |
          ~~~~~ ~~~~~~~~~~~
                  C1
0b6f0h. | 00 00 00 00 00 00 06 30 87 00 00 6E 98 00 00 00 | .......0...n.... |
                              ~~~~~~~~~~~ ~~~~~~~~
                                    C2      D1
0b700h. | 00 00 00 49 00 00 00 00 00 00 00 00 00 00 00 00 | ...I............ |
0b710h. | 83 41 00 00 00 00 00 00 00 1D 99 00 00          | .A...........    |

A1是什么?第一个文件开始位置,Refox和Unfoxall都用它来作为检测是否为Fox文件的一
个标记,改掉它 Refox和Unfoxall都认为不是FOX文件了,是否影响运行?不影响!我们先
不要改这里,第二次再改,先看看戏。

B1、B2:第二个文件的开始位置,B1-B2之间为第二个文件的基本信息,具体参照上次写
的FoxStructure。C1、C2、D1如此类推。

在设计环境中,B1、B2、C1、C2....都是不能更改的,一更改了VFP就不翻脸不认人了。:)
在运行环境中呢?B2、C2...才真正有用,B1、C1...只是充当摆设或进一步检校FOX特征。
因此,我们把B1改掉后,Unfoxall对文件大小的确定就发生了错误,进而不能正确反编译。
修改如下....我们可以将这种观点拓展到.SCT、.VCT文件中去,照样可行。

第一次修改:
0b660h. | DF 9B 71 E2 4B BE E3 7B BE F6 1B 08 00 3B 62 61 | ..q.K..{.....;ba |
0b670h. | 63 6B 75 70 73 5C CF EE C4 BF 5C 72 65 62 5C 64 | ckups\....\reb\d |
0b680h. | 65 66 65 5C 63 72 61 63 6B 6D 65 33 5C 00 63 6F | efe\crackme3\.co |
0b690h. | 6E 66 69 67 2E 66 70 77 00 63 3A 5C 77 69 6E 64 | nfig.fpw.c:\wind |
0b6a0h. | 6F 77 73 5C 74 65 6D 70 5C 00 63 72 61 63 6B 6D | ows\temp\.crackm |
0b6b0h. | 65 33 2E 66 78 70 00 33 63 72 61 63 6B 6D 65 2E | e3.fxp.3crackme. |
0b6c0h. | 67 69 66 00 06 29 00 00 00 49 FF FF FF 00 00 00 | gif..+...I...... |
                        ~~~~~~~~~~~ ~~~~~~~~~~~
                            A1          B1
0b6d0h. | 00 20 00 00 00 00 00 00 00 00 00 00 00 00 49 00 | . ............I. |
                                                    ~~~~~~
                                                      B2
0b6e0h. | 00 00 30 87 FF FF 2B 00 00 00 3C 00 00 00 00 00 | ..0...+...<..... |
          ~~~~~ ~~~~~~~~~~~
                  C1
0b6f0h. | 00 00 00 00 00 00 06 30 87 00 00 6E 98 00 00 00 | .......0...n.... |
                              ~~~~~~~~~~~ ~~~~~~~~
                                    C2      D1
0b700h. | 00 00 00 49 00 00 00 00 00 00 00 00 00 00 00 00 | ...I............ |
0b710h. | 83 41 00 00 00 00 00 00 00 1D 99 00 00          | .A...........    |

第二次修改改什么?就是改A1喽。。。。将A1由29h改成2Bh吧,Refox和Unfoxall都不能
识别了。

第二次修改后:

0b660h. | DF 9B 71 E2 4B BE E3 7B BE F6 1B 08 00 3B 62 61 | ..q.K..{.....;ba |
0b670h. | 63 6B 75 70 73 5C CF EE C4 BF 5C 72 65 62 5C 64 | ckups\....\reb\d |
0b680h. | 65 66 65 5C 63 72 61 63 6B 6D 65 33 5C 00 63 6F | efe\crackme3\.co |
0b690h. | 6E 66 69 67 2E 66 70 77 00 63 3A 5C 77 69 6E 64 | nfig.fpw.c:\wind |
0b6a0h. | 6F 77 73 5C 74 65 6D 70 5C 00 63 72 61 63 6B 6D | ows\temp\.crackm |
0b6b0h. | 65 33 2E 66 78 70 00 33 63 72 61 63 6B 6D 65 2E | e3.fxp.3crackme. |
0b6c0h. | 67 69 66 00 06 29 00 00 00 49 FF FF FF 00 00 00 | gif..+...I...... |
                        ~~~~~~~~~~~ ~~~~~~~~~~~
                            A1          B1
0b6d0h. | 00 20 00 00 00 00 00 00 00 00 00 00 00 00 49 00 | . ............I. |
                                                    ~~~~~~
                                                      B2
0b6e0h. | 00 00 30 87 FF FF 2B 00 00 00 3C 00 00 00 00 00 | ..0...+...<..... |
          ~~~~~ ~~~~~~~~~~~
                  C1
0b6f0h. | 00 00 00 00 00 00 06 30 87 00 00 6E 98 00 00 00 | .......0...n.... |
                              ~~~~~~~~~~~ ~~~~~~~~
                                    C2      D1
0b700h. | 00 00 00 49 00 00 00 00 00 00 00 00 00 00 00 00 | ...I............ |
0b710h. | 83 41 00 00 00 00 00 00 00 1D 99 00 00          | .A...........    |


就这样先吧,自己动手试验下,是否觉得很简单?
下次说说如何让Refox内存溢出和让Unfoxall非法操作。阿牛预约了,下次先在他的坛子
发布。

例子和本文下载地址:http://www.uf5du1.chinaw3.com/foxtech/02.zip