O caso de ofuscação de código?

Um caso de uso muito interessante para a ofuscação é rastrear a origem das cópias ilícitas. Supondo que a ofuscação seja uma operação relativamente barata, o autor original pode fornecer a cada cliente versões ofuscadas do aplicativo, se uma cópia ilícita for encontrada, o autor poderá comparar com as versões fornecidas e rastrear a fonte da pirataria.

Essa é uma forma de esteganografia , inspirada e na variação do "transporte de traidores "esquemas criptográficos . Não faço ideia se é comum ¹ , ou mesmo se é uma boa ideia, mas já o vi aplicado na prática sob os seguintes parâmetros:

• Mercado nacional altamente competitivo com apenas dois fornecedores,
• Cerca de 50 implantações cobriram o mercado,
• O tempo médio de desenvolvimento de ambos os aplicativos foi de dois anos (mais ou menos),
• O tempo médio de ofuscação para nosso aplicativo foi de algumas horas,
• Espera-se que o tempo de vida de ambos os aplicativos seja de aproximadamente dez anos.

O raciocínio foi, obviamente, segurança através da obscuridade inicialmente, e evoluiu no esquema acima mencionado em algum momento ² . Ambos os fornecedores tinham acesso ao código binário do outro, legalmente, e eu acho que é óbvio que as tentativas de decompilação de ambos eram esperadas. A ofuscação não fez nada em termos de segurança, a longo prazo. Ambos os fornecedores tinham equipes altamente motivadas e talentosas, trabalhando em um mercado extremamente lucrativo e de nicho, no final, nossos produtos eram mais semelhantes do que não, e qualquer vantagem competitiva foi obtida através de outros meios menos obscuros.

Eu não posso realmente expandir, porque (a) foi muito cedo na minha carreira e não obtive uma visão clara das decisões de design ou os resultados do esquema de rastreamento (se houver) e (b) alguns do meu envolvimento com o projeto estava sob um NDA.

Outro caso de uso válido para ofuscação pode ser quando você está de alguma forma legalmente obrigado a enviar seu código para terceiros :

If your firm does IP work for technology companies, or is involved in cases involving software source code, you may be obliged to submit your client’s source code to the USPTO, a court or third party.

Since source code is considered a trade secret, most regulatory agencies use a "50%" rule. Source code submitted is obscured so that it cannot be used as-is.

IANAL, e o link é mais relevante para cópias impressas de código, em vez de código de trabalho real, então isso pode ser completamente irrelevante.

Agora, como o Javascript é o exemplo canônico de ofuscação, há um efeito colateral que não é comumente considerado, e isso está escondendo códigos maliciosos no JavaScript ofuscado. Embora haja vantagens definitivas em minar o Javascript, eu não vejo nenhum ponto na ofuscação real e estou feliz. / 06 / minification-v-ofuscação / "> Douglas Crockford concorda comigo :

Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server.

Quanto à ofuscação de "segurança no emprego", esse é um comportamento que nunca deve passar pela revisão de código e, se identificado, não deve ser tolerado. Eu não iria tão longe quanto demitir o culpado no início, mas os ofensores repetitivos definitivamente merecem uma boa palmada, pelo menos.

_{¹ Depois de escrever isto, descobri esta resposta que basicamente descreve o mesmo esquema, por isso pode ser mais comum que eu pensava.
² Embora a esteganografia ainda seja segurança através da obscuridade.
³ Minification ~ removendo espaços em branco e encurtando tokens, não obscurecendo intencionalmente.
⁴ O Concurso Internacional de Código Ofuscado C conta?}

O argumento para ofuscação de código é que ele eleva a barra para um terceiro para determinar o que / como o código está funcionando.

No entanto, isso NÃO significa que um desenvolvedor deve estar escrevendo código ofuscado.

Veja, este é o pouco que eu acho que está faltando em sua pergunta: A ofuscação de código (assim como a minificação do JavaScript) não precisa - e não deve - ser feita manualmente pelo desenvolvedor. Da mesma forma, isso também não deve ser armazenado como arquivos principais de origem no controle de versão.

A ofuscação de código deve acontecer como uma etapa de pós-processamento durante a compilação em sua construção de produção. Há muitos produtos de terceiros para fazer isso também, então não há quase nenhum motivo para fazer isso em casa.

Por exemplo: Dotfuscator

O IEEE tem um artigo sobre a eficácia da ofuscação de código

Results show that identifier renaming significantly decreases the efficiency of attacks, at least doubling the time needed to complete a successful attack (even in the worstcase scenario, i.e., against the best attacker). In addition, obfuscation reduces the gap between novice and skilled attackers, making the latter less efficient, and makes systems that are easier to attack in clear more similar to those that are intrinsically harder to break.

Ênfase minha.

Participei do desenvolvimento de um MMORPG. Isso envolvia a lógica do servidor e a lógica do cliente. Durante todo o desenvolvimento de vários anos do projeto, sempre que considerávamos a interface entre o cliente e o servidor, a regra era que o cliente deveria ser tratado pelo servidor em todos os momentos, sob a suposição de que ele havia sido invadido. Em outras palavras, o servidor tinha que ser escrito de tal forma que não houvesse resposta que pudesse vir do cliente que causasse a falha do servidor ou permitir que o cliente trapaceie. Ainda assim, sabia-se desde o início que os hackers inevitavelmente encontrariam buracos no sistema e os explorariam para enganar. E depois de um tempo eles fizeram.

É claro que, antes de enviar o cliente para o grande mundo lá fora, nos certificamos de ofuscar isso. Acreditamos que a ofuscação teve os seguintes efeitos:

1. Isso impediu que os hackers não especialistas tentassem até mesmo.
2. Demorou hackers especialistas em realizar qualquer invasão.
3. Reduziu o número de hacks obtidos por hackers especialistas.
4. Limitou a eficácia dos hacks.
5. O que é mais importante: fez com que os hackers realizassem mais testes com seus clientes invadidos em nossos servidores antes de conseguir um hack de trabalho, o que aumentava as chances de descobri-los procurando atividades irregulares nos registros do servidor.

Contas de jogos de hackers descobertos foram encerradas sem reembolso, o que tornou o negócio de hacking mais caro e menos atraente.

Os efeitos que a ofuscação teve na manutenção eram quase nulos. Havia alguns lugares onde alguns programadores inexperientes estavam fazendo suposições sobre os nomes dos identificadores (eles estavam usando reflexão), mas uma vez que eles foram resolvidos, tudo estava bem. A etapa de ofuscação acabou se tornando parte da etapa geral de criação da versão de produção do jogo, então a maioria de nós nunca precisou se preocupar com isso ou ter algo a ver com isso. Nós já tínhamos uma ferramenta para ver os logs do jogo, então modificamos a ferramenta para usar a tabela de associação (mapeando identificadores ofuscados para identificadores apropriados) produzidos pelo ofuscador a fim de traduzir os logs para nós na hora, então nunca até mesmo teve que ver quaisquer identificadores ofuscados enquanto fazia exames post-mortem baseados em logs coletados no campo.

Ler e entender (e obviamente escrever) código ofuscado pode ser um desafio mental interessante. Ele provavelmente está fora do escopo do que você estava perguntando, mas exemplos como IOCCC podem ser uma fonte de diversão, bem como de terror.