逆向工程「編譯」Perl與C？

有一個聲稱符合C的客戶端比sudo「編譯」Perl字節碼或類似代碼更難以進行反向工程。任何人都有辦法證明或反駁這一點？逆向工程「編譯」Perl與C？

來源

2011-03-11 blunders

您使用哪種編譯器來編譯您的Perl代碼？如果它編譯爲機器碼，那麼應該沒有區別，但是如果它的字節碼那麼它可能更容易。 – Cody 2011-03-11 20:39:26

基於什麼難？我相信更多的人更熟悉逆轉流行架構的ASM而不是Perl字節碼，但這並不意味着它本質上更加困難。 – yan 2011-03-11 20:39:34

+1 @Cody：如果可以輕鬆地將Perl編譯爲機器碼，那麼是的。如果不是，但字節碼很容易就是字節碼。 – blunders 2011-03-11 20:41:50

我不太瞭解perl，但我會舉一些例子，爲什麼將編譯爲程序集的代碼反轉非常難看。

逆向工程c代碼最醜陋的地方就是編譯刪除了所有的類型信息。這種完全缺乏名稱和類型是IMO最糟糕的部分。
在動態類型語言中，編譯器需要保留更多關於它的信息。特別是字段/方法/ ...的名稱，因爲它們通常是不可能找到每個用途的字符串。

還有很多其他醜陋的東西。如整個程序優化使用不同的寄存器來每次傳遞參數。函數被內聯，所以一個簡單的函數出現在許多地方，通常由於優化而略有不同。

堆棧中的相同寄存器和字節被函數內的不同內容重用。獲得堆棧上的數組尤其醜陋。由於您無法知道陣列有多大以及結束的位置。

然後有微觀優化，可以讓人討厭。例如，我曾花費15分鐘以上來顛倒一次與return x/1600相似的簡單功能。因爲編譯器決定分區很慢，並將該分區重新編寫爲幾個乘法加法和按位操作。

來源

2011-03-11 20:51:56 CodesInChaos

。你有這個：http://www.hex-rays.com/decompiler.shtml？可能需要1秒才能達到x/1600;這有它的問題，但在RE方案中非常好，如果您將RE作爲日常工作，那麼它非常值得大量的價格標籤。 – chkdsk 2011-04-30 12:25:21

@Pra不，這比我的預算高很多。雖然它可能會處理一些問題（如x/1600示例），但類型信息的丟失很難反轉。從幾年前使用反編譯器的人那裏我聽說結果並不令人印象深刻，但從那時起它可能會變得更好（當時反編譯器還是很新的） – CodesInChaos 2011-04-30 12:29:08

Perl真的很容易reverse engineer。選擇的工具是vi，vim，emacs或記事本。

來源

2011-03-11 21:11:44

是的，現在perlcc超出了主要分佈並不再是一些選項。 – mkb 2011-03-11 21:20:48

虛擬機的反向工程代碼是通常更容易。虛擬機通常被設計爲該語言的簡單目標。這意味着它通常能夠合理簡單和直接地表示該語言的結構。

但是，如果您正在處理的是不是針對特定語言設計的虛擬機（例如，將Perl編譯爲JVM），那麼經常會讓您更加接近使用爲真實硬件生成的代碼 - - 也就是說，您必須採取一切必要措施來定位預定義的架構，而不是設計符合源的目標。

來源

2011-03-11 21:17:14

這的確提出了他們爲什麼擔心逆向工程的問題。將機器代碼恢復爲類似於原始源代碼的東西比通常的字節代碼更困難，但對於大多數不相關的惡意活動來說更是如此。如果有人想複製你的祕密或破壞你的安全，他們可以做得足夠，而不必將它變回原始源代碼的完美表示。

來源

2011-03-11 21:24:32

好的，多年來一直有這個充分的辯論;而且大多數結果從來沒有定論......主要是因爲沒關係。

對於有動機的逆向工程師來說，兩者都是一樣的。

如果你使用像perl2exe這樣的僞EXE製造商，那麼它比編譯C更容易「反編譯」，因爲perl2exe根本不編譯perl，只是有點「隱藏」（見http://www.net-security.org/vuln.php?id=2464;這是真的老，但概念可能仍然是相同的（我沒有研究過，所以不知道肯定，但我希望你明白我的觀點））

我會建議看看最適合工作的語言實際產品的維護和開發可以合理且可持續地完成。

還記得你_can_not_停止動機的對手，你需要使它更昂貴的反向比自己寫。

這4個應該讓困難（但不再是不可能的）...

[1]插入其做毫無意義的數學和複雜的數據結構的相互作用（如果正確完成這噪聲碼（隨機的地方，隨機碼）如果目的是顛倒代碼而不是功能，將會是一件非常頭疼的事情）。

[2]作爲構建過程的一部分，在源代碼上鍊接一些（不同的）代碼混淆器。

[3]應用軟件保護加密狗，這將阻止執行代碼，如果H/W不存在，這將意味着到加密狗的數據的物理訪問的扭轉可能發生的其餘部分之前，需要：http://en.wikipedia.org/wiki/Software_protection_dongle

[4]總有一些保護器（例如Themida http://www.oreans.com/themida.php）可以得到，它可以在構建完成後保護.exe（不管它是如何編譯的）。

...這應該給逆轉器足夠的頭痛。

但請記住，所有這些也會花錢，所以你應該總是權衡你試圖實現什麼，然後看看你的選擇。

總之：兩種方法同樣不安全。除非您使用的是非編譯perl-to-exe製造商，在這種情況下，本機編譯的EXE會勝出。

我希望這會有所幫助。

來源

2011-03-12 01:17:29 chkdsk

btw，[1]和[2]應該作爲構建過程來完成，而不是作爲開發過程，所以你絕不會影響你的源代碼樹，否則你將無法聘請任何人維護你的代碼：P – chkdsk 2011-03-12 01:20:12

btw，（http://search.cpan.org/~rurban/BC-1.30/lib/B/C.pm）看起來很有趣。 – chkdsk 2011-03-12 01:23:57

+1 @PrashantGupta：對於這個單獨的......「你需要讓它的轉換成本高於自己寫的」 - 除此之外，所有額外的鏈接和建議都是巨大的幫助，謝謝！ – blunders 2011-03-12 01:39:16

C比字節編譯的Perl代碼更難反編譯。任何經過字節編譯的Perl代碼都可以反編譯。字節編譯代碼不像編譯的C程序中的機器代碼。其他一些人建議使用代碼混淆技術。這些只是使代碼難以閱讀的技巧，並不會影響反編譯Perl源代碼的難度。反編譯源可能是難以閱讀，但也有很多的Perl解混淆工具，甚至Perl模塊：

http://metacpan.org/pod/B::Deobfuscate

Perl的包裝程序，如面值，PerlAPP或Perl2exe將不提供源代碼，無論是保護。在某些時候，源必須被提取，以便Perl可以執行該腳本。即使像加殼和PerlAPP Perl2exe，它試圖在源上的一些加密技術，可以使用調試器被擊敗：

http://www.perlmonks.org/?displaytype=print;node_id=779752;replies=1

它會從隨便瀏覽您的Perl代碼阻止別人，但即使封隔器具有解壓它之前的腳本可以運行。任何確定的人都可以獲得源代碼。

反編譯C是一個完全不同的野獸。一旦編譯完成，現在就是機器代碼。您最終會得到帶有大多數C反編譯程序的彙編代碼，或者某些商業C反編譯程序將採用彙編代碼並嘗試生成等效的C代碼，但除非是非常簡單的程序，否則很少能夠重新創建原始代碼。

來源

2011-03-12 23:58:13

逆向工程「編譯」Perl與C？

回答

相關問題