Conteúdo criptografado em jogos


45

Eu tenho essa ideia de usar criptografia para impedir que os usuários descubram o conteúdo do meu programa fora do próprio programa. Como os usuários podem encontrar texturas nunca usadas no jogo para fazer parte de algum tipo de ovo de Páscoa enquanto analisam os dados do jogo. Isso pode, por exemplo, arruiná-lo para todos, se publicado online.

Imagine uma sala secreta onde o jogador deve pressionar os números corretos em uma porta de segurança do jogo, que, se correta, deve gerar a chave de descriptografia correta e, em seguida, descriptografar a parte do nível e abrir a porta. Assim, tornando o ovo de Páscoa inacessível, mesmo quando se olha através dos dados do jogo, uma vez que a chave não está realmente armazenada, é gerada com base na entrada do usuário.

Aqui está outro exemplo do que eu estava imaginando. Eu tenho um jogo de quebra-cabeça com, digamos, 20 níveis, cada um criptografado usando uma chave diferente. Em vez de armazenar a chave de descriptografia com o programa, permitindo que alguém descompile o programa e encontre-o, em vez disso, giro a chave de criptografia / descriptografia com base na solução do quebra-cabeça anterior. Dessa forma, o jogador teria que realmente descobrir o quebra-cabeça antes de obter qualquer informação sobre o próximo nível, mesmo ao examinar os dados do jogo.

O jogador, se tiver conhecimento, pode forçá-lo com força bruta "facilmente", uma vez que o número de soluções de quebra-cabeças é provavelmente menor que o número de chaves de descriptografia. É realmente uma questão de complexidade do quebra-cabeça e não é muito importante aqui. Embora eu tenha postado uma resposta sobre isso aqui

Hoje existem programas / jogos que fizeram algo assim? Armazenando conteúdo criptografado em seus jogos? E se não, por que? Existem muitas regras e regulamentos sobre isso, tanto na loja quanto no país? Alguém vê alguma armadilha óbvia que estou perdendo? Ignorando coisas como a experiência do usuário, a ideia parece sólida para mim e me deixa curioso por que não tinha visto isso antes.

Edit : Pode não estar claro exatamente o que estou dizendo, então aqui está um exemplo mais concreto.

Digamos que eu tenho uma função que recebe uma seqüência de 20 caracteres e gera uma chave simétrica que eu posso usar para criptografar / descriptografar algum conteúdo do jogo. A única maneira de o usuário acessar esse conteúdo é conhecer esses 20 caracteres e gerar a mesma chave. Essa chave nunca é armazenada diretamente e é gerada instantaneamente com base na entrada do usuário. Esses personagens estariam escondidos no jogo no que poderia ser livros, diálogo com os NPCs, talvez até mesmo fora do jogo na parte de trás da caixa.

Portanto, com 2 * 10 ^ 28 combinações possíveis para tentar, provavelmente seria mais provável que as pessoas encontrassem o conteúdo da maneira pretendida, em vez de olhar os dados do jogo.

Edição 2 : o conteúdo em questão seria criptografado com uma chave arbitrária e secreta antes de ser enviado ao consumidor. Obviamente, essa chave não será enviada com o jogo. Ele ou ela teria que, de alguma forma, reconfigurar a chave novamente, dada uma série de pistas feitas com base na chave e que estão ocultas ao longo do jogo ou em qualquer outro lugar. No entanto, esse sistema seria transparente para o usuário, pois você não saberia que o conteúdo foi criptografado, a menos que você realmente analisasse os dados do jogo.

Como muitos mencionaram, isso tem uma desvantagem óbvia, pois seu caso de uso é limitado. Uma vez que uma única pessoa tenha descoberto, ele / ela pode compartilhá-lo com todo mundo, se não a chave / solução, então o próprio conteúdo. No entanto, se sua intenção é manter algo tão secreto que uma única pessoa não consiga resolvê-lo e as pessoas tenham que trabalhar juntas para resolvê-lo, ou você tem medo de que seu ovo de páscoa esteja tão bem escondido (por design) que é mais provável que alguém o encontre no código durante o jogo. Então eu acho que isso poderia funcionar muito bem.

Pessoalmente, eu recomendaria usá-lo apenas uma vez por jogo e apenas para coisas que não afetam o jogo principal, como ovos de páscoa, um final secreto. Qualquer quebra-cabeça teria que ser tão complicado ou bem escondido para atrasar as pessoas o suficiente para fazer a criptografia valer a pena e se esse quebra-cabeça atrapalhasse o progresso das pessoas, provavelmente ninguém estaria se divertindo.


56
As respostas se concentram nos detalhes técnicos, mas se seu objetivo é ocultar spoilers, considere que essas informações estarão disponíveis simplesmente jogando o jogo ; nesse ponto (se o jogo for popular), elas serão direcionadas diretamente para um artigo da Wikia para que todos possam leia, jogador ou não.
Leushenko 6/02/16

4
Duplicar no desenvolvimento de jogos stackexchange: "Como posso proteger meus dados de jogos contra hackers casuais?"
Philipp

5
Isso não é um pouco exagerado para um produto de entretenimento? Quero dizer que as pessoas podem pegar a "chave" procurando um passo a passo ou vamos jogar ou apenas perguntar às pessoas que já a tocaram. Além disso, o jogo pode se tornar mais propenso a erros por causa dessa maneira "mais ou menos obscura" de lidar com as coisas. Caso contrário, eu gosto da idéia e vai ser um truque bom, mas impedir que as pessoas ainda não vai de cortar / batota, mas sim torná-lo mais difícil
BlueWizard

3
Eu acho que isso seria especialmente legal se seus usuários forem conhecidos por invadir seu jogo e o quebra-cabeça for realmente muito difícil. Você pode imaginar nos fóruns "o que é esse arquivo criptografado estranho".
PyRulez 07/02

5
@PyRulez Ah yes! Essa tem sido minha principal motivação por trás disso. Eu odeio quando esses governos irritantes examinam os arquivos do jogo para encontrar todos os ovos da páscoa. Tudo para que eles possam publicá-lo nos fóruns de inimigos e arruinar a moral do país.
Christer

Respostas:


90

Esta pergunta está perguntando se é possível (não apenas comercialmente viável ou alguma outra interpretação) forçar pelo menos 1 usuário a resolver um quebra-cabeça em vez de hackear para desbloquear determinado conteúdo do jogo.

Que eu saiba, isso é definitivamente possível. De fato, é bizarro para mim que outras respostas estejam dizendo que não é possível, mesmo quando foi explicitamente declarado que a chave não é gerada nem armazenada, apenas lida a partir do estado do jogo (que poderia ter googleplexes de possíveis valores). O argumento de que "o jogo sabe como descriptografá-lo" para que não funcione implica que qualquer software de criptografia / descriptografia de código aberto (por exemplo, TrueCrypt) é inerentemente inseguro porque você sabe "como" descriptografar contêineres (basta digitar uma string baseada na entrada do teclado, é simples, certo?).

No caso mais simples, imagine que o jogo em si seja um simulador de teclado e faça a pergunta "qual é a senha dos meus arquivos criptografados?", Claramente todos concordamos que ter o código fonte do jogo não ajudaria. Agora imagine que o jogo faça as perguntas "qual é o nome do maior animal da Terra concatenado com o nome do menor animal?". Não está claro que ter o código fonte do jogo não ajudaria e você ainda precisa resolver o quebra-cabeça?

Com relação a se isso é possível, a resposta é absolutamente SIM, isso é possível.


9
Sinto que sua resposta é a única até agora que parece entender completamente minha pergunta. Muitos parecem pensar automaticamente que minha pergunta é como outras questões de criptografia relacionadas a jogos. Entendo de onde eles vêm, embora deseje que eles leiam minha pergunta um pouco melhor.
Christer

7
O que você está propondo é que a solução para os problemas esteja sendo armazenada apenas de maneira criptografada. É definitivamente possível confirmar uma solução válida, mas basicamente impossível voltar atrás. (como armazenar senhas-101). A segunda parte da pergunta sobre como ocultar o conteúdo que não exige que a entrada do usuário seja exibida é, no entanto, impossível de resolver (observe que, quando digo que não há entrada do usuário, quero dizer isso de uma maneira muito estrita)
WorldSEnder

3
Eu acho que o ponto principal é realmente que só é possível forçar um único usuário a resolver o quebra-cabeça, porque esse primeiro pode informar a todos. O que torna o ponto inteiro do exercício de criptografia mudo.
C7

4
Com o código fonte (ou um stringsno executável), uma charada como "Qual é o nome do maior animal ...?" pode ainda precisar ser resolvido pelo jogador / hacker, mas pelo menos ele pode evitar as viagens perigosas para o local do jogo em que a pergunta ocorre. Portanto, os enigmas em si também devem estar um pouco ocultos (texto como gráficos pode ser suficiente; mais elaboradamente, acho que me lembro de um jogo em que objetos 3D normais, quando vistos de um ponto específico, combinam-se prospectivamente com a solução de um enigma ou outro information ...)
Hagen von Eitzen

4
Citações citadas como "Isso pode, por exemplo, arruiná-lo para todos se postado online". da pergunta original ... desculpe, mas esta resposta está faltando o ponto. Seria igualmente vulnerável arruiná-lo para todos, se a resposta ou os arquivos descriptografados ou o que quer que fosse publicado, e fosse igualmente vulnerável a publicá-los.
Nathan Tuggy

57

Já foi tentado. Muitas, muitas vezes. Existe todo um setor secundário dedicado a tentar usar a criptografia para impedir que os usuários acessem um programa como entenderem. E isso nunca funciona. Os melhores esquemas de proteção tendem a durar cerca de um mês antes de serem quebrados, e a coisa sobre a Internet é que, uma vez quebrada uma vez, está quebrada em todos os lugares para sempre assim que alguém a publica. A armadilha óbvia que você está perdendo é que, para que seu programa use os dados, ele deve conter todas as informações necessárias para descriptografá-lo e, se o computador puder fazer isso, uma pessoa com acesso ao computador poderá fazer isso. este.

Isso já foi chamado de "o problema fundamental da criptografia": Alice deseja enviar uma mensagem para Bob, sem que Charlie seja capaz de lê-la, mesmo que ele a compreenda. O problema com a abordagem que você está propondo é que Bob e Charlie são a mesma pessoa neste caso.

Entendo o desejo de não prejudicar seus usuários, mas se as pessoas quiserem spoilers, elas os encontrarão e, se não o fizerem, tenderão a evitar ativamente os spoilers. Mas se você realmente quer fazer um ótimo jogo, siga o caminho oposto: abertura radical. Veja coisas como Neverwinter Nights , Starcraft ou a série Elder Scrolls , jogos que permanecem populares por anos e anos após o lançamento. Eles o fazem porque entregam poderosas ferramentas de design com o jogo que permitem aos usuários explorar tudo, descobrir como funciona e criar e compartilhar seu próprio conteúdo. Um jogo é apenas um jogo, até se tornar uma comunidade , e as comunidades perduram.


3
Nesse caso, quebrar a criptografia seria equivalente a escrever um bot que resolvesse os quebra-cabeças. Provavelmente mais difícil do que simplesmente completar o jogo e anotando as respostas
Ewan

15
Eu só quero dizer que esta resposta realmente não responde à minha pergunta! Na verdade, eu quero que as pessoas "decifrem o código" ou melhor, resolvam meu quebra-cabeça. Esse é o ponto, e sim, uma vez que alguém descobre que não posso impedi-lo de compartilhar a solução, não estou tentando. No entanto, você está errado ao dizer "deve conter todas as informações necessárias para descriptografá-las", pois o ponto principal foi que essas informações foram fornecidas pelo usuário. Leia a pergunta atualizada para obter detalhes.
Christer

6
@Christer Ele faz e aqui está o porquê: Mason está dizendo que se importa se eles podem entrar nos arquivos do jogo para descobrir a resposta de quebra-cabeça , porque apenas uma minoria vai realmente fazê-lo ..
Insane

9
@JonasDralle Esse é um ponto de vista nojento e cínico, e também não é verdade. A comunidade forte e duradoura criada em torno de Morrowind e Oblivion não impediu a venda de Skyrim ; se alguma coisa, tornou mais bem sucedido!
Mason Wheeler

3
@Cronax Se você usar a criptografia no estilo "one time pad", nesse caso, a chave é a solução do quebra-cabeça, o invasor não tem uma opção melhor do que a previsão bruta sobre o tamanho do espaço da chave. Com o tipo certo de quebra-cabeça, isso pode ser impracitualmente grande para ser resolvido durante a vida útil do universo. Além disso, se o ovo da páscoa for, digamos, uma mensagem do desenvolvedor, um invasor não terá como distinguir a mensagem real de uma mensagem aleatória e correta do Egnlish.
Ben Aaronson

10

Já estou aqui há tempo suficiente para saber que, se o conteúdo estiver lá, alguém o encontrará. Tornar mais difícil apenas atrairá pessoas mais determinadas. Quanto mais popular o seu produto, mais interessante ele se torna. Parcialmente porque é um desafio, em parte porque existem muitos lugares onde você pode obter "cred" publicando esse tipo de informação.

Se a chave é gerada localmente pelo jogo, você pode encontrar uma maneira de trapacear no jogo até o ponto em que a chave é gerada ou simplesmente digitar o trecho de código correto. Se a chave lhe for enviada a partir de um servidor para concluir determinadas etapas do jogo, alguém o enganará, fazendo-o acreditar que chegou longe o suficiente.

No final, seu jogo se beneficiará muito mais com o tempo que você gasta, tornando-o divertido e envolvente, além de tornar difícil descobrir qual é a cor do próximo nível.


Embora os dados criptografados com uma chave armazenada localmente sempre possam ser invadidos. Na prática, todos os aplicativos e jogos modernos usam isso até certo ponto.
Ewan

Confira soomla e como ele faz moedas
Ewan

Eu acredito que a pergunta era sobre como ocultar o conteúdo futuro de jogadores curiosos, não sobre como proteger moedas e estatísticas do jogador de adulteração
axl

1
Como se trata de um ovo de páscoa, atrair atenção é exatamente o que você deseja.
PyRulez 07/02

6
Tornando mais difícil só vai atrair as pessoas mais determinados Eu acho que esta é uma grande estratégia de marketing para um jogo :)
sampathsris

9

A principal razão pela qual isso deve estar no gamedev.SE é que fazer essa criptografia tem consequências na jogabilidade.

Você deseja que a solução para um quebra-cabeça seja a chave de criptografia para o próximo. Ou seja, os dados reais dessa solução devem descriptografar o próximo quebra-cabeça. Isso significa que a chave de descriptografia não faz parte dos dados do seu jogo; é gerado pelo jogador.

E aqui está a consequência. A descriptografia é geralmente binária. Você tem a chave de descriptografia exata necessária para descriptografar os dados ou não.

A conseqüência aqui é que, qualquer que seja o jogo que você crie, deve ser tão estreitamente focado que existe apenas uma solução possível para todos os níveis. Portanto, sua mecânica de quebra-cabeça deve ser projetada com muito cuidado, de modo que o jogador não consiga resolver o quebra-cabeça de maneira diferente da sua intenção.

Veja o Portal, Câmara de Teste 10, por exemplo. Você deveria ir para a esquerda, fazer algumas coisas, depois ir para a direita e fazer algumas coisas, tudo para abaixar uma plataforma.

Ou você pode apenas se dar um pouco de velocidade e se atirar na plataforma quando entrar.

GLaDOS: Então você fez um jogo de quebra-cabeça. Um jogo de quebra-cabeça que pune as pessoas que mais gostam de jogos de quebra-cabeça. Bom trabalho. Mas pelo menos esses hackers não terão seus preciosos dados. Porque as pessoas que gostam de resolver jogos de quebra-cabeça são os tipos exatos de pessoas que procuram soluções para jogos de quebra-cabeça online.

Então isso vale totalmente a pena.

Portanto, jogos de quebra-cabeça como Adventures of Lolo, SpaceCHEM e Portal (entre milhões de outros) estão prontos . Em vez disso, você deve criar seu jogo de forma que seja impossível criar um quebra-cabeça com mais de uma solução. Isso requer muito cuidado e geralmente requer jogabilidade bastante restritiva.

GLaDOS: Então você fez um jogo de quebra-cabeça. Um jogo que deve ser jogado por pessoas que gostam de encontrar soluções criativas para quebra-cabeças. E você criou um jogo que não tem soluções criativas para quebra-cabeças. *aplauso lento*

Não estou dizendo que você não pode criar um jogo assim. Ou que esse jogo não pode ser bom. Só que esse jogo teria que ser projetado de uma certa maneira.

Ah, e você precisa projetar essa jogabilidade de modo que seja impossível (ou altamente difícil) encontrar mecanicamente uma solução.

GLaDOS: Então você fez um jogo de quebra-cabeça. Um jogo de quebra-cabeça que é mais interessante para hackear do que para jogar. Bom trabalho.


Obviamente, há uma ressalva: o significado de "solução". Ou mais, que elementos de uma solução você leva em consideração?

Para qualquer jogo que envolva um personagem em movimento, você provavelmente não usará os movimentos exatos do personagem para construir a chave de descriptografia. Por exemplo, se você tem um jogo de quebra-cabeça em que o jogador precisa pegar determinados itens para "resolver" o quebra-cabeça, você pode fazer com que a chave dependa da ordem em que esses itens são tocados.

Obviamente, isso se depara com o problema acima, onde um jogador encontra uma maneira de fazer coisas fora de ordem. O que novamente significa que você precisa projetar o quebra-cabeça de tal maneira que exista apenas um pedido em que você possa escolher as coisas.

Além disso, quaisquer elementos que você use para construir a chave de descriptografia precisam fornecer entropia suficiente para dificultar a descriptografia de força bruta. Usando a mecânica da ordem de coleta acima, cada novo item é efetivamente um bit extra. Se um nível tiver apenas 8 itens, você estará fazendo criptografia de 8 bits. Qual é porcaria; a maioria dos smartphones consegue lidar com isso em segundos.

Atualmente, você precisa de pelo menos 128 para torná-lo um pouco desafiador. O que agora significa que cada nível precisa ter muitas coisas, impactando novamente o design do jogo.


2
@ Chris: Seu exemplo apenas trai a irrelevância da sua pergunta geral. O conteúdo de "um altar secreto fora de qualquer missão" é, por definição, irrelevante para qualquer jogo que seja fundamentalmente sobre a conclusão de missões . E se o seu jogo não é sobre completar missões, por que você tem missões? De qualquer maneira, o fato geral permanece: você está gastando muito tempo em algo sem relevância real para o seu jogo ou para os seus jogadores. Você deve concentrar seu tempo e energia muito limitados nas coisas que importam .
Nicol Bolas

2
@ Chris: " Além disso, uma vez que o fato de a criptografia ser usada é transparente para 99,9% dos usuários, esse não é um argumento válido por ser uma ideia horrível. " vá para recursos realmente úteis, então sim, é uma ideia horrível. Você passou mais tempo formulando sua pergunta e respostas às respostas do que esse recurso merece . Nesse período, você poderia estar escrevendo seu jogo real. Se é transparente para 99,9% dos usuários ... então por que isso deveria importar para eles se está criptografado? Por que gastar tempo para 0,1% das pessoas?
Nicol Bolas

2
Sinto muito, mas eu gosto de me divertir fazendo meus jogos! Nem todo mundo pode ser um robô produtor de jogos. Permitam-me também julgar quanto tempo isso leva e quanto eu estaria disposto a gastar. A parte de ecryption em si, pelo menos, seria fácil de implementar.
Christer

1
The consequence here is that whatever game you design must be so narrowly focused that there is only one possible solution to every level.Não necessariamente: ele pode criptografar o conteúdo de cada solução possível e enviar conteúdo criptografado duplicado para todas as soluções possíveis. É possível economizar espaço usando uma criptografia de duas camadas - a chave do usuário na resposta vinculada corresponde a uma solução específica, o documento corresponde ao conteúdo.
Mucaho 08/02

4
@mucaho: Isso requer conhecer "cada solução possível" de antemão.
Nicol Bolas

8

As respostas aqui são boas; Eu consideraria isso de outra perspectiva. O que você está descrevendo é um recurso . Os recursos têm custos e benefícios. Os custos incluem os custos em dólares da criação do recurso e os "custos de oportunidade". São elas: em um mundo em que você tem dólares finitos, horas e programadores finitos, cada recurso que você faz significa um número infinito de recursos possíveis que não foram feitos em seu lugar.

Portanto, a pergunta é: você pode indicar os custos desse recurso em termos reais? Não há recursos gratuitos, portanto, seja realista sobre os custos. Você está disposto a pagar mil dólares por esse recurso? Cem mil? Um milhão? Quais recursos você deseja cortar para ter esse recurso?

Acho que quando você começar a priorizar as coisas em termos de custos, benefícios e oportunidades perdidas, perceberá que já passou muito tempo pensando sobre esse recurso quando pensava em maneiras de tornar o jogo mais divertido.


5

O problema de Alice Bob e Eve ilustra isso bem. Como Mason apontou em sua resposta, você não pode esconder um segredo de Eva se Eva também é Bob.

Portanto, qualquer solução consistiria em Bob não ter todas as informações necessárias. Você precisaria tratar cada nível como uma mensagem individual, criptografada separadamente e ter uma fonte externa das mensagens para o próximo nível que fosse capaz de manter as mensagens corretamente.

Mas, eventualmente, isso se torna discutível. Se alguém puder jogar o jogo, também poderá escrever um programa para ingerir o jogo. Então, tudo o que você está fazendo é forçá-los a ir e voltar da sua fonte externa (provavelmente um servidor de algum tipo). Depois que eles descobrem como criar as mensagens para o servidor, é a mesma velha história.

Mas você está esquecendo um elemento-chave aqui. É um jogo. Se alguém trapaceia em um jogo, grande grito. Você não escreveu o jogo para trapaceiros. É o mesmo com orientações passo a passo ou guias de nivelamento: as pessoas que querem o desafio de descobrir por conta própria ignoram as soluções postadas. Mesmo se você fosse capaz de tornar o jogo impossível, sem jogá-lo (sabemos que é logicamente impossível, mas mesmo que você pudesse), apenas um cara passaria antes que ele postasse tudo o que fosse necessário para vencê-lo. Então você está apenas atrasando o inevitável.

Gaste seu tempo fazendo um jogo incrível. Há dez coisas que todo jogo precisa e, pela última vez que olhei, a criptografia não era uma delas.


2

Acredito que sua ideia não faz sentido.

Quando alguém joga o seu jogo, ele escolhe, não o faz para ganhar um prêmio, o faz por diversão.

Os usuários sabem que o mais divertido é jogar da maneira que você quis dizer e não trapacear , já que seus clientes já confiam em você como contador de histórias.

Assim que alguém encontrar a solução para um quebra-cabeça, ou seja, sua chave, ele poderá simplesmente publicá-la em algum lugar da Internet.
Jogadores que querem trapacear ainda poderão fazê-lo.


No entanto, se o seu jogo apresentar várias soluções, como níveis secretos de Super Mario Land, criptografar seus ativos impedirá um acesso fácil a essas soluções.

Embora isso pareça um ponto a favor da sua ideia, no final não é.

Mesmo com a criptografia, ainda seria possível saber que essas soluções secretas existem.
Uma vez que se saiba que existe uma solução secreta, impedir os jogadores de olhar para os ativos secretos seria irrelevante, pois eles ainda desejariam acessar as partes ocultas do jogo através do próprio jogo (sim, mesmo que já tenham visto todos os itens ocultos) textura / clipe / áudio / texto).

Você pode impedir o vazamento da existência de soluções secretas usando alguma técnica alheia 1 , mas ainda assim seria suspeito (por que fazer isso se não houver soluções secretas?), Os jogadores perderiam o interesse em encontrá-las e você teria menos jogadores , não mais.
Afinal, podemos jogar mais algumas horas depois de concluir um jogo para acionar alguns ovos de Páscoa, mas não jogaremos mais um minuto se acioná-los exigir um esforço titânico!


O que você quer fazer é como um livro escrito, onde o próximo capítulo é criptografado com uma palavra do capítulo atual, para impedir que os leitores se estraguem com o final.
Pense nisso, não é inútil?

1 Como o VeraCrypt, faça isso com volumes ocultos.


1
Na verdade, eu gosto dessa ideia de livro. Entendo que isso poderia frustrar muitas pessoas, mas também podia imaginar pessoas realmente querendo esse livro. Conheço pessoas que não podem deixar de estragar o final sozinhas, mesmo tentando não fazê-lo. Então, acho que esse livro poderia ajudar. Embora eles ainda pudessem procurar as chaves on-line, a menos que elas fossem personalizadas. Mesmo assim, eles poderiam procurar diretamente o final. Ainda assim, se eles estivessem tão desesperados, não faria sentido tentar detê-los ainda mais, como você disse.
Christer

1

Não comentarei a viabilidade comercial, no entanto, de uma perspectiva técnica pura, é um desafio divertido.


Gostaria de observar primeiro que qualquer coisa que não esteja criptografada não pode ser protegida. Você não pode bloquear a entrada em segredo, os crackers encontrarão uma maneira de contornar o portão; em vez disso, você deve tornar todo o segredo o próprio portão. Em termos de ativos, isso não precisa significar as texturas inteiras, etc ... apenas criptografar o plano e quais são usados ​​e como são suficientes, e por razões de desempenho, você desejará criptografar o mínimo de dados possível.


Em segundo lugar, você está certo de que, se a chave estiver contida no software, ela será provocada pelo software. Muitos jogos, ao proteger o conteúdo, tentam usar a segurança pela obscuridade ou por mecanismos que garantam que o software do jogo não tenha sido alterado. Essas são apenas táticas de atraso.

Sua idéia de usar a solução de um enigma como a chave é bastante interessante, no entanto, é provável que o uso da chave fornecida diretamente seja facilmente forçado. Em vez disso, trate a entrada do usuário como uma senha e use um esquema de hash de senha de última geração: o hash produzido é a chave.

No entanto, mesmo assim, há um erro na sua suposição de que a chave não está presente no jogo. Caso contrário, você não poderia direcionar seus jogadores para ele; portanto, em vez de tentar forçar o cofre com força bruta, alguém poderia fazer engenharia reversa dos ativos do jogo procurando pistas. Um quebra-cabeça em potencial em que consigo pensar é usar texturas para codificar glifos e a senha consistiria em alguns dos disponíveis no teclado, conforme revelado pelos locais que o jogador deveria ter visitado (em ordem):

  • O ponto crucial do problema é que o reconhecimento de imagens ainda é um pouco difícil para os computadores
  • além disso, destacamos o fato de que os crackers CAPTCHA são ajustados para letras e dígitos, não para glifos personalizados
  • além disso, destacamos o fato de que, combinando várias texturas (com transparência) para revelar o glifo ao jogador, nenhum ativo isolado no jogo contém a aparência do glifo
  • use outra textura (com fragmentos) em todo o lugar, mas nunca de maneira a gerar um glifo completo, exceto em locais ocultos que o jogador nunca deve conseguir

e qualquer programa para extrair automaticamente a combinação de glifos vencedor terá um dia infernal.


Em terceiro lugar, a próxima dificuldade é compartilhar. Quando a solução de um segredo for encontrada, ela será revelada. Idealmente, cada indivíduo deve receber uma versão ligeiramente diferente do software: aquela em que a chave seja exclusiva da versão do jogo. Para torná-lo prático, suponho que seria mais fácil separar o jogo (com seus ativos) dos "segredos" (criptografados) e "driver secreto" (o gerador de chaves, que coloca muitos fragmentos de textura em muitos e diferentes lugares) , algumas das quais formam as senhas).

O vetor de ataque óbvio é enganar o gerador, sempre escolhendo a mesma senha, ou enganar o verificador, sempre aceitando a mesma senha (baixando o arquivo de segredos de outra pessoa, por exemplo).

Aqui, uma solução em potencial seria vincular os arquivos à conta do usuário e salgar a senha como é geralmente recomendado:

  • quando o usuário solicitar um conjunto de arquivos, gere aleatoriamente um salt e quantas senhas você tiver segredos e crie os ativos secretos (você pode limitar esse processo a uma vez / dia / usuário, por exemplo, para evitar sobrecarregar o servidor)
  • armazene o registro de data e hora da geração e o sal nas informações da conta do usuário
  • envie de volta o carimbo de data e hora e os arquivos secretos personalizados ao usuário

Então, quando o usuário estiver pronto para enviar uma senha:

  • faça com que o usuário efetue login (se ela ainda não estiver)
  • faça com que o software envie a senha do carimbo de data e hora e do glifo
  • se o carimbo de data / hora for diferente daquele armazenado, informe ao usuário que ele está usando um conjunto obsoleto de arquivos secretos
  • se a senha já tiver sido tentada muitas vezes, informe ao usuário que ela está usando um conjunto obsoleto de arquivos secretos
  • caso contrário, faça o hash do salt + senha para produzir a chave
  • caso contrário, envie a chave de volta ao usuário para que ele possa ver seus arquivos personalizados
  • aumentar o número de vezes que essa senha foi tentada por esta conta

O objetivo aqui é impedir o compartilhamento da conta, tanto quanto possível:

  • o compartilhamento de uma conta para gerar arquivos secretos é (a) limitado, porque apenas um pode ser gerado por dia e (b) inútil, porque o último gerado torna o outro obsoleto
  • compartilhar uma conta e distribuir os arquivos secretos associados é inútil, porque uma senha específica só pode ser usada N vezes antes de não produzir mais a chave

E nós estamos quase lá.


Finalmente, mesmo lá, um cracker pode lançar uma versão modificada do jogo na qual os ativos secretos são descriptografados e diretamente integrados (ignorando seu cuidadoso esquema de verificação).

A solução é simples (e torna quase tudo acima do 1 obsoleto ): não confie no cliente.

Crie uma tabela de classificação no seu site e acompanhe o progresso dos jogadores na conta deles. Os jogadores podem afirmar que terminaram o jogo o quanto quiserem, mas, a menos que sua conta reflita isso, todos sabem que estão trapaceando ...

... isso é chamado de pressão social;)

1 Exceto o arquivo de posicionamento da textura, que usamos para impedir que um programa adivinhe a chave e, no entanto, possibilite que um usuário a obtenha.


Obrigado pela sua resposta atenciosa. Você faz bons pontos. Embora eu gostaria de acrescentar que a chave / solução não precisa ser armazenada no jogo, como você disse. Ele pode estar oculto no html da página do jogo, por exemplo, talvez você queira recompensar as pessoas que pesquisam coisas assim. Mas, mesmo no jogo, você pode ser mais criativo, como usar enigmas como uma solução, geometria que revela informações quando vistas de um ângulo, usar coisas relacionadas ao contexto que você provavelmente não entenderia, a menos que tenha lido muito do folclore da literatura. jogos. Como a Skyrim tem livros ou registros nos terminais do computador.
Christer

Eu não mencionei isso na minha pergunta, então não se preocupe. Como eu estava imaginando isso, você jogaria um jogo inteiro e parecia um jogo completo. No entanto, havia uma porta escondida que tinha uma fechadura estranha que você nunca passou. Espero que as pessoas curiosas e conversem, talvez até as pessoas que trabalham juntas para descobrir isso. Como ninguém descobriu isso, também é um tipo de glória a ser descoberta por descobrir também. Talvez, se houver tempo suficiente, os segredos ilusórios da porta gerarão lendas! É péssimo ter isso arruinado por alguém apenas olhando os recursos do jogo.
Christer

@ Chris: É péssimo ter isso arruinado por alguém apenas olhando através dos ativos do jogo. => Este é solucionável usando arquivos secretos para descrever o lugar de fato (reutilização de texturas existentes na maior parte), uma vez que o segredo está fora uma vez, porém, ele está fora ...
Matthieu M.

0

É uma ideia interessante; uma variante nos discos de quebra-cabeça e nos sistemas de proteção contra cópia que digitam a palavra do manual. Eu acho que alguns dos jogos "ARG" funcionam assim, onde é entendido que os jogadores estão agindo coletivamente contra o criador do jogo.

Obviamente, quando a primeira pessoa descriptografar, a publicará na internet.

O conteúdo generativo ou processual pode funcionar da mesma maneira: você não vê o mesmo mundo que outro jogador, a menos que compartilhe uma "semente".

Não vejo nenhum problema legal com ele, embora a Apple possa rejeitá-lo em sua App Store e talvez você precise fornecer a solução para que ele seja aprovado em consoles de jogos.


0

Contemplar medidas extras de segurança é divertido, mas não agrega valor concreto ao seu produto - ele demonstra sua astúcia aos crackers que encontram seu produto. Por princípio, seu antagonista o alcançará.

Ao contrário dos desenvolvedores que prosperam na criatividade, os crackers são pessoas analíticas - eles podem explorar intuitivamente o seu programa. Quando os desenvolvedores tendem a tomar medidas de segurança excessivas, eles negam - que o cracker possa reverter seu esquema de proteção novamente .

Se você deseja participar dessa competição em segundo plano, essa é a sua decisão - mas não deixe que isso desvie seu produto final, o que deve agradar o cliente. Um esquema de criptografia peculiar que transforma o jogo em uma lesma não ajuda.


0

Mason Wheeler tem razão: você não pode fazê-lo. Alguém sempre pode fazer engenharia reversa do seu jogo, se quiser.

Você não precisa "proteger" seu jogo de qualquer maneira da maneira que descreve. Assim que uma pessoa encontra o ovo da Páscoa, o segredo está fora do saco. Se cada cópia do jogo tiver um ovo de Páscoa diferente, apenas a cópia do hacker será conhecida. Você realmente se importa que um hacker em cada 1000 pessoas tenha encontrado o ovo de Páscoa sem passar pelo jogo?

A lei de direitos autorais é tal que ninguém pode ganhar dinheiro com seu jogo sem arriscar uma ação séria; portanto, os direitos autorais o protegem.

Quanto aos usuários aleatórios colocando suas texturas no avatar do fórum, e daí? Considere publicidade de base.

Ficar obsessivo em "proteger" coisas apenas o distrairá de realidades difíceis como: fazer o jogo .

Quando vejo pessoas sem produtos falando sobre seus esquemas de proteção de IP para coisas que nem existem, é um tipo de momento para mim, porque gera uma enorme bandeira vermelha sobre o projeto inteiro.


-1

Algumas possibilidades:

  • Ofuscação de código antigo simples . Não tornará o código impossível de decodificar, mas pelo menos será difícil.

  • Solução do lado do servidor. Você envia alguns comandos especiais para o servidor e o servidor pode enviar o código ... ou até mesmo baixar um DLC.

  • Você pode usar a esteganografia para ocultar o código executável em outro conteúdo.

Isso não tornará seu segredo 100% seguro, mas parece que ninguém perderá dinheiro se o segredo for revelado.


-1

É inútil, assim como qualquer outro esquema em que você armazena chave e algoritmo no cliente. Se você perguntar "onde está a chave, eu confio na entrada dos usuários e não a armazeno?", Lembre-se de que seu quebra-cabeça tem regras e recursos por suas definições - é resolvido por algum algoritmo, não por força bruta. Esse algoritmo exato e seus recursos É o algoritmo de geração de chaves que você acabou de codificar no jogo no estado ofuscado. Qualquer pessoa pode recuperar sua chave "inexistente" escrevendo um pequeno programa que resolve seu quebra-cabeça de acordo com suas regras.


1
Mas nem todo quebra-cabeça é facilmente solucionável por um computador, como um enigma que nunca foi feito antes. Também é difícil para um computador ler toda a caixa de diálogo do jogo e processar todas as texturas. Mesmo assim, como saberia quando surgisse algo relacionado a esse quebra-cabeça? A chave completa nem precisa ser armazenada no jogo, talvez haja uma pista para ler a parte de trás da caixa onde está a chave, o computador não pode fazer isso. Mesmo que o quebra-cabeça fosse algo que o computador pudesse resolver, como o Sudoku, pelo menos seria resolvê-lo e não contorná-lo.
Christer

@ Chris, não é diferente que descobrir outra criptografia caseira de "segurança por obscuridade". "Na caixa" - você acabou de escrever a chave do recurso "capa de papel" que você fornece ao usuário em vez do recurso "arquivo" que você fornece ao usuário . Grande negócio.
Oleg V. Volkov

@ Chris, isto é, resolver "um enigma que não foi feito antes" é exatamente igual a "resolver um algoritmo de criptografia caseiro que não foi feito antes".
Oleg V. Volkov

Você não vê como pode gerar uma chave de descriptografia com base na entrada do usuário? Você não vê que essa entrada do usuário pode ser alguma coisa? Qual é a entrada correta do usuário que gera uma boa chave de descriptografia, você pergunta? Quem sabe, está oculto durante todo o jogo de várias maneiras interessantes. Espero que você encontre, pois esse é o objetivo! Boa sorte para chegar a esse conteúdo de outra forma.
Christer

Como exatamente isso é diferente da fonte de leitura? Você executa a tarefa de acordo com as regras definidas -> você obtém a chave. Isso é tudo. Exceto que você pode usar atalhos apenas lendo suas "pistas" de outros recursos do jogo, em vez de realmente jogar o jogo.
Oleg V. Volkov
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.