Eu sei que parece estranho dizer, mas um colega programador no trabalho deliberadamente usou um par de más práticas de programação de propósito! Eu vou explicar. Primeiro, deixe-me dizer que ele é um cara inteligente e, na maioria das vezes, ele escreve um código inteligível.
Ele foi solicitado a implementar o licenciamento em um projeto de aplicativo da Web escrito em Java. Uma vez que é Java, se alguém realmente quisesse, poderia provavelmente abrir os frascos e ler os nomes das classes e métodos escritos dentro. Sua solução para esse problema era literalmente chamar as variáveis e os métodos de nomes pouco óbvios e plantá-los dentro de classes já congestionadas, em vez de gerar novas classes.
Sua justificativa era de que, se um hacker quisesse trocar certas classes para contornar as verificações de licenciamento (e, portanto, obter uma cópia gratuita do produto), ele teria um tempo muito mais difícil se não fosse óbvio quais métodos executam essas tarefas específicas. Só depois de ter feito isso eu o confrontei, sugerindo que talvez pudéssemos comprar algum tipo de biblioteca de obfuscator para fazer isso por nós, mantendo boas práticas de programação. Ele alega não ter tido tempo ou recursos para procurar esse tipo de solução.
.. O que me deixa em um dilema. Eu procuro por uma biblioteca de obfuscator em Java e corrijo seu código antigo (o que pode ser um pouco delicado sobre a remodelação de seu código), ou deixo como está, por mais que isso me irrita até o fim?
Segurança através da ofuscação nunca é uma boa segurança. Deve haver maneiras melhores de proteger sua propriedade intelectual. E é isso que você e seu colega devem mencionar como uma preocupação conjunta com seu gerente. Se a gerência decidir que não quer gastar tempo ou dinheiro em segurança aprimorada, ambos terão que conviver com essa decisão (não é o seu produto, é o produto da empresa) e é melhor não gastar (desperdício?) mais algum tempo sobre o assunto.
Original: O que seu chefe diz? Descubra - faça isso.
Pediram-me para elaborar o texto acima:
Primeiro de tudo, acho que você tem mais de um dilema:
Primeiro de tudo, visto de um caso de negócio o problema IS resolvido. A está no lugar e é - muito provavelmente - uma solução "boa o suficiente" para o problema. Sua empresa pode estar feliz com isso, basicamente, apenas protegida o suficiente para que o esforço deliberado seja necessário para quebrá-la.
Isso significa que, mesmo que você não goste (e, acredite, verá muito pior em sua carreira ), ele faz o que é necessário. Assim, à medida que o problema é resolvido, você não deve "apenas fazê-lo", mas sim convencer a pessoa que está encarregada de atribuir seu trabalho que o preço a longo prazo desta implementação será alto o suficiente para justificar uma reversão e escolhendo um ofuscador de estoque. Isso exigirá um pouco de preparação de você e também notará que obfuscators também têm desvantagens que você precisa saber (outras respostas cobrem isso bem). Por exemplo. rastreamentos de pilha não são imediatamente utilizáveis, etc. Tudo depende de como é importante evitar a pirataria. Observe que o mais difícil de quebrar são aqueles que exigem que os dongles de hardware sejam executados e, provavelmente, são mais caros do que seus clientes gostarão.
Portanto, essa decisão não é sua, já que sua empresa precisa usar recursos adicionais para ir para B. Portanto, é necessário levar suas preocupações à pessoa responsável, explicar isso e qualquer outro termo de longo prazo.Em outras palavras: O que seu chefe diz? Descubra - faça isso.
Note também que isso teria sido diferente se você tivesse levantado a questão antes, para que o desperdício de dinheiro pelo tempo gasto na implementação de A fosse menor. Em outras palavras, quando a escolha entre A e B deveria ser feita.
Por fim, gostaria de comentar sua pergunta sobre "apenas corrigir o código de outras pessoas". Esta não é uma pequena correção para o código existente (o que acho ótimo e incentivado, especialmente com testes no local). É uma reversão e reimplementação disruptiva e, mesmo em equipes com propriedade comum de código, isso não seria aceitável - pelo menos para mim - sem aprovação prévia.
Espero que isso esclareça o meu ponto de vista.
Do I look for a obfuscator library in Java and fix his old code (which might be a little touchy about remodeling his code), or do I leave it as it, as much as that irks me to no end?
Não , voltar atrás de alguém e alterar o código pelo qual eles são responsáveis seria uma ofensa pior do que escrever o código questionável para começar.
Você falou sobre isso com o programador, seu próximo passo é manter o nariz fora disso ou falar sobre o gerenciamento e, então, manter o nariz fora disso.
Houve uma revisão oficial de código de qualquer tipo - ou o confronto teve uma "revisão de código" não oficial? Eu diria que, como esse é um assunto delicado e importante, como segurança e licenciamento, você precisa elevar essa cadeia. Você fez a primeira parte - confrontando o programador. No entanto, agora que ele não está ouvindo, você pode / deve levá-lo para cima. Se você não fizer isso, você pode ser parte do problema.
Eu diria a ele que você vai fazer isso - isso pode mudar sua opinião. Se isso não acontecer, escreva um email muito politicamente correto, ainda que preciso e conciso, sobre a situação para o seu chefe, e CC o programador. No e-mail, solicite uma reunião entre os três e / ou qualquer outra parte participante.
Sempre encontre essas coisas de frente - ainda de forma política e amigável.
Se você puder encontrar um ofuscador que ofusque a assinatura das classes (nomes dos métodos, etc.), bem, proponha-se a comprar e usá-lo.
Até então, você pode ter que viver com isso. Admito fazer algo semelhante em um projeto recente do Grails - as verificações de licença são incorporadas deliberadamente no método de login já grande, por isso seria muito difícil substituir o método para ignorar a verificação.
Ele pode demonstrar que tal hack é viável, ou é apenas um cenário hipotético que ele está preocupado? Ele pode dar uma demonstração ao vivo desse trabalho? Ele deveria tentar. A sério. Se funcionar, ele deve ser apresentado ao gerenciamento e, em seguida, sugerir o obfuscator.
Se um obfuscator não for seguro o suficiente, você já procurou outras formas de proteger o JAR, talvez algo como criptografá-lo ou compilá-lo para código nativo?
RE: refazendo seu código: é apenas uma questão de renomear? Muitos IDEs têm ferramentas de refatoração que podem fazer isso com bastante facilidade.
Independentemente de quão valioso é o seu IP, o inteligente não é manipular seu código na esperança de confundir hackers. Além do fato de que vai ser um pesadelo para continuar, não resolve nenhum problema. Isso só torna mais difícil, mas não impossível. Portanto, não é realmente uma solução e os efeitos colaterais são ruins. É como tomar remédio que não funciona e tem efeitos colaterais ruins.
Seu problema é como proteger seu IP. Encontre uma solução para isso: obfuscators, servidor de licenças, etc.
Eu tive um problema semelhante quando outro desenvolvedor nomeou nossas rotinas de criptografia / descriptografia str__copy e str__delete (observe o segundo sublinhado). Era coxo e poderia ter sido feito melhor, então esperamos até que houvesse uma história em que a atualização do licenciamento fosse necessária. Gestão não teve um problema com o punhado extra de horas, porque nós descrevemos como "limpar para a próxima vez que entrar em licenciamento, vai demorar menos tempo e vai ser mais seguro". Problema resolvido, sem mágoas.
Meu primeiro pensamento foi a manutenção desse código. Se o código já está ofuscado e ele está em frente, boa sorte tentando entender o código. Você será então o hacker tentando decifrar o código.
Em vez disso, recomendo limpar o código e usar um obfuscator para fazer todo o trabalho pesado. A longo prazo, você terá muito código gerenciável e deixará toda a complexidade louca para quem quiser hackear sua licença.
Lembre-se que nenhum obfuscater é perfeito, e um hacker muito determinado pode fazer engenharia reversa de qualquer coisa, mas pelo menos será apenas ele. Além disso, os obfuscaters adicionam muito mais complexidade do que aquele que um cara provavelmente consegue.
Concordo plenamente com as respostas que você deve fazer ao seu chefe sobre o assunto e fazer o que ele diz.
No entanto, um adendo muito importante para essas respostas é que você deve documentar suas preocupações sobre segurança e manutenção. Quer você mude ou não o código, é importante que as pessoas saibam com o que você está preocupado e por quê. Isso é importante tanto de forma proativa (seu chefe não pode tomar uma decisão que ele nem sabe que precisa ser tomada) quanto defensivamente (se / quando um hacker picar buracos no sistema de licenciamento mal garantido, eles não podem culpá-lo por sua erro.)
"Não seja o profissional mais superior para saber de um problema".
Em outras palavras, diga ao seu chefe e vá de lá. Se você ficar quieto e estiver no topo do totum nesse segredo, quando o empurrão chegar, você será o responsável. Diga ao seu chefe de passagem e deixe-o decidir uma maneira de abordá-lo. Dessa forma, você está aliviado do fardo da escolha.
Não diga apenas ao seu chefe, porque muitos gerentes talvez não sejam tão técnicos, mas façam o que sempre fazemos: dar o problema e possíveis soluções com as vantagens / desvantagens de cada uma dessas soluções. Então deixe-os decidir e ter isso passado. É por isso que os gerentes / líderes recebem muito dinheiro!
A verdade é que, com tempo e recursos suficientes, tudo pode ser quebrado. É uma função simples de como o seu aplicativo é popular. Os mais populares são os hackers mais habilidosos que atrai e mais tempo é dedicado a quebrá-lo. O ofuscamento de código fornece apenas isso - um meio de aumentar o tempo necessário para quebrá-lo, semelhante à criptografia. Portanto, se o seu código for ofuscado, é necessário que o atacante seja habilidoso e dedique tempo a ele. Caso contrário, ele se desesperará e desistirá. Você precisa se perguntar se seu aplicativo vale a pena nos dois lados.
É realmente incrível o quão difícil pode ser tornar-se um código ofuscado. Você pode facilmente transformar um simples programa de 10 linhas C em uma montagem de 100 linhas através de ofuscação. Se você tentar depurá-lo, você vai pular sem sentido no código e pode ser realmente frustrante percorrê-lo. Eventualmente, ele vai quebrar, mas torna-se muito difícil e, como nada é realmente impossível, esse é o ponto. O ofuscamento de código reduz o número de pessoas capazes de quebrá-lo.
Claro que existem maneiras melhores, como tentar confundir o depurador não o cracker, mas este é um barato e eficiente. No entanto, nomear as coisas sem jeito não é suficiente. Você precisa alterar funções de chamada de fluxo de controle que realmente não fazem nada para seu código geral, mas aumentam o tamanho ea complexidade dele: chamar funções simuladas cujo valor de retorno não é usado em qualquer lugar, de dentro de funções que realmente fazem alguma coisa. Você já pode ver como isso pode ficar muito confuso.
Você tem algo que o invasor não tem. O código fonte original. Encontre uma maneira de organizar melhor para você.