MechMK1
2019-10-09 19:44:37 UTC
我一直堅信混淆本質上是無用的。混淆後的代碼並非不可能閱讀，只會更難閱讀。我相信，熟練的攻擊者能夠將混淆後的代碼重新帶入可讀性更高的狀態。
但是， OWASP建議對移動客戶端使用混淆，
因此，我的問題是：混淆是否能帶來可衡量的安全性收益？具體來說，它的好處超過了增加的成本，複雜性和降低的性能。
注意：當我說“混淆”時，我是在談論為防止反向工程而採取的有意識步驟。編譯器優化儘管使程序集不那麼容易閱讀，但其目的是提高性能，而不是防止反向工程。
以我的經驗，在安全領域中並沒有收集到很多衡量指標和經驗證據。它主要是很多“應該這樣工作”，軼事經歷和外推法。就我個人而言，我認為代碼混淆不只是安全性，更在於它試圖保護業務利益和代碼秘密。
@SteveSether我也有同樣的想法，但是鑑於我認為OWASP是可靠的消息來源，所以我想看看我的斷言是否錯誤。
混淆的一個小好處是信息破壞。諸如口頭語言，編碼習慣等之類的東西。該過程（最終是代碼）可以重新理解，但是標識符會丟失。雖然，我無法想到一個合理的理由。此外，某些混淆處理（例如，時光倒流的Java）可能會在輸出中引入無法使用當前技術/反編譯器輕鬆重建的功能。這使得Java極難進行反編譯。因此，甚至可以阻止有經驗的用戶推斷代碼。這是一個比競爭對手更好的困惑。
我發現令人著迷的是，去混淆的可能性在很大程度上取決於代碼樣式。就像變量名的重要性一樣。該代碼可以用較低級別的語言編寫，並使用非常高級的模式。像面向對象的類大致在Java級別上一樣，所有類都根據需要部分實現。同樣，使用設計模式，甚至跨越更長的代碼區域。所有這些結構主要用變量名表示。相同類型的兩個值可以屬於不同的類別，以名稱表示。不同的類甚至可以是相同的。
“ OWASP建議對移動客戶端使用混淆處理”-可能僅是因為，例如，使JavaScript混淆最小化，但是真正的目的只是使其變得更小，傳遞更少的信息並加快Internet流量和網頁加載時間
@Mawg但是OWASP並不特別建議混淆JavaScript
這個問題實際上是為了什麼？鏈接的OWASP頁面從字面上給出了這樣一種威脅，即混淆應該有助於防止對該威脅和解決方案進行詳細描述。
可以將其視為您前門的鎖。它決不能阻止某人闖入，但如果隔壁的房子沒有鎖或沒有鎖，那該人為什麼要弄亂你的門？如果他們有足夠的動力來瞄准你，那麼即使是電子圍欄也不會阻止他們。鎖也可以辯護-可以在法庭上辯護，因為它證明了該人有動機去獲得它，而不是能夠聲稱自己被邀請進入內部。
@Mawg該建議位於標題為“如何防止'逆向工程'？”的框中。該頁面全部關於逆向工程，而不是性能。
我認為是否提供安全利益與是否提供可衡量的安全利益是分開的。我相信它可以帶來安全利益，但是我不知道如何衡量利益。
真正的Javascript混淆：將其全部翻譯為[JSFuck]（http://www.jsfuck.com/）。
@Gloweye除了有些自動化工具，例如[JSUnFuck]（http://codertab.com/jsunfuck）完全將其反向
就像您將兩輛相同的汽車停放在一起，但其中一個將（明顯地）安裝了警報而其他沒有安裝了警報一樣。如果一個壞人會來並想要偷走其中一個，您認為他會選擇哪個？當然，如果他想要具體的東西，他還是會接受。這只是一個好習慣，通常不花任何錢就這樣做；）與JS有關，我通常將其視為縮小而不是迷戀。而且，如果可以將來源縮小為原始內容的一半，那麼這樣做是一個好主意。
_“ ...超過增加的成本，複雜性和降低的性能的好處。” _-解決您的問題的錯誤方面，但我會補充（或提醒您，它已包含在“成本”中，除了“降低性能”方面），當混淆本身將錯誤引入代碼時，用戶遇到的困難。這是旨在執行版權保護的技術措施的最大問題之一：它們總是使用戶體驗變差。合法用戶，那就是。亂砍並繞過複製保護的人不會受到這種不良影響。
令我震驚的是，有人會*有意*混淆代碼！