今天在研究pbd檔案，突然想到pbd檔案混淆器。因為還沒看過它的原理，但是我已經大致猜測到了他的工作原理。
比如我們寫上乙個if then else end if結構。
if 1 <> 1 then
//這裡寫這麼多只是為了在p-code段有足夠多的byte來做混淆。
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
return "aaaaaaaaaaaaaaa"
else
return "bbbbbbbbbbbbbbb"
end if
我們知道這個表示式恆等於返回"bbbbbbbbbbbbbbb"
但是反編譯器有個致命弱點是必須順序解析每個遇到的碼，並把他翻譯出來。也就是說是順序解析的。因為執行碼和資料是混合放置的。常規反編譯是必須順序流水解析的，就想asm一樣，如果中途你插進乙個byte，後續就會錯完。
在if 和choose等選擇結構的p-code或者機器碼表達方式中，仍然是採用jp和jnp指令。也就是比較後跳轉。所以這個1<>1恆false，也就是if前半段是永遠無法執行的，也就不會引起vm解析錯誤，因為永遠執行不到那裡去。但是反編譯器就會進入陷阱中而無法自拔。
內部表達序是：
取值（1），取值（1），jp（goto address1：）順序：執行1，執行2，執行3........
address1：順序：執行a，執行b，執行c........
可以看出，可以在"順序：執行1，執行2，執行3........"進行大量p-code的偽造，比如goto到乙個不存在的位址，或者取乙個非法位址的資料，或者偽造不可識別的p-code碼等。方法就很簡單了。
這樣偽造的結果是，程式執行沒有任何影響，而反編譯器陷入其中而導致異常處理時退出，或者顯示一些錯誤結果，或者空白(出於自身保護)。
這當然是個矛盾相生的問題，因為混淆器無法知道你寫的程式的本意，它只是乙個transfer，所以如果你寫：
if a>b then
else
end if
它是不可能去偽造的，必須是人為設定，就是說連這段if結構也必須是偽造的。當然反編譯器也可以在遇到無法分析時中斷上半段的解析，而直接goto到下半段解析。不過如果混淆的程度太高，可能不能夠越過。
因為操作碼有些要讀取資料，有的是單碼不讀取資料，所以如果反編譯器仍然採用順序流水方式，必然無法順利解析到指定的goto位置，因為偽造的p-code可能在取資料時已經越過了goto到的位置。所以必須把任何跳轉都分開解析，一旦一條路出現數個連續錯誤，如：不可識別操作碼或者非法資源位址訪問等，即刻終止，並按goto的位置去解析下半段。在跳與不跳之間或者多個goto下，必然有乙個是正確的出口，否則程式就不會順利執行的（這是乙個原則），只是最後的結果會出現很多goto標籤而已，但是可以認為，程式是可讀的。
WPF與混淆器
時至今日，混淆依然是 net 程式的一道重要保護手段，而混淆器對 wpf應用程式的支援是怎樣的呢？我們今天就通過例項講解一下。首先建立如下圖所示的簡單的使用者介面 在介面 中設定一些繫結屬性 在後台 中首先定義乙個種族列舉，以便於在列表中使用 下面在窗體 window1 類中定義以下屬性 紅圈處的 ...
原 Storm排程器
storm有4中內建排程器 defaultscheduler,isolationscheduler,multitenantscheduler,resourceawarescheduler.storm中可以實現自己的排程器來替代預設的給worker分配executor的排程器。可以在stom.yaml...
Google TCP 混淆器 窮人的 SSL
google 最近推出 tcp 混淆器 obfuscated tcp tcp 混淆器是乙個位於 tcp 上的傳輸層，用來實現資料加密，以阻止或探測網路上越來越猖獗的竊聽行為。基於 ssl 上的 tls 已經可以為網路傳輸提供完美的加密和保護，然而並不是所有人都有能力部署 ssl，不僅要支付可觀的證書...