Làm cách nào để bảo vệ trò chơi của tôi với khóa CD / số sê-ri?


25

Vì vậy, tôi đã quyết định tôi muốn giữ các bản sao lậu trò chơi XNA của mình không truy cập vào các máy chủ trò chơi chính thức (đã được kiểm duyệt, vì vậy những người đã trả tiền cho trò chơi sẽ có được trải nghiệm tốt nhất) bằng cách ngắt kết nối máy khách với CD sai hoặc bị sao chép hoặc bị cấm các phím (hoặc số sê-ri, vì trò chơi là kỹ thuật số và không có đĩa CD nào).

Làm cách nào để đưa hệ thống bảo vệ số sê-ri đó vào trò chơi của tôi (cả máy khách và máy chủ xác thực chính), vì vậy nó không dễ bị hack?


Lưu ý rằng tôi không có kinh nghiệm trong việc bảo vệ tốt loại đó cho phần mềm.

Tôi chưa bao giờ làm điều này trước đây, nhưng tôi hiểu những điều cơ bản. Tôi thấy lý do tại sao tôi không thể thực hiện kiểm tra khóa trên máy khách, vì vậy tôi sử dụng xác thực đăng nhập / vượt qua với mục nhập khóa một lần là tốt.

Hiện tại, mục tiêu của sự bảo vệ này là để giữ những kẻ gian lận tiềm năng và đột ngột hành xử người chơi ra khỏi máy chủ chính thức. Bất cứ ai cũng có thể chơi trên các máy chủ riêng có hoặc không có khóa, nhưng khả năng họ có thể có được trải nghiệm không mong muốn với những người chơi khác là lớn hơn. Tôi đoán nó đủ dễ để mua người chơi, vì họ phải trực tuyến để chơi trên các máy chủ chính thức.

Vì việc hack máy khách quá dễ dàng, tôi sẽ chỉ bảo vệ các thủ tục đăng ký ban đầu (và có thể là xác thực phía máy chủ), vì vậy không ai có thể đánh cắp các khóa trong khi chúng được chuyển.


Xem thêm:

Làm thế nào nhiều trò chơi nên xử lý xác thực?


Nếu ai đó đánh giá thấp, tôi mong đợi ít nhất là một nhận xét về những gì sai với câu hỏi. Các bạn, thực sự, tôi muốn câu hỏi của tôi tốt và giúp được nhiều người hơn là chỉ tôi.
dùng1306322

4
Tôi đoán đó là một phản ứng tự động để thêm DRM. Loại này không đặc biệt xấu, nhưng nhiều người trong chúng ta có trải nghiệm xấu với nó - chẳng hạn như khi Spore đóng gói cài đặt Windows của tôi.
Izkata

Thay vì khóa CD, bạn đã xem xét cách tiếp cận giống MMO / Minecraft giống như yêu cầu tên người dùng / mật khẩu để đăng nhập và sử dụng điều đó để xác thực người dùng?
Tetrad

4
Muốn DRM trên ứng dụng .NET!? Điều này cuối cùng sẽ thất bại với các công cụ như Reflector. Hãy nhìn vào Terraria. Sự phát triển đã dừng lại do vi phạm bản quyền (và rất nhiều doanh thu ...). Tôi thích ý tưởng dựa trên xác thực của @ Tetrad vì nó ngăn mọi người khỏi phải vá chức năng xác thực. Giữ tất cả dữ liệu trên máy chủ của bạn và khi đăng nhập thành công, hãy cung cấp cho họ dữ liệu của họ. Nếu bạn giữ dữ liệu cục bộ, thì họ chỉ có thể vá chức năng xác thực.

2
@Anko đó là một tham chiếu đến câu nói nổi tiếng "Chúng tôi yêu cầu nhiều khoáng sản hơn" . Và tôi có nghĩa là sự thật và chuyên môn. Thậm chí có thể chi tiết. Tôi không biết khi nào một vấn đề quan trọng đã có đủ sự chú ý, tôi cảm thấy như có gì đó để thêm và khách truy cập trang web có thể thấy chủ đề này thú vị (và có thể trở thành người dùng mới), vì vậy tôi đã nêu ra tiền thưởng.
dùng1306322

Câu trả lời:


24

Về cơ bản, bạn có ba yêu cầu:

  1. không nên dễ dàng sử dụng cùng một khóa cho nhiều trường hợp khách hàng,
  2. không dễ để tạo khóa hợp lệ mới và
  3. không nên dễ dàng đánh cắp chìa khóa của một khách hàng hợp pháp.

Phần đầu tiên khá đơn giản: chỉ cần đừng để hai người chơi đăng nhập vào cùng một máy chủ cùng một khóa. Bạn cũng có thể yêu cầu máy chủ trao đổi thông tin về người dùng đã đăng nhập hoặc liên hệ với máy chủ xác thực chia sẻ, do đó, ngay cả việc sử dụng cùng một khóa cho những người chơi khác nhau trên các máy chủ khác nhau cùng một lúc sẽ thất bại. Bạn cũng có thể muốn tìm kiếm các mẫu đáng ngờ về việc sử dụng khóa và, nếu bạn xác định rằng một khóa đã bị rò rỉ, hãy thêm nó vào danh sách các khóa bị cấm.


Đối với phần thứ hai, một cách đơn giản là duy trì cơ sở dữ liệu của tất cả các khóa được cấp hợp lệ. Miễn là các khóa đủ dài (giả sử, 128 bit trở lên) và được chọn ngẫu nhiên (sử dụng RNG an toàn), tỷ lệ của bất kỳ ai quản lý để đoán khóa hợp lệ về cơ bản là bằng không. (Ngay cả các khóa ngắn hơn nhiều cũng có thể an toàn nếu bạn sử dụng một số loại giới hạn tỷ lệ đối với các lần thử đăng nhập thất bại để ngăn các nỗ lực tìm khóa hợp lệ bằng vũ lực.)

Ngoài ra, bạn có thể tạo khóa bằng cách lấy bất kỳ mã định danh duy nhất nào và thêm mã xác thực tin nhắn (chẳng hạn như HMAC ), được tính bằng khóa chính bí mật. Một lần nữa, miễn là MAC đủ dài, tỷ lệ của bất kỳ ai không biết khóa chính có thể đoán MAC hợp lệ cho bất kỳ ID nào là không đáng kể. Một lợi thế của phương pháp này, bên cạnh việc loại bỏ nhu cầu về cơ sở dữ liệu khóa, là mã định danh có thể là bất kỳ chuỗi duy nhất nào và có thể mã hóa thông tin về máy khách mà khóa được cấp.

Một vấn đề khi sử dụng MAC là các máy chủ trò chơi chính thức (hoặc ít nhất là máy chủ xác thực) cần biết khóa chính để xác minh MAC, điều đó có nghĩa là, nếu máy chủ bị hack, khóa chính có thể bị rò rỉ. Một cách để giảm thiểu rủi ro này có thể là tính toán một số MAC cho mỗi ID, sử dụng các khóa chính khác nhau, nhưng chỉ lưu trữ một trong các khóa chính trên các máy chủ trò chơi. Bằng cách đó, nếu khóa chính đó bị rò rỉ và được sử dụng để tạo ID giả, bạn có thể thu hồi nó và chuyển sang khóa chính khác. Ngoài ra, bạn có thể thay thế MAC bằng chữ ký điện tử , có thể được xác minh chỉ bằng một nửa công khai của khóa chính.


Đối với phần thứ ba, một cách tiếp cận là đảm bảo rằng khách hàng sẽ không gửi khóa cho bất kỳ ai mà không cần xác minh rằng người nhận thực sự là một máy chủ chính thức hợp pháp. Ví dụ: bạn có thể sử dụng SSL / TLS (hoặc DTLS ) cho quá trình đăng nhập, cấp chứng chỉ tùy chỉnh cho máy chủ trò chơi của bạn và chỉ có chứng chỉ tin cậy máy khách do bạn cấp. Thuận tiện, sử dụng TLS cũng sẽ bảo vệ các khóa máy khách (và bất kỳ dữ liệu xác thực nào khác) khỏi những kẻ nghe trộm, ví dụ như trên các mạng WLAN công cộng.

Thật không may, cách tiếp cận này sẽ không cho phép các máy chủ của bên thứ ba xác minh khóa máy khách ngay cả khi họ muốn. Bạn có thể giải quyết vấn đề này bằng cách thiết lập máy chủ xác thực chính thức mà máy chủ trò chơi của bên thứ ba có thể sử dụng, ví dụ: bằng cách đăng nhập máy khách vào máy chủ xác thực và nhận mã thông báo một lần ngẫu nhiên mà họ có thể sử dụng để đăng nhập vào máy chủ trò chơi (sau đó gửi mã thông báo đến máy chủ xác thực để xác minh).

Ngoài ra, bạn có thể cấp chứng chỉ ứng dụng khách thực tế hoặc một cái gì đó giống như chúng cho khách hàng của bạn. Bạn có thể sử dụng một giao thức hiện có (như TLS) hỗ trợ xác thực chứng chỉ ứng dụng khách (được khuyến nghị) hoặc thực hiện giao thức của riêng bạn, ví dụ như thế này:

  • Chứng chỉ ứng dụng khách bao gồm một chuỗi ID tùy ý, cặp khóa chung / riêng và chữ ký số của ID và khóa chung sử dụng khóa chính.
  • Để đăng nhập, khách hàng gửi ID, khóa công khai và chữ ký của họ. Máy chủ trả lời bằng một chuỗi thử thách duy nhất (tốt nhất là bao gồm ID máy chủ và dấu thời gian mà khách hàng cần xác minh), mà khách hàng ký với khóa riêng (để chứng minh rằng họ biết khóa) và gửi chữ ký đến máy chủ.
  • Máy chủ kiểm tra cả hai chữ ký, chứng minh rằng ID + khóa chung tạo thành khóa khách hợp pháp (vì chúng được ký với khóa chính) và khóa máy khách thực sự thuộc về máy khách (vì máy khách có thể ký thách thức của máy chủ với riêng tư Chìa khóa).

(Giao thức này có thể được đơn giản hóa hơn nữa bằng cách ứng dụng khách tạo ra "thử thách", bao gồm ID máy chủ và dấu thời gian và ký tên. Tất nhiên, sau đó máy chủ cần xác minh rằng ID và dấu thời gian là hợp lệ. giao thức đơn giản này tự nó sẽ không ngăn kẻ tấn công trung gian có thể chiếm quyền điều khiển phiên của khách hàng, mặc dù điều đó sẽ ngăn họ lấy khóa riêng của khách hàng để đăng nhập trong tương lai.)


2
Một điểm nhỏ - trong khi một khóa hoàn toàn ngẫu nhiên cung cấp không gian khóa tối đa (và hoàn toàn khả thi nếu bạn xác thực dựa trên cơ sở dữ liệu của các khóa được cấp) thì nó không thân thiện với người dùng. Đặt một số xác nhận vào chính khóa để hầu hết các lỗi được bắt trước khi bạn cố gắng truy cập máy chủ.
Loren Pechtel

Tôi nghĩ, @LorenPechtel có một điểm mạnh về tính thân thiện với người dùng của khóa, và người dùng trả tiền vô tình gõ và gửi một khóa 'đánh máy sai / đánh vần sai' (máy đánh máy) cho máy chủ luôn luôn có thể.
Vishnu

@Vishnu Tôi biết là người dùng nhập khóa, tôi rất muốn có một số thông tin kiểm tra cho mỗi nhóm ngay cả khi điều đó có nghĩa là gõ phím dài hơn.
Loren Pechtel

16

Không có sự an toàn 100%, nhưng bạn có thể bắt đầu với một cách tiếp cận khá đơn giản:

  • Bạn sẽ cần một số cách để xác minh các khóa được tạo, ví dụ như bao gồm tổng kiểm tra. Tất nhiên, điều này không phải là quá dễ dàng để tìm ra.

  • Tùy chọn (nhưng được khuyến nghị) sẽ có cơ sở dữ liệu phía máy chủ xác minh các khóa bằng cơ sở dữ liệu của tất cả các khóa đã cho để bạn không thể tạo khóa, ngay cả khi bạn có thuật toán (hãy bỏ qua việc đánh dấu nó).

Từ đó trở đi, bạn có thể có hai cách tiếp cận khác nhau, nhưng theo một cách nào đó thì điều gì đó rất quan trọng:

  • Không xác minh khóa ở phía khách hàng. Điều này rất quan trọng, vì thực sự khá dễ dàng để dịch ngược những thứ được viết bằng .net / XNA. Nếu bạn phải yêu cầu khóa hoặc chuyển nó (đăng nhập hoặc đăng ký), hãy băm khóa (có thêm muối, v.v.) và gửi nó đến máy chủ.

Đối với các đường dẫn thực tế:

  • Yêu cầu khóa băm (xem bên trên) được gửi trong quá trình xác thực / đăng nhập.

  • Là một giải pháp thay thế (IMO là một giải pháp tốt hơn, mặc dù nhiều người không thích loại "DRM" này): Không sử dụng khóa trong máy khách. Thay vào đó, yêu cầu người dùng đăng nhập vào tài khoản và yêu cầu khóa CD hợp lệ (điều này yêu cầu cơ sở dữ liệu được đề cập ở trên) để tạo tài khoản. Đây là cách các trò chơi hiện đại, ví dụ như bất kỳ MMORPG trả tiền để chơi nào xử lý việc này.

Cá nhân, tôi đi theo cách tiếp cận tài khoản vì một lý do đơn giản: Cuối cùng, bạn không thể ngăn mọi người ăn cắp khóa CD (bruteforcing, đảo ngược kỹ thuật hoặc lừa đảo). Vì vậy, mọi người chỉ có thể tạo một khóa mới để tiếp tục chơi hoặc khóa những người khác khỏi trò chơi. Với các khóa bị ràng buộc tài khoản, không ai có thể làm bất cứ điều gì với một khóa đã được sử dụng. Trong trường hợp ai đó đã mua khóa do người khác tạo, bạn vẫn có thể chuyển quyền sở hữu tài khoản với giả định có đủ bằng chứng về điều này.


2
Thay vì tổng kiểm tra tiêu chuẩn, bạn nên sử dụng thuật toán băm bảo mật bằng mật mã. Bạn có thể giữ khóa riêng trên máy chủ và cung cấp cho khách hàng khóa chung và sau đó bạn biết rằng không cần truy cập vào máy chủ, hệ thống được bảo mật.
Adam

@Adam: Sử dụng thuật toán băm bảo mật bằng mật mã sẽ đảm bảo kẻ tấn công không thể tạo khóa hợp lệ, nhưng vấn đề không thể giải quyết được bằng cơ quan có thẩm quyền bàn giao các khóa hợp pháp. Mặc dù tổng kiểm tra đơn giản không an toàn lắm, các chức năng một chiều không khả thi trong bối cảnh này.
Marcks Thomas

Chà, bạn có thể kết hợp cả hai, ví dụ làm cho phần đầu tiên của khóa thành sự kết hợp ngẫu nhiên của các ký tự và nửa sau của hàm băm. Bất cứ ai bán trò chơi cũng không thể sử dụng keygen (trừ khi có một số cách để đảm bảo không có xung đột / xung đột xảy ra, như "id nhà cung cấp" là một phần của khóa).
Mario

1

Phần mềm Pangea - người tạo ra một số trò chơi Mac - đã viết một chủ đề về bảo vệ bản sao trong cuốn sách phát triển trò chơi (hiện miễn phí) của họ. Cuốn sách cũng giải thích làm thế nào để đối phó với các khóa lậu và các bản hack khác mà mọi người sử dụng. Cuốn sách tập trung vào phát triển các trò chơi Mac, nhưng các ý tưởng vẫn có thể hữu ích cho các nền tảng khác. Đi kèm với cuốn sách là mã nguồn cho mỗi chương, một phần của phần tải xuống bên dưới. Ngoài ra còn có mã nguồn (viết bằng C) liên quan đến bảo vệ bản sao.

Cuốn sách có thể được tải về ở đây .


Tôi không thể tìm thấy bất cứ điều gì hữu ích trong những cuốn sách đó.
dùng1306322

Cá nhân tôi mặc dù chương 16 có một số lời khuyên hay, nhưng YMMV.
Wolfgang Schreurs
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.