VFP 愛用者社區

Ruey · 註冊時間: 2003-03-12 文章: 1698 來自: tunglo 第 1 樓

關於VFP的加密
( 作者: 老王 )

Vfp語言易學好用，其排序、檢索速度之快，是VB和DELPHI所不及的，但其保密性差是也大家公認的。只要稍爲懂一定資料庫知識的人，一打開資料表，其內容便一目了然，且可任意更改，其保密性和安全性可想而知，這還只是其一。其二：隨著UNFOXpro.exe和Refox7.exe等的出現，你辛辛苦苦編的程式，即使編譯成EXE文件，一經UN或RE則你煞費苦心設置的版權符、驗證關、口令、密碼等都如同虛設。

那麽Vfp的保密性差的弱點就沒辦法避免嗎？NO ！辦法肯定有，這裏就先談談“資料表的加密問題”，以下就是我的一點粗淺看法，請網友們踴躍討論。

資料表加解密常見的有以下兩種方式：

1、直接在磁片上加解密，即在關閉資料表文件後，對已保存在磁片上的資料表文件進行加密，在每次打開資料表文件前，先在磁片上對資料表解密，然後再供 Vfp將其打開，其優點是加解密容易，一般程式師用Vfp提供的低級文件函數都能編出加解密程式；缺點是：在WIN的多工環境下，很容易取得解密後的資料，另外一旦系統出錯，還未來得及加密就重新啓動系統，那保留在磁片上的就是解密後的資料，對保密性能要求稍微高一些的程式師，一般不會採用此方式。

2、在記憶體中對資料表的欄位進行加解密，這又可分兩種：

A、象《遠端續緣》1999年第一期第8個問題那樣用ASCII碼進行+、-、*、/運算加解密，但這種方法有個缺點即當加或乘時，其值容易大於255(FFH)即大於ASCII碼的最大值，這時無法用CHR()換成字元保存，如對大於255的資料不加密，則解密時又會帶來麻煩，即同是254，哪個是加密後的254，哪個是未加密的254？這也就是爲何有人問漢字解密後會出現許多同音漢字的原因。

B、完全利用Vfp3.0以上版本提供的位元操作函數bitxor()進行加密，該加密方法是C語言及組合語言常用的加密方法，其原理是將一位元組的8位元二進位數字與另一個二進位數字進行異或操作，如用6個以上密匙(口令)進行加密，則在不知其密匙的情況下，是很難解密的。它還有一個優點是加解密用同一模組，即一次執行是加密，再次執行爲解密。以下是加解密常式（注：調用該過程時，需加密的資料表已打開，且爲當前工作區）：Procedure jjmgc
para Pass &&Pass是密匙，設Pass='wjgwkj'
priv all
mccd=len(Pass) &&取Pass密匙長度
Sjbzds=fcou()
Dime Jmsz(Sjbzds)
Go top
Scan
Scat to Jmsz &&讀一條記錄到陣列
For I=1 to Sjbzds
If type("Jmsz(i)")="C" &&該欄位是字元型嗎
Zdcd=len(trim(Jmsz(i))) &&取欄位長度
mc1=1
For x=1 to Zdcd
Jm1=asc(subs(Jmsz(I),x,1)) &&取欄位中一個位元組
jm2=asc(subs(Pass,mc1,1)) &&取Pass中一個位元組
jmjg= chr(bitxor(jm1,jm2)) &&將JM1按JM2的值異或
Jmsz(I)=stuf(Jmsz(I),x,1,jmjg) &&進行加密替換
mc1=iif(mc1>mccd,1,mc1+1) &&判斷MC1是否大於mCCD
Endf
Endi
Endf
Gath from Jmsz &&將加解密的資料，寫入當前記錄
Ends
retu

3、在記憶體中直接對整個資料表文件(.DBF)加解密，這也有兩種方法：

A、借助現成工具，猶如UCDOS SDK所提供的DBFKey()函數那樣，與FOX無縫連接，不裝入LoadSdk用USE是無法打開資料表的，其優點是顯而易見的，但目前在WIN環境下還找不到這樣的工具，而自己製作其難度大，一般程式師做不到。

B、用Vfp提供的低級文件函數，配合Create Curso -SQL 和 Insert -SQL 命令可實現類似UCDOS SDK所達到的功能，其原理是：

先用低級文件函數自定義一個文件頭(或著叫文件格式，象BMP、DOC等都有自己的文件格式)，在文件頭中可包含：文件頭長度、欄位名、欄位類型、欄位長度、每條記錄長度、密匙(口令字)等，接著將您的記錄按文件頭規定的格式加密後順序寫入文件中，由於文件格式是您自定義的，所以一般是無法打開讀取的。在使用時，用低級文件函數從您自定義的文件中先讀取文件頭的內容，讀到欄位名、欄位類型、欄位長度時，將其用Create Curso -SQL到新建的資料表中，讀取記錄後先解密，再用Insert -SQL 到剛建的資料表中，然後就可正常使用了，結束使用需存檔時再按上述方法寫入文件。

該方法始終是再記憶體中進行的，故即使系統出錯，重新啓動系統也無妨。用這種方法加解密確實是在Vfp狀態下比較好的辦法，但可能對於沒學過C語言或彙編的朋友，對文件格式等不理解，由於代碼較長，無法列出，如網友們有興趣，我可供《天堂軟體俱樂部》發放。

以上只是我對Vfp資料保密性問題的探討之一 —— 資料表加解密，從中大家會看到，如果只對資料表加解密，而對執行加解密的程式碼不加密，或用Refox等軟體將您的EXE文件反編譯，那您的加密方法及密匙(口令字)，就很容易暴露，其加密的可靠性就有問題，這就是我要講的第二個問題：