Oyunumu CD anahtar / seri numarası ile nasıl korurum?

Bu yüzden, XNA oyunumun korsan kopyalarını resmi oyun sunucularına erişmekten alıkoymaya karar verdim (bu sayede yönetiliyor, böylece oyun için para ödeyen insanlar en iyi deneyimi elde edecekler) müşterileri yanlış veya oluşturulmuş, kopyalanmış veya yasaklanmış bir CD ile ayırarak tuşları (veya seri numaraları, çünkü oyun dijital ve hiçbir CD yok).

Bu seri numarası koruma sistemini oyunuma (hem müşterilere hem de ana kimlik doğrulama sunucusuna) nasıl dahil edebilirim, bu yüzden kolayca kırılabilir değil mi?

Yazılım için bu tür korumayı iyi yapma konusunda hiçbir tecrübem olmadığını unutmayın.

Bunu daha önce hiç yapmadım, ama temellerini anlıyorum. Neden istemcide anahtar kontrolleri yapamadığımı anlıyorum, bu yüzden tek seferlik anahtar girişi ile oturum açma / onaylama kimlik doğrulaması kullanmak benim için sorun değil.

Şu anda, bu korumanın amacı potansiyel aldatıcıları tutmak ve oyuncuları resmi sunuculardan uzak tutmaktır. Herkes anahtarla veya anahtarsız özel sunucularda oynayabilir, ancak diğer oyuncularla istenmeyen bir deneyim elde etme şansı daha fazladır. Sanırım oyuncuları satın almak için yeterince kolay, çünkü resmi sunucularda oynamak için çevrimiçi olmaları gerekiyor.

İstemciyi hacklemek çok kolay olduğu için, yalnızca ilk kayıt (ve muhtemelen sunucu tarafı kimlik doğrulama) prosedürlerini koruyacağım, böylece aktarılırken hiç kimse anahtarları çalamaz.

Ayrıca bakınız:

Çok oyunculu oyunlar kimlik doğrulamayı nasıl ele almalı?

Temel olarak, üç gereksiniminiz var:

1. aynı anahtarı birden fazla müşteri örneği için kullanmak kolay olmamalıdır,
2. yeni geçerli anahtarlar oluşturmak kolay olmamalıdır ve
3. meşru bir müşterinin anahtarını çalmak kolay olmamalıdır.

İlk bölüm oldukça basit olmalı: iki oyuncunun aynı sunucuya aynı anda aynı anahtarla giriş yapmasına izin vermeyin. Ayrıca, sunucuların oturum açmış kullanıcılar hakkında bilgi alışverişinde bulunmasını sağlayabilir veya paylaşılan bir kimlik doğrulama sunucusuyla iletişim kurabilirsiniz, böylece aynı anahtarı farklı sunuculardaki farklı oyuncular için aynı anda kullanmak da başarısız olur. Ayrıca, muhtemelen anahtar kullanımın şüpheli kalıplarını aramak isteyeceksiniz ve bir anahtarın sızdırıldığını tespit ederseniz, yasaklı anahtarların listesine ekleyin.

İkinci kısım için, bir yol basitçe verilen tüm geçerli anahtarların bir veritabanını tutmaktır. Anahtarlar yeterince uzun (örneğin, 128 bit veya daha fazla) ve rastgele seçildikçe (güvenli bir RNG kullanarak), geçerli bir anahtar tahmin etmeyi başarabilenlerin oranları esasen sıfırdır. (Hatalı zorlama ile geçerli anahtarları bulma girişimlerini durdurmak için başarısız oturum açma girişimlerinde bir sınırlama oranı kullanıyorsanız, çok daha kısa anahtarlar bile güvenli olabilir.)

Alternatif olarak, herhangi bir benzersiz tanımlayıcı alarak ve ona gizli bir ana anahtar kullanılarak hesaplanan bir mesaj doğrulama kodu ( HMAC gibi ) ekleyerek anahtarlar oluşturabilirsiniz . Yine, MAC yeterince uzun olduğu sürece, ana anahtarın, herhangi bir ID için geçerli bir MAC tahmin edememesini bilmeyen bir kimsenin, ihmal edilebilir olması ihtimali yüksektir. Bu yöntemin bir avantajı, bir anahtar veri tabanına olan ihtiyacı ortadan kaldırmanın yanı sıra, tanımlayıcının herhangi bir benzersiz dize olabilmesi ve anahtarın verildiği müşteri ile ilgili bilgileri kodlayabilmesidir.

MAC kullanımı ile ilgili bir sorun, resmi oyun sunucularının (veya en azından kimlik doğrulama sunucusunun) MAC'yi doğrulamak için ana anahtarı bilmesi gerektiğidir; Bu riski azaltmanın bir yolu, her bir ID için farklı ana anahtarlar kullanarak birkaç MAC hesaplamak olabilir, ancak ana anahtarlardan yalnızca birini oyun sunucularında depolamak olabilir. Bu şekilde, eğer o ana anahtar sızdırılmışsa ve sahte kimlikler oluşturmak için kullanılmışsa, onu iptal edebilir ve başka bir ana anahtara geçebilirsiniz. Alternatif olarak, MAC'leri , ana anahtarın yalnızca genel yarısı kullanarak doğrulanabilen dijital imzalarla değiştirebilirsiniz .

Üçüncü kısım için, bir yaklaşım, alıcının gerçekten meşru bir resmi sunucu olduğunu doğrulamaksızın müşterinin anahtarını kimseye göndermeyeceğinden emin olmaktır. Örneğin , giriş işlemi için SSL / TLS (veya DTLS ) kullanabilir , oyun sunucularınız için özel sertifikalar verebilir ve yalnızca sizin tarafınızdan verilen müşteri güven sertifikalarını alabilirsiniz. Uygun bir şekilde, TLS kullanımı, müşteri anahtarlarını (ve diğer kimlik doğrulama verilerini) gizli ortaklardan, örneğin halka açık WLAN'lardan da koruyacaktır.

Ne yazık ki, bu yaklaşım üçüncü taraf sunucuların istemese bile istemci anahtarlarını doğrulamalarına izin vermez. Bunun için üçüncü taraf oyun sunucularının kullanabileceği bir resmi kimlik doğrulama sunucusu kurarak, örneğin müşterinin kimlik doğrulama sunucusunda oturum açması ve giriş yapmak için kullanabilecekleri bir kez rastgele bir simge almasıyla çalışabilirsiniz. oyun sunucusu (daha sonra bunu doğrulamak için belirteci kimlik doğrulama sunucusuna gönderir).

Alternatif olarak, müşterilerinize gerçek müşteri sertifikaları veya benzeri bir sertifika da verebilirsiniz. İstemci sertifikası kimlik doğrulamasını destekleyen (önerilen) mevcut bir protokolü (TLS gibi) kullanabilir ya da kendinizinkini uygulayabilirsiniz, örneğin:

• İstemci sertifikası, keyfi bir kimlik dizesi, bir genel / özel anahtar çifti ve bir ana anahtar kullanan kimliğin ve genel anahtarın dijital imzasından oluşur.
• Giriş yapmak için müşteri kimliğini, ortak anahtarını ve imzasını gönderir. Sunucu, istemcinin özel anahtarla imzaladığı (anahtarı bildiğini ispatlamak için) müşterinin özel anahtarla imzaladığı (anahtarı bildiğini ispatlamak için) benzersiz bir sorgu dizesiyle (tercihen bir sunucu kimliği ve bir zaman damgası dahil) yanıtlar.
• Sunucu, her iki imzayı da denetleyerek, ID + genel anahtarının meşru bir müşteri anahtarı oluşturduğunu (ana anahtarla imzalandıklarından beri) ve müşteri anahtarının gerçekten müşteriye ait olduğunu kanıtlar (müşteri, sunucunun özel ile olan mücadelesini imzalayabildiğinden beri) tuşu).

(Bu protokol, müşterinin bir sunucu kimliği ve bir zaman damgasından oluşan "meydan okumayı" oluşturmasını ve imzalamasını sağlayarak daha da basitleştirilebilir. Elbette, sunucunun kimliğin ve zaman damgasının geçerli olduğunu doğrulaması gerekir. bu basit protokol kendi başına bir aracı saldırganın müşterinin oturumunu ele geçirmesini engellemeyecek, ancak müşterinin gelecekteki girişler için gerekli olan özel anahtarını edinmelerini önleyecektir.)

% 100 tasarruf yok, ancak oldukça basit bir yaklaşımla başlayabilirsiniz:

• Oluşturulan anahtarları doğrulamak için bir yola ihtiyacınız olacak, örneğin sağlama toplamı. Tabii ki, bunu anlamak çok kolay olmamalı.

• İsteğe bağlı (ancak önerilir), algoritmayı almış olsanız bile anahtarlar oluşturamayacağınız, anahtarları verilen tüm anahtarların bir veritabanıyla doğrulayan bir sunucu tarafı veritabanı olacaktır (bruteforcing'i görmezden gelelim).

Oradan iki farklı yaklaşıma sahip olabilirsiniz, ancak her iki şekilde de bir şey çok önemlidir

• İstemci tarafındaki anahtarı doğrulamayın. Bu çok önemlidir, çünkü aslında .net / XNA'da yazılanları derlemek kolaydır. Anahtar istemek veya geçmek zorundaysanız (giriş ya da kayıt) anahtarını (eklenmiş bir tuzu vb.) Geçirin ve sunucuya gönderin.

Gerçek yollara gelince:

• Doğrulama / giriş prosedürü sırasında gönderilmek üzere bir karma anahtarı (yukarıya bakın) gerekli.

• Alternatif olarak (IMO daha iyisi, ancak çoğu kişi bu tür "DRM" lerden hoşlanmıyor): İstemcideki anahtarı kullanmayın. Bunun yerine, kullanıcının bir hesap için oturum açmasını ve hesap oluşturmak için geçerli bir CD anahtarı (yukarıda belirtilen veritabanını gerektirir) gerektirmesini gerektirir. Modern oyunların, mesela herhangi bir ödemeli MMORPG'nin bunu nasıl hallettiği budur.

Şahsen, basit bir nedenden ötürü hesap yaklaşımıyla giderdim: Sonunda, insanların CD anahtarlarını çalmasını engelleyemezsiniz (kaba kuvvet, tersine mühendislik veya dolandırıcılık). Gibi insanlar sadece oyuna devam etmek ya da oyundaki diğerlerini kilitlemek için yeni bir anahtar oluşturabilir. Hesap bağlı anahtarları ile, hiç kimse kullanımda olan bir anahtarla herhangi bir şey yapamaz. Birinin bir başkasının ürettiği bir anahtarı satın alması durumunda, bunun yeterli kanıtı olduğunu varsayarak hesap sahipliğini yine de devredebilirsiniz.

Birkaç Mac oyununun yaratıcısı olan Pangea Software (şimdi ücretsiz) oyun geliştirme kitaplarında kopya koruması hakkında bir konu yazdı. Kitap aynı zamanda korsan anahtarlarla ve insanların kullandığı diğer bilgisayar korsanlarıyla nasıl başa çıkılacağını da açıklıyor. Kitapta Mac oyunlarının geliştirilmesine odaklanmış, ancak fikirler diğer platformlar için hala faydalı olabilir. Kitapla birlikte verilenler, aşağıdaki indirmelerin bir parçası olan her bölümün kaynak kodudur. Ayrıca kopya korumayla ilgili kaynak kodu da (C ile yazılmış) bulunur.

Kitap buradan indirilebilir .