大家好，我是來自VxProtect團隊的趙川，我們的團隊是一群專注於安全技術的小團隊，在我們研究軟體加固與破解技術的過程當中，我們發現軟體加殼技術中作為軟體加固的核心VM本身的一些問題。針對這些問題我們做了一些研究，所以今天在這裡跟大家分享一下。

今天主要講的內容有三方面。第一個直接就是現有的VM，也就是VMP和TMP這兩款工具系統架構的一些基礎情況和它們本身存在的問題。第二就是今天我們標題當中的主題，透過參照當前量子技術的一些研究發現，基於量子的某些邏輯方案可以應用於我們的傳統計算機中。之後第三個部分就是在這種思路上的變化當中，我們還能做出多少其他方面的變化。

一．市面上常見VM產品相關技術分析

首先，我們來說說虛擬機器到底是一個什麼樣的東西？它是迴圈的，會不停讀取虛擬程式碼進行解釋執行。由於直譯器的原理和原始的CPU彙編指令不一樣，從而提高了分析者的分析成本，進而起到保護原始程式碼的作用，這就是現在VM本身的原理。

目前市面上最流行的要數俄羅斯的VMP（VMprotect），與西班牙Themida系列的保護工具了。這兩款工具雖然都號稱有程式碼虛擬保護的功能，但原理還是有很大的不同，甚至是走了兩個極端方向的。

首先我們介紹一下TMD的分析保護原理。Themida VM的原理就是一個大迴圈讀取opcode，然後跳轉到對應的handler上來進行解釋執行，再跳轉，再讀取這樣一個迴圈的過程。

即使後續相對應的RISC VM和原來的CISC VM，都是如此的結構。但它的提升和改進在於改成了堆機+x86的一種解釋模式。到了新版本，在TMD上面就誕生了大家都很熟悉的“動物園”VM模式，從Fish VM到Tiger VM，到後面的Dolphin、Puma、Shark和Eagle，其實後面本身的改進升級也就是在它們自己原始的架構和指令集上進行迴圈的套娃，用這樣的方式增加程式碼直接變形的複雜度。

而VMP是大家最熟悉的一款虛擬化的保護軟體，相比於TMD的簡潔，VMP最大的變化就是引用了萬用門，以及加入了vAdd指令，來模擬包括SUB等之類的指令功能。

我們知道，Nor和Nand在幾乎所有的“數位電路”中都會提到的關鍵內容，在VMP1.0版本當中一開始就引入了了Nor這個萬用門來進行邏輯位的計算。由於其幾乎可以說只需要一個函式就可以透過組合實現幾乎所有的邏輯操作，所以它被稱為萬用門，也稱為萬用閘。

同時也因此，該特性具有不錯的歧義性，導致逆向的時候需要參考上下文才能得出原始的計算結果是什麼。這裡的黃字部分是我們對於VMP進行的一些現行研究。

在VMP3.0版本中，又引用了Nand萬用門增大分析難度，這是它的邏輯公式。除此之外，VMP還使用了剛剛講的vAdd Handler來模擬執行包括add、sub、adc等這樣的指令操作。

在剛出現的時候，這確實讓人非常大開眼界。而且透過vAdd指令可以同時計算與sub等指令一樣的標誌位的操作，在這裡我們也做出了一些指令的說明。而其他的還包括虛擬暫存器的輪轉演算法、計算器加密等技術。

總結一下，VMP本身的優點毋庸置疑，它透過萬用門來增加了程式碼的歧義性之類的優點。它的缺點，我們總結出來就是程式碼變形和垃圾干擾程式碼過於單一，不少handler計算之後的pushfd無法變形，導致它會暴露原始handler的功能。而TMD最大的缺點是handler缺少歧義性，虛擬暫存器更是和x86、x64本身的指令是對應的，這樣讓還原的難度大大降低了。

一句話總結下就是，VMP是透過編譯的複雜性，編碼複雜的VmOpcode來增加它的還原難度，而TMD是透過程式碼變形讓VmHandler更加難以識別，來增加難度。

二．Themida/VMProtect產品安全現狀分析

像我們剛才講的，2004年到2005年VMP和TMD直接都發布了他們的第一個版本，如今雖然他們的版本號都已經進入了3.x的時代，但本質來講，他們的核心還是沒有太大的變化。整整16年了，大家從當初的一籌莫展到現在脫殼機、脫殼指令碼、VM還原外掛等之類的都被逐步開發出來。

在本身的軟體還原部分，大家從原來的手工作坊，到逐行地進行直接分析，再到現在半自動化，使用對應的工具來進行程式碼的還原。現在我們就來展示幾款相關的分析工具。

首先是TMD相關的分析工具，由於TMD的Handler基本上都是使用CPU的直接指令，導致只要分析VmOpcode流程規則就可以比較容易地分析出來原始的asm指令。而TMD早期版本的CISC VM和RISC VM目前已經可以比較完美地被OU1.8直接還原。

等到TMD2.0引入了“動物園”模式後，他其實是可以被Themida-Winlicense Ultra Unpacker等脫殼工具搞定的，但目前看來只有Dolphin，Puma，Shark，Eagle這幾個版本號基於套娃的方式，虛擬機器就會相對安全一些。但恰恰因為他基於套娃的這種方式，它還有一個很突出的缺點就是速度極其緩慢。

下面，我們來分析下VMP工具的現狀。VMP最大的問題就是從它2004年釋出第一個版本之後，到現在其實本質核心並沒有太大的更新，只是增加了一個萬用門。目前已經有大量可以直接對它進行逆向分析的自動化工具，比如說像VMP分析外掛1.4、FKVMP，甚至已經商業化的xxVMP這種分析工具。

在這樣的大背景下，TMD跟VMP遭遇到的這種情況本身也致使軟體的安全防護技術需要得到發展。那麼接下來，討論一下現有技術架構上，我們自己團隊研究了哪些讓其可以前進的發展方向。

三．現有可增強的安全技術方向分析

第一個，在現在的軟體逆向當中，只要我們有足夠的耐心，直接Vm Handler就可以一個一個被識別，透過逆向分析程式碼可以整理出一個比較乾淨的Handler，然後分析出整個VM的執行規則。

在這種情況下我們要如何做呢？首先我想到的是要加強Handler的程式碼變形，讓Vm Handler的程式碼面目全非，只要膨脹程式碼足夠複雜就可以有效阻止Vm Handler直接被逆向分析。目前程式碼變形能力方面TMD會比VMP強悍得多，當然SE之類的殼會同時吸取雙方的優點，讓VMProtect的Vm Handler也變得更加複雜，甚至中間加入一些Dummy Jump來誤認為這是一個Handler的結束，讓分析工具無法直接分析出來。

第二個，VMP自己本身是沒有手動調節變異強度的功能的，但它有一個Ultra選項可以讓變異後的程式碼再進行一次VM虛擬化。只不過由於變形程度不高，在VMProtect3x下引入的Nand Handler可以和Nor相互之間進行模擬保護。同時，vAdd剛剛我們也說了，它也可以模擬Sub，再重複模擬，透過犧牲運算速度來加強程式碼膨脹的效果。

第三個方向的話，我們本身發散出來的思路是說VM Protect採用的是萬用門來實現邏輯位，指令運算確實堪稱一代經典。但是十幾年下來有無數的外掛和工具都可以直接去識別這兩個門，根據《布林代數》我們可以推匯出一些功能近似的變種門，比如說Imply,Nimply,Andn,Nandn。

本身我們推導的是這樣的一個順序，在Andn其實是在x86跟x64指令當中就已經出現的，它的程式碼實現直接就像下面的黃色標識部分所示，直接產生了一個新的萬用門。

與此對應的話，Andn反過來直接就有一個Nandn，它可以產生萬用門的變種。同時有Andn，自然也有基於Nor的這樣一個變種門，不過它的學名叫Imply，圖上可以看到他們的程式碼實現。

既然有Imply自然就有Nimply。它本身是Imply的一個反向變種，這樣我們就擴充套件出了4個萬用門，在和原來的Nand，Nor進行組合的同時又能搞出不少的規則。

第四個我們可以想像出來的技術，就是OISC技術（單一指令計算機）。這是一種非常極端的計算機型別，現實中基本上是不可能看到的，在少量的教科書當中是有被提到過。整個計算過程只有一個指令，根據設定好的地址和引數直接就可以進行“圖靈完備”，其中經常被提到的有減法機、加法機等等。因為只有單一指令能完美地直接去模擬其它的指令，所以對於逆向來說確實是一個很具有歧義性的東西，破解難度也會增加，導致這種技術雖然看上去都很“美”，但是它的速度和體積在單一指令計算機來說確實是夠嗆的。

在減法機實現位操作上，往往需要上百條指令的組合。在我們模擬減法機的時候，在它變化之後其它的這些東西都是需要大量的指令。用在一些非常不在意速度的地方是可以勉強接受的，但是我們日常中在進行軟體保護的過程中一般還是不使用的。

總結起來，以上我們能想到的這四個方向，基本上就是目前最流行、最有可行性的技術保護方案。除了第三種方法之外，其他的方案雖然從一定程度上解決了自動化分析工具這樣一個問題，但是這僅僅只是在“無限堆甲”，在這種模式下，它的代價也令人頭疼，就是慢而且體積超大。

四．“量子邏輯閘”的新方向

至此，我們團隊提出了一個問題，有沒有一種方案既能保證軟體的執行速度，又能讓我們的程式碼更加安全呢？借某位不知名網友的話，“遇事不決，量子力學”。之前研究量子計算機和它引申的一些知識的時候，我們就發現了一些東西。

量子力學是目前比較熱門的領域，雖然傳統計算機下它是沒有辦法直接去利用量子去進行計算的，但是在我們研究過程中發現它的一些量子理論的研究還是可以給我們很多提示和啟發的。

既然講到量子門，我簡單解釋一下什麼是量子。經典位元與1位量子位元看上去十分類似，最大的區別就是多了一個Psi和0到1的疊加狀態，就像PPT 上所展示的位元，相當於是一個磁極的SN級一樣。只不過量子直接多了一個Psi本身的疊加狀態作為它的控制位。

為了讓這種模型更加簡單，就用我做的這張圖向大家直接進行展示。我們可以把量子位元的0和1想象成磁鐵的兩極，再加上Psi疊加狀態控制位的時候，Psi就是這個磁鐵的方向標籤。由於“疊加”且方向相反的原因，透過組合多個量子位元我們可以得到一個m*n的矩陣，矩陣裡面就是不同引數組合的計算值。基於這個原理，量子計算的併發就有了一個理論基礎。這裡要強調的是，我們只是基於量子的原理進行了一些在傳統計算機上的模擬。

首先是可控交換門，它的作者是在1982年提出這個如今量子計算中經常用到的邏輯閘的。它的原理是透過c位控制i1，i2兩個數值進行位元位交換。圖上是我們整理出來的真值表，當c為0的時候i1，i2不變。當c等於1的時候，i1，i2交換位元位，透過O1、O2來輸出，透過這樣簡單的操作就可以實現萬用邏輯閘基礎的構造。

它本身的程式碼實現如這張PPT所示，使用C語言可以直接構築出來。相信大家都有一個問題，它到底能有什麼用？

這是我們整理出來的它本身可以具有的相對應的算式。透過Fredkin Gate，然後它後面的引數是a,0,b的時候，可以模擬出來它的b輸出，o1的輸出是andn，o2的輸出是andn。同樣的，直接Fredkin，它的引數是a,-1,b的時候，它的o1、o2的輸出是inply和or，下面以此類推。

也就是說，我們透過單一的Fredkin演算法，控制它本身裡面的引數，是傳值引數還是控制引數的不同，它可以模擬出幾乎所有不同的邏輯引數。也就是說在逆向過程中，逆向者只能看到Fredkin和它後面對應的三個引數，這個算式代表的是什麼邏輯運算，只有透過上下文找到引數真實的含意才能知道，而這個東西就具備了我們所說的歧義性。

正如之前講的，磁鐵的兩極是分不開的，但是我們透過調整輸入引數、控制位、引數順序，都可以去幹涉我們的計算，既可以同時得到兩個相反的計算結果，又可以透過簡單的控制即可以產生10幾種的計算結果。在這種複雜的規則作用下，分析VM Handler就不是一個簡單的程式碼識別可以去完成的這麼一個簡單的事情了。

再展示另外一個Toffoli Gate。這是1980年提出的Toffoli門，也叫做控控反轉門。它的原理和Fredkin不同的是，這裡不是做ab引數的直接交換了，而是當c,a都為1的時候b反轉輸出，也就是這裡我們真值表直接算出來的，在上面本身輸出值c,a都有0存在的時候，後面的輸出值是不變的。

但是本身c,a輸入值都為1的時候，要對它後面的輸出結果進行反轉，黃字部分是我們做出的程式碼的模擬。這樣子的話，它就能夠實現一個反轉的效果，同時我們就可以直接去模擬不同的原始邏輯運算，Xor甚至可以只透過一步運算就能夠完成，其他操作的話則可以透過邏輯組合來進行實現。

簡單總結一下，透過以上的講解，大家會發現“量子邏輯閘”的優勢就在於其核心“歧義”。同樣的計算下，根據輸入引數的順序不同，在相同的計算公式下，就像我們剛才展示的Fredkin或者是Toffoli的方法，可以直接得到不同的結果，同時這樣的特性下也產生了相應的優勢。

五．萬物皆可萬用門

道成一，一生二，二生三，三生萬物。也就是說我們團隊在研究過程當中，透過研究Fredkin Gate跟Toffoli Gate之後產生了一個疑問，Fredkin Gate我們剛剛看到了，它可以模擬16種可能的運算，那萬一Fredkin Gate也被直接逆向完了怎麼辦？

透過對量子邏輯閘本身的研究，我們總結出了兩個方法論。第一個，想要增加複雜度，套娃就好了，不是原始的TMD裡實現的直接套娃疊加，而是透過增加它的邏輯位和其他相關引數順序本身的不同來增加它的複雜度，要基於這個思路來進行套娃。第二個就是一切看似無關的計算都能從更宏觀的角度觀察，它都是有規律的。

由此，我們總結出來的第一個演算法是二元三輸入的萬用門。這是我們自己想出來的兩個門，一個叫與或非門，一個叫或與非門。它的簡單實現就像第一行這邊，AOI(a,b,c) = ~(a|(b&c))  = ~a & ~(b & c)。但我們研究發現，在這種情況下，AOI (0,-1,a)或者AOI (0,a,-1)的情況，它可以模擬Not (a)的運算。而AOI (0,a,b)，他可以模擬Nand(a)的直接這樣計算，以此類推……

也就是說我們透過一些邏輯位套娃方式的疊加，透過加入一個類似控制位或者說加入它本身引數的不同，從而生成很多種變種的歧義。

第二個，我們受到的啟發是常見的計算都可以讓它轉變為萬用門。首先是選擇器計算，比如說以我們常用的mux32為例，黃字就是目前我們自己總結出來的，透過Mux32(a,o,b)它可以模擬andn的計算，而Mux 32(a,-1,b)它可以模擬or這樣的計算，以此類推……

這就產生了一個很有意思的現象，當我們用這種思路進行程式碼加固的時候，逆向者看到Mux 32的時候就存在一個問題，到底是用選擇器的指令還是經過處理後的替代的邏輯運算指令？

在這裡的話，還有其它可以用的萬用門，比如說半加器、半減器、借位計算，甚至大於、小於的計算等等我們平時忽視的計算操作都可以用來實現相關的萬用門。而且不同的萬用門之間可以相互組合，形成無數種新的萬用門，讓常規的VM分析外掛直接失去作用。這就是我們《孫子兵法》講的“兵無常勢，水無常形”。

六．“數學計算”與“位運算”

前面我們講了邏輯計算中可以使用的萬用門直接進行的一些程式碼加固的新思路和方案，那麼數學計算呢？在VMP中最讓人津津樂道的就是“Add Handler”，它能夠模擬“add，adc，sub” 等指令的操作，這相當於開創了一個新的保護模式。除了add替代計算之外，我們現在也想出了幾種新的方案，可以直接模擬出更多的效果。

第一個是基於“恆等式”的替換，VMP Add中使用Add進行相關的指令替換，剛出現的時候非常讓人頭疼。然而16年過去了，這套規則仍然在使用。既然我們可以使用Add直接進行替換操作，為什麼不可以使用sub，adc，或者是sbb進行替換操作呢？

Adc的替換規則幾乎和add一模一樣，唯一的區別在於計算前受CF的影響，會在add基礎上再加上CF的值。最直接了當的方法是可以使用stc指令來清空CF標誌，就可以實現和add一樣的操作了。

Sub和Add指令是反過來的，計算規則自然也就是相反的，甚至可以直接用sub來替代cmp，就不需要複雜的合併標誌位操作了，謹記下面的規則即可。

第二個我們能夠想到的關於數學運算方面直接的複雜變換思路是基於分數和浮點數的計算，除了使用一些加減混合計算還有一些古老的分數技巧，就可以實現其它新的加減乘除的替代，比如說加法，Add(a,b)我們可以用a/b+ 1，然後再乘B，就能實現a+b這樣的結果，以此類推。

這些是相對比較簡單的替換操作，我們在這裡僅僅只是拋磚引玉，甚至是基於fsin、fcos，連分數等替換可以創造一個命題生成器來直接生成非常複雜的替代規則。這種替代規則一旦生成，對於習慣於去除錯“整數指令”的破解者，應該還是很有衝擊性的。

第三個想到的方案，是基於量子邏輯閘的加法器、減法器、乘法器和除法運算器。作為電子電路的基礎知識，我們說構築“加減乘除”運算器幾乎是每個人的基本功，但是由於現實思路和程式碼的千差萬別，所以分析起來還是比較痛苦的。這裡最簡單的加法器，我們直接做出了一個推演，圖上左邊是我們用C直接寫的一個簡單的原始思路的加法器，右邊是直接使用我們的量子邏輯閘來做的一個C方面的程式碼。

試想一下，這個程式碼發生膨脹之後會發生什麼樣的效果，當逆向者看到被膨脹過的程式碼會看到什麼？除了正常的計算之外，我們還可以用到上面講過的萬用門來組合，來實現這個加法器。同理，減法器、乘法器、除法器都是可以透過直接這樣的方式來進行直接實現的。之後就是發揮每個人的想象力，我們可以無限地去想象可以構築怎樣一個複雜的運算。

第四個我們能夠想到的替換方案，是基於“組合恆等式”的替換方案。在有了以上幾種數學計算方式之後，我們就可以透過恆等式把它進行相應的組合，來生成無數的規則。當你沒有好的辦法的時候，套娃就是最好的辦法，像黃色程式碼部分，在Add(a,b)中我們可以直接把它擴散成後面非常複雜的相關計算。

規則是可以無限巢狀的，而且每一行都沒辦法輕易最佳化和刪除，這裡只是拋磚引玉，大家事後可以自己寫一個規則生成器來實現這樣的膨脹，看看效果。

七．程式碼變形的核心“抗干擾標誌位計算”

前面我們講了邏輯運算本身的變形和數字計算相關的變形。但在軟體本身的加固過程中，我們經常碰到的問題是標誌位的問題。不管對於VM還是程式碼變形，想要模擬結果都不是難事，幾乎誰都可以去寫幾個普通的替換規則，真正直接想讓變形後的程式碼可以百分之百執行正確的時候，我們就不能只是模擬結果，同時還要模擬標誌位。

下面就分享一下標誌位的模擬及其相關的最佳化。在TMD和VMP標誌位與邏輯混淆方案中，TMD的處理方法比較簡單粗暴，恢復標誌位，執行MULC、CL等之類的程式碼，最後儲存標誌位Pop。

只有在跳轉程式碼才使用了JCC_INSIDE, JCC_OUTSIDE, JMP_INSIDE等Handler來實現判斷就導致了一個問題。TMD的VM Handler只能1：1地實現，而VMP直接在vNor，vNand，vAdd Handler中記錄pushfd，然後透過自身的各種位運算重新更新到虛擬暫存器當中。既然可以直接使用vAdd來計算OF，AF，CF這些位，同樣也可以設計vSub,vSbb,vAdc這類指令，直接相對應地進行直接的計算。

以上兩種方案還是需要使用到pushfd，這就導致我們不敢把Handler的程式碼變形做得太過分（因為會影響標誌位暫存器），要不然我們就只能不停地去push fd，popfd來儲存標誌位的暫存器。特別是vAdd中，add馬上就要進行pushfd，這裡我們提供一種無分支的“抗干擾”計算標誌位的方法。
這張圖是我們完整的一個實現，它可以不需要考慮目前標誌暫存器，不依賴pushfd，popfd即可實現標誌位的動態計算，更可以隨心所欲直接去變形我們的程式碼。

第三個我們能想到的方案就是使用“惰性計算”進行最佳化和保護。由於x86、x64下標誌位計算是強制的，所以即使你不需要標誌位運算結果，and、or、add等指令還是計算標誌位的。但是在程式碼的vm或變形的保護中，這就成了暴露指令。於是只針對需要標誌位結果的指令才進行計算，就成了我們最佳化的重點。

通常需要用到標誌位的指令不多，cmp,jcc,adc等之類的，也就這些指令需要用到標誌位。透過反彙編分析，找到這幾條指令上覆蓋標誌位的指令，比如說cmp+jnz這樣的組合，只需要計算cmp標誌位的影響就可以了，後面直接就不需要再處理了。VMP跟SE在生成某些垃圾程式碼的時候也會參考以下幾條是不是有影響標誌位的計算(and,or,add等)。如果有，VMP和SE在生成垃圾程式碼的時候就不需要考慮標誌位的影響問題，因為它會直接覆蓋上去。

八．VM架構的改進與創新

前面向大家論述的都是我們團隊基於量子邏輯閘本身和量子門所產生的自己的啟發，也就是各種的歧義和替代等方案。現在我們就為大家提供幾種在原有架構下VM一樣也能有改進空間的方案。

第一，動態流指令集的設計。VmOpcode虛擬指令在設計上要跟著Vm Handler走，那麼VmOpcode就面臨了幾個問題。Vm Handler都是一個一個的case，因為它是一個個case，所以現有的指令集是可以被自動化工具所識別的。既然能被識別出來，那我們就需要對VmOpcode進行更加複雜化的處理。另外，它還存在的問題是過多的JCC(REL指令)會導致快取重新整理，CPU速度降低的問題。

基於這幾個問題，我們要如何來進行處理呢？在二八定律下大部分的程式碼是重複的，我們將重複的程式碼打包成一個個Block，Block裡面多個的Handler就都被合併到同一個Handler裡面去了，它的優點有以下四點：第一它減少了原Handler之間頻繁JCC導致CPU快取重新整理，CPU執行率降低的問題。第二原Handler的功能單一，容易被分析，現在我們把它組合起來之後，一個Block就包含了多條指令，增大了分析難度。第三點透過在Block中間增加REL指令拆斷指令流，干擾自動分析框架。第四點是在指令集引數當中可以插入虛假和解密等微程式碼來增大分析難度。但同時它也是有缺點的，就是編譯器開發難度確實比較大。

第二個我們可以執行的方向就是生成智慧垃圾程式碼。“smart trash code”最早出現在Zombie引擎當中，引擎會隨機產生“解密程式碼和常量”同時“模擬執行”，這些隨機的程式碼得到執行後的結果，最後再補上一個數值，獲得完整的常量數值。

圖上是我們自己模擬的一個結果，這樣做的好處是避免了傳統的“垃圾程式碼生成器”產生沒什麼耦合性的程式碼，從而讓一些“垃圾程式碼清除外掛”無法被清除。後來在2013年經過pr0mix在XTG2.0多型變形引擎中的改進，增加了呼叫API進行加強，純人工處理將是一件非常痛苦的事情，來增強它本身垃圾程式碼直接對於逆向者的干擾。

第三點我們想到的方式就是執行路徑模糊與隱藏。在VMP和TMP當中，程式碼執行流程都是採用一個大迴圈或者是一個handler table來進行跳轉。到了VMP 3.0時代的話，他採用直接地址定址來實現VmHandler之間的跳轉操作，雖然提高了分析難度，但是由於設計缺陷，一些分析外掛還是可以直接被識別出來的。

特別是在現在，“符號執行”，“虛擬執行”等跟蹤工具下面，許多內部程式碼的執行流程都暴露無遺。在這裡的話，針對這些問題我們也提出了幾種思路，在handler中間直接插入定址指令，讓handler產生割裂的效果，或者使用非正常跳轉，比如說異常處理來實現跳轉，而不是在原來大迴圈的jump當中進行跳轉。又或者是使用協程切換，使用混淆樹來進行定址的碰撞，來直接進行跳轉。

由於篇幅的限制，其它的思路沒辦法更詳細地跟大家分享，在這裡簡單提一下，也就是說VM當中可否直接加入自校驗的功能，在反除錯的VmHandler上面能否直接再進行更多的處理。多型編譯器演算法，例如更高階的隨機暫存器的分析演算法，多型指令生成系統以及API的直接呼叫，這都是我們認為未來可以有的發展方向。

九．Iot等跨平臺領域與未來的技術發展方向

以上向大家介紹的是我們基於量子邏輯閘和量子邏輯閘帶給我們的啟發，也就是歧義性和它的變化性，讓我們領悟對於現行VM虛擬機器直接進行下一步技術更新換代的思路。那在軟體加固這一塊，更進一步的思路是什麼呢？

我們的思考是第一，存不存在現有晶片條件下，無法被“傳統逆向”方法分析的保護方案。第二，“混淆電路”，“多方驗證”，“同態加密”， “虛擬黑盒安全混淆”是否可以用於程式碼保護方案中。第三，基於硬體PUF（物理不可複製函式）的保護方案，直接在程式碼當中我們要如何設計實現。第四，基於GCC和LLVM的通用多語言安全編譯器系統是否可以實現。第五，能否開發出基於網路互動“零成本”的程式碼保護方案。

以上都是我們團隊認為我們接下來需要去研究的方向，並且我們也已經有了一定的成果。再次感謝看雪論壇讓我有這樣的機會為大家展現我們團隊研究的一些新思路，謝謝大家！

本屆峰會議題回顧

2020看雪SDC議題回顧 | 逃逸IE瀏覽器沙箱：在野0Day漏洞利用復現

2020 看雪SDC議題回顧 | LightSpy：Mobile間諜軟體的狩獵和剖析

2020 看雪SDC議題回顧 | DexVmp最新進化：流式編碼

2020 看雪SDC議題回顧 | Android WebView安全攻防指南2020

2020 看雪SDC議題回顧 | 生物探針技術研究與應用

2020 看雪SDC議題回顧 | 世界知名工控廠商密碼保護機制突破之旅

2020 看雪SDC議題回顧 | 敲開晶片記憶體保護的最後一扇“門”

……

更多議題回顧盡情期待！！

後續會在論壇釋出關於本議題更為詳細的講解，敬請關注！