Tenho estudado materiais relacionados ao DotNet recentemente e sscli é realmente uma coisa boa: P.
Enquanto estudava, sintetizei o conhecimento e fiz essa pequena ferramenta.
O princípio de proteção é semelhante ao remotesoft e ao maxtocode chineses. O programa criptografado também precisa ser acompanhado por uma biblioteca de tempo de execução quando for lançado.
No entanto, ao contrário desses dois, a biblioteca de tempo de execução incluída não é uma DLL nativa pura, mas um assembly híbrido C++/CLI.
A ferramenta tomou forma e a estrutura geral do kernel foi concluída. Usado para criptografar uma amostra e funciona normalmente.
Alguns aspectos excedem até o maxtocode.
1. Não depende dos programas ildasm e ilasm da Microsoft.
Tanto a desmontagem quanto a montagem do IL são implementadas programaticamente.
Assemblies contendo código nativo podem ser criptografados.
2. Ferramenta anti-descompilação, montagem criptografada maxtocode não pode ser visualizada diretamente com o refletor, mas depois de executar o programa, use o pedumper e, após o despejo, você pode usar o reflectotr para visualizar a estrutura.
A montagem criptografada pelo dnguard é melhor do que eu esperava. A montagem criptografada não pode ser visualizada com o refletor e a montagem despejada não pode ser visualizada com o plug-in do refletor.
Acho que o refletor ainda está um pouco fraco. Softwares semelhantes, Disa# e Xenocode fox, podem abrir e visualizar diretamente os assemblies criptografados do maxtocode e do dnguard.
Para tanto, tentei adicionar ofuscação estrutural ao assembly criptografado do dnguard. Teve um efeito, ou seja, ao visualizar a estrutura em Disa# e fox, haverá alguma confusão, ou seja, funções da classe A podem ser exibidas. na classe B. O efeito não é muito bom, existem apenas algumas funções em cada classe que podem causar problemas.
3. Os novos recursos do Anti .Net 2.0 não são muito fortes. A força é semelhante à do maxtocode 3.13 (Ouvi dizer que o maxtocode lançou 3.14. na resposta no blog de Jason, parece ser igual a 3.13). Max 3.12 pode ser usado corrigindo apenas alguns bytes, e a reflexão 3.13 não é muito diferente, e o número de bytes necessários para correção é ainda menor que o 3.12.
Existe agora uma solução melhor neste sentido, que pode aumentar muito a intensidade sem afetar a eficiência. Mas não pode impedir completamente os despejos.
Existe também uma solução anti-dump relativamente perfeita, que precisa ser implementada em conjunto com outra tecnologia de proteção.
Não planejamos discutir esse aspecto em profundidade. Após a conclusão do shell de criptografia DNGuard, iniciaremos outra tecnologia de proteção e, finalmente, combinaremos as duas proteções.
4. Use ildasm e ilasm para restaurar a montagem após o Anti dump. Além dos novos recursos anti-dump do anti .net 2.0, o DNGuard também adiciona o anti, um dumper que fiz nos primeiros dias. Além disso, o recurso de montagem híbrida C++/CLI também é usado para evitar ildasm após o dump. No entanto, isso não é muito forte e pequenas montagens podem ser facilmente reparadas para implementar a montagem IL.
Ainda há muito trabalho a ser feito. O algoritmo de criptografia ainda não foi elaborado e a proteção da biblioteca de tempo de execução em si ainda não foi feita. Descobri que você pode encontrar ferramentas de proteção prontas para DLLs puramente nativas, como thmida, o que é muito bom. A biblioteca de tempo de execução do maxtocode usa esse shell, mas nunca consegui encontrar um bom método para DLLs C++/CLI. . Parece que só podemos adicionar manualmente uma camada de proteção e já começamos a testá-la. Agora vamos adicionar um shell de criptografia simples. Depois de concluído, colocaremos uma demonstração do DNGuard nele.
Após o DNGuard criptografar a montagem, use o refletor para visualizar:
Use o refletor para visualizar o dump do assembly criptografado do DNGuard:
A montagem criptografada pelo Maxtocode é visualizada com o Reflector:
Depois de despejar o assembly criptografado do Maxtocode, visualize-o com o Reflector:
