Pergunta

Estou tentando tornar um código difícil de quebrar usando o Objective-C em um Mac.

Uma das coisas que preciso fazer é verificar se o aplicativo foi quebrado.

Sou novo no Objective-C e Xcode e, da maneira que imagino testar meu aplicativo, sempre termino em um teste básico que pode ser corrigido facilmente.

Por exemplo: suponha que estou prestes a testar a existência de um determinado valor em uma certa parte do binário. Essa operação será algo como:

"Este é o valor = x?" Se não, está rachado.

Isso é muito fácil de quebrar. O hacker pode corrigir facilmente o teste e torná -lo sempre verdadeiro.

Estou tentando imaginar algo que poderia testar algo, não aparecendo como um teste que pode ser facilmente corrigido.

Sei que não posso parar 100% de pirataria, mas pelo menos estou tentando tornar as coisas mais difíceis, desencorajar a maior parte dos biscoitos por aí.

Alguma idéia de maneiras de coisas como essa pode ser feita sem e torna as coisas difíceis para alguém que olha para o binário?

Obrigado por qualquer ajuda.

Foi útil?

Solução

Torne difícil para eles avaliar seu esquema e altere seu esquema regularmente. Um exemplo de livro didático é executar a verificação em intervalos ímpares que consumirão tempo para que eles localizem as fontes de suas verificações e todas as referências cruzadas durante o progresso da avaliação da licença. Combine isso com várias verificações e você deve estar definido para a maioria dos lançamentos, basta adicionar uma boa dose de criatividade ao criar seu esquema. Além disso, é um pouco divertido jogar seu jogo; Para fazer com que eles liberem uma rachadura que falha 1 mês após a publicação da rachadura ... ok, isso pode apenas sair pela culatra, mas se você estiver se esforçando para combatê -los em primeiro lugar ...

É uma comunidade interessante; Se você é novo nisso, estudar as comunidades também será benéfico. Como mencionado anteriormente, as rachaduras acontecem para o desafio, algumas versões do produto simplificarão seu esquema de proteção de cópias para 'publicidade gratuita'. Então ... você não pode realmente lutar rachando muito, porque se alguém estiver determinado, isso simplesmente desperdiçará seu tempo e o frustrará. Observar a cultura pode ser interessante. Você provavelmente está na melhor posição se reconhecer que está sendo rachado equivale a 'software popular' e, portanto, deve ser feliz. Você geralmente não deve perder muito sono por causa disso (embora haja obviamente exceções nisso). Além disso, como essa pergunta está listada na categoria MAC: não vou desenterrar estatísticas, mas seu software tem menos probabilidade de receber atenção dos biscoitos se você estiver segmentando o OS X.

Se você é um programador iniciante, o uso inteligente dessas informações (e aceitação) pode ser tudo o que você precisa saber para combater efetivamente os biscoitos.

Outras dicas

A menos que seu software esteja relacionado à segurança, acho que uma abordagem melhor seria alterada para alterar seu plano de licenciamento para tornar o software gratuito para usuários domésticos que mal usam o software e caros para as organizações.

As organizações raramente usam software rachado, devido aos problemas legais, onde os usuários domésticos que são usuários ocasionais não gostam de gastar US $ 100 por usar o software de vez em quando.

Isso levaria a motivação dos biscoitos para quebrar o software.

Não. Lembre -se, (bom) crackers crack software por diversão. Quanto mais elaborado seu esquema de proteção, mais desafiador e divertido será para o cracker. Além disso, as pessoas que provavelmente usarão seu software ilegalmente não pagarão por isso de qualquer maneira, mesmo que não possam obter uma versão rachada. Seu tempo será melhor gasto melhorando seu produto.

Dito isto, você pode impedir a maioria dos biscoitos amadores, retirando seu executável de símbolos de depuração. Você terá que permitir isso nas preferências do projeto.

Todos os esquemas de proteção realmente fortes que estou ciente de uso Código de modificação auto-modificadora extensivamente, de uma maneira ou de outra. No entanto, isso definitivamente não é algo que um programador iniciante deve estar preparado para lidar.

Um perigo é que, se você fizer um esforço excessivo, poderá acabar quebrando as coisas para usuários legítimos. Várias máquinas de arcade da Atari nos anos 80 tinham código que faria várias coisas interessantes se detectasse que a ROM foi alterada. Os efeitos seriam sutis; Por exemplo, um jogo chamado Tempest concederia jogos gratuitos ilimitados se o jogo terminasse quando um jogador tivesse certos valores de pontuação. Na ROM de liberação de Tempest, no entanto, a soma de verificação foi calculada incorretamente, para que todas as máquinas tivessem esse comportamento. Não tenho certeza até que ponto esse inseto afetou os ganhos em máquinas em campo, mas imagino que alguns operadores ficariam bastante chateados ao descobrir.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top