Lập kế hoạch và mã hóa obfuscation

Question

Chủ lao động của tôi sử dụng Dotfuscator trên tất cả phần mềm sản xuất .Net của chúng tôi. Bởi vì điều này, chúng ta tuyệt đối bị cấm sử dụng bất kỳ databinding tích hợp hoặc bất cứ điều gì phản ánh về tên thuộc tính/chức năng - bởi vì dotfuscator thay đổi chúng và do đó bất cứ điều gì ràng buộc ngay lập tức và irredeemably phá vỡ.

Tôi tiếp tục lăn logic này trong tâm trí của mình và nó bắt đầu bị tổn thương. Có phải là một cách để tránh bế tắc này, nó quá rộng và một vấn đề cơ bản để không có một giải pháp rõ ràng đã thoát khỏi chúng ta.

Vì vậy, làm cách nào để phản ánh với Obfuscation? Bí quyết là gì? Có lẽ phải có các obfuscators thương mại đủ thông minh để giải quyết vấn đề. Các tùy chọn cho phiên bản của chúng tôi (khá ngu ngốc) là gì?

Answer 1

Chúng tôi đã thực hiện một số cải tiến cho Dotfuscator để giúp giảm bớt các vấn đề liên quan đến databinding. Chức năng Obfuscation thông minh đã được thêm vào trong phiên bản 4.3.100 vào tháng 3 năm 2008 để phân tích tĩnh các hội đồng và tự động loại trừ các mục từ việc đổi tên/xóa bỏ được biết là gây ra lỗi thời gian chạy. Chúng tôi đã liên tục mở rộng và nâng cao chức năng này và Dotfuscator ngày nay hoạt động xung quanh các kịch bản ràng buộc dữ liệu chuẩn với thường không có cấu hình bổ sung tối thiểu. Thậm chí nếu Obfuscation thông minh không nắm bắt mọi tình huống của bạn, rất dễ xác định các quy tắc tùy chỉnh để loại trừ các thuộc tính của một số loại hoặc phân cấp thừa kế bằng cách sử dụng quy tắc loại trừ tùy chỉnh (bao gồm các loại đối sánh theo mẫu RegEx). Bạn cũng có thể trang trí các mục có thuộc tính System.Reflection.ObfuscationAttribute để đảm bảo rằng chúng sẽ bị loại trừ khỏi việc đổi tên hoặc xóa khi chạy qua Dotfuscator.

Nếu bạn đang ràng buộc từ đánh dấu XAML đến các loại trong codebehind, một vài bản phát hành cuối cùng đã hỗ trợ đổi tên XAML/BAML để khớp với mã phía sau. Điều này cải thiện tổng thể cứng và cũng loại bỏ một loạt các vấn đề khi các biểu tượng trong đánh dấu không phù hợp với các định nghĩa mã.

Tôi khuyên bạn nên thực hiện một số bằng chứng đơn giản về các ứng dụng khái niệm bằng cách sử dụng databinding tương tự như những gì bạn muốn sử dụng trong các ứng dụng của mình và chạy chúng thông qua Dotfuscator để xem nó xử lý chúng như thế nào. Nếu bạn tìm thấy bất kỳ tình huống nào mà Obfuscation thông minh không tự động loại trừ các mục tiêu ràng buộc dữ liệu, hãy gửi chúng đến support@preemptive.com. Chúng tôi luôn tìm kiếm các kịch bản được xác định rõ ràng để cải thiện sản phẩm.

Answer 2

Đó là công việc của một bộ obfuscator để phá vỡ các mối quan hệ có thể nhìn thấy trong mã nguồn để chúng không còn rõ ràng trong mã thực thi kết quả. Phản ánh dựa trên các mối quan hệ như “tài sản được yêu cầu bởi đoạn mã này là mã được định nghĩa bởi đoạn mã đó”. Vì vậy, nó không đáng ngạc nhiên rằng obfuscation và phản ánh không chơi tốt với nhau.

Đổi tên các thuộc tính chỉ bằng 0 độ obfuscation. Một obfuscator nontrivial cũng sẽ làm những việc như chia thuộc tính thành hai, để mã nguồn chỉ đề cập đến một thuộc tính P, một số mã thời gian chạy sẽ sử dụng P1, và một số mã thời gian chạy sẽ sử dụng P2, và sẽ có đủ các bài tập giữa chúng để các thuộc tính có giá trị đúng khi cần thiết, nhưng cũng là các phép gán ký sinh để chúng không có giá trị đúng khi chúng không cần thiết. Nó không chỉ là P đã được đổi tên: không còn là một thuộc tính P.

Tôi không biết tại sao bạn nghĩ rằng sự phản chiếu cộng với sự xáo trộn là “phạm vi rộng và cơ bản”: cả phản ánh lẫn sự xáo trộn đều khá hiếm trong chương trình lớn của chương trình, và không có sự tương quan giữa việc sử dụng chúng, vì vậy tôi không nghĩ nhiều người đang cố gắng có cả hai.

Việc thiếu sự phản ánh chỉ là một mục trong danh sách dài những thứ làm cho chi phí làm xáo trộn bạn. Nếu người quyết định sử dụng obfuscation không phải là một maven an ninh, cố gắng để búa nó vào chúng mà obfuscation có một chi phí rất cao mà họ chắc chắn đã đánh giá thấp.