Supposons que je construis un ensemble .NET et que je ne l'ai pas signé avec un nom fort, il est copié à un stockage, puis à un autre, puis il finit dans la production. Si un bit ou deux des matières d'assemblage sont changés accidentellement (un problème matériel ou quelque chose comme ça) est une chance que .NET Runtime ne le remarque pas et considère toujours l'image de montage valide?
3 Réponses :
Vous ne savez pas ce que vous voulez dire par .NET Runtime ne le remarquera pas? .NET Runtime n'exécutera pas la vérification DLL s'il n'est pas fortement signé. Il essaiera de charger la DLL. Si le changement corrompt la DLL, la charge DLL (DLL) échouera.
Les assemblages contiennent le code IL. Supposons qu'il y ait une instruction quelque part dans le code et les bits changent de telle sorte qu'il soit modifié en une autre instruction toujours valide. Runtime sera-t-il juste charger et gérer joyeusement ce code?
Ecrire ce programme:
sn -v yourprogram.exe
Accrochez-vous, cela signifie-t-il que je peux prendre une assemblée signée tierce, modifiez-la de sorte que par exemple certains aspects de celui-ci appelle maintenant à mon code, et cela va toujours bien fonctionner? Quel est le point d'assemblées signées si c'est le cas?
@Davidarno Strong-Name est principalement construit pour résoudre la DLL-Hell ... avec nom fort, vous pouvez avoir plusieurs assemblages avec le même "nom humain" mais qui sont produits par différentes entreprises. Vous pouvez réactiver la vérification de l'assemblage.
Oui, il y a une chance.
Mettons la question sur sa tête.
Puis-je modifier arbitrairement un bit dans l'assembly et toujours l'exécuter / l'utiliser?
Non, beaucoup de bits et d'octets sont lus lors de la charge et de l'exécution et la plupart d'entre eux importent.
Si des textes ou des chiffres, fondamentalement des données, les changements, la possibilité de réduire la chance, mais pas entièrement à zéro, en fonction des données exactes qui ont changé.
La réponse à votre question est-ce que:
Il n'y a aucune garantie de toute façon.
Dépend de la nature de la corruption, où elle s'est produite dans le fichier et si le temps d'exécution décide de vérifier. J'ai vu un bloc de données de 4k dans un assemblage de cadre qui est corrompu et n'affecte pas sensiblement les applications. Nous avons seulement remarqué que quelque chose n'allait pas lorsque certaines constructions ont échoué (la corruption a chevauché une partie de la table des attributs personnalisés, les entraînant de perdre leurs références parents et C # pour voir des paramètres «OUT» en tant que paramètres 'ref').