我不認為有任何可靠的方法來做到這一點。 機器碼格式非常復雜，比assembly文件更復雜。 編譯的二進制文件(比如ELF格式文件)并不是真的有可能產生一個源代碼匯編程序，它將編譯成相同的(或類似的)二進制文件。 為了理解差異，將GCC編譯直接輸出到匯編器( gcc -S )的輸出與objdump在可執行文件( objdump -D )上的輸出進行比較。

我可以想到兩個主要的并發癥。 首先，由于指針偏移等原因，機器碼本身并不是與匯編代碼一一對應的。

例如，考慮C代碼到Hello世界：

int main() { printf("Hello, world!\n"); return 0; }

這編譯為x86匯編代碼：

.LC0: .string "hello" .text movl $.LC0, %eax movl %eax, (%esp) call printf

其中.LCO是一個命名常量，printf是共享庫符號表中的一個符號。 比較objdump的輸出：

80483cd: b8 b0 84 04 08 mov $0x80484b0,%eax 80483d2: 89 04 24 mov %eax,(%esp) 80483d5: e8 1a ff ff ff call 80482f4

首先，常量.LC0現在只是內存中的某個隨機偏移量 – 在正確的位置創build一個包含這個常量的匯編源文件是很困難的，因為匯編器和鏈接器可以自由select這些常量的位置。

其次，我不完全確定(這取決于位置獨立的代碼)，但我相信對printf的引用實際上并沒有在那里的代碼中的指針地址編碼，但ELF頭包含一個查找表，它在運行時dynamic地replace它的地址。 因此，反匯編代碼并不完全對應源代碼匯編代碼。

總之，源程序集具有符號，而編譯的機器代碼具有難以反轉的地址 。

第二個主要的復雜情況是程序集源文件不能包含原始ELF文件頭中的所有信息，比如要dynamic鏈接哪些庫以及原始編譯器放在那里的其他元數據。 這將很難重build。

就像我所說的那樣，一個特殊的工具可能會操縱所有這些信息，但是不太可能只是簡單地生成匯編代碼，而這些匯編代碼可以被重新組裝回可執行文件。

如果您只想修改可執行文件的一小部分，我build議比重新編譯整個應用程序更微妙的方法。 使用objdump來獲取你感興趣的函數的匯編代碼。手工將它轉換為“源代碼匯編語法”(在這里，我希望有一個工具實際上產生與input相同語法的反匯編) ，并根據需要進行修改。 完成后，重新編譯這些函數并使用objdump來找出修改過的程序的機器碼。 然后，使用hex編輯器手動將新的機器代碼粘貼到原始程序相應部分的頂部，注意新代碼的字節數與舊代碼的字節數完全相同(否則所有偏移量都會錯誤)。 如果新代碼較短，則可以使用NOP指令進行填充。 如果時間較長，則可能會遇到麻煩，可能需要創build新的function并調用它們。

總結

以上是生活随笔為你收集整理的linux 可执行文件反编译,如何反汇编，修改，然后重新组装一个Linux可执行文件？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。