Bảo vệ mã .NET khỏi kỹ thuật đảo ngược?


491

Obfuscation là một cách, nhưng nó không thể bảo vệ khỏi phá vỡ bảo mật chống vi phạm bản quyền của ứng dụng. Làm cách nào để đảm bảo rằng ứng dụng không bị giả mạo và làm cách nào để đảm bảo rằng cơ chế đăng ký không thể được thiết kế ngược?

Ngoài ra, có thể chuyển đổi ứng dụng C # sang mã gốc và Xenocode quá tốn kém.

C # cung cấp rất nhiều tính năng và là ngôn ngữ lý tưởng cho mã của tôi, vì vậy việc viết lại toàn bộ cơ sở mã trong C ++ là điều không cần thiết.

Chứng chỉ bảo mật có thể dễ dàng được gỡ bỏ khỏi các hội đồng đã ký trong .NET.



@Andreas: Thật tuyệt vời !! Tôi sẽ thử. Bất cứ ai sử dụng nó?
Jack

1
@ Chỉ dành cho các ứng dụng lưu trữ cửa sổ. Không có dòng thời gian cho các ứng dụng máy tính để bàn (theo như tôi có thể nói).
Tyler Long

Nếu bạn muốn bản địa không có C ++ cổ xưa, hãy sử dụng Delphi. Sự dễ dàng của .Net đến từ Delphi anyways.
William Egge

Câu trả lời:


671

Bạn không thể.

Có những bước bạn có thể thực hiện để làm cho nó khó khăn hơn một chút , nhưng cuối cùng bất kỳ thực thi nào trên máy cục bộ đều có thể bị bẻ khóa. Cuối cùng, mã đó phải được chuyển đổi thành mã máy gốc và mọi ứng dụng có thể chạy được đều dễ bị tấn công.

Những gì bạn muốn làm chỉ là làm cho nó đủ khó để bẻ khóa để làm cho nó không có giá trị rắc rối của mọi người.

Một số gợi ý tôi có cho bạn để giúp bảo vệ ứng dụng của bạn:

  • Làm xáo trộn mã của bạn. Dotfuscator có phiên bản miễn phí và đi kèm với Visual Studio.
  • Sử dụng khóa chung / riêng hoặc mã hóa bất đối xứng để tạo giấy phép sản phẩm của bạn. Điều này đảm bảo rằng chỉ bạn mới có thể tạo mã giấy phép của mình. Thậm chí nếu ứng dụng của bạn được nứt, bạn có thể chắc chắn rằng họ sẽ không được phát hành một máy phát điện chính cho ứng dụng của bạn, bởi vì nó là không thể đảo ngược các thuật toán tạo ra chìa khóa.
  • Sử dụng trình đóng gói của bên thứ ba để đóng gói tệp thực thi .NET của bạn vào ứng dụng trình bao bọc Win32 được mã hóa. Themida là một trong những người tốt hơn. Điều này ngăn mọi người phản ánh ứng dụng của bạn trong .NET Reflector và khiến cho việc giải nén bị đảo ngược trở nên khó khăn.
  • Viết trình đóng gói tùy chỉnh của riêng bạn . Nếu các nhà đóng gói bên thứ ba quá đắt tiền, hãy xem xét việc viết của riêng bạn. Đôi khi các trình đóng gói tùy chỉnh có thể rất hiệu quả, vì không có phương pháp được công bố tốt về cách giải nén chúng. Hướng dẫn Cách viết trình đóng gói của riêng bạn cung cấp rất nhiều thông tin tốt về cách viết trình đóng gói Win32 của riêng bạn.

Cuối cùng, nếu mọi người muốn ứng dụng của bạn bị bẻ khóa thì họ sẽ làm. Nhìn vào tất cả các phần mềm thương mại ngoài kia có một lượng lớn tài nguyên để bảo vệ các ứng dụng của chúng và chúng vẫn bị bẻ khóa trước khi các ứng dụng thậm chí được phát hành ra công chúng.

Một kỹ sư đảo ngược có tay nghề cao có thể kích hoạt IDA-Pro và cắt qua ứng dụng của bạn như bơ bất kể bạn làm gì. Một ứng dụng đóng gói có thể được giải nén và obfuscation chỉ ngăn không cho nó đi dạo trong công viên. Tất cả công việc khó khăn của bạn với mã giấy phép phức tạp của bạn có thể được hoàn tác với một bản vá byte đơn.

Bạn chỉ cần chấp nhận rằng có một cơ hội rất thực tế mọi người sẽ vi phạm bản quyền phần mềm của bạn. Có một số người sẽ không bao giờ trả tiền cho ứng dụng của bạn cho dù đó là những gì bạn không cần phải lo lắng.

Tuy nhiên, có nhiều doanh nghiệp không bao giờ mạo hiểm kiện và vui vẻ mua giấy phép phần mềm và nhiều người dùng máy tính không muốn mạo hiểm, thấy nó sai hoặc không đủ hiểu biết về công nghệ để vi phạm bản quyền. Đây là những khách hàng thực sự của bạn và bạn nên tập trung nỗ lực vào việc cung cấp cho họ trải nghiệm người dùng tốt và bỏ qua những người bẻ khóa phần mềm của bạn.

Trước đây tôi đã đăng ký bản quyền của mình và tôi coi đó là một vấn đề cá nhân. Tôi đã ở đây, một nhà phát triển thời gian nhỏ, đổ cả trái tim và tâm hồn vào một ứng dụng và những người này đã có mật để cướp biển từ tôi?! Họ đã lấy tiền trực tiếp từ túi của tôi!

Tôi ngay lập tức thêm vào một loạt mã DRM hà khắc và cố gắng phá hoại bất kỳ người nào bằng cách sử dụng một bản sao bất hợp pháp hoặc bị bẻ khóa. Tất nhiên tôi nên làm việc để làm cho ứng dụng của mình tốt hơn thay vì cố gắng ngăn chặn điều không thể tránh khỏi. Không chỉ vậy, nhưng tôi đã làm tổn thương những khách hàng thực sự của mình, tất cả những sự bảo vệ thêm này tôi sẽ đưa vào.

Sau một trận chiến dài, tôi nhận ra mình đang chiến đấu với thủy triều và tất cả thời gian này bị lãng phí là vô ích. Tôi lấy ra tất cả các mã nhà điện thoại ngoại trừ các chức năng giấy phép barebones và không bao giờ nhìn lại.


67
Vì vậy, +1 gần như là +2. Tôi ước nhiều người cuối cùng sẽ hiểu rằng bạn chỉ đơn giản là không thể bảo vệ phần mềm của mình trước kẻ tấn công quyết tâm.
Bombe

102
Bạn đã đạt đến niết bàn bảo vệ phần mềm: không phải là thêm bảo vệ, mà là tập trung vào sản phẩm và làm cho nó tốt đến mức mọi người MUỐN trả tiền cho nó. Và đối với những người vi phạm bản quyền, họ sẽ không bao giờ trả bất cứ cách nào vì vậy như thể họ chưa từng tồn tại.
Arthur Chaparyan

6
@Arthur Chaparyan, tôi đồng ý. Phải mất một thời gian dài để đến đây nhưng cuối cùng tôi đã nhìn thấy ánh sáng. Tôi đã đi vào con đường của sự bảo vệ hạn chế hơn và chiến đấu với các cracker. Tôi đã học được tất cả những gì có thể về kỹ thuật đảo ngược trong nỗ lực ngăn chặn chính tôi. Cuối cùng tôi đã tìm ra ý thức hệ đúng đắn
mmcdole

50
Địa ngục tôi đã rất vinh dự khi phát hiện ra ai đó nghĩ rằng phần mềm của tôi đáng để vi phạm bản quyền ...
Erik Forbes

10
Khi bạn bắt đầu dựa vào doanh số bán phần mềm của mình cho phần lớn thu nhập của bạn, nó sẽ thay đổi mọi thứ. Cảm giác như ai đó đang ăn cắp từ bạn. Tôi hiểu những gì bạn đang nói mặc dù. Tôi đã bị sốc khi lần đầu tiên tìm thấy các vết nứt cho phần mềm của mình trên các trang web torrent.
mmcdole

265

Bạn không thể bảo mật hoàn toàn bất kỳ ứng dụng nào (được quản lý hay không). Nếu các hệ thống như Playstation và iPad có thể bị bẻ khóa - nơi nhà cung cấp thậm chí kiểm soát phần cứng - ứng dụng của bạn có hy vọng gì? Rất may, bạn không thực sự muốn. Theo tôi, bạn cần bảo mật ứng dụng của mình vừa đủ để ai đó không thể vô tình vi phạm bản quyền sản phẩm của bạn và không còn nữa.

Ví dụ: nếu bạn sử dụng giấy phép cho mỗi máy, nó sẽ không hoạt động khi bạn cài đặt nó trên máy thứ hai mới. Bạn sẽ muốn có một thông báo lỗi tốt để ngăn các cuộc gọi hỗ trợ thêm, nhưng đừng dành thêm thời gian để làm cho nó quá khó để xử lý và đừng đánh vào đầu người dùng.

Một ví dụ khác là một thử nghiệm giới hạn thời gian. Thậm chí đừng lo lắng về những điều đơn giản như nếu người dùng có thể quay ngược đồng hồ hệ thống. Một người nào đó biết rằng họ đang vi phạm giấy phép của bạn và miễn là người dùng biết khi nào họ vi phạm bạn đã làm đủ.

Bạn cần phải làm điều này nhiều vì người dùng không quan tâm đến giấy phép của bạn. Giấy phép là những thứ trang điểm mà không ai quan tâm cho đến khi họ cần. Không ai đọc chúng, và họ thực sự không cần phải làm vậy. Do đó, cách tốt nhất để cho người dùng biết ranh giới là ở đâu nếu hành vi vượt trội cho ứng dụng của bạn tuân thủ giấy phép. Trong trường hợp đầu tiên này có nghĩa là không cài đặt hoặc cài đặt ở chế độ phiên bản dùng thử lần thứ hai. Đối với cái sau, nó có thể chỉ có nghĩa là kiểm tra một ngày văn bản đơn giản trong một tệp cấu hình. Dù bằng cách nào, hãy chắc chắn rằng bạn xử lý nó một cách thanh lịch, hữu ích và tôn trọng.

Vì vậy, điều đó giải thích những gì nó có nghĩa là làm nhiều như vậy. Nhưng tại sao không đi xa hơn? Tại sao không cắm mỗi lỗ nhỏ bạn có thể tìm thấy? Câu trả lời là hai phần. Đầu tiên, nếu ai đó sẽ vượt qua ngưỡng đạo đức khi cố tình vi phạm các điều khoản cấp phép của bạn - thậm chí theo một cách đơn giản - họ cũng sẽ sẵn sàng làm điều gì đó khó khăn hoặc nguy hiểm hơn như rút ứng dụng của bạn khỏi torrenttrang web - và có một số nguy hiểm nhất định liên quan đến việc chạy các ứng dụng được tải xuống từ các nguồn không đáng tin cậy. Làm cho nó trở nên khó khăn hơn chỉ là một phiền toái nhỏ cho những người dùng này và rủi ro gây ra vấn đề với khách hàng trả tiền của bạn. Giữ cho nó đơn giản có thể ngăn ai đó đào sâu vào ứng dụng của bạn và giải phóng một vết nứt toàn diện hơn. Thứ hai, bạn có ít mắt để tìm kiếm sai sót; Các tin tặc có rất nhiều, và chúng có nhiều thực hành hơn để tìm thấy chúng. Bạn chỉ cần bỏ lỡ một lỗ hổng nhỏ và ứng dụng của bạn sẽ có cùng phân phối trên các trang web vi phạm bản quyền như thể bạn không làm gì cả. Bạn phải luôn luôn đúng; họ chỉ phải may mắn một lần. Vì vậy, nỗ lực cần có là rất cao và khả năng của bất kỳ thước đo thành công nào là rất thấp.

Cuối cùng, nếu ai đó muốn cướp ứng dụng của bạn (như trái ngược với chỉ sử dụng nó), và đó là mục tiêu chính của họ, họ sẽ làm. Bạn không thể làm gì để ngăn chặn chúng. Đây là bản chất của phần mềm; một khi các tệp tạo nên sản phẩm của bạn nằm trên máy tính của người dùng, họ sẽ có thể thực hiện với chúng theo ý muốn. Điều này đặc biệt có liên quan trong các môi trường được quản lý như Java hoặc .NET , nhưng nó chắc chắn cũng áp dụng cho mã gốc. Thời gian đứng về phía họ, và cho đủ thời gian bất kỳ bảo mật kỹ thuật số nào cũng có thể bị phá vỡ.

Vì bạn không thể ngăn người dùng vi phạm bản quyền sản phẩm của mình, nên hành động tốt nhất của bạn là thu hút nhóm người dùng này theo cách sử dụng họ để mang lại lợi ích cho bạn. Thường có thể khiến họ làm việc cho bạn hơn là chống lại bạn. Với ý nghĩ đó, cho dù ứng dụng của bạn là gì, có lẽ nó đáng để giữ một phiên bản miễn phí gần như hoàn toàn hoạt động và không hết hạn. Sự khác biệt giữa ngay cả thẻ giá 1 đô la Mỹ và miễn phí là rất lớn, nếu không vì lý do nào khác, khách hàng không phải tin tưởng bạn với thẻ tín dụng của họ. Một phiên bản miễn phí của sản phẩm của bạn sẽ không chỉ tiêu diệt phân phối lậu một cách hiệu quả (tại sao lại mạo hiểm với phiên bản lậu khi bạn có thể hợp pháp với cùng một mức giá?), Nó có khả năng mở rộng đáng kể đối tượng của bạn.

Kết quả là bạn có thể cần tăng giá của phiên bản trả tiền, để cuối cùng thay vì 2.000 người dùng ở mức 20 đô la, bạn có 100.000 người dùng miễn phí, trong đó 500 người sẵn sàng trả 99 đô la cho phiên bản "chuyên nghiệp" . Điều này kiếm được nhiều tiền hơn so với việc bạn dành nhiều thời gian để khóa sản phẩm của mình. Hơn thế nữa, bạn có thể thu hút những người dùng miễn phí này và tận dụng mối quan hệ theo nhiều cách quan trọng.

Một là hỗ trợ. Một người bi quan sẽ nhân cơ hội này để phàn nàn về chi phí tăng thêm khi hỗ trợ 100.000 người dùng miễn phí, nhưng thay vào đó, một điều đáng kinh ngạc xảy ra: sản phẩm của bạn chủ yếu tự hỗ trợ. Bạn thấy điều này mọi lúc với các dự án nguồn mở lớn không có tiền cho chi phí hỗ trợ. Người dùng sẽ bước lên và làm cho nó xảy ra.

Người dùng miễn phí thường giảm các kỳ vọng hỗ trợ để bắt đầu và vì lý do chính đáng. Tất cả những gì bạn cần làm là đánh dấu phiên bản miễn phí là chỉ đủ điều kiện nhận hỗ trợ cộng đồng và đưa lên một diễn đàn trực tuyến được kiểm duyệt bởi người dùng cho mục đích đó. Cơ sở kiến ​​thức hỗ trợ của bạn là tự tạo và người dùng nâng cao sẽ hướng dẫn những người cần nắm tay thêm. Thậm chí quan trọng hơn, điều này sẽ cho phép bạn xác định và sửa lỗi nhanh hơn, cuối cùng là cải thiện chất lượng sản phẩm của bạn và giảm tổng chi phí hỗ trợ. Điều này là không thể trước đây vì cơ sở người dùng của bạn không đủ lớn, nhưng khi bạn coi người dùng miễn phí là khách hàng thì nó có thể hoạt động rất tốt.

Khác là thông tin phản hồi. Bằng cách xem diễn đàn của bạn, bạn học được những ý tưởng cải tiến quan trọng mà bạn có thể chưa bao giờ xem xét khác. Điều này có thể cho phép bạn cuối cùng biến nhiều người dùng miễn phí của mình thành người dùng trả tiền và tạo ra một sản phẩm hấp dẫn hơn sẽ thu hút được lượng khán giả lớn hơn.

Cuối cùng, bạn cần xem xét tiếp thị. Tất cả những người dùng miễn phí này hiện là người hâm mộ thay vì đối thủ và họ sẽ hành động tương ứng. Không chỉ vậy, khi đến lúc phát hành phiên bản tiếp theo của bạn, những người dùng này sẽ hoàn toàn đi qua kênh phân phối được phê duyệt của bạn, thay vì một số cơ chế chưa biết khác. Điều đó có nghĩa là đối với phiên bản tiếp theo của bạn, bạn bắt đầu kết nối với đối tượng lớn hơn, rất quan tâm và hỗ trợ.

Các tính năng tốt nhất để dành cho phiên bản chuyên nghiệp là các công cụ nhằm mục đích giúp cho việc triển khai và quản lý doanh nghiệp trở nên dễ dàng. Một kẻ bẻ khóa sẽ không coi đây là một lý do đủ hấp dẫn để hack nó để sử dụng cho riêng mình, nhưng đối với một doanh nghiệp đang tìm mua 300 giấy phép và đẩy nó ra toàn công ty thì đây là điều bắt buộc. Tất nhiên, dù sao thì phiên bản chuyên nghiệp cũng sẽ bị sao chép, nhưng một lần nữa: đừng đổ mồ hôi vì có lẽ bạn sẽ không thể bán sản phẩm cho những tên cướp đó bất kể bạn đã làm gì, vì vậy nó không làm bạn mất bất kỳ doanh thu nào .

Mặc dù về mặt tâm lý có thể khó có thể cho đi sản phẩm của bạn nhiều như vậy, hy vọng bạn có thể hiểu làm thế nào nó thực sự là cách tốt nhất để đi. Không chỉ vậy, đó là cách duy nhất để đi trong dài hạn. Tôi biết ai đó ở ngoài kia nghĩ rằng họ không muốn làm theo cách này. Rốt cuộc, họ đã có được bằng cách bán tốt sản phẩm $ 20 bị khóa trong nhiều năm. Nhưng điều đó thật tệ, bởi vì nếu bạn không làm theo cách này, cuối cùng sẽ có người khác làm . Và sản phẩm của họ sẽ tốt như của bạn, hoặc đủ gần để họ có thể thoát khỏi việc tuyên bố điều đó. Sau đó, đột nhiên giá của bạn trông cực kỳ, doanh số giảm đáng kể và bạn không thể làm gì khác. Bạn có thể chọn cho một tầng trung lưu bổ sung nếu bạn phải, nhưng nó không thể giúp bạn.


1
@ Học: nó phát triển theo thời gian và vượt qua chuyển đổi tự động sang ngưỡng CW.
Joel Coehoorn 17/03/2016

1
+1 Tốt hơn câu trả lời tôi đưa ra cho phiên bản trước của câu hỏi này. @Joel Không biết có giới hạn.
pipTheGeek

1
Tôi không hoàn toàn đồng ý với tất cả mọi thứ ở đây và dù sao đó cũng là một +1 dễ dàng cho phần trình bày và lập luận cực kỳ chu đáo.
Beska

2
Lập luận tốt, nhưng bỏ lỡ một điểm về bảo vệ sở hữu trí tuệ. Nếu ứng dụng của bạn có một số mã làm điều gì đó hơi phức tạp, obfuscation có thể cung cấp sự khác biệt giữa sao chép và dán mã phẳng, và cố gắng diễn giải và tái thiết kế mã để nó hoạt động. Điều này đặc biệt quan trọng với các bản cập nhật: nếu ai đó đã sao chép mã bị xáo trộn của bạn, khi bạn phát hành bản cập nhật, họ phải làm lại từ đầu - và ít nhất, điều đó khiến họ đau đớn / tốn kém / thời gian hơn. Nếu bạn không bảo vệ nó theo một cách nào đó, họ chỉ cần sao chép / dán lại và nó hoạt động.
gregmac

4
Bài đăng tuyệt vời - nó thực sự đi sâu vào tất cả các chi tiết đúng về lý do tại sao không đáng bận tâm để viết bảo vệ bản sao phức tạp. Mặc dù câu hỏi là một bản sao, nó đáng để mở lại nó chỉ cho câu trả lời này. Có lẽ một mod có thể hợp nhất nó?
EMP

45

Theo kinh nghiệm của tôi, làm cho ứng dụng hoặc thư viện của bạn khó bị bẻ khóa hơn làm tổn thương khách hàng trung thực của bạn trong khi chỉ trì hoãn một chút những người không trung thực. Tập trung vào việc tạo ra một sản phẩm ma sát thấp, tuyệt vời thay vì bỏ nhiều công sức vào việc trì hoãn điều không thể tránh khỏi.


38

Một bí mật mà bạn chia sẻ với nhiều người không phải là bí mật. Nếu bạn có những thứ bí mật trong mã của mình, việc che giấu nó không có tác dụng bảo vệ; nó chỉ phải khử mùi một lần . Nếu bạn có một bí mật mà bạn không muốn chia sẻ với khách hàng của mình, thì đừng chia sẻ nó với khách hàng của bạn . Viết mã của bạn dưới dạng dịch vụ web và giữ mã siêu bí mật của bạn trên máy chủ của riêng bạn, nơi chỉ bạn mới có thể nhìn thấy mã đó.


1
Btw tôi đang thực hiện một dự án trong đó tôi cũng muốn kích hoạt một sản phẩm "ngoại tuyến". (Tôi đã tạo một dịch vụ WCF để thực hiện kích hoạt trực tuyến). Trong trường hợp này bạn sẽ thao tác mã như thế nào? bạn có thể cho tôi một số hit?
Piyush

1
Ý tưởng thú vị, nhưng khóa học hành động nào bạn muốn giới thiệu cho ai đó đang phát triển một ứng dụng phải chạy mà không có kết nối dữ liệu, chẳng hạn như trò chơi WP7?
Charlie Skilbeck

23

Nói rộng ra, có ba nhóm người ngoài kia.

  • Những người sẽ không mua phần mềm của bạn và dùng đến các vết nứt, hoặc nếu họ không tìm thấy, không sử dụng phần mềm của bạn. Đừng mong kiếm được tiền từ nhóm này. Họ dựa vào các kỹ năng của bản thân hoặc vào các cracker (những người có xu hướng ưu tiên thời gian của họ tùy thuộc vào mức độ hữu ích của bạn và đối tượng của bạn lớn như thế nào. Càng hữu ích, càng sớm có một vết nứt).

  • Nhóm người dùng hợp pháp sẽ mua (trả tiền) phần mềm của bạn, bất kể bạn sử dụng cơ chế bảo vệ nào. Đừng làm khó người dùng hợp pháp của bạn bằng cách sử dụng một cơ chế bảo vệ phức tạp vì họ sẽ trả tiền cho nó trong mọi trường hợp. Một cơ chế bảo vệ phức tạp có thể dễ dàng làm hỏng trải nghiệm người dùng và bạn không muốn điều này xảy ra với nhóm này. Cá nhân, tôi sẽ bỏ phiếu chống lại bất kỳ giải pháp phần cứng nào, làm tăng thêm chi phí cho phần mềm của bạn.

  • Một nhóm thiểu số sẽ dùng đến biện pháp bẻ khóa "phi đạo đức" và sẽ chỉ trả tiền cho phần mềm của bạn các tính năng của phần mềm này được bảo vệ bởi cơ chế cấp phép. Bạn có thể không muốn làm cho nhóm này cực kỳ dễ dàng phá vỡ sự bảo vệ của bạn. Tuy nhiên, tất cả những nỗ lực bạn dành cho việc bảo vệ phần mềm của bạn sẽ được đền đáp, tùy thuộc vào nhóm người này lớn như thế nào. Điều này hoàn toàn phụ thuộc vào loại phần mềm bạn đang xây dựng.

Đưa ra những gì bạn đã nói, nếu bạn nghĩ rằng có một nhóm thiểu số đủ lớn có thể bị đẩy vào việc mua phần mềm của bạn, hãy tiếp tục và thực hiện một số hình thức bảo vệ. Hãy suy nghĩ về số tiền bạn có thể kiếm được từ nhóm thiểu số này so với thời gian bạn dành cho việc bảo vệ hoặc số tiền bạn chi cho API / công cụ bảo vệ của bên thứ ba.

Nếu bạn muốn thực hiện một giải pháp của riêng mình, sử dụng mật mã khóa công khai là một cách tốt (trái ngược với các thuật toán đối xứng) để ngăn chặn việc hack dễ dàng. Ví dụ, bạn có thể ký kỹ thuật số giấy phép của mình (số sê-ri hoặc tệp giấy phép). Cách duy nhất để giải quyết vấn đề này sau đó là dịch ngược, thay đổi và biên dịch lại mã (mà bạn có thể làm khó hơn bằng cách sử dụng các kỹ thuật như những gợi ý trong câu trả lời của Simucal).


Sử dụng mật mã mạnh để bảo vệ / xác minh giấy phép của bạn là hoàn toàn vô dụng nếu ai đó loại bỏ mã hủy bỏ ứng dụng nếu giấy phép không kiểm tra. :)
Bombe

Đồng ý, nhưng như tôi đã nói, sự bảo vệ không dành cho những nhóm người dùng sẽ sử dụng các vết nứt (một giả định mà tôi đưa ra sẽ tồn tại).
Huyền bí

mật mã khóa công khai = mật mã bất đối xứng. Tôi nghĩ bạn có nghĩa là đối xứng.
mmcdole

1
Công bằng mà nói, điểm thứ ba là sai lệch vì nó cho rằng một phần của mọi người luôn là thiểu số. Tôi khá chắc chắn trong một số khuôn khổ nhất định, đó là một đa số rõ ràng. Tôi có các trò chơi trực tuyến với nhiều người chơi tính năng ghi nhớ bởi vì a) hầu hết người dùng là trẻ em với tiêu chuẩn đạo đức rất thấp b) chi phí có thể là đáng kể cho những người dùng nếu đó là một khoản phí hàng tháng mà kéo trong nhiều tháng, vv
j RIV

19

Bạn không thể ngăn mọi người bẻ khóa phần mềm của bạn.

Tuy nhiên, bạn có thể khiến chúng tạo ra các vết nứt sẽ làm giảm doanh số của bạn. Keygenerators có thể cấp mã đăng ký hợp lệ cho phần mềm của bạn tệ hơn nhiều so với các bản vá đơn giản loại bỏ các ưu đãi đăng ký khỏi phần mềm của bạn. Đó là vì bản crack sẽ chỉ hoạt động cho một phiên bản phần mềm và sẽ ngừng hoạt động với bản cập nhật phần mềm tiếp theo mà bạn phát hành. Công cụ tạo khóa sẽ tiếp tục hoạt động cho đến khi bạn thay đổi thuật toán khóa đăng ký và đó là điều bạn không muốn làm thường xuyên vì nó sẽ loại bỏ các khách hàng trung thực của bạn.

Vì vậy, nếu bạn đang tìm kiếm một phương pháp để chống lại các trình tạo khóa bất hợp pháp cho phần mềm của mình và bạn không muốn sử dụng mã hóa giả định do mã đăng ký dài mà mã này tạo ra, bạn có thể xem Xác minh khóa một phần.

Xác minh khóa một phần đảm bảo rằng mỗi trình tạo khóa bất hợp pháp chỉ hoạt động cho một bản phát hành phần mềm cụ thể của bạn. Về cơ bản những gì bạn làm là đảm bảo rằng mỗi bản phát hành phần mềm của bạn chỉ liên kết với mã để kiểm tra MỘT SỐ chữ số của mã đăng ký. Các chữ số chính xác là ngẫu nhiên, vì vậy các cracker sẽ phải thiết kế ngược nhiều phiên bản phần mềm khác nhau của bạn và kết hợp tất cả những thứ này vào một bộ tạo phím để phát hành một bộ tạo phím hoạt động cho tất cả các phiên bản phần mềm của bạn.

Nếu bạn phát hành các phiên bản phần mềm mới một cách thường xuyên, điều này dẫn đến nhiều trình tạo khóa được phát tán trên tất cả các loại lưu trữ vi phạm bản quyền phần mềm không còn hoạt động nữa. Những tên cướp biển phần mềm tiềm năng thường tìm kiếm một bản crack hoặc keygen cho phiên bản mới nhất, vì vậy chúng có thể sẽ thử một vài trong số chúng và cuối cùng sẽ bỏ cuộc.

Tôi đã sử dụng Xác minh khóa một phần trong các trò chơi phần mềm chia sẻ mới hơn (C ++) của mình và nó rất hiệu quả. Trước khi chúng tôi gặp nhiều vấn đề với máy phát điện mà chúng tôi không thể chiến đấu. Sau đó, có rất nhiều vết nứt và một vài trình tạo phím chỉ hoạt động cho phiên bản cụ thể của trò chơi đó, nhưng không có trình tạo khóa nào có thể hoạt động với tất cả các phiên bản. Chúng tôi thường xuyên phát hành các bản cập nhật rất nhỏ của trò chơi và để làm cho tất cả các vết nứt hiện có trước đây trở nên vô dụng.

Dường như có một khung .NET mã nguồn mở cho Xác minh khóa một phần , mặc dù tôi chưa thử.


1
Giống như ý tưởng, bạn cũng có thể sử dụng các mật khẩu khác nhau để mã hóa giả định trong các bản phát hành khác nhau.
Priyank Bolia

Ý tưởng thú vị, nhưng chính xác thì vấn đề với mã đăng ký dài là gì? Ngày nay, không ai sẽ nhập nó bằng tay - mọi người sẽ sao chép và dán nó, vì vậy dù là 10 ký tự hay 100 ký tự thì cũng không nên tạo ra sự khác biệt nào.
EMP

4
@Evgeny: Điều đó chỉ đúng nếu người dùng của bạn là người dùng quyền lực. Chúng tôi đã tạo phần mềm chia sẻ / trò chơi thông thường trong nhiều năm và tôi có thể nói với bạn rằng hầu hết người dùng của chúng tôi không thể sao chép và dán. Cửa sổ đăng ký thậm chí còn đi kèm với một hướng dẫn về cách sao chép và dán, và một số thậm chí không có nó sau khi đọc nó.
Adrian Grigore

Ồ OK, tốt, bạn rõ ràng có nhiều kinh nghiệm hơn tôi trong việc này, vì vậy tôi không thể tranh luận, tôi chỉ có thể nói tôi ngạc nhiên. Nhưng tôi sẽ nói rằng nếu họ không biết cách sao chép và dán thì bạn nên tạo mã dài 200 ký tự, để họ học được một kỹ năng máy tính nói chung rất hữu ích. :)
EMP

1
@Evgeny: Ngay cả với các mã đăng ký ngắn, chúng tôi vẫn nhận được rất nhiều email từ những người đã nhập sai mã của họ và do đó nghĩ rằng mã không thể hợp lệ vì họ sẽ không bao giờ mắc lỗi như vậy nhiều lần trong một hàng. Tôi thích để lại việc giảng dạy CNTT cho các công ty khác ... :-)
Adrian Grigore

16
  • Sử dụng cập nhật trực tuyến để chặn những bản sao không được cấp phép.

  • Xác minh số sê-ri từ các mô-đun khác nhau của ứng dụng của bạn và không sử dụng một lệnh gọi chức năng duy nhất để thực hiện xác minh (để các cracker không thể bỏ qua xác minh một cách dễ dàng).

  • Không chỉ kiểm tra số sê-ri khi khởi động, thực hiện xác minh trong khi lưu dữ liệu, thực hiện vào mỗi tối thứ sáu, thực hiện khi người dùng không sử dụng ...

  • Xác minh tổng kiểm tra tệp ứng dụng, lưu trữ tổng kiểm tra bảo mật của bạn ở những nơi khác nhau.

  • Đừng đi quá xa về các loại thủ thuật này, hãy đảm bảo ứng dụng của bạn không bao giờ gặp sự cố / gặp trục trặc trong khi xác minh mã đăng ký.

  • Xây dựng một ứng dụng hữu ích cho người dùng quan trọng hơn nhiều so với việc tạo một
    nhị phân không thể phá vỡ cho các cracker.


14

Bạn có thể..

Tiềm năng phần mềm của Microsoft SLP InishTech cung cấp khả năng giúp bảo vệ mã mà không ảnh hưởng đến chức năng của các ứng dụng của bạn.

CẬP NHẬT: (Tiết lộ: Tôi làm việc trên Eazfuscator.NET) Điều làm cho Phần mềm Dịch vụ SLP của Microsoft có tiềm năng khác biệt là khả năng ảo hóa mã, vì vậy bạn chắc chắn có thể . Vài năm trôi qua kể từ khi câu hỏi ban đầu được hỏi; ngày nay có nhiều sản phẩm có sẵn cũng hoạt động trên cơ sở tương tự như:


2
định giá bạn tôi, mua một phần mềm cấp phép từ Microsoft là quá tốn kém cho ISV bình thường
Priyank Bolia

Tôi đã thử nó, nó hoạt động rất tốt nhưng nó chỉ mã hóa mã bên trong một phương thức chứ không phải toàn bộ lắp ráp hoặc dự án, do đó, một cracker có thể dễ dàng thay đổi dòng chương trình bằng cách tiêm IL
Mohsen Afshin

@ogggre Nếu thêm liên kết nhà cung cấp, bạn thực sự cần tiết lộ các kết nối của mình trong bài đăng. Ngoài ra phiên bản SLPS hiện có (mà tôi làm việc trên: D) không hỗ trợ thuốc generic. Đương nhiên tất cả các giải pháp đều có ưu và nhược điểm riêng mà chỉ một người đánh giá mới có thể bối cảnh đúng đắn cho mọi người
Ruben Bartelink

@MohsenAfshin Tôi không hiểu bạn đang nói gì - vấn đề là bạn cần bảo vệ bất kỳ phương pháp nào trong đó việc thêm / xóa / thay đổi IL sẽ vi phạm cấp phép. Bởi vì những thứ ảo hóa không thể miễn phí, đơn giản là nó không có ý nghĩa để 'bảo vệ một cách kỳ diệu tất cả' như bạn đang đề xuất. Quay lại điểm chính: Mục đích của Bảo vệ SP là ngăn chặn các thay đổi của IL đối với các phương pháp mà bạn chọn trên cơ sở chúng nhạy cảm (cộng với một số khác là tiếng ồn để tránh gây ra lỗi bạn cần bẻ khóa bit này tại đây -> ký )
Ruben Bartelink

1
@RubenBartelink Tôi đồng ý với bạn. Thật không may, chủ đề này là quá lớn với một số trang nội dung. Lúc đầu tôi muốn thêm một câu trả lời mới nhưng StackOverflow cho rằng tốt hơn là nên mở rộng câu trả lời hiện có. Tôi cũng vậy. Hy vọng phần thông tin nhỏ của tôi là hữu ích. Cảm ơn đã cập nhật về hỗ trợ chung trong SLPS và các chỉnh sửa của bạn.
ogggre

10

.NET Reflector chỉ có thể mở "mã được quản lý", về cơ bản có nghĩa là "mã .NET". Vì vậy, bạn không thể sử dụng nó để phân tách các tệp COM DLL, C ++ gốc, mã Visual Basic 6.0 cổ điển , v.v ... Cấu trúc của mã .NET được biên dịch làm cho nó rất thuận tiện, di động, có thể khám phá, có thể kiểm chứng, v.v. .NET Reflector tận dụng điều này cho phép bạn ngang hàng thành các tập hợp đã biên dịch nhưng trình dịch ngược và trình dịch ngược không có nghĩa là cụ thể đối với .NET và đã tồn tại chừng nào trình biên dịch đã xuất hiện.

Bạn có thể sử dụng obfuscators để làm cho mã khó đọc hơn, nhưng bạn không thể chính xác ngăn nó bị dịch ngược mà không làm cho .NET không thể đọc được. Có một số sản phẩm ngoài kia (thường đắt tiền) tuyên bố "liên kết" ứng dụng mã được quản lý của bạn với ứng dụng mã gốc, nhưng ngay cả khi những sản phẩm này thực sự hoạt động, một người quyết tâm sẽ luôn tìm cách.

Tuy nhiên, khi nói đến obfuscation, bạn sẽ nhận được những gì bạn phải trả cho. Vì vậy, nếu mã của bạn là độc quyền đến mức bạn phải đi một quãng đường dài như vậy để bảo vệ nó, bạn nên sẵn sàng đầu tư tiền vào một obfuscator tốt.

Tuy nhiên, trong 15 năm kinh nghiệm viết mã của tôi, tôi đã nhận ra rằng việc bảo vệ quá mức mã nguồn của bạn là một sự lãng phí thời gian và có rất ít lợi ích. Chỉ cần cố gắng đọc mã nguồn gốc mà không hỗ trợ tài liệu, bình luận, vv có thể rất khó hiểu. Thêm vào đó là các tên biến vô nghĩa mà trình dịch ngược xuất hiện và mã spaghetti mà các obfuscators hiện đại tạo ra - bạn có thể không phải lo lắng quá nhiều về việc mọi người đánh cắp tài sản trí tuệ của bạn.


9

nó thật sự đáng giá thế sao? Mọi cơ chế bảo vệ có thể bị phá vỡ với quyết tâm đầy đủ. Xem xét thị trường của bạn, giá của sản phẩm, lượng khách hàng, v.v.

Nếu bạn muốn một cái gì đó đáng tin cậy hơn thì hãy đi theo con đường của các phím cứng, nhưng điều đó khá rắc rối (đối với người dùng) và đắt tiền hơn. Các giải pháp phần mềm có thể sẽ lãng phí thời gian và tài nguyên, và điều duy nhất họ sẽ cung cấp cho bạn là ý thức sai về "bảo mật".

Ít ý tưởng hơn (không có ý tưởng nào là hoàn hảo, vì không có ý tưởng nào hoàn hảo).

  • Chống trùng lặp
  • Thay đổi ngôn ngữ, sử dụng các thủ thuật hay mà các tác giả của Skype đã sử dụng
  • Giấy phép máy chủ

Và đừng lãng phí quá nhiều thời gian cho nó, bởi vì các cracker có nhiều kinh nghiệm với các kỹ thuật điển hình và đi trước bạn vài bước. Trừ khi bạn muốn sử dụng nhiều tài nguyên, có thể thay đổi ngôn ngữ lập trình (thực hiện theo cách của Skype).


Đừng quên rằng hoàn toàn có thể tấn công phần mềm của khóa phần cứng.
Magnus Hoff

Đúng, đó là sự thật, lựa chọn thực sự duy nhất là ứng dụng được triển khai một phần trong phần cứng (ví dụ như một số phần mềm kỳ lạ - ứng dụng VHDL). Điều này cũng có thể bị bẻ khóa mặc dù ...
Ẩn danh

Điều gì về dongle thực hiện một chiến lược khóa công khai / riêng tư. Chỉ có khóa riêng của dongle mới có thể giải mã ứng dụng và chạy nó.
mmcdole

Đó là những gì khóa phần cứng thường làm. Nhưng bạn có thể tấn công dongle - sao chép nó hoặc phần mềm chịu trách nhiệm nói chuyện với dongle (phá vỡ, vô hiệu hóa, v.v.).
Ẩn danh

1
Trong trường hợp của tôi, nó thực sự đáng giá. Sau khi tôi triển khai Xác minh khóa một phần và thay đổi lược đồ khóa đăng ký cho một sản phẩm hiện có, doanh số tăng lên theo cách đáng kể. Tất cả các phần mềm có thể bị bẻ khóa, câu hỏi chỉ là bạn nâng thanh cao cho cướp biển phần mềm thông thường.
Adrian Grigore

9

Nếu bạn muốn mọi người có thể chạy mã của bạn (và nếu bạn không, thì tại sao bạn lại viết mã đó ngay từ đầu?), Thì CPU của họ cần có khả năng thực thi mã của bạn. Để có thể thực thi mã, CPU cần có khả năng hiểu nó.

Vì CPU bị câm và con người thì không, điều này có nghĩa là con người cũng có thể hiểu được mã.

Chỉ có một cách để đảm bảo rằng người dùng của bạn không nhận được mã của bạn: không cung cấp cho họ mã của bạn.

Điều này có thể đạt được theo hai cách: Phần mềm như một dịch vụ (SaaS), nghĩa là bạn chạy phần mềm của mình trên máy chủ và chỉ cho phép người dùng của bạn truy cập từ xa. Đây là mô hình mà Stack Overflow sử dụng, ví dụ. Tôi khá chắc chắn rằng Stack Overflow không làm xáo trộn mã của họ, nhưng bạn không thể dịch ngược nó.

Một cách khác là mô hình thiết bị: thay vì cung cấp cho người dùng mã của bạn, bạn cung cấp cho họ một máy tính chứa mã. Đây là model mà máy chơi game, hầu hết điện thoại di động và TiVo sử dụng. Lưu ý rằng điều này chỉ hoạt động nếu bạn "sở hữu" toàn bộ đường dẫn thực thi: bạn cần xây dựng CPU của riêng bạn, máy tính của riêng bạn, viết hệ điều hành của riêng bạn và thực hiện CLI của riêng bạn . Sau đó, và chỉ sau đó bạn có thể bảo vệ mã của bạn. (Nhưng lưu ý rằng ngay cả sai lầm nhỏ nhất cũng sẽ khiến tất cả các biện pháp bảo vệ của bạn trở nên vô dụng. Microsoft, Apple, Sony, ngành công nghiệp âm nhạc và ngành công nghiệp điện ảnh có thể chứng thực điều đó.)

Hoặc, bạn không thể làm gì, điều đó có nghĩa là mã của bạn sẽ được bảo vệ tự động bởi luật bản quyền.


8

Thật không may, bạn sẽ không chạy trốn khỏi điều này. Đặt cược tốt nhất của bạn là viết mã của bạn bằng C và P / Gọi nó.

Có một nhược điểm nhỏ, ai đó có thể dịch ngược ứng dụng của bạn sang CILhủy mọi mã xác minh / kích hoạt (ví dụ: cuộc gọi đến thư viện C của bạn). Hãy nhớ rằng các ứng dụng được viết bằng C cũng được thiết kế ngược bởi các tin tặc bền bỉ hơn (chỉ cần nhìn vào cách các trò chơi bị bẻ khóa nhanh chóng trong những ngày này). Không có gì sẽ bảo vệ ứng dụng của bạn.

Cuối cùng, nó hoạt động rất giống nhà của bạn, bảo vệ nó đủ tốt để nó tốn quá nhiều công sức (mã spaghetti sẽ giúp ích ở đây) và để kẻ tấn công chỉ di chuyển sang nhà hàng xóm bên cạnh của bạn (cạnh tranh :)). Nhìn vào Windows Vista, phải có 10 cách khác nhau để bẻ khóa nó.

Có những gói ngoài đó sẽ mã hóa tệp EXE của bạn và giải mã nó khi người dùng được phép sử dụng nó, nhưng một lần nữa, đó là sử dụng một giải pháp chung không nghi ngờ gì đã bị bẻ khóa.

Các cơ chế kích hoạt và đăng ký nhằm vào 'Joe trung bình:' những người không đủ hiểu biết về công nghệ để vượt qua nó (hoặc vì vấn đề đó biết rằng họ có thể bỏ qua nó). Đừng bận tâm với bánh quy, họ có quá nhiều thời gian trên tay.


1
Nếu bạn thực sự bận tâm đến việc thuê ngoài mã đăng ký của mình thành một dll, bạn nên đảm bảo rằng DLL phải khác với mọi phiên bản mới của phần mềm của bạn. Nếu không, làm cho mọi người dễ dàng hơn để bẻ khóa phần mềm của bạn. Tất cả những gì họ cần làm là bẻ khóa DLL của bạn một lần và sử dụng nó cho tất cả các phiên bản sau. Ngay cả người dùng cuối cũng có thể làm điều này một khi họ tìm thấy một DLL bị bẻ khóa cũ và điều này thậm chí còn tệ hơn cả việc đưa cơ chế đăng ký vào mã được quản lý của bạn.
Adrian Grigore

8

Ngoài việc mua bảo vệ, bạn (hoặc nhà phát triển của bạn) có thể học cách bảo vệ bản sao.

Đây là những ý tưởng:

Lúc đầu, hãy thử viết một chương trình tự viết lên bàn điều khiển. Đó là một vấn đề nổi tiếng. Mục đích chính của nhiệm vụ này là để thực hành viết mã tự tham chiếu.

Thứ hai, bạn cần phát triển một công nghệ sẽ viết lại một số mã theo cách phụ thuộc vào CIL của các phương thức khác .

Bạn có thể viết một máy ảo (chưa bằng .NET ). Và đặt một số mã trong đó. Cuối cùng, máy ảo chạy một máy ảo khác chạy mã. Đó là một phần của các chức năng hiếm khi được gọi là không làm chậm hiệu suất quá nhiều.

Viết lại một số logic vào C ++ / CLI và trộn mã được quản lý với không được quản lý. Điều này sẽ làm cứng việc tháo gỡ. Trong trường hợp này, đừng quên cung cấp nhị phân x64 .


không nhận được bạn có thể giải thích chi tiết.
Priyank Bolia

7

Đúng. Đúng rồi. Mã .NET cực kỳ dễ dàng để đảo ngược kỹ sư nếu mã không bị xáo trộn.

Obfuscation sẽ thêm một lớp phiền toái cho những người đang cố gắng thiết kế phần mềm của bạn. Tùy thuộc vào phiên bản bạn nhận được, bạn sẽ nhận được các cấp độ bảo vệ khác nhau.

Visual Studio bao gồm một phiên bản Dotfuscator . Vì là phiên bản đi kèm, bạn chắc chắn không nhận được sự xáo trộn mạnh nhất có thể. Nếu bạn xem danh sách tính năng của họ, bạn sẽ thấy chính xác những gì bạn đang thiếu (và chính xác những gì ứng dụng sẽ làm để làm cho mã của bạn an toàn hơn).

Có một vài trình giải mã .NET miễn phí hoặc mã nguồn mở khác ngoài đó (nhưng tôi không thể nhận xét về chất lượng hoặc các phương pháp khác nhau mà họ sử dụng):

Cuối cùng, không có gì là hoàn hảo. Nếu ai đó thực sự muốn xem phần mềm của bạn hoạt động như thế nào, họ sẽ làm.


11
Đó không chỉ là "nếu họ thực sự muốn xem phần mềm của bạn hoạt động như thế nào, thì họ sẽ làm". Nếu họ quan tâm, họ có thể đoán mà không cần nhìn. 99,9% + phần mềm không có bất kỳ thuật toán bụi pixie ma thuật nào. Phần khó của lập trình không phải là một kỹ thuật bí mật đặc biệt. Nó chỉ là nhận được tất cả các bộ phận để xếp hàng và làm việc.
Ken

9
@Ken - Suỵt! Bạn không thể để phần còn lại của thế giới biết rằng hầu hết thời gian chúng ta không sử dụng thuật toán bụi pixie ma thuật.
Justin Niessner

9
Justin: Liệu tình yêu có được tính là một thuật toán ma thuật? Tình yêu là những gì làm cho chương trình của tôi đặc biệt. Tôi không nghĩ bạn có thể tháo rời Tình yêu.
Ken

Babel.NET không còn miễn phí nữa. Bạn có thể tìm thấy một danh sách các obfuscators phổ biến nhất (miễn phí và thương mại) ở đây .
InputOutput

6

Chà, bạn không thể HOÀN TOÀN bảo vệ sản phẩm của mình khỏi bị bẻ khóa, nhưng bạn có thể tối đa hóa / nâng cao mức độ bảo mật và làm cho nó trở nên quá khó để bị bẻ khóa bởi người mới và người bẻ khóa trung gian.

Nhưng hãy nhớ rằng không có gì là không thể bẻ khóa, chỉ có phần mềm ở phía máy chủ được bảo vệ tốt và không thể bị bẻ khóa. Dù sao, để tăng cường mức độ bảo mật trong ứng dụng của bạn, bạn có thể thực hiện một số bước đơn giản để ngăn chặn một số cracker "không phải tất cả" phá vỡ các ứng dụng của bạn. Những bước này sẽ làm cho những chiếc bánh quy này trở nên điên cuồng và có thể tuyệt vọng:

  • Làm xáo trộn mã nguồn của bạn, rõ ràng điều này sẽ làm cho mã nguồn của bạn trông giống như một mớ hỗn độn và không thể đọc được.
  • Kích hoạt một số thói quen kiểm tra ngẫu nhiên trong ứng dụng của bạn như cứ sau hai giờ, 24 giờ, một ngày, tuần, v.v. hoặc có thể sau mỗi hành động người dùng thực hiện.
  • Lưu tổng kiểm tra MD5 của ứng dụng đã phát hành của bạn trên máy chủ của bạn và thực hiện một thói quen có thể kiểm tra tổng kiểm tra MD5 hiện tại với tập tin thực ở phía máy chủ của bạn và làm cho nó được kích hoạt ngẫu nhiên. Nếu tổng kiểm tra MD5 đã bị thay đổi, điều đó có nghĩa là bản sao này đã bị sao chép trái phép. Bây giờ bạn chỉ có thể chặn nó hoặc phát hành bản cập nhật để chặn nó, v.v.
  • Cố gắng tạo một thói quen có thể kiểm tra xem một số mã (chức năng, lớp hoặc thói quen cụ thể) của bạn có thực sự bị sửa đổi hoặc thay đổi hoặc thậm chí bị xóa hay không. Tôi gọi nó (kiểm tra tính toàn vẹn mã).
  • Sử dụng các trình đóng gói không xác định miễn phí để đóng gói ứng dụng của bạn. Hoặc, nếu bạn có tiền, hãy tìm giải pháp thương mại như Thamida hoặc .NET Reactor . Các ứng dụng đó được cập nhật thường xuyên và một khi cracker giải nén ứng dụng của bạn, bạn có thể nhận được bản cập nhật mới từ các công ty đó và khi bạn nhận được bản cập nhật mới, bạn chỉ cần đóng gói chương trình của mình và phát hành bản cập nhật mới.
  • Phát hành cập nhật thường xuyên và buộc khách hàng của bạn tải xuống bản cập nhật mới nhất.
  • Cuối cùng làm cho ứng dụng của bạn rất rẻ. Đừng làm cho nó quá đắt. Tin tôi đi, bạn sẽ có được nhiều khách hàng hài lòng hơn và những kẻ bẻ khóa sẽ rời khỏi ứng dụng của bạn, bởi vì nó không đáng để họ bẻ khóa một ứng dụng rất rẻ.

Đó chỉ là những phương pháp đơn giản để ngăn chặn người mới và những kẻ bẻ khóa trung gian phá vỡ ứng dụng của bạn. Nếu bạn có thêm ý tưởng để bảo vệ ứng dụng của mình, đừng ngại thực hiện chúng. Nó sẽ chỉ khiến những kẻ bẻ khóa sống khó khăn, và họ sẽ nản lòng, và cuối cùng họ sẽ rời khỏi ứng dụng của bạn, bởi vì nó không đáng để họ mất thời gian.

Cuối cùng, bạn cũng cần xem xét dành thời gian của mình để mã hóa một ứng dụng tốt và chất lượng. Đừng lãng phí thời gian của bạn vào việc mã hóa các lớp bảo mật phức tạp. Nếu một cracker giỏi muốn bẻ khóa ứng dụng của bạn, anh ấy / cô ấy sẽ làm bất kể bạn làm gì ...

Bây giờ đi và thực hiện một số đồ chơi cho các cracker ...


5

Salamander , một trình biên dịch và trình liên kết .NET gốc từ Remotesoft có thể triển khai các ứng dụng mà không cần .NET framework. Tôi không biết làm thế nào nó sống theo yêu cầu của nó.


Câu trả lời khá dễ dàng: Thật đáng tiếc, hầu hết các câu trả lời đều nói về obfuscation. Obfuscation là tốt để ngăn chặn lần đầu tiên (giống như Reflector) cố gắng tìm mã của bạn, đó là tất cả. Điều đó không tệ. Và tất nhiên, không có gì ngăn chặn các tin tặc thực sự hiểu mã lắp ráp, ngoài việc viết một ứng dụng SAAS (thậm chí sau đó chúng có thể cố gắng hack máy chủ của bạn). Nhưng có nhiều hơn, có những công cụ như Salamander, .NET Reactor được đề cập khác, người cung cấp (có thể) gần như cùng một hình thức bảo mật không biên dịch như Win32 .exe được biên dịch C ++. Những công cụ nào là tốt nhất, tôi chưa thể đánh giá.
Philm

5

Nếu Microsoft có thể đưa ra giải pháp, chúng tôi sẽ không có phiên bản Windows lậu, vì vậy không có gì là an toàn. Dưới đây là một số câu hỏi tương tự từ Stack Overflow và bạn có thể thực hiện theo cách riêng của mình để bảo vệ chúng. Nếu bạn đang phát hành các phiên bản khác nhau thì bạn có thể áp dụng các kỹ thuật khác nhau cho các phiên bản khác nhau, do đó, khi lần đầu tiên bị bẻ khóa, phiên bản thứ hai có thể tiếp quản.


5

Lò phản ứng .NET

Cập nhật

Jared chỉ ra rằng de4dot tuyên bố có thể dịch ngược nó.

.NET Reactor cung cấp sự bảo vệ hoàn toàn cho tài sản trí tuệ nhạy cảm của bạn bằng cách chuyển đổi các cụm .NET của bạn thành các quy trình không được quản lý mà không thể hiểu là CIL và không có công cụ hiện có nào có thể dịch ngược. Tin tặc không có quyền truy cập vào bất kỳ hình thức dễ hiểu nào về nguồn của bạn.

Mạnh mẽ và linh hoạt, các tính năng cấp phép .NET Reactor cho phép bạn thực thi các điều kiện cấp phép và bảo vệ dòng doanh thu của mình bằng cách sử dụng khóa phần cứng và phần mềm. Người quản lý giấy phép có thể xây dựng giấy phép thử nghiệm hoặc vĩnh viễn, chỉ trong vài giây. Một bộ công cụ phát triển phần mềm (SDK) được ghi chép đầy đủ, hoàn chỉnh với các ví dụ, cho phép bạn gọi hệ thống cấp phép trực tiếp từ mã của mình, cho phép bạn tạo các tiện ích mở rộng tùy chỉnh cho hệ thống cấp phép.


3
Tôi đã cố gắng liên lạc với những người đó với một số câu hỏi, tôi đã có về sản phẩm của họ, nhưng họ không bao giờ trả lời. Bạn đã thử sản phẩm của họ. Tôi đã đi với lắp ráp thông minh và cả sản phẩm và hỗ trợ của họ là rất tốt. Nhưng như tôi đã nói trong câu hỏi obfuscation là một cách, nhưng không đầy đủ bằng chứng.
Priyank Bolia

1
Tôi đã gặp một số vấn đề với sản phẩm của họ trước đó và sau đó tôi đã hỏi một số câu hỏi liên quan đến các biểu tượng có độ phân giải cao trong nhóm.google.se/group/net-reactor-users và tôi đã nhận được câu trả lời và cách khắc phục, nhưng bây giờ có vẻ như chúng khó giữ lấy. Thật tệ - đó là một sản phẩm tuyệt vời và tôi vẫn đang sử dụng nó
loraderon

2
Nếu "không có công cụ hiện có nào có thể dịch ngược", tại sao nó lại được liệt kê dưới dạng obfuscator / packer được hỗ trợ trên trang tính năng de4dot?: Bitbucket.org/0xd4d/de4dot
Jared Thirsk

Có lẽ bởi vì đó là một tuyên bố cũ và họ đã không cập nhật trang web của họ. Tôi không còn là người sử dụng bất kỳ công cụ obfuscation nào.
loraderon

de4dot là một công cụ rất mạnh. Tôi đã thử nó chống lại một số obfuscators và nó làm cho một công việc tuyệt vời. Tuy nhiên, nó không thể xử lý các tệp được bảo vệ .NET Reactor (v6.0). Có lẽ de4dot không cập nhật.
InputOutput

4

Đây là một ý tưởng: bạn có thể có một máy chủ được lưu trữ bởi công ty của bạn mà tất cả các phiên bản phần mềm của bạn cần kết nối. Đơn giản chỉ cần họ kết nối và xác minh khóa đăng ký là không đủ - họ sẽ xóa séc. Ngoài kiểm tra khóa, bạn cũng cần để máy chủ thực hiện một số nhiệm vụ quan trọng mà khách hàng không thể tự thực hiện, do đó không thể xóa. Điều này tất nhiên có thể có nghĩa là rất nhiều xử lý nặng trên một phần của máy chủ của bạn, nhưng nó sẽ làm cho phần mềm của bạn khó bị đánh cắp và giả sử bạn có một sơ đồ khóa tốt (kiểm tra quyền sở hữu, v.v.), các khóa cũng sẽ khó lấy trộm. Điều này có thể xâm lấn nhiều hơn bạn muốn, vì nó sẽ yêu cầu người dùng của bạn được kết nối với internet để sử dụng phần mềm của bạn.


5
Điều gì sẽ xảy ra nếu máy chủ không hoạt động hoặc người dùng không có quyền truy cập internet luôn, phương pháp của bạn sẽ khiến khách hàng thất vọng vì có quá nhiều chuyến đi khứ hồi đến các máy chủ internet chỉ để sử dụng một ứng dụng.
Priyank Bolia 17/03/2016

Tôi hoàn toàn đồng ý. Đó là lý do tại sao tôi nói "điều này có lẽ xâm lấn nhiều hơn bạn muốn ..." trong dòng cuối cùng của tôi. Tôi chỉ cung cấp cho OP giải pháp tốt nhất mà tôi nghĩ là khả thi về mặt kỹ thuật, không phải là cách tiếp cận tốt nhất để giữ cho khách hàng hài lòng :)
rmeador 17/03/2016

Trong quý đầu tiên của năm 2010 (vài tháng sau khi câu trả lời này được viết), công ty phát triển trò chơi Ubisoft đã thử điều này và dường như tải trên các thành phần phía máy chủ quá lớn đến nỗi các trò chơi không thể chơi được. Ấn tượng chung về SW: "rắc rối khi cài đặt, không thể sử dụng ngoại tuyến, xâm lấn và không đáng tin cậy ". Vì vậy, nếu bạn quyết định rằng xử lý phía máy chủ là cách tốt nhất, hãy chắc chắn rằng bạn thực sự có thể mở rộng theo yêu cầu.
Piskvor rời khỏi tòa nhà

3

Bất cứ điều gì chạy trên máy khách có thể được dịch ngược và bẻ khóa. Obfusification chỉ làm cho nó khó hơn. Tôi không biết ứng dụng của bạn, nhưng 99% thời gian tôi không nghĩ rằng nó đáng để nỗ lực.


3

Xin lỗi, không thể bảo mật hoàn toàn một ứng dụng.



2

Hãy nhớ rằng 99% + người dùng của bạn sẽ không quan tâm đến việc kiểm tra khả năng thực thi của bạn để xem cách thức hoạt động của nó.

Cho rằng rất ít người thậm chí sẽ bận tâm cố gắng và hầu hết các obfuscators có thể được làm việc xung quanh, nó có đáng để bạn dành thời gian và công sức không?

Bạn nên đầu tư thời gian vào việc cải thiện sản phẩm của mình để nhiều người muốn sử dụng nó hơn.


2

Chỉ cần thêm một cảnh báo: nếu bạn sẽ sử dụng obfuscation, hãy kiểm tra xem mọi thứ vẫn hoạt động! Obfuscation có thể thay đổi những thứ như tên lớp và tên phương thức. Vì vậy, nếu bạn sử dụng sự phản chiếu để gọi một số phương thức và / hoặc các lớp nhất định (như trong kiến ​​trúc plugin), ứng dụng của bạn có thể bị lỗi sau khi làm xáo trộn. Ngoài ra stacktraces có thể vô dụng để theo dõi lỗi.


2

Nếu nó được viết bằng .NET và được biên dịch thành CIL , nó có thể được phản ánh. Nếu bảo mật là một mối quan tâm và cần tránh sự che giấu, thì tôi khuyên bạn nên viết ứng dụng của mình bằng ngôn ngữ không được quản lý, về bản chất, khó hơn là kỹ sư đảo ngược.


2

Làm thế nào để đảm bảo rằng ứng dụng không bị giả mạo và làm thế nào để đảm bảo rằng cơ chế đăng ký không thể được thiết kế ngược.

Cả hai đều có cùng một câu trả lời rất đơn giản: không trao mã đối tượng cho các bên không tin cậy, chẳng hạn như (rõ ràng) khách hàng của bạn. Việc lưu trữ ứng dụng trên máy của bạn có khả thi hay không chỉ phụ thuộc vào những gì nó làm.

Nếu đó không phải là một ứng dụng web , có lẽ bạn có thể cho phép đăng nhập SSH bằng X chuyển tiếp đến một máy chủ ứng dụng (hoặc Remote Desktop Connection , tôi đoán vậy, cho Windows).

Nếu bạn cung cấp mã đối tượng cho những người tầm thường và họ nghĩ rằng chương trình của bạn có thể rất vui để bẻ khóa, nó sẽ bị bẻ khóa. Không có cách nào xung quanh nó.

Nếu bạn không tin tôi, hãy chỉ ra một ứng dụng cao cấp chưa bị bẻ khóa và vi phạm bản quyền.

Nếu bạn sử dụng các phím cứng, nó sẽ khiến việc sản xuất trở nên đắt đỏ hơn và người dùng của bạn sẽ ghét bạn vì điều đó. Đó là một con chó cái thực sự để bò xung quanh trên sàn cắm và rút 27 thứ USB khác nhau của bạn vì các nhà sản xuất phần mềm không tin tưởng bạn (tôi tưởng tượng).

Có những gói ngoài đó sẽ mã hóa EXE của bạn và giải mã nó khi người dùng được phép sử dụng nó

Tất nhiên, cách xung quanh là bẻ khóa bài kiểm tra "có thể sử dụng nó" để nó luôn trả về đúng.

Một mẹo khó chịu có thể là sử dụng các giá trị byte của các opcodes thực hiện kiểm tra ở một nơi khác trong chương trình theo cách bẩn sẽ khiến chương trình gặp sự cố với xác suất cao trừ khi giá trị vừa phải. Nó làm cho bạn liên kết với một kiến ​​trúc cụ thể, mặc dù :-(


không một điểm sự cố nào dễ gỡ lỗi và ghi đè mã trong .NET để bỏ qua kiểm tra đó. Ngoài ra, bạn sẽ thay đổi opcodes trong .NET như thế nào, bạn có thể giải thích về điều này không?
Priyank Bolia

Oh. Tôi đã có C thủ thuật trong tâm trí; giả sử, lấy địa chỉ của hàm xác thực, thêm 10 byte đầu tiên trong mảng char đó (bỏ con trỏ hàm); chọn bất kỳ hàm f và lưu trữ [địa chỉ của f trừ tổng trước đó] trong fptr. Luôn gọi f là * (fptr + tổng đó). Tính toán trước "số tiền đó"
Jonas Kölker

2

Chỉ cần làm cho một ứng dụng tốt và mã một hệ thống bảo vệ đơn giản. Không quan trọng bạn chọn cách bảo vệ nào, nó sẽ bị đảo ngược ... Vì vậy, đừng lãng phí quá nhiều thời gian / tiền bạc.


2

Khi nói đến .NET, nếu bạn phát hành ứng dụng Windows Forms (hoặc bất kỳ ứng dụng nào có ứng dụng khách có tệp Thực thi di động), thì nó có thể bị bẻ khóa.

Nếu bạn muốn gắn bó với .NET và muốn giảm thiểu cơ hội lấy mã nguồn của mình, thì bạn có thể muốn xem xét triển khai nó như một ứng dụng ASP.NET trên máy chủ web, thay vì biến nó thành ứng dụng Windows Forms.


2

Thành thật mà nói, đôi khi chúng ta cần làm xáo trộn mã (ví dụ: đăng ký các lớp giấy phép, v.v.). Trong trường hợp này, dự án của bạn không miễn phí. IMO, bạn nên trả tiền cho một obfucator tốt.

Dotfuscator ẩn mã của bạn và .NET Reflector hiển thị lỗi khi bạn cố dịch ngược mã.


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.