PowerBuilder混淆器v2010.11.01說明書
目錄：
一．相關(guān)知識簡介
二．歷史
三．本軟件特點
四．注冊
五．在線認證
六．混淆
七．如何購買
八．服務(wù)與升級
九．下載地址
十．聯(lián)系方式
十一。本版本改進
十二。開發(fā)歷史與修改日志

正式版價格參看：http://www.mis2erp.com

圖片：

[img]http://dl.iteye.com/upload/attachment/580734/321a7cd6-de60-3ce8-915e-e4d1d7c12265.png[/img]


一．相關(guān)知識簡介 回目錄
什么是混淆器，什么是PB混淆器？為何要使用混淆器？
在編譯型語言中，高級語言總被直接編譯成匯編碼，然后再到機器碼，所以比較低階，除了反匯編外，基本無法分析程序。
而在PB和早期的VB，現(xiàn)在的Java，C#等都是相當高等級的帶“動態(tài)特性”的語言，他們利用虛擬機技術(shù)或者層次更高的解釋技術(shù)，將高級代碼先編譯成一種精簡的中間執(zhí)行碼，然后被解釋執(zhí)行。與純解釋執(zhí)行的vbscript等相比，少了重復(fù)n次的掃描和分析，所以認為比較快。
在PB中，比如：
long ll_temp
ll_temp = 100+100
這個最簡單的算式，編譯器先確定右邊是兩個字面量的數(shù)字類型相加(此處僅舉例，也可能在編譯時就事先加為200，如果是100+變量，100就一定會編譯到執(zhí)行碼里面)，在pb中默認的數(shù)字類型是long型，浮點小數(shù)是double型。當然也有其他的認定比如把10賦值給一個int型(16位)，則字面量可能被確定為int或者uint，這個是編譯器自行判斷，通常編譯器都分得很細，針對每種語言界定的意義都有相應(yīng)的表達方式。如上等式，編譯后的形式大致為
A．取值/long型/100; B。取值/long型/100; C。相加/long型加法； D。數(shù)據(jù)類型轉(zhuǎn)換(不是必須,但類型不同的數(shù)或者變量，必先做類型轉(zhuǎn)換)；E。賦值(將值或者地址/指針賦值給變量)
也許編譯后的代碼舉例是：（HEX）
10 00 01 00 //取某個變量，代號為01
20 00 //取long型字面量（長度16位的碼）
64 00 00 00 //字面量0x64，就是100(long占用4位，并存在本地，如其他類似C，C++中的指針類型，基于處理方便的原則，本地只保存4位指針(或叫地址),而實際內(nèi)容保存在一個固定的段內(nèi)。比如longlong類型(8位),或者浮點數(shù)，金融數(shù)，字符串，數(shù)組等都是長度不確定的，有個專門的結(jié)構(gòu)來表達他們，而在代碼內(nèi)，只存放指針，操作時，因為知道數(shù)據(jù)類型，也就知道在何位置，如何存取相應(yīng)的部分。
20 00 //取第二個數(shù)字
64 00 00 00 //第二個100
50 00 //long型相加
5F 00 00 00 //賦值
這就是大概意義上的P-Code碼。實際過程中，因為涉及到數(shù)據(jù)類型的轉(zhuǎn)換或者提升，有許多的輔助代碼。比如long和int相加，要提升int再相加。這是一個常識。當然還有其他與C，C++一致的要求，就是語法，比如優(yōu)先級，這在P-code中也有實際的實現(xiàn)，否則就不成其為一種語言了。由于數(shù)據(jù)類型眾多，而且PB對內(nèi)嵌的SQL等支持很好，所以碼表極多。如longlong類型和byte類型，try。。。catch都是在發(fā)展的過程中添加進來的。這樣，到目前pb12為止，據(jù)統(tǒng)計，碼表已經(jīng)達到640個之多。從PB5-12和PBK2.5(2.0我未安裝,后續(xù)可補)總計碼表6000余。每個碼都各司其責，完成指定的具體任務(wù)。
不管是機器碼還是P-code，都為執(zhí)行碼+數(shù)據(jù)，數(shù)據(jù)的長度由前面的執(zhí)行碼決定。有的沒有數(shù)據(jù)，有的有多個byte的數(shù)據(jù)。如上第一行，01 00為變量的代號，占2個字節(jié)。因為一個字節(jié)(255個)不敷表示。
對于執(zhí)行碼與數(shù)據(jù)混合的這種形式，我們知道不執(zhí)行前面的碼，就無法預(yù)知后面某個位置的某個byte到底何用。也就是我們無法區(qū)分某個byte到底是執(zhí)行碼還是數(shù)據(jù)。一切都必須從第一個碼開始執(zhí)行，同樣的，反編譯是一個根據(jù)碼表和數(shù)據(jù)反向解析和得到源碼的程序，他是一個模擬的虛擬機，不過它執(zhí)行的結(jié)果不是數(shù)據(jù)運算結(jié)果，而是得到我們的意圖，我們程序員所寫的源碼。在機器碼編譯時，由于CPU只有在執(zhí)行比較簡單的任務(wù)才會得到較高的效率(加減，移位，異或，取反，判斷溢出等)，CPU無法執(zhí)行一個調(diào)用SQL的過程，但是在p-code中，調(diào)用SQL可以被編譯成一個p-code碼，然后再由虛擬機中的函數(shù)來具體處理，它的靈活性很高，能處理高階的邏輯。所以硬件碼都比較低層，而且近似數(shù)字處理的機械過程。而P-code不一樣，它與源碼有直接的對應(yīng)關(guān)系。除了邏輯判斷會有多種表達式用相同的實現(xiàn)而無法真正還原源碼的寫法外，就一個簡單的a = b+c這樣的算式來說，與源碼是一一對應(yīng)的。這也是現(xiàn)在PB反編譯和Java，c#的代碼可以反出來一摸一樣，令我們瞠目結(jié)舌的緣故。
混淆器發(fā)展了這么多年，有幾種實現(xiàn)，如打亂順序，然后再重新串聯(lián)；抹掉一些遺留而本身運行不依賴的字符，如非公開的function/event和instance變量，本地變量都是不被外部訪問的，所以編譯器就在內(nèi)部直接呼叫ID。而外部呼叫的全局函數(shù)，public的實例變量名，全局變量等，外部直呼其名。就不可以抹掉，只能全局替換(僅舉例，有用無用要具體判斷)。當然利用花指令，廢指令，能擾亂正向分析而讓反編譯誤入歧途，也是一個方法。以現(xiàn)在的P-code編譯或者所謂的字節(jié)碼而言，最主要保證不被破解就是要守住反編譯一關(guān)，否則編譯后發(fā)行和發(fā)布源碼無任何區(qū)別。需要反出源碼的人當然最好是程序員，因為反編譯后會有一些錯誤，程序員知道他自己的書寫習慣容易恢復(fù)；而對于不想得到代碼的人，他可以看到一些關(guān)鍵的數(shù)字，文字，邏輯判斷的位置，而用Hex搜索，不下幾分鐘，就能定位從而修改Pcode。如把=改成<>，從前面的知識我們知道，只是一個byte的修改而已。
如此簡單的一個舉例，只想說明一個問題，在這種P-code模式的編譯情況下，反應(yīng)的計算過程相當?shù)母唠A，也就是能對高級代碼有一個直接的映射。這也就是PB等語言存在反編譯器的緣故。而不曾聽說編譯型語言有反編譯器一說。
正是有如此特點，所以PB代碼要保護起來有相當難度，但是我們知道，在很多論壇都對調(diào)試pbd有經(jīng)驗介紹，提得最多的是利用反編譯器得到可閱讀的源碼再寫注冊機，當然這已經(jīng)不是意義上的破解了。本質(zhì)是反編譯器在破解軟件。而亦有少數(shù)跟蹤到vm內(nèi)部去打轉(zhuǎn)的說法，得出的結(jié)論就是調(diào)試很麻煩。所以不借助反編譯器，是很難破解pb寫的程序的。當然簡單的程序，和碰到孜孜不倦的那種高手除外。因為堆棧，內(nèi)存等都可以被調(diào)試看到，特別我們的注冊過程又會生成如磁盤號，注冊碼等，如果跟蹤還是容易得到的。不過，聰明的人都會在許多地方下“暗樁”,也就是叫破解者無所適從的方式。畢竟誰能把破解的東西用于生產(chǎn)環(huán)境呢？
因為人們較高的研究熱情，如.net和java都可以反編譯得非常棒，當然pb也不例外。可想無混淆措施的pb代碼等于源碼。
我對以上的內(nèi)容了解有限，在pbd格式分析過程中也只領(lǐng)悟到這些。并且我也不是調(diào)試能手，所以就此打住。我們的任務(wù)就僅限于阻止反編譯器得逞。
混淆器就是通過改變代碼存放的物理順序并重新串聯(lián)，以不改變其執(zhí)行邏輯，而阻止其順序分析。還有如去除部分文字，函數(shù)，事件名，參數(shù)名字，再加上特意制作的虛假對象，虛假函數(shù)事件，或者虛假的代碼片段。
通過對pbd格式的透徹分析，我采用以下幾種思路來混淆。
1.1 去掉一切可以去掉的字節(jié)，只要反編譯器有依賴的字節(jié)，反編譯器必崩潰，針對的是那種舊版本不再維護的反編譯器如pbkiller。只要改極少地方，即可讓其休息。不再困擾大家。當然也許pbkiller只是要做一個正當?shù)姆淳幾g而已。
1.2 抹掉諸如變量名，函數(shù)名，參數(shù)名，事件名等，當然有些是無法抹掉的，因為pb這種語言還存在一種動態(tài)調(diào)用。原則上可以進行等效替換，不過容易出錯，目前尚不支持，比如pbd中的object列表，有網(wǎng)友建議我擾亂，可是部分人只處理極個別pbd文件，不會把所有的pbd打開來操作一遍，所以操作起來得不償失。如create using “object-name”和object.classname,以及synamic call “xxx”等都對對象名字等有依賴，函數(shù)和事件也可以寫成字符串來call，所以暫時未做到此功能，因為要保證像反編譯器一樣100%定位和替換相應(yīng)的字符串，否則會出錯。
其實過往的混淆器powershield沒有做這一點，其實這點很重要，pb的防止反編譯其實就這點實現(xiàn)就足夠了。如果反編譯出來的代碼無閱讀性，那也就沒任何意義了。一堆亂字符表達的東西不會有任何意義。即使你看到是一個邏輯比較，你也不知道誰跟誰在比較。看到一個自加，你也不知道誰在自加。替換字符多數(shù)會出現(xiàn)0x01-0x20之間的不可顯示符號，甚至換行，所以是很難看懂的。一個亂字符可以查找替換重命名，而帶有換行符的恐怕沒有幾個人能換掉它。

這是擾亂函數(shù)的參數(shù)的效果。
1.3 花指令也亦采用邏輯陷阱，跳轉(zhuǎn)等重組代碼區(qū)。致使分析困難阻止反編譯。Powershield的這方面做的比較模式化，所以容易被“反”。我目前旨在加強并同第二點配合讓其更強悍。
1.4 造假，在其他地方尚未見到如此提法，但是我們知道給一個不是對象的對象或者不是函數(shù)的函數(shù)放在pbd中，總能起到立竿見影的效果。方法不在玄，關(guān)鍵是要管用。混淆器要的就是一個結(jié)果。我們試想一下在一個昏暗的燈光底下，一個破解者一上來就是拿出一個反編譯器來搞搞pbd文件。并不是人人都能力寫反編譯的程序，所以癥結(jié)就在這里。
1.5 其他方法，我有想到或者參考到其他混淆器時，就羅列下來并形成一個遠期的改進，添加進來。
二．歷史 回目錄
歷史上有LJTT的PowerShield(支持7,8,9)，Kevins的pb偽碼清除器pbe；反編譯器有LJTT的depb，kevins的pbkiller(9以下）和kenshu的shudepb。
Pb自2005年后“沒落”，同時期的pbkiller和Powershield也停止更新。Shudepb一直孜孜不倦地更新，成為最新的pb反編譯器，支持5-11多版本。
反編譯的意義在工程恢復(fù)。這個價值還是很高的。
混淆器在保護授權(quán)，無保護無任何權(quán)益可談。
本軟件的意義就在于繼承和加強PowerShield的思路，并支持全部版本。因為現(xiàn)在用6.5，8，9，10.5，11.5做正式開發(fā)的比較多。支持10以上是一個迫切需要。
三．本軟件特點 回目錄
對Powershield的借鑒，傳承和提高，繼續(xù)保護pb編譯后代碼。操作簡單，處理速度快，以1-2s即可混淆完一個pbd。并不需要改動源碼。
開放一個免費版本(測試版)并未限制PB版本和代碼長度等。采用免費+收費模式，價格采用多層次，基本可做到想用即用，滿意再購買，價格可自由選擇，無任何約束。
來信，留言必復(fù)，有問必答。
四．注冊 回目錄
正式版采用在線注冊方式，需要購買和測試的朋友請先郵件聯(lián)系我，并先打開程序一次，然后認證服務(wù)器記錄下你的機器碼，然后只需要告知電腦名稱即可。
計算機名稱：
姓名：
公司名：
地址：
電話/手機號：
QQ/MSN：
聯(lián)系郵件：
其他說明：
當然，你通過QQ等也可以把這些信息告訴我，不一定非用Mail不可。
電腦名請從桌面》我的電腦圖標》右鍵》屬性》計算機名》完整的計算機名稱
請將” 完整的計算機名稱”用郵件發(fā)給作者。購買后會在認證機器上開啟一個賬號。本機不設(shè)置任何授權(quán)碼。
五．在線認證 回目錄
購買登記過的用戶，打開軟件后將會得到如下回應(yīng)：
第一行明確提示出驗證的結(jié)果，包括機器碼，文件CRC，授權(quán)的期限，授權(quán)的版本。
并請注意第二行的提示，到底有沒有通過驗證，如未通過“載入文件”按鈕是灰色不可用的。

認證過程采用分布在廣州和深圳的兩臺離線服務(wù)器，每2分鐘一次，通過第三方網(wǎng)盤，接受用戶端認證文件，驗證通過后將發(fā)回信息。認證服務(wù)器和客戶端無任何接觸，確保了認證服務(wù)器安全性。
六．混淆 回目錄
6.1 支持的PB版本
購買所有版本的用戶將能獲得混淆所支持的所有版本，而購買1-2個版本的用戶將具體限制在購買的版本內(nèi)。
到目前為止，支持的版本是PKB2.5，PB5,6,7,8,9,10,10.5,11,11.5,12。
版本為pbvm.dll的版本，如pbvm115.dll，版本就是11.5。版本不是指開發(fā)工具的版本。多個開發(fā)工具的版本都是用同一個虛擬機.
6.2 適用范圍
由于混淆器預(yù)先打亂程序代碼擺放的物理順序，進而重新串接，并增加一些冗余代碼阻止機械分析和反編譯。故而代碼總長度約為原代碼長度的2-3倍，執(zhí)行時因為冗余代碼都是簡單的指令，在執(zhí)行時間上增加不多。但因情況帶有隨機性并無固定模式，大致估算執(zhí)行時間為原代碼的2-3倍。
針對一些授權(quán)和認證等代碼，造成的問題不會突出，但是如果用在大循環(huán)中的某些函數(shù)，循環(huán)次數(shù)會把所需時間放大N倍，需要自行評估考量。以混淆后實際執(zhí)行測試為準。
經(jīng)過實測，在默認配置下，pbd文件混淆后體積擴大約2-3倍。
6.3 選擇文件
為了避免不必要的麻煩，請把需要混淆的編譯后文件拷貝到一個臨時目錄，比如“桌面\新建文件夾”，而不要直接在工程項目的文件夾去操作。

在文件類型處可選擇pbd，dll，pkb，exe類型。本版本中，程序?qū)⒆詣幼R別exe文件是pkb還是pb。
注意文件在被運行時無法被混淆器打開。文件被ue等二進制編輯器打開后無法在pb中編譯。所以必須強調(diào)，用正確編譯后的pbd來混淆，混淆時保證其他程序不開啟該pbd。
還有種情況是部分用戶對放在項目文件夾內(nèi)的pbd直接操作。失敗后，用PB重新編譯，選擇“incremental”而不是“full”，造成pb認為對應(yīng)的pbl源碼無變化而不會重新編譯該pbd。一來二去，自己也弄糊涂了，要避免這些問題。其次有個問題也是與此相關(guān)的，就是改動一個對象后，單獨編譯所在的pbl而且是“incremental”，并不能解決問題。可能引發(fā)運行時錯誤。有經(jīng)驗的話是要full編譯一下應(yīng)該沒問題。
還有一種特殊的問題是，如果編譯產(chǎn)生錯誤的話，pbd中的對象有可能只生成了不完整的HEX，這種情況在我用pb6.5編譯和分析pbd格式時親自看到過，如果遇此問題，你提供pbd給我，只怕我也誤入歧途。也就是說，在報告問題前，請確認你混淆前的程序可以run。
加載文件后，出現(xiàn)對象列表，同時備份一個后綴名為.bac的文件：

軟件只對幾種對象進行處理：apl，win，uo，fun。Menu對象的事件中只有一兩句程序，所以不處理，處理也沒意義。Struct和dw等當然也不會處理。在顯示對象列表時已經(jīng)過濾掉了。

*關(guān)于下劃線開頭的對象名無法被混淆：
在解析pbd格式時，要排除一些系統(tǒng)內(nèi)定的對象如“_initsrc”。這個基本是每個對象都會帶有。
還有幾十個屬性或者函數(shù)如：__destroy_object，__set_attribute，__set_attribute_item，__get_attribute等。
因為我無法知道到底它們一共有多少以及是具體是哪些，每個版本又互不相同，所以只有抓第一個字符為下劃線的對象或函數(shù)做特別處理。
所以建議不要采用下劃線開頭來命名，包括對象名，函數(shù)和事件名，以及屬性名，變量名。如果要特別標示，請改用我們pb規(guī)則中不用的前綴。當然不用混淆的話不存在此問題。
現(xiàn)在程序已經(jīng)修改為提示并略過下劃線開頭的對象。注意看混淆后產(chǎn)生的提示信息。見下圖帶++++++++的提示部分。

6.4 勾選需要混淆的對象

可以單獨打鉤選擇需要混淆的文件，也可以在 打鉤，再去掉部分對象，適合選擇較多對象的情況。
6.5 勾選需要擾亂的對象(廢對象)

假定你在pbd中放有一個對象，是其他任何地方不會用到的，其實就是為了阻止反編譯而故意所為，其用途在于我們可以利用混淆器將其擾亂，而為反編譯者留下一個難題。
比如你有一些很關(guān)鍵的對象，名字類似uo_getsystem_info，uo_basecalss,你可以用類似的名字生成其他幾個廢對象，如uo_getsystem_infomation,uo_base等。并在此打鉤，系統(tǒng)將其二進制進行修改破壞，增加反編譯的阻力。如果反編器無甄別能力，則：要不就停止或者報錯，或者崩潰，要不就出現(xiàn)卡死狀態(tài)。總之，現(xiàn)有反編譯要改進能甄別這種欺騙才可以勝任。
6.6 填寫需要擾亂的函數(shù)或者事件名稱(廢函數(shù)或廢事件)

注意，一行輸入一個函數(shù)或者事件名，然后回車。
有鑒于6.5的方法，反編譯器可能提供一個單點調(diào)試的模式給反編譯者來跳過某個對象，所以將這種思想植入正常的對象內(nèi)，也就是在正常的對象內(nèi)部寫有一個或者多個“欺騙的廢函數(shù)或者事件“，你要保證他不被該對象內(nèi)部其他代碼調(diào)用，也不被外部的任何地方調(diào)用。要求同6.5。注意的是只要你輸入名字，不要參數(shù)表，而且這個函數(shù)名不管存在哪個對象(勾選的)里面，哪一層，都可以被擾亂，舉例說w_1下面有一個函數(shù)ue_xxx，而你在w_1的某個控件上也寫有一個函數(shù)，比如uo_1.ue_xxx，只要寫上ue_xxx，w_1和uo_1的這兩個自定義事件都將被擾亂。所以在使用時也要特別小心，名字最好接近實際的名字，但是要有所規(guī)劃。一旦弄錯，可能造成無法測試到的發(fā)布錯誤，直到用戶使用時發(fā)現(xiàn)。如果你寫錯了名字，把正常的函數(shù)擾亂了，執(zhí)行程序時將報運行時錯誤或者立即崩潰。
如果反編譯在此對象卡住或許會全部跳過此對象的分析而錯過正常代碼的分析。
6.7 執(zhí)行混淆動作

按此按鈕。執(zhí)行混淆動作。
如果你尚未購買此版本，則有如下提示，因為授權(quán)機器并未返回程序所需的6000個參數(shù)中的關(guān)于該版本的參數(shù)。程序無法正常運行而報錯。
當然還有可能是pbd自身的問題，但是你應(yīng)該首先確認是否購買該版本。

6.8 恢復(fù)文件重新混淆

如果有問題，可以恢復(fù)，注意只能恢復(fù)當前在操作的這個文件。所以在一開始要強調(diào)混淆操作時要把pbd文件拷貝到桌面上建立的臨時目錄內(nèi)。有錯誤的話最簡單從原始位置拷貝過來覆蓋。
依我的建議，應(yīng)該考慮從原始位置復(fù)制pbd過來重新混淆，而不應(yīng)該依賴該按鈕。因為我們有時會在錯誤的基礎(chǔ)上備份。
6.9 提示信息
6.9.1 文件已經(jīng)被混淆，重復(fù)混淆錯誤：

6.9.2 重要的提示信息

注意，提示信息以短劃線做標記。一般僅起到提示作用。以便明確程序的確做了相應(yīng)的處理。
6.9.3 錯誤信息

注意，錯誤的提示全部以一串加號做標記，遇到此類標記，應(yīng)該仔細閱讀甄別，并將其報告給作者。
特別注意，現(xiàn)在已經(jīng)對此類錯誤采取保守措施處理，即遇到這種一時半會無法解決的錯誤，程序都是跳過那一段代碼而未混淆！這一點使用者一定要清楚。你應(yīng)該要評估出現(xiàn)這種情況時要不要繼續(xù)發(fā)行你的程序！切記。
6.9.4 正常混淆后的提示

在默認參數(shù)下，混淆后的文件體積大致增加2-3倍。
6.10 選項配置

因改成中文，選項界面不再贅述。
6.11 關(guān)于”自建陷阱”的使用
標記，”自建陷阱”的標記為：
Long ll_mylong //申明變量
ll_mylong = 123456789+123456789+123456789+123456789+123456789+123456789 //”自建陷阱”的標記
記得表達式是: 等號左邊為一個局部變量，long型，變量名任意，等號右邊是6個“123456789“相加。混淆器在遇到這個算式時，將把代碼變成任意跳轉(zhuǎn)或者垃圾，或者偽造的執(zhí)行碼。

當然這個算式要放在“永遠無法執(zhí)行得到“的地方，比如：
Choose case ll_mylong
Case x1: //執(zhí)行不到的case
ll_mylong = 123456789+123456789+123456789+123456789+123456789+123456789
Case x1: //執(zhí)行不到的case
ll_mylong = 123456789+123456789+123456789+123456789+123456789+123456789
Case x1: //執(zhí)行不到的case
ll_mylong = 123456789+123456789+123456789+123456789+123456789+123456789
。。。
End choose

當然還可以其他的方式，如：
If(1=2){
ll_mylong = 123456789+123456789+123456789+123456789+123456789+123456789
}

或者多個if。。。else if。。。else if。。。。。end if均可。
原則：盡可能利用復(fù)雜表達式，本地變量，全局變量，函數(shù)等來寫條件，就如你平時寫程序一樣，這樣不容易被機械地甄別。只是需要這樣的條件恒false。
比如：
If(gf_fun1(p1,p2,p3)+100< gl_temp+ll_temp) then … //這個條件就是煞有介事的樣子。并且也很難甄別出來。因為是程序員寫的，而不是程序自動產(chǎn)生的，
//現(xiàn)在機器內(nèi)置的10幾種模式相對還是比較呆板。此次改進后將在此功能上極大增強。
注意，為了保險起見，一段代碼內(nèi)建議至少三五個這種標記。
6.12 移除Machine編譯的偽碼
機器碼編譯時，編譯器仍然像pbd一樣保留著pcode部分，同pbd一樣，如果不移除，照樣可以反編譯。

在這個地方打鉤，軟件即可處理。為保證兼容性，程序在處理時只是簡單將其入口地址拿掉。變通地達到效果。
6.13 如何測試混淆后的代碼
同編譯后發(fā)行前的pbd那樣測試。就如平常測試一般。


[img]http://dl.iteye.com/upload/attachment/580732/45ecc19d-2b9b-3b83-b50c-2e0e71718941.png[/img]


七．如何購買 回目錄
先發(fā)郵件給作者，雙方確定好后再付款，付款后開通正式版在線用戶。也可以先開通測試半個月到一個月，滿意再購買。 聯(lián)系方式
當然也可以群組，QQ上聯(lián)系。
八．服務(wù)與升級 回目錄
原則上一次性購買的允許免費升級。在升級這個問題上，不會做限制。
對1年期和半年期購買的，該軟件的版本也不受限制，程序有升級時全部可升級到最新版，但是服務(wù)時間受到限制。
從定價上策略上，主要針對企業(yè)用戶做高端的服務(wù)，至于個人pber，提供半年和一年期的服務(wù)。
PB版本可以任選。
如不提供在線認證服務(wù)時，將制作本地直接運行的版本，發(fā)送給一次性購買者。

之前的v2010.06.01還是可以繼續(xù)使用，因強度有限制，所以不宜使用到正式的發(fā)行軟件中，主要起測試作用。
v2010.06.01不再維護源碼，僅保留二進制執(zhí)行碼。所以請勿用于生產(chǎn)環(huán)境。
九．下載地址 回目錄
下載地址: http://chengg0769.download.csdn.net (csdn下載頻道)
http://www.onlinedown.net/soft/15463.htm (華軍下載站)
http://www.mis2erp.com/soft/pbobfuscator.rar (私人網(wǎng)站)

作者blog: http://blog.csdn.net/chengg0769
文章介紹: http://blog.csdn.net/chengg0769/archive/2010/04/17/5495693.aspx
十．聯(lián)系方式 回目錄
聯(lián)系郵件：chengang0769#21cn.com，chengang0769#gmail.com，QQ：273939617，mobile：13790299411
十一．本版本改進 回目錄
在v2010.06.1的基礎(chǔ)上，增加支持“自建陷阱”，并改成正式版，支持付費購買服務(wù)。
并支持英文和簡體中文自動配置。根據(jù)默認語言，自動顯示為英文或簡體中文。用戶默認語言是“簡體中文”則顯示簡體中文，否則全部顯示英文。如下用戶將顯示中文：

十二．開發(fā)歷史與修改日志 回目錄
2010.10.28 修正5個PCODE碼，修改在線認證方式。
2010.09.22 (陰歷中秋) 測試非簡體語言，英文界面報時間格式錯誤strtodate not a valid date format，修改bug；另發(fā)現(xiàn)一個rev-szchar緩沖區(qū)錯誤，修改bug。
2010.09.10 增加用戶可以自定義的“邏輯陷阱”，彌補靠程序無法構(gòu)建復(fù)雜的此類陷阱的不足。并修改成正式版，在線認證。修改界面支持中英文自動切換。
版本改為v2010.10.01
2010.07.02 網(wǎng)友PB8告知，他用到幾個以下劃線開頭的對象無法混淆，已回復(fù)他：本軟件不支持下劃線開頭的對象名，下劃線保留給了“甄別”PB內(nèi)置對象用。見此解釋
2010.06.18: 接網(wǎng)友PB8的報告，在20x處理時出現(xiàn)一個低階的bug(空格字符串出現(xiàn)亂碼錯誤)，修正。版本改為：V2010.06.1;
2010.05.27: PCM報告一個UO引用錯誤，經(jīng)查為普遍錯誤。PropertyClear error(0-08)。修正。可能這個錯誤會影響到相當多對象，故提升版本為v2010.05.4
2010.05.19: 增補與整理pb5，10.5的碼表，并測試5，10，10.5的pb-sample通過；
自此，支持5-12全系列。因pb12剛出正式版，前期只測試過beta，待后期著重測試。版本改為v2010.05.3。
NOD一個bug修正.
2010.05.17: 修正在checklistbox中未列出的對象如struct，menu等的"混淆標志"未清零的bug,致使未列出對象的參數(shù)被非法修改，致使運行錯誤。
bug由pcm和群內(nèi)的牛解庖丁(475392*)測試時發(fā)現(xiàn)的,可能跟內(nèi)存有關(guān),如我的電腦測試多次都不出現(xiàn)。有的電腦每次都出現(xiàn)，但是應(yīng)該歸程序責任。
限制用戶必須勾選至少一個對象，否則無法得到某些參數(shù)的正確的初始化值。版本更新到2010.05.2
2010.05.15: 修正短代碼擴展系數(shù)太大造成的越界問題
2010.05.12: 修正TRL和FRE造成的問題。并測試自己的兩個pb11編譯的項目，運行正常。修改版本號為2010.05.1
2010.05.11: 增加移除dll機器碼編譯時的偽碼，一個網(wǎng)友說可以抹掉。但是我無法確定，故為一個選項供用戶勾選。但是并未移除，而是先混淆，然后將入口地
址拿掉，成無頭僵尸，起到相同作用，因為我不想為此改動太多代碼造成新問題。
2010.05.07: 修正try...catch結(jié)構(gòu)的轉(zhuǎn)移地址
2010.05.02： 增補pb10.5增加的byte類型的碼約十個
2010.05.01: 承ourmis.com/pcm的樣本測試，發(fā)現(xiàn)10Bx標志處最后一個short不能為0，因為采用隨機數(shù)擾亂，故測試大約十多次才發(fā)現(xiàn)一次，修正。
2010.05.01: 承ourmis.com/pcm提醒，當我用自己的pb9測試時，6x標志可抹掉仍然運行正常，而他寄來的樣本(也是9)就是不能抹掉，看提示好像是n_cst_msg,好
像是PFC的東東，本想抹掉一切可能抹掉的東西，此處只好不抹。
2010.04.30: 反編譯器那邊發(fā)現(xiàn)全局函數(shù)重載(內(nèi)含一個以上的函數(shù)體造成報錯)修正。
2010.04.29： 與反編譯器一起修正6，7，8與9嚴重不同：取ctrl-list的不同，從而6-12測試解析正常了。
2010.04.29： 與反編譯器一起修正：取控件名時判斷控件的編號時 >=8000 寫成了 ==8000,導(dǎo)致嚴重遺漏從而解析出錯。修正。
2010.04.28: 對超長代碼段實行折中妥協(xié)，自動降低JCP復(fù)雜度使得空間不夠的提示盡量不出現(xiàn)。當無法插入JCP時，使用簡單JXP做連接還原代碼執(zhí)行順序。
對超短代碼段提升長度為200字節(jié)。
2010.04.23： public的func和event需要用名字呼叫，故不抹掉。
2010.04.21: 修改exe格式丟失結(jié)尾的TRL段問題
2010.04 受網(wǎng)友建議，因pb11有代替9的趨勢，感覺10以上混淆器是空缺并迫切需要，遂趕工完成并發(fā)布PB混淆器beta版。編程耗時40天。
2010.03.27 Foxstudio在2010.3.27寄了一份pb5開發(fā)工具綠色版，從而有幸使得PB版本近乎完整。Pkb未下載到2.0，只研究了2.5beta。發(fā)覺借用pb9的技術(shù)，故2.0無異。
2010.03 認真分析Powershield混淆方法和模式，寫出反混淆單元，并以一套國產(chǎn)POS為例，反編譯并修改字節(jié)獲得無限試用期。見blog文字記述。
驗證了其模式化造成容易被“反混淆”的不足。為后續(xù)混淆器開發(fā)奠定了基礎(chǔ)。如僅為其升級版，簡單復(fù)制它的方法，無任何創(chuàng)新，不足以保護pbd文件不被破解。
2009.08-2010-02 開發(fā)反編譯器部分代碼至90%，因其格式艱深，無任何文字可參考，多個關(guān)口差點”喪命”。且要兼容11個版本，屢屢廢棄代碼重寫，前后耗時6月余，年后由于其他項目拖累，尚 未釋出。
2009.07-2009.09 分析pbd文件格式，可見blog上零碎文字。

感謝的話：
感謝各位網(wǎng)友的鼎立支持！
特別感謝發(fā)來郵件或者csdn-blog留言，群組提交意見的朋友們！感謝敢于測試和使用的勇士們！
在此不具名一并致謝！

------------------------END-------------------------------------- 廣東東莞 2010-09-23 06:06 回目錄

總結(jié)

以上是生活随笔為你收集整理的PB混淆加密大师(powerbuilder防止反编译,pb混淆器，PB加壳，支持5-12)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。