Executando verificação de segurança...
7

Obfuscação de código, vocês costumam utilizar?

Neste vasto universo da programação, em algum momento vamos nos deparar com a prática fascinante e, muitas vezes, controversa da obfuscação de código, onde para alguns, é uma técnica valiosa para proteger a propriedade intelectual e dificultar a engenharia reversa e para outros pode parecer desnecessária e até mesmo um despercídio de tempo.

Ao longo de minha jornada como programador, tenho me deparado com situações em que a obfuscação de código se tornou uma opção a ser considerada, particularmente em projetos onde o próprio cliente cuida da infraestrutura e tem acesso total aos artefatos do sistema. (Diferentemente de um SaaS por exemplo, onde os cliente não possuem acesso ao "binário" em si)

Recentemente tive algumas experiências com javascript-obfuscator para JavaScript e IonCube para PHP, e em ambas, sempre após a obfuscação do código, quando rodamos os testes E2E, temos algumas funcionalidades que "param de funcionar", onde temos que reajustar os parâmetros da obfuscação até tudo funcionar corretamente.

Essa configuração leva um bom tempo para deixar liso na pipeline, mas com isso, sempre fico mais tranquilo do que "jogar o código puro" para os clientes, correndo o risco de tentarem fazer uma engenharia reversa encima.

Isso levanta as questões:
Vocês, colegas desenvolvedores, já tiveram experiências com a obfuscação de código?
É uma prática que faz parte regular do seu arsenal de desenvolvimento?
Você já fez ou participou de uma engenharia reversa em algum software?

Carregando publicação patrocinada...
5

Há cerca de 10 anos me deparei exatamente com a mesma situação que você e parti para a mesma solução: ionCube.

Hoje resolvo esse problema da forma mais simples: eu vendo apenas o serviço e mantenho toda a infraestrutura. Se o cliente quiser manter, ele que pague o equivalente a dois ou três anos vezes o valor mensal que eu cobraria. Fim.

Tenho clientes que pagam pelo serviço e me garantem renda recorrente. Tenho clientes que eventualmente compraram o software depois. Todas as partes felizes. Quer o código? Que pague.

É claro que no começo eu tive que me submeter a entregar código praticamente de graça. Cheguei até a ser roubado. Mas faz parte do crescimento. Hoje o meu código é fechado, a menos que o cliente pague por ele.

2

Não vou mentir que hoje é o ponto que eu tenho mais receio de acontecer, roubo de propriedade intelectual.
Eu estou trabalhando há meses em um sistema Saas e tenho receio de sofre com um clone do meu projeto.

2

É um ponto a ser considerado com cuidado, mesmo. Ideias podem ser "roubadas" tranquilamente, pois o que importa é uma boa execução. E o código é parte da execução.

4

Acredito que seja valido, mas não vai impedir que seu codigo seja roubado, pois sempre será possível fazer a engenharia reversa se você tiver acesso ao codigo.

Em meados de 2007 participei de uma equipe que fez a engenharia reversa do código para um microcontrolador PIC. Na época a pessoa responsável pelo código fonte havia deixado a empresa e levado consigo esse codigo, apenas existia o binario que era gravado no microcontrolador.

No começo é dificil, mas a medida que detectamos padrões, e começamos a conseguir nomear variáveis, vai se tornando mais fácil, é um grande quebra cabeças.

3

Infelizmente é comum o cliente roubar propriedade intelectual dos programadores sim.
Principalmente de linguagens como Java, .NET ou caso seja um aplicativo web hospedado no servidor dele, onde ele tem acesso ao código-fonte.
Ouvi o caso de um programador Java onde o cliente não só roubou o código-fonte como ainda mandou e-mail desdenhando, foi um estagiário que escreveu: Fiz engenharia reversa do seu software e tirei o "if" que valida o registro do software e sai do programa. Não precisamos mais pagar mensalidades.
Ele ficou com tanta raiva e rancor que mudou para C++.

2

Eu atuo, principalmente, com mobile e ofuscação de código é "o padrão" nesse cenário. O android tem um ofuscador padrão que já vem ativado sempre que se cria um projeto novo e o iOS faz um processo interno com o XCode que deixa tudo muito mais difícil de fazer eng reversa.

Mesmo nesse cenário, ainda é um assunto que divide muita opinião entre times e clientes, pois é bem comum acontecer o cenário que vc exemplificou, ocorrerem problemas em testes E2E ou até mesmo em runtime, que são causados pela ofuscação do código.
Então, apesar de ser uma ótima prática pensando na segurança e proteção de PI, é mais um cenário onde o depende seja a melhor resposta, pois em alguns cenários, não vale o risco de ter um erro em produção sendo que o que pode ser exposto pode não ser tão 'valioso' assim aos olhos do cliente.