Các trường hợp cho mã obfuscation?

Các lý do hàng đầu để viết mã bị xáo trộn, về mặt lợi ích thực sự cho những người phát triển mã và doanh nghiệp chạy mã đó (nếu mã đang được đề cập là trên thực tế là mã giao dịch)? Có trường hợp tài liệu nào (có sẵn trực tuyến ở một số địa điểm) mô tả khi obfuscation làm tốt hơn xấu? Có những ví dụ nổi tiếng trong đó, ví dụ, obfuscation đã được chứng minh là có ý nghĩa trì hoãn một bên thứ 3 độc hại khỏi nhận mã? Có vẻ như, giống như việc cuộn các cửa sổ xe hơi của bạn sẽ không ngăn mọi người phá vỡ chúng và đánh cắp âm thanh nổi của bạn, làm xáo trộn mã của bạn chỉ giữ cho những người trung thực thành thật.

=========

Lý lịch:

Đây là một nỗ lực nhằm cố tình thách thức các giả định của tôi về chủ đề này.

Nói chung tôi rất khó chống lại việc sử dụng mã obfuscation, nhưng tôi tò mò liệu tôi có thiếu thứ gì không. Tôi hiểu tại sao, trong các trường hợp như JavaScript, việc thu nhỏ giúp mọi thứ tải nhanh hơn và tất cả (có lợi ích thực sự, chức năng ở đó), nhưng dường như tôi không thể đưa ra một lý do duy nhất tại sao mã bị che giấu, với mục đích trở thành một trở ngại để khám phá những gì một phần của mã / thuật toán làm , thực sự có hiệu quả cho bất kỳ mục đích nào.

Với nguồn mở đang trở nên phổ biến, câu hỏi dường như là "chia sẻ mã, hoặc giữ nó độc quyền?" Khi nói đến mã thương mại, tôi có thể hiểu lý do tại sao bạn không thể chia sẻ mọi thứ và bạn đã có luật pháp để chống trộm.

BTW, nếu lý do ai đó viết mã bị xáo trộn là "bảo mật công việc" thì tôi sẽ sa thải bất kỳ lập trình viên nào được tìm thấy một cách nhất quán và cố tình sử dụng obfuscation với mục đích duy nhất là giúp giữ công việc của họ, trừ khi họ có thể chứng minh rằng nó có một số lợi ích kinh doanh. Điều đó hoàn toàn chống lại đội ngũ đến mức thật nực cười, và chỉ ra ai đó quan tâm hơn đến việc giữ công việc của họ thông qua các hoạt động sai lầm, sau đó giữ nó vì họ viết phần mềm tuyệt vời.

Tôi chỉ đề cập đến trường hợp cụ thể này bởi vì, trong khi tôi nhận ra mọi người thường nói đùa, tôi muốn răn đe bất kỳ câu trả lời nào mà lực đẩy cơ bản của nó là che giấu cho an ninh công việc là một ý tưởng tốt.

Một trường hợp sử dụng rất thú vị để che giấu là truy tìm nguồn gốc của các bản sao bất hợp pháp. Giả sử rằng obfuscation là một hoạt động tương đối rẻ, tác giả ban đầu có thể cung cấp cho mỗi khách hàng các phiên bản ứng dụng bị che khuất khác nhau, nếu tìm thấy một bản sao bất hợp pháp, tác giả có thể so sánh với các phiên bản được cung cấp và truy nguyên nguồn gốc của vi phạm bản quyền.

Đó là một hình thức của steganography , được truyền cảm hứng và biến thể của các sơ đồ mật mã "truy tìm" . Tôi không biết nó có phổ biến ¹ hay thậm chí nếu đó là một ý tưởng hay, nhưng tôi đã thấy nó được áp dụng trong thực tế theo các tham số sau:

• Thị trường toàn quốc cạnh tranh cao chỉ với hai nhà cung cấp,
• Khoảng 50 triển khai bao phủ thị trường,
• Thời gian phát triển trung bình cho cả hai ứng dụng là một vài năm (nhiều hơn hoặc ít hơn),
• Thời gian obfuscation trung bình cho ứng dụng của chúng tôi là một vài giờ,
• Tuổi thọ cho cả hai ứng dụng dự kiến ​​là khoảng mười năm.

Cơ sở lý luận tất nhiên là bảo mật thông qua che khuất ban đầu, và nó đã phát triển theo sơ đồ nói trên tại một số điểm ² . Cả hai nhà cung cấp đều có quyền truy cập vào mã nhị phân của nhau, và tôi nghĩ rằng rõ ràng là các nỗ lực dịch ngược từ cả hai đều được mong đợi. Obfuscation không làm gì về mặt an ninh, về lâu dài. Cả hai nhà cung cấp đều có những đội ngũ có động lực và tài năng cao, làm việc trong một thị trường cực kỳ có lợi nhuận và cuối cùng, sản phẩm của chúng tôi giống nhau hơn không, và bất kỳ lợi thế cạnh tranh nào cũng có được thông qua các phương tiện khác, ít mơ hồ hơn.

Tôi thực sự không thể mở rộng, vì (a) còn rất sớm trong sự nghiệp của tôi và tôi đã không có được một cái nhìn tổng quan rõ ràng về các quyết định thiết kế hoặc kết quả của kế hoạch truy tìm (nếu có) và (b) một số sự liên quan của tôi với dự án là một NDA.

Một trường hợp sử dụng hợp lệ khác cho obfuscation có thể là khi bạn bằng cách nào đó có nghĩa vụ pháp lý để gửi mã của mình cho bên thứ ba :

Nếu công ty của bạn làm việc IP cho các công ty công nghệ hoặc liên quan đến các vụ việc liên quan đến mã nguồn phần mềm, bạn có thể phải nộp mã nguồn của khách hàng của mình cho USPTO, tòa án hoặc bên thứ ba.

Vì mã nguồn được coi là bí mật thương mại, hầu hết các cơ quan quản lý sử dụng quy tắc "50%". Mã nguồn được gửi bị che khuất để không thể sử dụng nguyên trạng.

IANAL và liên kết có liên quan nhiều hơn đến các bản sao mã cứng hơn là mã làm việc thực tế, vì vậy điều này có thể hoàn toàn không liên quan.

Bây giờ, vì Javascript là ví dụ điển hình cho việc xáo trộn, có một tác dụng phụ không được xem xét phổ biến và đó là ẩn mã độc trong Javascript bị che khuất. Mặc dù có những lợi thế nhất định trong việc thu nhỏ ³ Javascript, tôi không thấy bất kỳ điểm nào trong việc che giấu thực tế và tôi rất vui khi Douglas Crockford đồng ý với tôi :

Cuối cùng, có câu hỏi về quyền riêng tư. Đây là một nguyên nhân bị mất. Không có chuyển đổi sẽ giữ cho một hacker quyết tâm hiểu chương trình của bạn. Điều này hóa ra đúng với tất cả các chương trình ở tất cả các ngôn ngữ, nó hoàn toàn đúng với JavaScript vì nó được phân phối ở dạng nguồn. Lợi ích riêng tư được cung cấp bởi obfuscation là một ảo ảnh. Nếu bạn không muốn mọi người xem chương trình của mình, hãy rút phích cắm máy chủ của bạn.

Đối với obfuscation cho "bảo mật công việc", đó là một hành vi không bao giờ vượt qua đánh giá mã, và nếu được xác định thì không nên dung thứ. Ban đầu tôi sẽ không bắn xa thủ phạm, nhưng những kẻ phạm tội lặp lại chắc chắn xứng đáng được đánh đòn tốt, ít nhất là vậy.

Tóm lại, obfuscation là một ví dụ điển hình của bảo mật thông qua che khuất, nó chỉ có giá trị rõ ràng là như một biện pháp ngăn chặn và không có gì hơn thế. Có thể có những trường hợp sử dụng sáng tạo ⁴ Tôi không biết, nhưng nói chung, lợi ích là tối thiểu, tốt nhất.

_{¹ Sau khi viết bài này, tôi đã tìm ra câu trả lời này về cơ bản mô tả cùng một sơ đồ, vì vậy nó có thể phổ biến hơn mà tôi nghĩ.
² Mặc dù steganography vẫn bảo mật thông qua che khuất.
³ Giảm thiểu ~ xóa khoảng trắng và rút ngắn mã thông báo, không cố ý che khuất.
⁴ Có phải bị xáo trộn C Cuộc thi luật quốc tế đếm?}

Trường hợp đối với mã obfuscation là nó tăng thanh cho bên thứ 3 để xác định những gì / làm thế nào mã đang hoạt động.

Tuy nhiên, điều đó KHÔNG có nghĩa là nhà phát triển nên viết mã bị xáo trộn.

Hãy xem, đây là bit tôi nghĩ là thiếu trong câu hỏi của bạn: Mã hóa mã (giống như thu nhỏ JavaScript) không cần - và không nên - được nhà phát triển thực hiện thủ công. Tương tự, điều này không nên được lưu trữ dưới dạng tệp nguồn lõi của bạn trong phiên bản kiểm soát.

Mã obfuscation nên xảy ra như một bước xử lý bài trong quá trình biên dịch vào bản dựng sản xuất của bạn. Có rất nhiều sản phẩm của bên thứ 3 cũng làm điều này, vì vậy hầu như không có lý do gì để làm điều này trong nhà.

Ví dụ: Dotfuscator

IEEE có một bài viết về hiệu quả của mã obfuscation

Kết quả cho thấy việc đổi tên đáng kể sẽ giảm đáng kể hiệu quả của các cuộc tấn công, ít nhất là gấp đôi thời gian cần thiết để hoàn thành một cuộc tấn công thành công (ngay cả trong trường hợp xấu nhất, ví dụ, chống lại kẻ tấn công tốt nhất). Ngoài ra, obfuscation làm giảm khoảng cách giữa những kẻ tấn công mới và những kẻ tấn công lành nghề, làm cho nó trở nên ít hiệu quả hơn và làm cho các hệ thống dễ dàng tấn công rõ ràng tương tự như những kẻ thực chất khó phá vỡ hơn.

Nhấn mạnh mỏ.

Tôi đã tham gia phát triển MMORPG. Điều này liên quan đến logic máy chủ và logic máy khách. Trong suốt quá trình phát triển kéo dài nhiều năm của dự án, bất cứ khi nào chúng tôi xem xét giao diện giữa máy khách và máy chủ, quy tắc là máy khách phải được xử lý bởi máy chủ mọi lúc theo giả định rằng nó đã bị hack. Nói cách khác, máy chủ phải được viết theo cách mà không có phản hồi nào có thể đến từ máy khách sẽ khiến máy chủ bị lỗi hoặc cho phép máy khách gian lận. Tuy nhiên, ngay từ đầu, người ta đã biết rằng tin tặc chắc chắn sẽ tìm thấy các lỗ hổng trong hệ thống và khai thác chúng để gian lận. Và sau một thời gian họ đã làm.

Tất nhiên, trước khi đưa khách hàng đến thế giới rộng lớn ngoài kia, chúng tôi chắc chắn đã làm xáo trộn nó. Chúng tôi tin rằng obfuscation có những tác dụng sau:

1. Nó ngăn cản các tin tặc không chuyên gia thậm chí cố gắng.
2. Nó trì hoãn tin tặc chuyên gia trong việc đạt được bất kỳ hack.
3. Nó làm giảm số lượng hack đạt được bởi các tin tặc chuyên gia.
4. Nó hạn chế tính hiệu quả của các vụ hack.
5. Quan trọng nhất: nó khiến các tin tặc thực hiện nhiều lần chạy thử với các máy khách bị tấn công của chúng trước các máy chủ của chúng tôi trước khi đạt được một bản hack hoạt động, điều này làm tăng cơ hội chúng tôi phát hiện ra chúng bằng cách tìm kiếm hoạt động bất thường trong nhật ký máy chủ.

Tài khoản trò chơi của các tin tặc được phát hiện đã bị chấm dứt mà không được hoàn lại, do đó, điều này làm cho việc kinh doanh hack trở nên tốn kém và kém hấp dẫn hơn.

Vì vậy, do tất cả những điều trên, tôi tin rằng obfuscation có tác động tích cực tổng thể trong trò chơi của chúng tôi và bằng cách mở rộng, obfuscation có thể có tác động tích cực tổng thể trong bất kỳ phần mềm nào có thể bị hack. (Ví dụ: phần mềm chứa các biện pháp bảo vệ bản sao.)

Những ảnh hưởng mà obfuscation có đối với việc bảo trì gần như không có. Có một vài nơi mà một số lập trình viên thiếu kinh nghiệm đã đưa ra các giả định về tên của các định danh, (họ đang sử dụng sự phản chiếu), nhưng một khi chúng được sắp xếp thì mọi thứ đều ổn. Bước obfuscation chỉ trở thành một phần của bước xây dựng tổng thể cho phiên bản sản xuất của trò chơi, vì vậy hầu hết các nhà phát triển của chúng tôi không bao giờ phải lo lắng về nó hoặc có bất cứ điều gì để làm với nó. Chúng tôi đã có một công cụ để xem nhật ký của trò chơi, vì vậy chúng tôi đã sửa đổi công cụ này để sử dụng bảng kết hợp (ánh xạ các định danh bị che khuất thành các định danh thích hợp) do obfuscator tạo ra để dịch các bản ghi cho chúng tôi một cách nhanh chóng, vì vậy chúng tôi không bao giờ thậm chí phải xem bất kỳ số nhận dạng bị che khuất nào trong khi thực hiện kiểm tra sau khi chết dựa trên nhật ký được thu thập từ hiện trường.

Đọc và hiểu (và rõ ràng là viết) mã bị xáo trộn có thể là một thách thức tinh thần thú vị. Nó có thể nằm ngoài phạm vi của những gì bạn đã hỏi, nhưng các ví dụ như IOCCC có thể là một nguồn giải trí cũng như kinh dị.