VFP的簡單加密，可能很多朋友都已經掌握了。此文僅針對初學者。 (6千字)

以下來說說如何簡單加密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