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

我可以想到兩個(gè)主要的并發(fā)癥。 首先，由于指針偏移等原因，機(jī)器碼本身并不是與匯編代碼一一對(duì)應(yīng)的。

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

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

這編譯為x86匯編代碼：

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

其中.LCO是一個(gè)命名常量，printf是共享庫符號(hào)表中的一個(gè)符號(hào)。 比較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現(xiàn)在只是內(nèi)存中的某個(gè)隨機(jī)偏移量 – 在正確的位置創(chuàng)build一個(gè)包含這個(gè)常量的匯編源文件是很困難的，因?yàn)閰R編器和鏈接器可以自由select這些常量的位置。

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

總之，源程序集具有符號(hào)，而編譯的機(jī)器代碼具有難以反轉(zhuǎn)的地址 。

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

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

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

總結(jié)

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

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