bat文件雖然好用，但安全性太脆弱
隨便什么人都可以打開查看，甚至修改其中內(nèi)容
有沒有什么辦法不把.bat轉(zhuǎn)換成.exe或.com之類，仍是.bat文件
但別人無法查看并修改其中內(nèi)容？？？
有沒有什么自我加密之類的呢？
高手給個解決的思路吧
目前討論的方案如下：
１、在批處理代碼插入Unicode特征串的方案
　　對記事本等使用IsTextUnicode函數(shù)識別編碼類型的程序有效
　　對type/edit/EditPlus/UltraEdit等不使用IsTextUnicode函數(shù)的程序無效

２、給批處理代碼頭部增加Unicode字節(jié)序標(biāo)記（BOM）的方案
       EncryBat.rar (zxcv) 

　　對記事本、Word、UltraEdit、type等支持Unicode編碼的程序有效
　　對edit/WinRAR內(nèi)部查看器等不支持Unicode編碼的程序無效

３、將批處理代碼的回車換行符置換為回車符的方案

　　對edit等分別識別回車換行符的編輯器有效

４、對批處理代碼進行字典式轉(zhuǎn)換的方案
　　代碼明文運行時動態(tài)生成，故此方案與編輯器無關(guān)；
BAT文件加密法 （比Bat2Com那個軟件好使<因為那個軟件不支持中文>）
方法是:
打開“記事本”將文件開頭寫入以下的語句

 記事本程序在保存一篇新建的文檔時，如果沒有指定編碼類型，會使用缺省的ANSI類型（對于中文版來說，對應(yīng)的就是GB碼）。

       而在打開一篇已創(chuàng)建的文檔時，它會分析文檔的編碼類型，它首先判斷文檔頭部有無BOM（Byte Order Mark，字節(jié)序標(biāo)記，長度為２～３字節(jié)），如果有則根據(jù)其內(nèi)容判斷編碼類型，F(xiàn)F、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）[1]。

       因為事實上有很多非ANSI編碼的文檔是沒有任何BOM的“純文本”，所以對這些文檔不能簡單的判斷為ANSI編碼。而需要使用一系列的統(tǒng)計學(xué)算法根據(jù)文檔內(nèi)容來猜測文檔編碼。記事本使用了 IsTextUnicode 函數(shù)來判斷是否為 Unicode/Unicode big endian 編碼，使用 IsTextUTF8 判斷是否為 UTF8 編碼。

      但既然是統(tǒng)計學(xué)算法，就難免存在誤判，尤其在文檔內(nèi)容過短時，由于樣本的容量太小，這種誤判的概率會顯著增大。比如那個有名的微軟與聯(lián)通有仇的笑話，就是記事本在打開只有"聯(lián)通"二字的ANSI編碼文檔時，IsTextUTF8 函數(shù)將其誤判為UTF8編碼[2]；同樣的誤判也發(fā)生在 IsTextUnicode 函數(shù)上，比如具有 “this app can break”這種具有4335結(jié)構(gòu)的文檔，會被誤判為 Unicode 編碼[3][4]。

      需要說明的是，這種誤判的可能性是建立在文本較短且其字節(jié)位特征不被干擾的前提上的。如果將上述的文本做稍許修改（即使只是增加一個回車），則誤判很難再發(fā)生。

      而 yuanyong630 兄方案的特殊性在于，它的字節(jié)串不但具有Unicode特征，而且很長達到了1288字節(jié)，也就是說它的Unicode特征性很強，所以可以抵抗一些較短的不具有Unicode特征串的干擾，這是由統(tǒng)計學(xué)的規(guī)律所決定的。但是在干擾串稍長時，Unicode的特征將會受到顯著干擾，直至被 IsTextUnicode 函數(shù)認定為非 Unicode。所以，有些朋友總是無法測試成功，應(yīng)該是與附加的批處理代碼長度和內(nèi)容相關(guān)。大家可以測試一下[5]中的代碼。

      因為其他的編輯器（比如 Word / Wordpad / EditPlus / UltraEdit）使用了更新的編碼類型判斷算法，所以在 Unicode 判斷上改進了不少，而 UTF8 的判斷仍然不盡如人意。但因為理論上來說完全準(zhǔn)確地算法并不存在，所以我們只能依靠避免使用無BOM的非ANSI文檔，或者打開文檔時手動指定編碼類型。

      另外，如果使用記事本保存了這些誤判了編碼類型的文件，則將難以恢復(fù)。如果使用誤判編碼保存，則將給原文檔加上BOM標(biāo)記，則使用其他編輯器也再無法觀察到原文檔。如果使用 ANSI 編碼保存，則原文檔將會被當(dāng)作 Unicode 文檔而被轉(zhuǎn)換，還原的可能性接近于零。

[1] Unicode簡介
http://my.opera.com/neutronstar/blog/index.dml/tag/編碼

[2] 微軟為什么和聯(lián)通有仇
http://blog.vckbase.com/localvar/archive/2005/07/12/9510.aspx

[3] Notepad bug? Encoding issue?
http://weblogs.asp.net/cumpsd/archive/2004/02/27/81098.aspx

[4] Bush Hid The Facts
http://www.shoutwire.com/comments/16341/Bush_Hid_The_Facts

[5] cry.cmd
對于將 0d 0a 改為 0a 的方法，不如將之改為 0d 。也即將回車換行改為只回車不換行，則當(dāng)前行的文本會被沒有換行的文本行所覆蓋，如此反復(fù)覆蓋疊加。如果在批處理的最后一行添加一句長度大于以上所有行的注釋文本，則最終只會顯示這樣注釋。 

      這樣的方法，對EDIT和TYPE是有效的，所以在DOS時代曾一度流行。不過，這個方案與yuanyong630兄的方案類似，只是針對于特定文本處理器的特定文本處理機制，無法適用于所有平臺環(huán)境。 

      至于其他的加密方法，也各有缺陷，想達到軟件工程的要求是比較困難的。.
BAT加密工具.rar    EncryBat.rar  

最新評論