Nội dung được mã hóa trong các trò chơi

Tôi đã có ý tưởng sử dụng mã hóa để ngăn người dùng tìm ra nội dung trong chương trình của tôi bên ngoài chương trình. Giống như người dùng có thể thấy kết cấu không bao giờ được sử dụng trong trò chơi có nghĩa là một phần của một loại trứng Phục sinh trong khi đi qua dữ liệu trò chơi. Điều này có thể làm hỏng nó cho mọi người nếu được đăng trực tuyến.

Hãy tưởng tượng một căn phòng bí mật nơi người chơi phải bấm đúng số trên cửa an ninh trong trò chơi, nếu đúng sẽ tạo ra khóa giải mã chính xác và sau đó giải mã phần đó của cấp và mở cửa. Do đó, làm cho quả trứng Phục sinh không thể truy cập được ngay cả khi xem qua dữ liệu trò chơi do khóa không thực sự được lưu trữ, nó được tạo dựa trên đầu vào của người dùng.

Đây là một ví dụ khác về những gì tôi đã tưởng tượng. Tôi có một trò chơi giải đố với giả sử 20 cấp độ, mỗi cấp được mã hóa bằng một khóa khác nhau. Thay vì lưu trữ khóa giải mã với chương trình trực tiếp cho phép ai đó dịch ngược chương trình và tìm thấy nó, thay vào đó tôi tạo khóa mã hóa / giải mã dựa trên giải pháp của câu đố trước đó. Bằng cách này, người chơi sẽ phải thực sự tìm ra câu đố trước khi nhận được bất kỳ thông tin nào về cấp độ tiếp theo, ngay cả khi xem qua dữ liệu trò chơi.

Người chơi, nếu có kiến ​​thức, có thể vũ phu có thể "dễ dàng" cho rằng số lượng giải pháp câu đố có lẽ ít hơn số lượng khóa giải mã. Nó thực sự là một vấn đề phức tạp của câu đố và không quan trọng lắm ở đây. Mặc dù tôi đã đăng một câu trả lời về nó ở đây

Có chương trình / trò chơi ngày nay đã làm một cái gì đó như thế này? Lưu trữ nội dung được mã hóa trong trò chơi của họ? Và nếu không tại sao? Có rất nhiều quy tắc và quy định về nó, ở cấp độ cửa hàng hoặc quốc gia? Có ai nhìn thấy bất kỳ cạm bẫy rõ ràng mà tôi đang thiếu? Bỏ qua những thứ như trải nghiệm người dùng, ý tưởng này có vẻ hợp với tôi và khiến tôi tò mò tại sao tôi chưa từng thấy điều này trước đây.

Chỉnh sửa : Có thể không rõ chính xác những gì tôi đang nói, vì vậy đây là một ví dụ cụ thể hơn.

Giả sử tôi có một hàm có một chuỗi gồm 20 ký tự và tạo một khóa đối xứng mà tôi có thể sử dụng để mã hóa / giải mã một số nội dung trong trò chơi. Cách duy nhất người dùng có thể nhận được nội dung đó là biết 20 ký tự đó và tạo cùng một khóa. Khóa này không bao giờ được lưu trữ trực tiếp và được tạo nhanh chóng dựa trên đầu vào của người dùng. Những nhân vật này sẽ được ẩn trong trò chơi trong những gì có thể là sách, hộp thoại với NPC, thậm chí có thể bên ngoài trò chơi ở mặt sau của hộp.

Vì vậy, với 2 * 10 ^ 28 khả năng kết hợp để thử, có thể nhiều khả năng mọi người sẽ tìm thấy nội dung theo cách dự định thay vì xem qua dữ liệu trò chơi.

Chỉnh sửa 2 : Nội dung được đề cập sẽ được mã hóa bằng khóa tùy ý và bí mật trước khi được chuyển đến tay người tiêu dùng. Chìa khóa này rõ ràng sẽ không được vận chuyển cùng với trò chơi. Anh ta hoặc cô ta sẽ phải bằng cách nào đó đánh đố chìa khóa lại với nhau bằng một loạt manh mối được tạo ra dựa trên chìa khóa, và nó được ẩn trong suốt trò chơi hoặc ở một nơi khác. Tuy nhiên, hệ thống này sẽ minh bạch cho người dùng vì bạn sẽ không biết nội dung được mã hóa trừ khi bạn thực sự xem qua dữ liệu trò chơi.

Như nhiều người đã đề cập, điều này có một nhược điểm rõ ràng là trường hợp sử dụng của nó bị hạn chế. Một khi một người đã tìm ra nó, anh ấy / cô ấy có thể chia sẻ nó với mọi người khác, nếu không phải là chìa khóa / giải pháp thì chính nội dung đó. Tuy nhiên, nếu ý định của bạn là giữ một cái gì đó bí mật đến nỗi một người không thể giải quyết nó và mọi người phải làm việc cùng nhau để giải quyết nó, hoặc bạn sợ rằng trứng Phục sinh của bạn bị che giấu rất tốt (theo thiết kế) nhiều khả năng ai đó sẽ tìm thấy nó trong mã thay vì chơi trò chơi. Sau đó, tôi nghĩ rằng điều này có thể làm việc tuyệt vời.

Cá nhân tôi khuyên bạn chỉ nên sử dụng nó một lần cho mỗi trò chơi và chỉ cho những thứ không ảnh hưởng đến trò chơi cốt lõi, ví dụ như trứng Phục sinh, một kết thúc bí mật. Bất kỳ câu đố nào cũng phải quá phức tạp hoặc được giấu kỹ để nó làm mọi người chậm lại, đủ để mã hóa nội dung có giá trị và nếu câu đố này cản trở mọi người tiến bộ thì có lẽ không ai có thể vui vẻ.

Câu hỏi này là hỏi liệu có thể (không chỉ khả thi về mặt thương mại hoặc một số giải thích khác) để buộc ít nhất 1 người dùng giải câu đố thay vì hack để mở khóa một số nội dung trò chơi.

Theo hiểu biết của tôi điều này là chắc chắn có thể. Trên thực tế, thật kỳ lạ với tôi rằng các câu trả lời khác đang nói rằng nó hoàn toàn không thể, ngay cả khi nó đã được tuyên bố rất rõ ràng rằng khóa không được tạo ra cũng không được lưu trữ, chỉ đọc từ trạng thái trò chơi (có thể có googleplexes các giá trị). Lập luận rằng "trò chơi biết cách giải mã nó" vì vậy nó sẽ không hoạt động sau đó ngụ ý rằng bất kỳ phần mềm mã hóa / giải mã nguồn mở nào (ví dụ, TrueCrypt) vốn không an toàn vì bạn biết "cách" để giải mã các thùng chứa (chỉ cần nhập một chuỗi dựa trên đầu vào bàn phím, thật đơn giản phải không?).

Trong trường hợp đơn giản nhất, hãy tưởng tượng rằng trò chơi là một trình giả lập bàn phím và nó đặt câu hỏi "mật khẩu cho các tệp được mã hóa của tôi là gì?", Rõ ràng tất cả chúng ta đều đồng ý rằng việc có mã nguồn cho trò chơi sẽ không có ích. Bây giờ hãy tưởng tượng trò chơi đặt câu hỏi "tên của con vật lớn nhất trên Trái đất được ghép với tên của con vật nhỏ nhất là gì?". Có phải không rõ rằng ngay cả việc có mã nguồn của trò chơi cũng không giúp được gì, và bạn vẫn phải giải câu đố?

Đối với việc liệu điều này có khả thi hay không thì câu trả lời là CÓ, điều này là có thể.

Nó đã được thử. Rất rất nhiều lần. Có toàn bộ ngành công nghiệp phụ dành riêng cho việc cố gắng sử dụng mã hóa để ngăn người dùng truy cập chương trình khi họ thấy phù hợp. Và nó không bao giờ hoạt động. Các kế hoạch bảo vệ tốt nhất có xu hướng kéo dài khoảng một tháng trước khi chúng bị bẻ khóa, và điều về Internet là, một khi nó bị bẻ khóa một lần, nó sẽ bị nứt ở mọi nơi mãi mãi ngay khi ai đó đăng nó. Cạm bẫy rõ ràng mà bạn thiếu là để chương trình của bạn sử dụng dữ liệu, nó phải chứa tất cả thông tin cần thiết để giải mã nó và nếu máy tính có thể làm điều đó, một người có quyền truy cập vào máy tính có thể làm cái đó.

Nó được gọi là "vấn đề cơ bản của mật mã học": Alice muốn gửi tin nhắn cho Bob, mà Charlie không thể đọc được nó ngay cả khi anh ta hiểu được. Vấn đề với cách tiếp cận mà bạn đề xuất là Bob và Charlie là cùng một người trong trường hợp này.

Tôi có thể hiểu mong muốn không làm hỏng người dùng của bạn, nhưng nếu mọi người muốn những kẻ phá hoại họ sẽ tìm thấy họ, và nếu họ không, họ sẽ có xu hướng chủ động tránh những kẻ phá hoại. Nhưng nếu bạn muốn thực sự tạo ra một trò chơi tuyệt vời, hãy đi theo con đường ngược lại: sự cởi mở triệt để. Nhìn vào những thứ như Neverwinter Nights , Starcraft hay sê-ri Elder Scrolls , những trò chơi phổ biến trong nhiều năm và nhiều năm sau khi phát hành. Họ làm như vậy bởi vì họ vận chuyển các công cụ thiết kế mạnh mẽ với trò chơi cho phép người dùng tìm hiểu mọi thứ, tìm ra cách thức hoạt động cũng như xây dựng và chia sẻ nội dung của riêng họ. Một trò chơi chỉ là một trò chơi, cho đến khi nó trở thành một cộng đồng và cộng đồng chịu đựng.

Tôi đã ở đây đủ lâu để biết rằng nếu nội dung ở đó, sẽ có người tìm thấy nó. Làm cho nó khó hơn sẽ chỉ thu hút những người quyết tâm hơn. Sản phẩm của bạn càng phổ biến, nó càng trở nên thú vị. Một phần vì đó là một thách thức, một phần vì có rất nhiều nơi bạn có thể đạt được "tín dụng" bằng cách đăng loại thông tin này.

Nếu khóa được tạo bởi trò chơi cục bộ, bạn có thể tìm cách gian lận trong trò chơi cho đến khi điểm được tạo hoặc chỉ đơn giản là đào đúng đoạn mã. Nếu khóa được gửi cho bạn từ một máy chủ khi hoàn thành một số bước nhất định trong trò chơi, ai đó sẽ lừa máy chủ của bạn tin rằng họ đã nhận được đủ xa.

Cuối cùng, trò chơi của bạn sẽ được hưởng lợi nhiều hơn từ thời gian bạn làm cho nó trở nên thú vị và hấp dẫn, hơn là làm cho việc tìm ra màu cấp độ tiếp theo là gì.

Lý do chính tại sao điều này nên có trên gamedev.SE là việc thực hiện mã hóa này có hậu quả về lối chơi.

Bạn muốn giải pháp cho một câu đố là khóa mã hóa cho lần tiếp theo. Đó là, dữ liệu thực tế của giải pháp đó phải giải mã câu đố tiếp theo. Điều này có nghĩa là khóa giải mã không phải là một phần dữ liệu của trò chơi của bạn ở bất cứ đâu; nó được tạo bởi người chơi.

Và đây là hậu quả. Giải mã thường là nhị phân. Bạn có khóa giải mã chính xác cần thiết để giải mã dữ liệu hoặc không.

Hậu quả ở đây là bất cứ trò chơi nào bạn thiết kế phải tập trung hẹp đến mức chỉ có một giải pháp khả thi cho mọi cấp độ. Vì vậy, cơ chế giải đố của bạn phải được thiết kế rất cẩn thận để người chơi không thể giải câu đố theo cách khác với ý định của bạn.

Lấy Cổng thông tin, Phòng thử nghiệm 10 chẳng hạn. Bạn phải đi bên trái, làm một số thứ, sau đó rẽ phải và làm một số thứ, tất cả để hạ thấp một nền tảng.

Hoặc bạn có thể chỉ cho mình một số vận tốc và phóng mình lên bục khi bạn bước vào ngay.

GLaDOS: Vì vậy, bạn đã thực hiện một trò chơi câu đố. Một trò chơi giải đố trừng phạt những người thích trò chơi giải đố nhất. Làm tốt lắm. Nhưng ít nhất những tin tặc đó sẽ không nhận được dữ liệu quý giá của bạn. Bởi vì những người thích giải các trò chơi giải đố là những loại người chính xác tìm kiếm giải pháp cho các trò chơi giải đố trực tuyến.

Vì vậy, nó hoàn toàn xứng đáng.

Vì vậy, các trò chơi giải đố như Adventures of Lolo, SpaceCHEM và Portal (trong số hàng triệu người khác) đã được đưa ra. Thay vào đó, bạn phải thiết kế trò chơi của mình sao cho không thể tạo ra một câu đố có nhiều hơn một giải pháp. Điều đó đòi hỏi rất nhiều sự quan tâm và thường yêu cầu hạn chế đáng kể lối chơi.

GLaDOS: Vì vậy, bạn đã thực hiện một trò chơi câu đố. Một trò chơi dành cho những người thích tìm giải pháp sáng tạo cho các câu đố. Và bạn đã tạo ra một trò chơi không có giải pháp sáng tạo cho các câu đố. *vỗ tay chậm*

Tôi không nói rằng bạn không thể tạo ra một trò chơi như vậy. Hoặc đó là một trò chơi không thể tốt. Chỉ có một trò chơi như vậy sẽ phải được thiết kế theo một cách nhất định.

Oh, và bạn phải thiết kế gameplay này như vậy mà nó là không thể (hoặc rất khó khăn) để móc tìm một giải pháp.

GLaDOS: Vì vậy, bạn đã thực hiện một trò chơi câu đố. Một game giải đố thú vị hơn để hack hơn là chơi. Làm tốt lắm.

Tất nhiên, có một cảnh báo cho vấn đề này: ý nghĩa của "giải pháp". Hay hơn nữa, bạn tính đến yếu tố nào của một giải pháp?

Đối với bất kỳ trò chơi nào liên quan đến nhân vật đang di chuyển, có lẽ bạn sẽ không sử dụng các chuyển động chính xác của nhân vật để xây dựng khóa giải mã. Ví dụ: nếu bạn có một trò chơi giải đố trong đó người chơi cần nhặt một số vật phẩm nhất định để "giải" câu đố, bạn có thể tạo ra phím phụ thuộc vào thứ tự chạm vào những vật phẩm đó.

Tất nhiên, điều này gặp phải vấn đề ở trên, nơi người chơi tìm ra cách để làm những việc không theo trật tự. Điều đó một lần nữa có nghĩa là bạn phải thiết kế câu đố sao cho chỉ có một thứ tự bạn có thể nhặt được.

Hơn nữa, bất kỳ yếu tố nào bạn sử dụng để xây dựng khóa giải mã đều cần cung cấp đủ entropy để làm cho việc giải mã mạnh mẽ trở nên khó khăn. Sử dụng cơ chế đặt hàng ở trên, mỗi mục mới có hiệu quả thêm một bit. Nếu một mức chỉ có 8 mục, bạn đang thực hiện mã hóa 8 bit. Đó là tào lao; hầu hết điện thoại thông minh có thể xử lý điều đó trong vài giây.

Ngày nay, bạn cần ít nhất 128 để làm cho nó thậm chí hơi khó khăn. Điều đó có nghĩa là mỗi cấp độ cần phải có nhiều thứ trong đó, một lần nữa ảnh hưởng đến thiết kế trò chơi của bạn.

Các câu trả lời ở đây là tốt; Tôi sẽ nhìn nó từ một quan điểm khác mặc dù. Những gì bạn đang mô tả là một tính năng . Các tính năng có chi phí và lợi ích. Các chi phí bao gồm cả chi phí đô la để tạo ra tính năng và "chi phí cơ hội". Đó là: trong một thế giới nơi bạn có đô la hữu hạn và giờ hữu hạn và lập trình viên hữu hạn, mọi tính năng bạn làm có nghĩa là vô số tính năng có thể không được thực hiện ở vị trí của nó.

Vì vậy, câu hỏi là: bạn có thể nói chi phí của tính năng này theo nghĩa thực không? Không có tính năng miễn phí, vì vậy hãy thực tế về chi phí. Bạn có sẵn sàng trả một ngàn đô la cho tính năng này? Một trăm nghìn? Một triệu? Những tính năng nào bạn sẵn sàng cắt giảm để có tính năng này?

Tôi nghĩ rằng một khi bạn bắt đầu ưu tiên mọi thứ về chi phí, lợi ích và cơ hội bị bỏ lỡ, bạn sẽ nhận ra rằng bạn đã dành quá nhiều thời gian để suy nghĩ về tính năng này khi bạn có thể nghĩ về những cách để làm cho trò chơi thú vị hơn.

Vấn đề Alice Bob và Eve minh họa rõ điều này. Như Mason đã chỉ ra trong câu trả lời của anh ấy, bạn không thể giữ bí mật với Eve nếu Eve cũng là Bob.

Do đó, mọi giải pháp sẽ bao gồm Bob không có tất cả các thông tin cần thiết. Bạn sẽ phải coi mỗi cấp độ là một tin nhắn riêng lẻ, được mã hóa riêng biệt với nhau và có nguồn tin nhắn bên ngoài cho cấp độ tiếp theo có thể giữ cổng tin nhắn đúng cách.

Nhưng cuối cùng, điều đó trở thành tranh luận. Nếu ai đó có thể tự chơi trò chơi, thì cũng có thể viết một chương trình để ăn trò chơi. Vì vậy, tất cả những gì bạn đang làm là buộc họ phải qua lại từ nguồn bên ngoài của bạn (có thể là một máy chủ nào đó). Khi họ bẻ khóa cách tạo tin nhắn đến máy chủ của bạn, đó là câu chuyện cũ.

Nhưng bạn đang quên một yếu tố quan trọng ở đây. Đó là một trò chơi. Nếu ai đó gian lận trong một trò chơi, whoop lớn. Bạn đã không viết trò chơi cho những kẻ gian lận. Đó là điều tương tự với các hướng dẫn tìm kiếm hoặc hướng dẫn lên cấp: những người muốn thử thách tự mình tìm ra nó sẽ bỏ qua các giải pháp được đăng. Ngay cả khi bạn không thể bẻ khóa trò chơi mà không thể chơi nó (chúng tôi biết điều đó là không thể, nhưng NGAY LẬP TỨC NẾU bạn có thể) sẽ chỉ cần một anh chàng đi qua trước khi anh ta đăng mọi thứ cần thiết để đánh bại nó. Vì vậy, bạn chỉ trì hoãn là không thể tránh khỏi.

Dành thời gian của bạn để làm cho một trò chơi tuyệt vời. Có mười điều mọi nhu cầu trò chơi và cuối cùng tôi đã xem, mã hóa không phải là một trong số đó.

Tôi tin rằng ý tưởng của bạn là vô nghĩa.

Khi ai đó chơi trò chơi của bạn, họ chọn chơi nó, họ không làm điều đó để giành giải thưởng, họ đang làm điều đó để giải trí.

Người dùng biết rằng điều thú vị nhất đến từ cách chơi của bạn và sẽ không lừa dối , vì khách hàng của bạn họ đã tin tưởng bạn như một người kể chuyện.

Ngoài ra, ngay khi ai đó tìm thấy giải pháp cho câu đố, tức là chìa khóa của bạn, họ có thể chỉ cần đăng nó ở đâu đó trên internet.
Người chơi muốn gian lận vẫn có thể làm điều đó.

Tuy nhiên, nếu trò chơi của bạn đưa ra nhiều giải pháp, như cấp độ bí mật của Super Mario Land, mã hóa tài sản của bạn sẽ ngăn việc truy cập dễ dàng vào các giải pháp đó.

Mặc dù điều này có vẻ là một điểm có lợi cho ý tưởng của bạn, nhưng cuối cùng thì không.

Ngay cả với mã hóa, vẫn có thể biết rằng các giải pháp bí mật như vậy tồn tại.
Một khi đã biết rằng có một giải pháp bí mật tồn tại, việc ngăn người chơi nhìn vào tài sản bí mật sẽ không liên quan vì họ vẫn muốn truy cập vào các phần ẩn của trò chơi thông qua chính trò chơi (vâng, ngay cả khi họ đã nhìn thấy mọi ẩn kết cấu / clip / âm thanh / văn bản).

Bạn có thể ngăn chặn sự rò rỉ của sự tồn tại của các giải pháp bí mật bằng cách sử dụng một số kỹ thuật lãng quên ¹ , nhưng vẫn đáng nghi ngờ (tại sao làm điều đó nếu không có giải pháp bí mật?), Người chơi sẽ mất hứng thú tìm kiếm chúng và bạn sẽ có ít người chơi hơn , không hơn.
Sau tất cả, chúng ta có thể chơi thêm một vài giờ nữa sau khi hoàn thành một trò chơi để kích hoạt một số quả trứng Phục sinh nhưng chúng ta sẽ không chơi thêm một phút nữa nếu kích hoạt chúng sẽ đòi hỏi một nỗ lực phi thường!

Những gì bạn muốn làm giống như một cuốn sách viết trong đó chương tiếp theo được mã hóa bằng một từ của chương hiện tại, để ngăn người đọc làm hỏng bản thân kết thúc.
Hãy suy nghĩ về nó, nó không phải là vô nghĩa?

_{¹ Khá giống như VeraCrypt làm điều đó với khối lượng Ẩn.}

Tôi sẽ không bình luận về khả năng thương mại, tuy nhiên từ góc độ kỹ thuật thuần túy, đó là một thách thức thú vị.

Trước tiên tôi sẽ lưu ý rằng bất cứ điều gì không được mã hóa đều không thể được bảo vệ. Bạn không thể chuyển cổng vào một bí mật, những kẻ bẻ khóa sẽ tìm cách đi quanh cổng, thay vào đó bạn phải tự mình thực hiện toàn bộ bí mật. Về tài sản, điều này không có nghĩa là toàn bộ kết cấu, v.v ... chỉ cần mã hóa gói và được sử dụng và làm thế nào là đủ, và vì lý do hiệu suất, bạn sẽ muốn mã hóa càng ít dữ liệu càng tốt.

Thứ hai, bạn đúng rằng nếu khóa được chứa trong phần mềm thì nó sẽ bị trêu chọc từ phần mềm. Nhiều trò chơi, khi bảo vệ nội dung, cố gắng sử dụng bảo mật bằng cách che khuất hoặc cơ chế đảm bảo rằng phần mềm trò chơi không bị thay đổi. Đó chỉ là những chiến thuật trì hoãn.

Ý tưởng của bạn về việc sử dụng giải pháp của một bí ẩn là chìa khóa khá thú vị, tuy nhiên, sử dụng khóa được cung cấp trực tiếp có thể dễ dàng bị ép buộc. Thay vào đó, hãy coi đầu vào của người dùng là mật khẩu và sử dụng sơ đồ băm mật khẩu hiện đại: hàm băm được tạo ra là chìa khóa.

Tuy nhiên, ngay cả khi đó, có một sai lầm trong giả định của bạn rằng chìa khóa không có trong trò chơi. Nếu không, bạn không thể điều khiển người chơi của mình hướng tới nó; do đó, thay vì cố gắng cưỡng bức an toàn, thay vào đó, người ta có thể đảo ngược các tài sản trò chơi đang tìm kiếm manh mối. Một câu đố tiềm năng mà tôi có thể nghĩ đến là sử dụng họa tiết để mã hóa glyphs, và sau đó mật khẩu sẽ bao gồm một vài thứ có sẵn trên bàn phím, như được tiết lộ bởi các vị trí mà người chơi nên truy cập (theo thứ tự):

• mấu chốt của vấn đề là nhận dạng hình ảnh vẫn còn hơi khó đối với máy tính
• trên hết, chúng tôi đưa ra một thực tế là các cracker CAPTCHA được điều chỉnh cho các chữ cái và chữ số, chứ không phải glyphs tùy chỉnh
• trên hết, chúng tôi đưa ra một thực tế rằng bằng cách kết hợp nhiều kết cấu (với độ trong suốt) để tiết lộ glyph cho người chơi, không có tài sản duy nhất nào trong trò chơi chứa hình dạng của glyph
• sử dụng kết cấu khác (có các mảnh) ở khắp mọi nơi, nhưng không bao giờ theo cách tạo ra glyph đầy đủ ngoại trừ ở những nơi khuất, người chơi sẽ không bao giờ có thể tiếp cận

và bất kỳ chương trình nào để tự động trích xuất kết hợp glyph chiến thắng sẽ có một ngày khủng khiếp.

Thứ ba, khó khăn tiếp theo là chia sẻ. Khi các giải pháp cho một bí mật được tìm thấy, nó sẽ được tiết lộ. Lý tưởng nhất, mỗi cá nhân nên được trao một phiên bản phần mềm hơi khác nhau: một phiên bản trong đó khóa là duy nhất cho phiên bản trò chơi của họ. Để làm cho nó thực tế, tôi cho rằng việc tách trò chơi (với tài sản của nó) sẽ dễ dàng hơn khỏi "bí mật" (mã hóa) và "trình điều khiển bí mật" (trình tạo khóa, nơi đặt nhiều mảnh kết cấu ở nhiều nơi khác nhau , một số trong đó tạo thành mật khẩu).

Vectơ tấn công rõ ràng đang lừa người tạo luôn luôn chọn cùng một mật khẩu hoặc lừa người xác minh để luôn chấp nhận cùng một mật khẩu (ví dụ bằng cách tải xuống tệp bí mật của người khác).

Ở đây, một giải pháp tiềm năng sẽ là liên kết các tệp với tài khoản của người dùng và muối mật khẩu như thường được đề xuất:

• khi người dùng yêu cầu một tập hợp các tệp, hãy tạo ngẫu nhiên một muối và nhiều mật khẩu mà bạn có bí mật sau đó tạo các tài sản bí mật (ví dụ bạn có thể muốn giới hạn quá trình này một lần / ngày / người dùng, để tránh làm quá tải máy chủ của bạn)
• lưu trữ dấu thời gian của thế hệ và muối vào thông tin tài khoản của người dùng
• gửi lại dấu thời gian và các tệp bí mật được cá nhân hóa cho người dùng

Sau đó, khi người dùng đã sẵn sàng để gửi mật khẩu:

• có người dùng đăng nhập (nếu cô ấy chưa có)
• có phần mềm gửi cả dấu thời gian và mật khẩu glyph
• nếu dấu thời gian khác với dấu thời gian được lưu trữ, hãy thông báo cho người dùng rằng cô ấy đang sử dụng một tập tin bí mật lỗi thời
• nếu mật khẩu đã được thử quá nhiều lần, hãy thông báo cho người dùng rằng cô ấy đang sử dụng một tập tin bí mật lỗi thời
• mặt khác, băm muối + mật khẩu để tạo khóa
• nếu không, hãy gửi lại khóa cho người dùng để cô ấy có thể xem các tệp được cá nhân hóa của mình
• tăng số lần mật khẩu này được cố gắng bởi tài khoản này

Mục tiêu ở đây là cản trở việc chia sẻ tài khoản càng nhiều càng tốt:

• chia sẻ tài khoản để tạo các tệp bí mật bị (a) giới hạn, bởi vì chỉ có thể tạo một tài khoản mỗi ngày và (b) vô dụng, bởi vì việc tạo mới nhất làm cho cái kia trở nên lỗi thời
• chia sẻ tài khoản và phân phối các tệp bí mật liên quan là vô ích, bởi vì mật khẩu đã cho chỉ có thể được sử dụng N lần trước khi nó không mang lại khóa nữa.

Và chúng tôi đang ở gần đó.

Cuối cùng, ngay cả ở đó, một cracker có thể phát hành một phiên bản sửa đổi của trò chơi trong đó các tài sản bí mật được giải mã và tích hợp trực tiếp (bỏ qua sơ đồ xác minh cẩn thận của bạn).

Giải pháp rất đơn giản (và làm cho hầu hết mọi thứ trên ¹ lỗi thời ): không tin tưởng khách hàng.

Tạo bảng xếp hạng trên trang web của bạn và theo dõi tiến trình của người chơi trong tài khoản của họ. Người chơi có thể tuyên bố họ đã hoàn thành trò chơi tất cả những gì họ muốn, nhưng trừ khi tài khoản của họ phản ánh điều này, mọi người đều biết rằng họ đã gian lận ...

... đây được gọi là áp lực xã hội;)

¹ Ngoại trừ tệp định vị kết cấu, chúng tôi đã sử dụng để ngăn chương trình đoán khóa và giúp người dùng có thể lấy được tệp.

Đó là một ý tưởng thú vị; một biến thể trên các đĩa câu đố và các hệ thống bảo vệ bản sao nhập từ thủ công. Tôi nghĩ rằng một số trò chơi "ARG" hoạt động như thế này, trong đó có thể hiểu rằng người chơi đang hành động tập thể chống lại nhà thiết kế trò chơi.

Rõ ràng một khi người đầu tiên giải mã nó, họ sẽ xuất bản nó trên internet.

Nội dung thủ tục hoặc nội dung có thể hoạt động theo cùng một cách: bạn không nhìn thấy thế giới giống như một người chơi khác trừ khi bạn chia sẻ "hạt giống".

Tôi không thể thấy bất kỳ vấn đề pháp lý nào với nó, mặc dù Apple có thể từ chối nó từ cửa hàng Ứng dụng của họ và bạn có thể phải cung cấp giải pháp để được phê duyệt trên bảng điều khiển trò chơi.

Xem xét các biện pháp bảo mật bổ sung là giải trí, nhưng nó không thêm giá trị cụ thể cho sản phẩm của bạn - nó thể hiện sự nhanh nhẹn của bạn đối với các cracker gặp phải sản phẩm của bạn. Theo nguyên tắc, nhân vật phản diện của bạn sẽ bắt kịp bạn.

Trái ngược với các nhà phát triển phát triển mạnh về sáng tạo, crackers là những người phân tích - họ có thể khai thác trực giác chương trình của bạn. Khi các nhà phát triển có xu hướng áp dụng các biện pháp bảo mật quá mức, họ lại phủ nhận - rằng cracker có thể đảo ngược sơ đồ bảo vệ của họ, một lần nữa .

Cho dù bạn muốn tham gia vào cuộc thi nền tảng này, đó là cuộc gọi của bạn - nhưng đừng để nó làm sao lãng sản phẩm cuối cùng của bạn, điều này phải làm hài lòng khách hàng. Một sơ đồ mã hóa kỳ quặc biến trò chơi thành một con sên không giúp ích gì.

Mason Wheeler có quyền: bạn không thể làm điều đó. Ai đó luôn có thể đảo ngược kỹ sư trò chơi của bạn nếu họ muốn.

Dù sao bạn cũng không cần phải "bảo vệ" trò chơi của mình theo cách bạn mô tả. Ngay khi một người tìm thấy quả trứng Phục sinh, bí mật đã được đưa ra khỏi túi. Nếu mỗi bản sao của trò chơi có một quả trứng Phục sinh khác nhau, thì chỉ có bản sao của hacker mới được biết. Bạn có thực sự quan tâm rằng một hacker trong số 1000 người đã tìm thấy quả trứng Phục sinh mà không cần thông qua trò chơi?

Luật bản quyền là như vậy mà không ai có thể kiếm tiền từ trò chơi của bạn mà không phải chịu một vụ kiện nghiêm trọng, vì vậy bản quyền bảo vệ bạn.

Theo như người dùng ngẫu nhiên đưa họa tiết của bạn lên avatar diễn đàn của họ, vậy thì sao? Hãy xem nó là rễ cỏ quảng cáo.

Trở nên ám ảnh về việc "bảo vệ" những thứ sẽ khiến bạn mất tập trung vào những thực tế khó khăn như: làm game .

Khi tôi thấy những người không có sản phẩm nào nói về các kế hoạch bảo vệ IP của họ cho những thứ thậm chí không tồn tại, đó là một khoảnh khắc bỏ đi đối với tôi bởi vì nó giương cao một lá cờ đỏ nhảm nhí trên toàn bộ dự án.

Một số khả năng:

• Đồng bằng mã cũ obfuscation . Nó sẽ không làm cho mã không thể giải mã nhưng ít nhất nó sẽ khó.

• Giải pháp phía máy chủ. Bạn gửi một số lệnh đặc biệt đến máy chủ và máy chủ có thể gửi cho bạn mã ... hoặc thậm chí tải xuống một DLC.

• Bạn có thể sử dụng Steganography để ẩn mã thực thi trong nội dung khác.

Điều này sẽ không làm cho bí mật của bạn an toàn 100% nhưng dường như không ai sẽ mất tiền nếu bí mật được tiết lộ.

Nó cũng vô dụng như mọi lược đồ khác nơi bạn lưu trữ cả khóa và thuật toán trên máy khách. Nếu bạn hỏi "chìa khóa ở đâu, tôi dựa vào đầu vào của người dùng và không tự lưu trữ nó?", Hãy nhớ rằng câu đố của bạn có các quy tắc và tài nguyên theo định nghĩa của nó - nó được giải quyết bằng một số thuật toán, không phải bằng cách sử dụng. Thuật toán chính xác này và tài nguyên của nó là thuật toán tạo khóa mà bạn vừa mã hóa vào trò chơi ở trạng thái bị xáo trộn. Bất cứ ai cũng có thể lấy khóa "không tồn tại" của bạn bằng cách chỉ cần viết một chương trình nhỏ giải quyết câu đố của bạn theo quy tắc của bạn.