Có quan trọng để làm xáo trộn mã ứng dụng C ++ không?


11

Trong thế giới Java, đôi khi dường như có vấn đề, nhưng, còn C ++ thì sao? Có những giải pháp khác nhau?

Tôi đã suy nghĩ về việc ai đó có thể thay thế thư viện C ++ của một HĐH cụ thể bằng một phiên bản khác của cùng một thư viện, nhưng có đầy đủ các ký hiệu gỡ lỗi để hiểu mã của tôi làm gì. IS là một điều tốt để sử dụng các thư viện tiêu chuẩn hoặc phổ biến?

Điều này cũng có thể xảy ra với một số thư viện dll trong Windows được thay thế bằng "phiên bản gỡ lỗi" của thư viện đó. Là nó tốt hơn để thích biên dịch tĩnh? Trong các ứng dụng thương mại, tôi thấy rằng đối với cốt lõi của ứng dụng, họ biên dịch mọi thứ tĩnh và đối với hầu hết các dll (thư viện động nói chung) được sử dụng để cung cấp một số công nghệ của bên thứ ba như giải pháp chống vi phạm bản quyền (tôi thấy điều này trong nhiều trò chơi ), Thư viện GUI (như Qt), thư viện hệ điều hành, v.v.

Là biên dịch tĩnh tương đương với obfuscation trong thế giới Java? Trong điều kiện tốt hơn, nó có phải là giải pháp tốt nhất và hợp lý nhất để bảo vệ mã của bạn?


4
Hãy nhớ rằng, bất cứ điều gì bạn làm, một người có quá nhiều thời gian sẽ có thể
khử nhiễu

13
Nhiều trình biên dịch đi kèm với một /Ochuyển đổi obfuscation. Một số thậm chí có nhiều mức độ obfuscation, lên đến /O3;)
MSalters

@MSalters Không, g ++ có -O3;)
BЈовић

@Zavior Hoặc chỉ cần thiết kế ngược lại, đơn giản và đơn giản. Nó thậm chí không yêu cầu nhị phân, chỉ là một phân tích kỹ lưỡng về phần mềm.
John Weisz

Câu trả lời:


27

Đừng lãng phí thời gian của bạn khi thua trận

Như đã lưu ý trong nhiều câu trả lời tương tự khác cho C ++ và các ngôn ngữ khác, điều này chủ yếu là vô dụng .

Đọc thêm

Các bài đọc được chọn về chủ đề (không phải tất cả đều cụ thể về C ++, nhưng các nguyên tắc chung được áp dụng):

Câu trả lời StackExchange

Giấy tờ

Trích dẫn nổi tiếng về Obfuscation:

Cuối cùng, có câu hỏi về quyền riêng tư mã. Đây là một nguyên nhân bị mất. Không có sự chuyển đổi nào sẽ khiến 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. - Douglas Crockford


Không bao giờ?

Tôi không nói rằng bạn không bao giờ nên che giấu và rằng không có bất kỳ lý do chính đáng nào cho nó, nhưng tôi nghiêm túc đặt câu hỏi về sự cần thiết của nó trong hầu hết các trường hợp và hiệu quả chi phí của nó.

Hơn nữa, có những tình huống obfuscation là một yêu cầu thực tế. Ví dụ, nếu bạn viết vi-rút, rõ ràng là obfuscation (và một động lực, tốt nhất là) là một điều tốt cho sự sống còn của chương trình của bạn vì nó có khả năng sao chép. Tuy nhiên, điều này hầu như không phải là một trường hợp "phổ biến" ...


Chúng tôi đã từng sử dụng một dongle phần cứng trong đó có yêu cầu cấp phép để quan sát tất cả các lệnh gọi hàm dongle - và họ đã cung cấp một công cụ để thực hiện. Luôn khiến tôi hơi nghi ngờ về chất lượng 'bảo vệ' của họ!
Martin Beckett

@MartinBeckett: thực sự kỳ lạ.
haylem

3

Không, điều này không đáng để nỗ lực và tôi nghĩ nó hoàn toàn không cần thiết. Các chức năng bạn gọi có thể được đoán bởi chức năng bạn cung cấp.

Lý do obfuscators tồn tại cho Java là vì ánh xạ giữa mã byte Java và mã nguồn Java được xác định khá rõ và tên của tất cả các hàm và biến thành viên được lưu trữ trong mã byte (bất kể chúng là công khai, riêng tư hoặc được bảo vệ ) vì vậy trình thông dịch mã byte Java có thể trình bày một số Java chung cho thấy cấu trúc của nguồn ban đầu khá tốt đối với nguồn không được kiểm tra.

C ++ biên dịch trực tiếp sang ngôn ngữ máy. Nó có thể được tháo rời, nhưng ngôn ngữ lắp ráp khá tẻ nhạt để đối phó. Dịch ngược là khó khăn hơn nhiều vì tất cả các thay đổi tối ưu hóa thực hiện cho mã trong quá trình biên dịch.


0

Suy nghĩ về điều này, có một số loại obfuscation khác nhau. Hãy bắt đầu với việc mã hóa mã nguồn, việc này hoàn toàn lãng phí thời gian; đủ khó để hiểu mà không có điều đó! Vì vậy, thay vào đó hãy tập trung vào việc xáo trộn gói phân phối, về cách mã được gửi đến người dùng.

Béo nhẹ

Obfuscation nhỏ tồn tại để ngăn người dùng thông thường chọc ngón tay vào và phá vỡ mọi thứ một cách dễ dàng. Nó không ngăn chặn được tin tặc xác định, nhưng nó có giá trị trong việc giúp đảm bảo rằng những thứ bạn được yêu cầu hỗ trợ là những gì bạn thực sự đã giao. Mức độ bảo vệ cần thiết cho loại điều này thực sự khá thấp; gói giao hàng chỉ đơn giản là trông không dễ đọc và có thể chỉnh sửa (không có công cụ chuyên môn) và điều đó khá tốt.

Thu nhỏ Javascript là một ví dụ về điều này, mặc dù nó không được bán trên thị trường như vậy. Không ai có thể muốn đọc và chỉnh sửa một tệp JS được rút gọn, ngay cả khi về mặt kỹ thuật hoàn toàn có thể làm được nếu bạn đủ quyết tâm / kiên trì.

Tương tự với việc phân phối các ứng dụng Java. Chỉ đóng gói mã vào một JAR thực thi sẽ ngăn chặn phần lớn sự dại dột, mặc dù nó có tất cả lực lượng của một câu lịch sự vui lòng Giữ lại Dấu hiệu Cỏ trong một công viên thành phố.

Ngay cả khi phân phối mã C ++, tước bỏ các ký hiệu không cần thiết từ tệp thực thi sẽ đủ để đủ điều kiện là mã hóa nhỏ. Điều quan trọng là thật khó xử khi đọc kết quả với tư cách là người dùng, nhưng không phải là vấn đề khi thực hiện nó dưới dạng máy tính.

Obfuscation lớn

Obfuscation chính là giữ cho người dùng xác địnhhiểu biết ra. Đây cũng là một trò chơi thua hoàn toàn; nếu một máy tính có thể thực thi nó, một người có thể tách nó ra và tìm ra những gì nó làm. Cách gần nhất bạn có thể nhận được là làm cho chương trình tự giải mã liên tục, biến đổi những gì nó làm một lúc thành một điều hoàn toàn khác mà nó làm vào một thời điểm khác. Việc tạo ra những thứ như vậy sẽ khá khó khăn và vẫn không thể ngăn chặn được một hacker thực sự giỏi (mặc dù chúng sẽ thực sự khá khó khăn với bạn khi kết thúc nó với số lượng nỗ lực cần thiết để giải mã tất cả mã tự sửa đổi đó).

Tốt hơn nhiều là suy nghĩ về các giải pháp khác. Ví dụ: bạn có thể giữ mã vương miện của nữ hoàng trên mã máy chủ mà bạn kiểm soát và chỉ cho phép các cuộc gọi dịch vụ đến nó, làm cho máy khách trở thành một tặng phẩm miễn phí về cơ bản là phần đầu cho các bit có giá trị. Hoặc bạn có thể đi theo con đường hợp đồng / hợp pháp hơn và chỉ bàn giao các cơ quan thực thi cho các tổ chức chính thức đồng ý không chọc vào mã của bạn hoặc bồi thường cho bạn nếu họ làm như vậy (vì vậy đó sẽ là một loại NDA). Mục đích sẽ là tạo ra một động lực mạnh mẽ để tin tặc không hack và cho người dùng để giữ mã khỏi mọi tin tặc không bị ràng buộc bởi thỏa thuận.

Nhưng bạn không được cho rằng mã của bạn không bao giờ bị bẻ khóa. Với ảo hóa, bất kỳ trạng thái chương trình thực thi nào cũng có thể được kiểm tra và theo dõi, và bất cứ điều gì cố gắng đánh bại điều đó (ví dụ, theo dõi đồng hồ đến nguồn thời gian bên ngoài) sẽ có nhiều khả năng gây ra sự cố cho người dùng hợp pháp hơn tin tặc. (Xem lịch sử của DRM để biết các nhà xuất bản thông tin rất kiên quyết không thể giữ an toàn cho hệ thống của họ một khi mã nằm trong tay đối thủ của họ.) Tốt hơn hết là tập trung vào việc làm cho người dùng thực sự hài lòng. Các khoản lỗ từ vết nứt thường xuyên sẽ không là gì so với số tiền thêm vào thông qua việc làm hài lòng khách hàng đúng cách.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.