使反向工程成為C共享庫的提示更加困難

Question

我對您可以采取的預防措施感興趣，以使逆向工程C共享庫變得更加困難

似乎不可能完全阻止，但你可以采取可能需要更長時間的步驟，因此不那么有吸引力/成本更高

代碼混淆，編譯器優化選項編譯器調試標志等等（我會特別感興趣的是gcc編譯器）

對於以$或工時等方式逆向工程~5KLOC C共享庫（.so大小~200kb）的相對難度的任何想法也感興趣。

Answer 1

這些是我所知道的一些技巧：

• 使用strip與--strip-unneeded選項刪除，只是需要搬遷（因為我們正在談論的共享庫）中的那些所有符號：

  strip --strip-unneeded libmylib.so

• 靜態鏈接標准libc，這會產生更大的庫/二進制文件，這意味着需要更多的代碼進行處理以及混淆，因為將函數與庫函數分開會更加困難：

  gcc -static ...

• 強制編譯器內聯小函數，這會在代碼中嵌入小函數而不是調用它們，因此幾乎不可能區分代碼和標准庫代碼。

話雖如此，我必須補充一點，我有一個使用上述措施的二進制文件，我能夠在幾個小時內對其進行逆向工程，如果你很好奇，我就會重建symtab ，並且我沒有反向工程大師。

Answer 2

- 無需代碼混淆（如在C＃或Java中）。

目標代碼中不存在內部變量和函數的名稱。

但是，導出函數的名稱仍將以明文形式顯示在共享對象文件中。 這聽起來很合理。

- 最好使用gcc優化標志-O2或-O3 。

使用編譯器優化，目標代碼可能與源代碼有很大不同。 實際上很難回到原始的C源代碼。

但是，始終可以在裝配級別恢復工程師。 通常，並非所有程序都有價值。 在裝配中對有趣部分進行逆向工程更容易，而不是C中的整個程序。

Answer 3

最常見的防反轉技術的問題在於它們是眾所周知的並且存在克服它們的工具。 當然，剝離符號和混淆是必須的，但這只是隱藏名稱/符號。

如果你想讓反向器的工作更加困難，那就自己發明一些代碼操作。 它可以是非常簡單的東西，比如使用自定義調用約定，但這會使所有反匯編程序無法識別函數的開始和結束。

這些簡單的技巧將非常有效，因為沒有一個已經制作的工具可以將代碼恢復為原始代碼。 你看，對於幾乎所有商業包裝商或加密器，已經有一個單擊解包器。

Answer 4

沒有那么多。 一旦剝離了調試符號並對所有內部符號進行了模糊處理（而不是外部符號，因為庫的客戶端需要一個符號鏈接），那么你可以做的就不多了。 由於1-1指令到操作碼的映射，裝配反匯編非常容易。 另一方面，很難理解編譯器生成的匯編代碼，因為它充滿了奇怪的優化和效率技巧。

在這方面，將GCC轉換為最高優化可能是您可以使用的最好的混淆技巧之一。

考慮到現代計算能力，拆卸本身不需要那么長時間，並且在這一點上需要人來解讀它。

但是好奇的是：沒有逆向工程有什么重要意義？ 保證財務數據安全的加密和安全性大多是開源的。 或者這是一個專有的軟件保護的東西？

Answer 5

將代碼與開關/案例混淆混合（使其成為非線性）。

使用C ++模板在編譯時加密變量/字符串。 可以在double類型中封裝整數類型，以使反轉更加困難。

在實際代碼（jmp x，db 0E8h，x：等）之間插入程序集混淆宏

使用BOOST;）它確實使逆向工程變得痛苦......;）