因為這確實很難做到。

要詳細說明：

您還需要提取非代碼的內容。考慮導入表，導出表，字符串和其他數據。

編寫代碼時，這只是程序的一部分。另一部分是“編譯器優化和數據”部分。這樣幾乎不可能創建可重新編譯的程序集。如果要在程序集級別上編輯程序，建議使用windbg和LordPE。

這是來自IDA Pro的書，但即使是IDA，儘管如此，但最終仍會做出猜測。答案來自克里斯·伊格爾（Chris Eagle）的“ IDA Pro書”。

1. “為什麼沒有任何反彙編程序可以針對良性程序（一個沒有混淆的程序）生成可重新組裝的asm代碼？ “
ol>

編譯過程是有損失的。

在機器語言級別，沒有變量或函數名，並且變量類型信息只能通過數據的使用方式來確定，而不是通過顯式類型聲明來確定。當您觀察到32位數據正在傳輸時，您需要進行一些調查工作以確定這32位是否表示一個整數，一個32位浮點值或一個32位指針。

編譯是一個多對多運算。

這意味著源程序可以通過許多不同的方式轉換為彙編語言，而機器語言可以通過許多不同的方式轉換回源語言。結果，編譯文件並立即對其進行反編譯可能會產生與輸入的文件截然不同的源文件，這是很常見的。反編譯器非常依賴語言和庫。用設計用於生成C代碼的反編譯器處理由Delphi編譯器生成的二進製文件可能會產生非常奇怪的結果。同樣，通過不了解Windows編程API的反編譯器提供已編譯的Windows二進製文件可能不會產生任何有用的結果。

基本上，在這一點上，這仍然需要人工判斷。我聽到的最好的類比是從源代碼編譯二進製文件就像在計算哈希。

1. “如果我想實現這樣的工具（沒有IDA Pro的幫助，從一開始就畫草圖），有可能嗎？”
ol>

在我看來，這聽起來像是一個有趣的理論研究問題：編譯是否可以真正視為生成哈希簽名？我的腸子說“是”。數學將非常複雜，並且可能必須使用可證明的語言來完成。我們通常使用散列，因為它們不容易進行逆向工程。但是，您仍然可以使用彩虹表之類的方法來攻擊哈希，因此需要考慮一個大型項目。我的直覺告訴我，所有可能的二進製文件上的彩虹表都是NP-Complete。

還認為確定數據類型還需要人工判斷，而我們在自動化那種智能方面仍然不是很擅長。可能嗎？也許。聰明的人仍然會使用IDA之類的工具是有原因的。

1. “還有其他我可能錯過的與此相關的問題嗎？”
ol>

我是反彙編的新手，所以我將其保留給大個子男孩，但希望至少我回答了一個問題，為什麼它這麼難做？

Eagle，Chris（2011-06-16）。 IDA Pro書：全球最受歡迎的反彙編程序非官方指南（Kindle位置151-152）。沒有澱粉新聞。 Kindle版。

您的問題非常有趣，但這並不是一個新問題。

許多人已經將我們所謂的二進制重寫用於分析目的。例如， DynInst & MAQAO 這樣做是為了對應用程序進行概要分析，以便在基本塊中定位瓶頸。現在您可能會問自己的問題是如何完成的？簡單。大多數可用的反彙編程序，例如 objdump ， objconv ， IDA 等，都是在獨立模式下工作的，通常會在反彙編中打印一條指令，而其他諸如 > udis86 & distorm 除了提供獨立模式外，還提供了API以訪問反彙編代碼。但是， DynInst ， MAQAO strong>，大​​多數二進制重寫工具所做的工作是反彙編二進製文件，並在重組二進製文件之前在數據結構中的適當位置插入探針。因此，與地址，分支，上下文保存等相關的所有必要更改都將在重組之前得到正確處理。

您必須知道，編寫這樣的工具非常困難。第一個挑戰是編寫可靠的反彙編程序。當然，這意味著選擇一種反彙編算法（線性掃描與遞歸遍歷），將指令與數據分離（它們可以混合使用-例如shellcode），等等。接下來是第二個挑戰，修補反彙編的代碼。這是非常棘手的問題，我將為您指出這份文檔，該文檔應該會很有幫助： http://www.maqao.org/publications/techreports/madras_techreport.pdf。它由 MAQAO （ MADRAS - Multi Architecture Disassembler Rewriter and Assembler ）中使用的反彙編器的作者編寫。關於本文檔的有趣部分是參考文獻（超過50篇，非常有幫助）以及描述所使用算法的附錄。

儘管我不太熟悉 MAQAO 和 DynInst ，但我還是建議您檢查有關它們的出版物（文檔，科學論文等）。我還建議您檢查 PEBIL （PMaCs有效二進制儀器工具包），Intel的 PIN ， Valgrind ， PLTO ， Elfsh / ERESI 和 Etch 。

這些工具大多數都執行二進制重寫&修補程序，我相信這是可以進行二進制重寫的很好的例子。

我希望我的回答可以幫助您找到想要的東西。

某些系統使用簡單的可執行格式，該格式通過按指定順序組合指令和已處理的彙編文件中包含的已定義數據來鏈接；鏈接器將應用地址修復程序，但否則輸出可執行文件的內容將與程序員指定的內容完全相同，僅此而已；不外乎。原來的MS-DOS .COM文件格式就是這樣，因此反彙編程序可以獲取一個COM文件並生成一個文件，該文件在組裝和鏈接後會產生位相同的文件（反彙編可能必須使用數據指令，用於任何不了解的指令，或可能編譯為除文件中顯示的位模式以外的任何指令的指令，但是如果沒有其他任何條件，則可以使用define-byte指令創建任何可執行文件字節。但是，其他系統使用的鏈接器更加複雜，並且必須生成存儲在文件中的其他信息，使用不同版本的工具構建相同的源文件可能會產生不同的二進製文件。通常，在執行反彙編-補丁-重新彙編序列時，將努力減少地址更改的代碼量。如果代碼將某個函數的地址存儲在某個地方，但是反彙編程序沒有意識到這是一個函數地址而不是常量，代碼將起作用的唯一方法是如果函數停留在相同的地址。不幸的是，沒有一種與MS-DOS或Windows構建工具兼容的目標文件來指定應該放置的位置。當代碼最初被編譯或彙編時，鏈接器可以自由地將函數放置在任何地方，並將適當地更新“常量”函數地址。在處理反彙編代碼時，無法確保該函數停留在舊地址，也無法確保所有依賴它的地址都可以在移動時得到更新。

到目前為止，已建立的二進制重寫方法是動態重寫，其中二進製文件在真實輸入上運行時被重寫。想想諸如 PIN ， DynamoRIO 和 Dyninst 之類的工具工具，以及諸如 qemu 之類的二進制翻譯器。

與動態重寫（精確的控制流圖恢復）相比，靜態重寫工具具有根本的挑戰。也就是說，對於二進製文件中的每個基本塊，我們需要知道其跳轉指令的可能目標集。困難在於二進製文件具有許多間接跳轉指令。例如，如果我們面對以 bx r3 結尾的基本塊，那麼我們需要進行 precise 和 reliable 值集分析（VSA）可以告訴我們 r3 在運行時可能取的值。不幸的是，這種分析通常是不確定的。但是，行為良好的編譯器會生成以某種方式結構化的二進製文件，這一事實在很大程度上是有用的。

請注意，解決CFG恢復問題將使我們能夠作為副產品解決代碼/數據分離問題。也就是說，遞歸下降反彙編可以使我們在這種情況下將代碼與代碼字節流中的數據完全分開。

在這裡，我可以參考去年在USENIX Security中引入的以下論文：

王帥，王培，吳鼎好：可拆卸拆卸。 USENIX Security 2015：627-642

他們的工具 Uroboros 是 not strike>開源的。它基於使用 objdump 的迭代線性掃描反彙編。拆卸技術本身已在較早的文章中進行了討論。儘管如此，它為實際有效的靜態二進制重寫提供了有趣的技術（或者至少是他們的主張）。他們甚至多次重寫同一二進製文件而不破壞它。最後，請注意，靜態二進制重寫很大程度上不適用於運行時代碼生成的二進製文件。

更新：

似乎有許多缺點 Uroboros 已在 Ramblr 中得到解決，在此處進行討論：

Wang等。等“ Ramblr：使重組變得更加出色”，網絡和分佈式系統安全性研討會（NDSS'17）的會議記錄。 2017

特別是，他們提到重新組裝的二進製文件沒有執行開銷或大小擴展。