Konten terenkripsi dalam game

Saya telah memiliki gagasan untuk menggunakan enkripsi untuk mencegah pengguna mencari tahu konten dalam program saya di luar program itu sendiri. Seperti halnya pengguna dapat menemukan tekstur yang tidak pernah digunakan dalam game yang dimaksudkan untuk menjadi bagian dari semacam telur Paskah saat menelusuri data game. Ini misalnya dapat merusaknya untuk semua orang jika diposting secara online.

Bayangkan sebuah ruang rahasia di mana pemain harus menekan angka yang benar pada pintu keamanan dalam permainan, yang jika benar harus menghasilkan kunci dekripsi yang benar dan kemudian mendekripsi bagian tingkat dan membuka pintu. Dengan demikian membuat telur Paskah tidak dapat diakses bahkan ketika melihat melalui game-data karena kunci sebenarnya tidak disimpan, itu dihasilkan berdasarkan input pengguna.

Ini adalah contoh lain dari apa yang saya bayangkan. Saya memiliki permainan puzzle dengan katakanlah 20 level, masing-masing dienkripsi menggunakan kunci yang berbeda. Alih-alih menyimpan kunci dekripsi dengan program yang secara langsung memungkinkan seseorang untuk mendekompilasi program dan menemukannya, saya malah menghasilkan kunci enkripsi / dekripsi berdasarkan solusi dari teka-teki sebelumnya. Dengan cara ini pemain harus benar-benar mencari tahu teka-teki sebelum mendapatkan informasi tentang tingkat berikutnya, bahkan ketika melihat melalui data-game.

Pemain, jika berpengetahuan luas, bisa dengan kasar memaksa "dengan mudah" mengingat bahwa jumlah solusi puzzle mungkin kurang dari jumlah kunci dekripsi. Ini benar-benar masalah kompleksitas teka-teki dan tidak terlalu penting di sini. Meskipun saya memposting jawaban mengenai hal itu di sini

Apakah ada program / permainan hari ini yang telah melakukan hal seperti ini? Menyimpan konten terenkripsi di game mereka? Dan jika tidak mengapa? Apakah ada banyak peraturan tentang hal itu, baik di tingkat toko atau negara? Adakah yang melihat jebakan jelas yang saya lewatkan? Mengabaikan hal-hal seperti pengalaman pengguna, idenya sepertinya masuk akal dan membuat saya penasaran mengapa saya belum pernah melihat ini sebelumnya.

Sunting : Mungkin tidak jelas apa yang saya katakan, jadi di sini adalah contoh yang lebih konkret.

Katakanlah saya memiliki fungsi yang terdiri dari 20 karakter dan menghasilkan kunci simetris yang dapat saya gunakan untuk mengenkripsi / mendekripsi beberapa konten dalam game. Satu-satunya cara pengguna mencapai konten itu adalah dengan mengetahui 20 karakter tersebut dan menghasilkan kunci yang sama. Kunci ini tidak pernah disimpan secara langsung dan dihasilkan dengan cepat berdasarkan input pengguna. Karakter-karakter ini akan disembunyikan dalam game dalam apa yang bisa berupa buku, dialog dengan NPC, bahkan mungkin di luar permainan di bagian belakang kotak sekalipun.

Jadi dengan 2 * 10 ^ 28 kombinasi yang mungkin untuk dicoba mungkin akan lebih mungkin orang akan menemukan konten dengan cara yang dimaksud daripada dengan melihat melalui data-game.

Sunting 2 : Konten tersebut akan dienkripsi dengan kunci sewenang-wenang dan rahasia sebelum dikirim ke konsumen. Kunci ini jelas tidak akan dikirimkan bersama game. Dia harus entah bagaimana memecahkan kunci kembali bersama-sama diberikan serangkaian petunjuk yang dibuat berdasarkan kunci, dan yang tersembunyi sepanjang permainan atau di tempat lain. Namun sistem ini akan transparan bagi pengguna karena Anda tidak akan tahu kontennya dienkripsi kecuali Anda benar-benar melihat melalui data-game.

Seperti yang telah banyak disebutkan ini memiliki satu kelemahan yang jelas dalam hal penggunaannya terbatas. Setelah satu orang menemukan jawabannya, ia dapat membaginya dengan orang lain, jika bukan kunci / solusinya maka isinya sendiri. Namun jika niat Anda adalah menyimpan sesuatu yang sangat rahasia sehingga satu orang tidak akan bisa menyelesaikannya dan orang-orang harus bekerja sama untuk menyelesaikannya, atau Anda takut telur paskah Anda begitu tersembunyi (menurut desain) sehingga ia lebih mungkin seseorang akan menemukannya dalam kode daripada melalui permainan. Maka saya pikir ini bisa bekerja dengan baik.

Saya pribadi menyarankan untuk hanya menggunakannya mungkin sekali per pertandingan dan hanya untuk hal-hal yang tidak mempengaruhi permainan inti, misalnya telur paskah, akhir rahasia. Teka-teki apa pun harus sedemikian rumit atau tersembunyi dengan baik agar dapat memperlambat orang cukup untuk membuat mengenkripsi konten layak dan jika teka-teki ini menghalangi kemajuan orang maka tidak ada yang mungkin bersenang-senang.

Pertanyaan ini menanyakan apakah mungkin (tidak hanya layak secara komersial atau beberapa interpretasi lainnya) untuk memaksa setidaknya 1 pengguna untuk memecahkan teka-teki alih-alih meretas untuk membuka kunci konten game tertentu.

Setahu saya ini pasti mungkin. Sebenarnya, aneh bagi saya bahwa jawaban lain mengatakan itu sama sekali tidak mungkin, bahkan ketika telah dinyatakan secara eksplisit bahwa kuncinya tidak dihasilkan atau disimpan, hanya dibaca dari keadaan permainan (yang mungkin memiliki googlepleks dari kemungkinan nilai). Argumen bahwa "permainan tahu cara mendekripsi" sehingga tidak akan berfungsi kemudian akan menyiratkan bahwa setiap perangkat lunak enkripsi / dekripsi open source (misalnya, TrueCrypt) secara inheren tidak aman karena Anda tahu "bagaimana" mendekripsi wadah (cukup masukkan string berdasarkan input keyboard, sederhana bukan?).

Dalam kasus yang paling sederhana, bayangkan bahwa gim itu sendiri adalah simulator papan ketik dan ia menanyakan pertanyaan "apa kata sandi untuk file terenkripsi saya?", Jelas kita semua sepakat bahwa memiliki kode sumber untuk gim tidak akan membantu. Sekarang bayangkan permainan mengajukan pertanyaan "apa nama hewan terbesar di Bumi yang digabung dengan nama hewan terkecil?". Tidak jelas apakah memiliki kode sumber gim pun tidak akan membantu, dan Anda masih harus menyelesaikan puzzle?

Sehubungan dengan apakah ini mungkin, jawabannya adalah YA mutlak, ini mungkin.

Sudah dicoba. Banyak kali. Ada seluruh sub-industri yang didedikasikan untuk mencoba menggunakan enkripsi untuk mencegah pengguna mengakses suatu program sesuai keinginan mereka. Dan itu tidak pernah berhasil. Skema perlindungan terbaik cenderung bertahan sekitar sebulan sebelum mereka retak, dan hal tentang Internet adalah, sekali itu retak sekali, itu retak di mana-mana selamanya begitu seseorang mempostingnya. Jebakan yang jelas Anda lewatkan adalah agar program Anda dapat menggunakan data, ia harus berisi semua informasi yang diperlukan untuk mendekripsi, dan jika komputer dapat melakukan itu, orang yang memiliki akses ke komputer dapat melakukannya. bahwa.

Ini disebut "masalah mendasar kriptografi": Alice ingin mengirim pesan kepada Bob, tanpa Charlie dapat membacanya bahkan jika ia mengetahui hal itu. Masalah dengan pendekatan yang Anda usulkan adalah bahwa Bob dan Charlie adalah orang yang sama dalam kasus ini.

Saya dapat memahami keinginan untuk tidak merusak pengguna Anda, tetapi jika orang ingin spoiler mereka akan menemukan mereka, dan jika tidak, mereka akan cenderung aktif menghindari spoiler. Tetapi jika Anda ingin benar-benar membuat permainan yang hebat, ambil rute yang berlawanan: keterbukaan radikal. Lihatlah hal-hal seperti Neverwinter Nights , Starcraft , atau seri Elder Scrolls , game yang tetap populer selama bertahun-tahun setelah dirilis. Mereka melakukannya karena mereka mengirimkan alat desain yang kuat dengan permainan yang memungkinkan pengguna untuk menggali segala sesuatu, mencari tahu cara kerjanya, dan membangun dan berbagi konten mereka sendiri. Sebuah permainan hanyalah sebuah permainan, sampai ia menjadi sebuah komunitas , dan komunitas bertahan.

Saya sudah cukup lama mengetahui bahwa jika kontennya ada, seseorang akan menemukannya. Membuatnya lebih sulit hanya akan menarik lebih banyak orang yang bertekad. Semakin populer produk Anda, semakin menarik jadinya. Sebagian karena ini merupakan tantangan, sebagian karena ada begitu banyak tempat yang bisa Anda peroleh "kreditkan" dengan memposting informasi semacam ini.

Jika kunci dibuat secara lokal oleh permainan, Anda dapat menemukan cara untuk menipu melalui permainan sampai titik di mana kunci dihasilkan, atau cukup menggali potongan kode yang tepat. Jika kunci dikirimkan kepada Anda dari server untuk menyelesaikan langkah-langkah tertentu dalam permainan, seseorang akan menipu server Anda untuk meyakini bahwa mereka sudah cukup jauh.

Pada akhirnya, gim Anda akan mendapat banyak manfaat lebih banyak dari waktu yang Anda habiskan untuk membuatnya menyenangkan dan menarik, karena menyulitkan untuk mencari tahu apa warna level selanjutnya.

Alasan utama mengapa ini harus di gamedev.SE adalah bahwa melakukan enkripsi ini memiliki konsekuensi gameplay.

Anda ingin solusi untuk satu puzzle menjadi kunci enkripsi untuk puzzle berikutnya. Yaitu, data aktual dari solusi itu harus mendekripsi puzzle berikutnya. Ini berarti bahwa kunci dekripsi bukan bagian dari data gim Anda di mana pun; itu dihasilkan oleh pemain.

Dan inilah konsekuensinya. Dekripsi biasanya biner. Entah Anda memiliki kunci dekripsi tepat yang diperlukan untuk membatalkan enkripsi data, atau Anda tidak.

Konsekuensinya di sini adalah bahwa permainan apa pun yang Anda desain harus sangat terfokus sehingga hanya ada satu solusi yang mungkin untuk setiap level. Jadi mekanisme teka-teki Anda harus dirancang dengan sangat hati-hati sehingga pemain tidak dapat memecahkan teka-teki dengan cara yang berbeda dari niat Anda.

Ambil Portal, Test Chamber 10 misalnya. Anda seharusnya ke kiri, melakukan beberapa hal, lalu ke kanan dan melakukan beberapa hal, semua untuk menurunkan platform.

Atau Anda bisa memberikan diri Anda beberapa kecepatan dan melemparkan diri Anda ke platform ketika Anda masuk.

GLaDOS: Jadi Anda membuat game puzzle. Sebuah game puzzle yang menghukum orang-orang yang paling menikmati game puzzle. Kerja bagus. Tapi setidaknya para peretas itu tidak akan mendapatkan data berharga Anda. Karena orang-orang yang senang memecahkan permainan puzzle adalah jenis orang yang mencari solusi untuk permainan puzzle online.

Jadi itu sangat berharga.

Jadi, game puzzle seperti Adventures of Lolo, SpaceCHEM, dan Portal (di antara jutaan lainnya) sudah ada. Sebagai gantinya, Anda harus mendesain gim Anda sedemikian rupa sehingga tidak mungkin membuat puzzle yang memiliki lebih dari satu solusi. Itu membutuhkan perhatian yang sangat besar, dan biasanya membutuhkan gameplay yang sangat membatasi.

GLaDOS: Jadi Anda membuat game puzzle. Gim yang dimaksudkan untuk dimainkan oleh orang-orang yang suka menemukan solusi kreatif untuk teka-teki. Dan Anda membuat game yang tidak memiliki solusi kreatif untuk teka-teki. * bertepuk tangan lambat *

Saya tidak mengatakan bahwa Anda tidak dapat membuat game seperti itu. Atau bahwa permainan seperti itu tidak baik. Hanya saja game seperti itu harus dirancang dengan cara tertentu.

Oh, dan Anda harus merancang gameplay ini sedemikian rupa sehingga mustahil (atau sangat sulit) menemukan solusi secara mekanis .

GLaDOS: Jadi Anda membuat game puzzle. Gim puzzle yang lebih menarik untuk diretas daripada dimainkan. Kerja bagus.

Tentu saja, ada satu peringatan untuk ini: arti dari "solusi". Atau lebih tepatnya, elemen solusi apa yang Anda perhitungkan?

Untuk game apa pun yang melibatkan karakter bergerak, Anda mungkin tidak akan menggunakan gerakan tepat karakter untuk membuat kunci dekripsi. Misalnya, jika Anda memiliki permainan puzzle di mana pemain harus mengambil barang-barang tertentu untuk "memecahkan" teka-teki, Anda bisa membuat kunci bergantung pada urutan item-item itu disentuh.

Tentu saja, ini mengalami masalah di atas, di mana seorang pemain menemukan cara untuk melakukan hal-hal yang tidak beres. Yang lagi-lagi berarti Anda harus merancang teka-teki sedemikian rupa sehingga hanya ada satu urutan yang bisa Anda ambil.

Lebih jauh lagi, elemen apa pun yang Anda gunakan untuk membuat kunci dekripsi perlu menyediakan entropi yang cukup untuk membuat dekripsi kasar menjadi sulit. Menggunakan mekanik urutan pengumpulan di atas, setiap item baru secara efektif satu bit tambahan. Jika level hanya memiliki 8 item, Anda sedang melakukan enkripsi 8-bit. Yang omong kosong; sebagian besar ponsel cerdas dapat menanganinya dalam hitungan detik.

Saat ini, Anda membutuhkan setidaknya 128 untuk membuatnya bahkan sedikit menantang. Yang sekarang berarti bahwa setiap level perlu memiliki banyak hal di dalamnya, sekali lagi memengaruhi desain game Anda.

Jawabannya bagus; Saya akan melihatnya dari sudut pandang lain. Apa yang Anda gambarkan adalah fitur . Fitur memiliki biaya dan manfaat. Biaya termasuk biaya dolar untuk membuat fitur, dan "biaya peluang". Yaitu: di dunia di mana Anda memiliki dolar terbatas dan jam terbatas dan programmer terbatas, setiap fitur yang Anda lakukan berarti jumlah fitur yang tak terbatas yang mungkin tidak dilakukan di tempatnya.

Jadi pertanyaannya adalah: dapatkah Anda menyatakan biaya fitur ini secara nyata? Tidak ada fitur gratis, jadi bersikap realistis tentang biaya. Apakah Anda bersedia membayar seribu dolar untuk fitur ini? Seratus ribu? Satu juta? Fitur apa yang ingin Anda potong untuk memiliki fitur ini?

Saya pikir begitu Anda mulai memprioritaskan hal-hal dalam hal biaya, manfaat, dan peluang yang terlewatkan, Anda akan menyadari bahwa Anda telah menghabiskan terlalu banyak waktu untuk memikirkan fitur ini ketika Anda bisa memikirkan cara untuk membuat permainan lebih menyenangkan.

Masalah Alice Bob dan Hawa menggambarkan hal ini dengan baik. Seperti yang ditunjukkan Mason dalam jawabannya, Anda tidak bisa menyimpan rahasia dari Hawa jika Hawa juga Bob.

Dengan demikian, solusi apa pun adalah Bob tidak memiliki semua informasi yang diperlukan. Anda harus memperlakukan setiap tingkat sebagai pesan individual, dienkripsi secara terpisah dari satu sama lain, dan memiliki sumber eksternal pesan untuk tingkat berikutnya yang dapat menjaga gerbang pesan dengan benar.

Namun akhirnya, itu menjadi diperdebatkan. Jika seseorang dapat memainkan game sendiri, maka dapat juga menulis sebuah program untuk menelan game juga. Jadi semua yang Anda lakukan adalah memaksa mereka untuk bolak-balik dari sumber eksternal Anda (mungkin semacam server). Begitu mereka memecahkan cara membuat pesan ke server Anda, itu adalah cerita lama yang sama.

Tapi Anda lupa elemen kunci di sini. Ini permainan. Jika seseorang berselingkuh dalam sebuah permainan, teriakan besar Anda tidak menulis game untuk curang. Itu adalah hal yang sama dengan penelusuran langkah atau panduan leveling: orang-orang yang ingin tantangan mencari tahu sendiri akan mengabaikan solusi yang diposting. Bahkan jika Anda bisa membuat permainan retak menjadi mustahil tanpa memainkannya (kami tahu itu tidak mungkin secara logis, tetapi BAHKAN JIKA Anda bisa) itu hanya akan membutuhkan satu orang berjalan sebelum dia memposting semua yang diperlukan untuk mengalahkannya. Jadi Anda hanya menunda hal yang tak terhindarkan.

Habiskan waktu Anda membuat game yang luar biasa. Ada Sepuluh Hal yang Dibutuhkan Setiap Gim dan terakhir saya melihat, enkripsi bukan salah satunya.

Saya percaya ide Anda tidak ada gunanya.

Ketika seseorang memainkan permainan Anda, mereka memilih untuk memainkannya, mereka tidak melakukannya untuk memenangkan penghargaan, mereka melakukannya untuk bersenang-senang.

Pengguna tahu bahwa hal yang paling menyenangkan berasal dari bermain dengan cara yang Anda maksudkan dan tidak akan menipu , karena pelanggan Anda, mereka sudah mempercayai Anda sebagai pendongeng.

Juga segera setelah seseorang menemukan solusi untuk sebuah teka-teki, yaitu kunci Anda, mereka dapat mempostingnya di suatu tempat di internet.
Pemain yang ingin menipu masih bisa melakukannya.

Namun, jika game Anda menghadirkan beberapa solusi, seperti level rahasia Super Mario Land, mengenkripsi aset Anda akan mencegah akses yang mudah ke solusi itu.

Meskipun ini tampaknya merupakan titik yang mendukung ide Anda, pada akhirnya tidak.

Bahkan dengan enkripsi masih mungkin untuk mengetahui bahwa ada solusi rahasia.
Setelah diketahui bahwa ada solusi rahasia, mencegah para pemain dari melihat aset rahasia tidak akan relevan karena mereka masih ingin mengakses bagian-bagian tersembunyi dari permainan melalui permainan itu sendiri (ya, bahkan jika mereka telah melihat setiap tersembunyi tekstur / klip / audio / teks).

Anda dapat mencegah bocornya keberadaan solusi rahasia dengan menggunakan beberapa teknik ^{1 yang} tidak disadari , tetapi itu masih mencurigakan (mengapa melakukan itu jika tidak ada solusi rahasia?), Para pemain akan kehilangan minat untuk menemukan mereka dan Anda akan memiliki lebih sedikit pemain , tidak lebih.
Lagipula kita bisa bermain beberapa jam lagi setelah menyelesaikan permainan untuk memicu beberapa telur Paskah tetapi kita tidak akan bermain satu menit lagi jika memicu mereka akan membutuhkan upaya besar!

Apa yang ingin Anda lakukan adalah seperti buku tulis di mana bab berikutnya dienkripsi dengan kata dari bab saat ini, untuk mencegah pembaca merusak sendiri bagian akhirnya.
Pikirkan tentang itu, bukankah tidak ada gunanya?

_{¹ Cukup banyak seperti VeraCrypt melakukannya dengan volume tersembunyi.}

Saya tidak akan mengomentari kelayakan komersial, namun dari sudut pandang teknis murni itu adalah tantangan yang lucu.

Saya pertama-tama akan mencatat bahwa apa pun yang tidak dienkripsi tidak dapat dilindungi. Anda tidak dapat membuat pintu masuk menjadi rahasia, cracker akan menemukan jalan di sekitar gerbang, sebaliknya Anda harus membuat seluruh rahasia itu menjadi gerbang itu sendiri. Dalam hal aset, ini tidak harus berarti seluruh tekstur, dll ... hanya mengenkripsi rencana dan yang digunakan serta bagaimana mencukupi, dan untuk alasan kinerja Anda ingin mengenkripsi data sesedikit mungkin.

Kedua, Anda benar bahwa jika kunci tersebut terkandung dalam perangkat lunak maka itu akan diejek dari perangkat lunak. Banyak game, saat melindungi konten, mencoba menggunakan keamanan dengan ketidakjelasan atau mekanisme yang memastikan bahwa perangkat lunak game belum diubah. Itu hanya taktik menunda.

Gagasan Anda untuk menggunakan solusi enigma sebagai kuncinya agak menarik, namun, menggunakan kunci yang disediakan secara langsung cenderung mudah dipaksakan. Sebagai gantinya, perlakukan input pengguna sebagai kata sandi dan gunakan skema hashing kata sandi yang canggih: hash yang dihasilkan adalah kuncinya.

Namun, bahkan kemudian, ada kesalahan dalam asumsi Anda bahwa kuncinya tidak ada dalam permainan. Jika tidak, Anda tidak bisa mengarahkan pemain Anda ke sana; karena itu, alih-alih mencoba memaksa brankas, seseorang malah bisa merekayasa balik aset gim untuk mencari petunjuk. Salah satu teka-teki potensial yang dapat saya pikirkan adalah menggunakan tekstur untuk menyandikan mesin terbang, dan kata sandi akan terdiri dari beberapa yang tersedia pada keyboard, seperti diungkapkan oleh lokasi yang seharusnya dikunjungi pemain (dalam urutan):

• inti masalahnya adalah bahwa pengenalan gambar masih agak sulit untuk komputer
• di atas yang kita laporkan fakta bahwa cracker CAPTCHA disetel untuk huruf dan angka, bukan mesin terbang kustom
• di atas itu kita melapisi fakta bahwa dengan menggabungkan beberapa tekstur (dengan transparansi) untuk mengungkapkan mesin terbang kepada pemain, tidak ada aset tunggal dalam permainan yang berisi seperti apa mesin itu seharusnya terlihat
• menggunakan tekstur lain (dengan fragmen) di semua tempat, tetapi tidak pernah dengan cara yang menghasilkan mesin terbang penuh kecuali di tempat tersembunyi pemain tidak akan pernah bisa mencapai

dan program apa pun untuk secara otomatis mengekstrak kombinasi mesin terbang yang menang akan sangat menyebalkan.

Ketiga, kesulitan berikutnya adalah berbagi. Setelah itu solusi untuk rahasia yang ditemukan, maka akan terungkap. Idealnya, setiap individu harus menyerahkan versi perangkat lunak yang sedikit berbeda: satu di mana kuncinya adalah unik untuk versi gim mereka. Untuk membuatnya praktis, saya menduga akan lebih mudah untuk memisahkan permainan (dengan asetnya) dari "rahasia" (terenkripsi) dan "driver rahasia" (generator utama, yang menempatkan banyak fragmen tekstur di banyak tempat berbeda) , beberapa di antaranya membentuk kata sandi).

Vektor serangan yang jelas adalah menipu generator untuk selalu memilih kata sandi yang sama atau menipu pemeriksa untuk selalu menerima kata sandi yang sama (misalnya dengan mengunduh file rahasia orang lain).

Di sini, solusi potensial adalah dengan menautkan file ke akun pengguna, dan untuk menambahkan garam seperti yang biasanya disarankan:

• ketika pengguna meminta satu set file, secara acak menghasilkan garam dan kata sandi sebanyak yang Anda punya rahasia kemudian membuat aset rahasia (Anda mungkin ingin membatasi proses ini menjadi satu kali / hari / pengguna misalnya, untuk menghindari kelebihan server Anda)
• menyimpan stempel waktu generasi dan garam ke dalam informasi akun pengguna
• mengirim kembali stempel waktu dan file rahasia yang dipersonalisasi kepada pengguna

Kemudian, ketika pengguna siap untuk mengirimkan kata sandi:

• minta pengguna untuk login (jika dia belum)
• minta perangkat lunak mengirim stempel waktu dan kata sandi mesin terbang
• jika stempel waktu berbeda dari yang disimpan, beri tahu pengguna bahwa ia menggunakan sekumpulan file rahasia yang sudah usang
• jika kata sandi sudah terlalu sering dicoba, beri tahu pengguna bahwa ia menggunakan sekumpulan file rahasia yang sudah usang
• jika tidak, tambahkan garam + kata sandi untuk menghasilkan kunci
• jika tidak, kirim kunci kembali ke pengguna sehingga dia dapat melihat file yang dipersonalisasi
• tingkatkan berapa kali kata sandi ini dicoba oleh akun ini

Tujuannya di sini adalah untuk menghambat pembagian akun sebanyak mungkin:

• berbagi akun untuk menghasilkan file rahasia adalah (a) terbatas, karena hanya satu yang dapat dihasilkan per hari dan (b) tidak berguna, karena yang terbaru dihasilkan membuat yang lain usang
• berbagi akun dan mendistribusikan file rahasia yang terkait tidak berguna, karena kata sandi yang diberikan hanya dapat digunakan N kali sebelum tidak menghasilkan kunci lagi

Dan kita hampir sampai.

Akhirnya, bahkan di sana, seorang cracker dapat merilis versi modifikasi dari gim di mana aset rahasia didekripsi dan diintegrasikan secara langsung (melewati skema verifikasi Anda yang cermat).

Solusinya sederhana (dan membuat hampir semuanya di atas usang ¹ ): jangan percaya klien.

Buat papan peringkat di situs web Anda, dan pantau perkembangan pemain di akun mereka. Pemain dapat mengklaim bahwa mereka telah menyelesaikan permainan yang mereka inginkan, tetapi kecuali akun mereka mencerminkan hal ini, semua orang tahu mereka telah menipu ...

... ini disebut tekanan sosial;)

¹ Kecuali file pemosisian tekstur, yang kami gunakan untuk mencegah program menebak kunci, namun memungkinkan pengguna untuk mendapatkannya.

Itu ide yang menarik; varian pada cakram teka-teki dan masukkan-kata-dari-sistem perlindungan salinan manual. Saya pikir beberapa game "ARG" bekerja seperti ini, di mana agak dipahami bahwa para pemain bertindak secara kolektif melawan perancang game.

Jelas sekali orang pertama mendekripsi, mereka akan mempublikasikannya di internet.

Konten generatif atau prosedural dapat bekerja dengan cara yang sama: Anda tidak melihat dunia yang sama dengan pemain lain kecuali Anda berbagi "seed".

Saya tidak dapat melihat masalah hukum dengan itu, meskipun Apple dapat menolaknya dari App store mereka dan Anda mungkin harus memberikan solusi agar disetujui di konsol game.

Merenungkan langkah-langkah keamanan ekstra itu menghibur, tetapi itu tidak menambah nilai nyata pada produk Anda - itu menunjukkan betapa bagusnya Anda terhadap kerupuk yang menjumpai produk Anda. Secara prinsip, antagonis Anda akan menyusul Anda.

Berlawanan dengan pengembang yang berkembang dalam kreativitas, cracker adalah orang yang analitik - mereka secara intuitif dapat mengeksploitasi program Anda. Ketika pengembang cenderung melakukan tindakan keamanan yang berlebihan, mereka menyangkal - bahwa cracker dapat membalikkan skema perlindungan mereka, lagi .

Apakah Anda ingin berpartisipasi dalam kompetisi latar belakang ini, itu adalah panggilan Anda - tetapi jangan biarkan itu mengalihkan perhatian dari produk akhir Anda, yang harus menyenangkan pelanggan. Skema enkripsi unik yang mengubah game menjadi siput tidak membantu.

Mason Wheeler benar: Anda tidak bisa melakukannya. Seseorang selalu bisa membalikkan permainan Anda jika mereka mau.

Anda tidak perlu "melindungi" gim Anda dengan cara yang Anda uraikan. Segera setelah satu orang menemukan telur Paskah rahasia keluar dari tas. Jika setiap salinan gim memiliki telur Paskah yang berbeda, maka hanya salinan peretas yang akan diketahui. Apakah Anda benar-benar peduli bahwa satu peretas dari 1000 orang menemukan telur Paskah tanpa melalui gameplay?

Undang-undang hak cipta sedemikian rupa sehingga tidak seorang pun dapat menghasilkan uang dari permainan Anda tanpa mengambil risiko gugatan serius, sehingga hak cipta melindungi Anda.

Sejauh pengguna acak menempatkan tekstur Anda di avatar forum mereka, lalu bagaimana? Anggap saja iklan akar rumput.

Menjadi obsesif tentang hal-hal "melindungi" hanya akan mengalihkan Anda dari kenyataan sulit seperti: membuat game .

Ketika saya melihat orang-orang yang tidak memiliki produk berbicara tentang skema perlindungan IP mereka untuk hal-hal yang bahkan tidak ada, ini adalah momen yang menyenangkan bagi saya karena hal itu menimbulkan bendera merah besar yang mengamuk di seluruh proyek.

Beberapa kemungkinan:

• Kebingungan kode lama polos . Itu tidak akan membuat kode mustahil untuk diuraikan, tetapi setidaknya akan sulit.

• Solusi sisi server. Anda mengirim beberapa perintah khusus ke server dan server dapat mengirimi Anda kode ... atau bahkan mengunduh DLC.

• Anda dapat menggunakan Steganografi untuk menyembunyikan kode yang dapat dieksekusi di konten lain.

Ini tidak akan membuat rahasia Anda 100% aman tetapi tampaknya tidak ada yang akan kehilangan uang jika rahasia itu terungkap.

Tidak ada gunanya sama seperti skema lain di mana Anda menyimpan kunci dan algoritma pada klien. Jika Anda bertanya "di mana kuncinya, saya bergantung pada input pengguna dan tidak menyimpannya sendiri?", Ingat bahwa puzzle Anda memiliki aturan dan sumber daya dengan definisi - itu diselesaikan dengan beberapa algoritma, bukan dengan bruteforcing. Algoritma yang tepat ini dan sumber dayanya ADALAH algoritma pembuatan kunci yang baru saja Anda masukkan ke dalam game dalam keadaan tidak jelas. Siapa pun dapat mengambil kunci "tidak ada" Anda hanya dengan menulis program kecil yang memecahkan teka-teki Anda sesuai dengan aturan Anda.