Bagaimana cara melindungi game saya dengan kunci CD / nomor seri?

Jadi saya telah memutuskan saya ingin menjaga salinan bajakan game XNA saya dari mengakses server game resmi (yang dimoderasi, sehingga orang-orang yang membayar untuk game akan mendapatkan pengalaman terbaik) dengan memutuskan klien dengan CD yang salah atau dihasilkan, duplikat atau banned. kunci (atau nomor seri, karena permainan ini digital dan tidak ada CD sama sekali).

Bagaimana cara memasukkan sistem perlindungan nomor seri ke permainan saya (baik klien dan server otentikasi utama), sehingga tidak mudah diretas?

Perhatikan bahwa saya tidak memiliki pengalaman membuat perlindungan yang baik untuk perangkat lunak.

Saya belum pernah melakukan ini sebelumnya, tetapi saya mengerti dasar-dasarnya. Saya mengerti mengapa saya tidak bisa melakukan pemeriksaan kunci pada klien, jadi saya boleh saja menggunakan otentikasi login / pass dengan entri kunci satu kali.

Saat ini, tujuan dari perlindungan ini adalah untuk menjaga potensi curang dan mengganggu pemain dari server resmi. Siapa pun dapat bermain di server pribadi dengan atau tanpa kunci, tetapi kemungkinan mereka mendapatkan pengalaman yang tidak diinginkan dengan pemain lain lebih besar. Saya kira itu cukup mudah untuk membeli pemain, karena mereka harus online untuk bermain di server resmi.

Karena meretas klien terlalu mudah, saya hanya akan melindungi prosedur pendaftaran awal (dan mungkin otentikasi sisi-server), sehingga tidak ada yang dapat mencuri kunci saat sedang ditransfer.

Lihat juga:

Bagaimana seharusnya permainan multipemain menangani otentikasi?

Pada dasarnya, Anda memiliki tiga persyaratan:

1. seharusnya tidak mudah untuk menggunakan kunci yang sama untuk beberapa instance klien,
2. seharusnya tidak mudah untuk menghasilkan kunci yang valid baru, dan
3. seharusnya tidak mudah untuk mencuri kunci dari klien yang sah.

Bagian pertama seharusnya cukup mudah: jangan biarkan dua pemain masuk ke server yang sama dengan kunci yang sama secara bersamaan. Anda juga dapat meminta server bertukar informasi tentang pengguna yang masuk, atau menghubungi server authetikasi bersama, sehingga bahkan menggunakan kunci yang sama untuk pemain yang berbeda di server yang berbeda pada saat yang sama akan gagal. Anda mungkin juga ingin mencari pola penggunaan kunci yang mencurigakan dan, jika Anda menentukan bahwa kunci telah bocor, tambahkan ke daftar kunci yang dilarang.

Untuk bagian kedua, salah satu caranya adalah dengan hanya memelihara database dari semua kunci yang dikeluarkan yang valid. Selama kunci cukup panjang (katakanlah, 128 bit atau lebih) dan dipilih secara acak (menggunakan RNG aman), kemungkinan orang mengelola menebak kunci yang valid pada dasarnya nol. (Bahkan kunci yang jauh lebih pendek bisa aman jika Anda menggunakan semacam pembatasan laju pada upaya login yang gagal untuk menghentikan upaya untuk menemukan kunci yang valid dengan kekerasan.)

Atau, Anda dapat membuat kunci dengan mengambil pengidentifikasi unik dan menambahkan kode otentikasi pesan (seperti HMAC ), dihitung menggunakan kunci master rahasia, untuk itu. Sekali lagi, selama MAC cukup panjang, peluang siapa pun yang tidak tahu kunci master untuk dapat menebak MAC yang valid untuk ID apa pun dapat diabaikan. Salah satu keuntungan dari metode ini, selain menghilangkan kebutuhan akan basis data kunci, adalah bahwa pengidentifikasi dapat berupa string unik, dan dapat menyandikan informasi tentang klien yang kunci tersebut dikeluarkan.

Satu masalah dengan menggunakan MAC adalah bahwa server game resmi (atau setidaknya server otentikasi) perlu mengetahui kunci master untuk memverifikasi MAC, yang berarti bahwa, jika server diretas, kunci master mungkin bocor. Salah satu cara untuk mengurangi risiko ini bisa dengan menghitung beberapa MAC untuk setiap ID, menggunakan kunci master yang berbeda, tetapi hanya menyimpan salah satu kunci utama di server game. Dengan begitu, jika kunci master itu pernah bocor dan digunakan untuk menghasilkan ID palsu, Anda dapat mencabutnya dan beralih ke kunci master lain. Atau, Anda bisa mengganti MAC dengan tanda tangan digital , yang dapat diverifikasi hanya dengan menggunakan setengah dari kunci master.

Untuk bagian ketiga, satu pendekatan adalah memastikan bahwa klien tidak akan mengirim kuncinya kepada siapa pun tanpa memverifikasi bahwa penerima benar-benar server resmi yang sah. Misalnya, Anda bisa menggunakan SSL / TLS (atau DTLS ) untuk proses login, mengeluarkan sertifikat khusus untuk server game Anda dan hanya memiliki sertifikat kepercayaan klien yang dikeluarkan oleh Anda. Dengan mudah, menggunakan TLS juga akan melindungi kunci klien (dan data authetikasi lainnya) dari penyadap misalnya di WLAN publik.

Sayangnya, pendekatan ini tidak akan membiarkan server pihak ketiga memverifikasi kunci klien bahkan jika mereka mau. Anda dapat mengatasinya dengan menyiapkan server otentikasi resmi yang dapat digunakan server game pihak ketiga, misalnya dengan meminta klien masuk ke server otentikasi dan menerima token satu kali acak yang dapat mereka gunakan untuk masuk ke server game (yang kemudian mengirimkan token ke server otentikasi untuk memverifikasinya).

Atau, Anda bisa mengeluarkan sertifikat klien yang sebenarnya, atau sesuatu seperti itu, kepada klien Anda. Anda dapat menggunakan protokol yang ada (seperti TLS) yang mendukung otentikasi sertifikat klien (disarankan) atau mengimplementasikan protokol Anda sendiri, misalnya seperti ini:

• Sertifikat klien terdiri dari string ID acak, pasangan kunci publik / pribadi dan tanda tangan digital ID dan kunci publik menggunakan kunci utama.
• Untuk masuk, klien mengirim ID, kunci publik, dan tanda tangan mereka. Server membalas dengan string tantangan unik (lebih disukai termasuk ID server dan cap waktu, yang harus diverifikasi oleh klien), yang ditandatangani oleh klien dengan kunci pribadi (untuk membuktikan bahwa mereka tahu kunci) dan mengirimkan tanda tangan ke server.
• Server memeriksa kedua tanda tangan, membuktikan bahwa kunci publik ID + membentuk kunci klien yang sah (karena mereka ditandatangani dengan kunci master) dan bahwa kunci klien sebenarnya milik klien (karena klien dapat menandatangani tantangan server dengan privat kunci).

(Protokol ini dapat lebih disederhanakan dengan meminta klien membuat "tantangan", yang terdiri dari ID server dan cap waktu, dan menandatanganinya. Tentu saja, maka server perlu memverifikasi bahwa ID dan cap waktu itu valid. Juga perhatikan bahwa protokol sederhana ini, dengan sendirinya, tidak akan menghentikan penyerang tengkulak untuk dapat membajak sesi klien, meskipun akan mencegah mereka dari mendapatkan kunci pribadi klien yang diperlukan untuk login mendatang.)

Tidak ada kecakapan 100%, tetapi Anda bisa mulai dengan pendekatan yang agak sederhana:

• Anda perlu beberapa cara untuk memverifikasi kunci yang dibuat, misalnya checksum yang disertakan. Tentu saja, ini tidak mudah untuk diketahui.

• Opsional (tetapi disarankan) akan ada database sisi server yang memverifikasi kunci dengan database semua kunci yang diberikan sehingga Anda tidak dapat membuat kunci, bahkan jika Anda memiliki algoritma (mari kita abaikan bruteforcing).

Dari sana Anda dapat memiliki dua pendekatan yang berbeda, tetapi bagaimanapun juga ada sesuatu yang sangat penting:

• Jangan verifikasi kunci di sisi klien. Ini sangat penting, karena sebenarnya agak mudah untuk mendekompilasi hal-hal yang ditulis dalam .net / XNA. Jika Anda harus meminta kunci atau meneruskannya (login atau registrasi), kunci hash (dengan garam tambahan, dll.) Dan kirimkan ke server.

Adapun jalur yang sebenarnya:

• Mengharuskan kunci hash (lihat di atas) untuk dikirim selama prosedur otentikasi / login.

• Sebagai alternatif (IMO yang lebih baik, meskipun banyak yang tidak suka "DRM" semacam ini): Jangan gunakan kunci di klien sama sekali. Sebaliknya, mengharuskan pengguna masuk ke akun dan memerlukan kunci CD yang valid (ini membutuhkan database yang disebutkan di atas) untuk membuat akun. Ini adalah cara permainan modern, misalnya MMORPG bayar-untuk-main menangani ini.

Secara pribadi, saya akan menggunakan pendekatan akun karena alasan sederhana: Pada akhirnya, Anda tidak dapat mencegah orang mencuri kunci CD (bruteforcing, reverse engineering, atau scamming). Dengan demikian Orang hanya bisa membuat kunci baru untuk terus bermain atau untuk mengunci orang lain dari permainan. Dengan kunci terikat akun, tidak seorang pun dapat melakukan apa pun dengan kunci yang sudah digunakan. Jika seseorang membeli kunci yang dihasilkan orang lain, Anda masih dapat mentransfer kepemilikan akun dengan anggapan ada cukup bukti tentang hal ini.

Perangkat Lunak Pangea - pengembang beberapa game Mac - telah menulis sebuah topik tentang perlindungan salinan dalam buku pengembangan game mereka (sekarang gratis). Buku ini juga menjelaskan cara menangani kunci bajakan dan peretasan lainnya yang digunakan orang. Buku ini memiliki fokus pada pengembangan game Mac, tetapi ide-ide itu mungkin masih berguna untuk platform lain. Termasuk dalam buku ini adalah kode sumber untuk setiap bab, bagian dari unduhan di bawah ini. Ada juga kode sumber (ditulis dalam C) termasuk yang terkait dengan perlindungan salinan.

Buku itu bisa diunduh di sini .