Torrey’s method encrypts software code such that it’s only decrypted by the computer’s processor at the last possible moment before the code is executed.
La méthode de chiffrement de Torrey chiffre le code de sorte à ce qu'il soit déchiffré par le processeur le plus tard possible avant que le code ne soit exécuté.
Oui, ça risque d'être pénible... mais, le code qui déchiffre ne sera pas chiffré, sinon le processeur ne pourra pas déchiffrer le reste. Ou alors il faudra un processeur particulier, mais compte tenu du fait que le marché ne sera pas inondé avec un tel processeur d'ici, minimum, 5 ans (temps de conception, de production de masse, puis de se répandre sur le marché... ouai, 5 ans c'est pas déconnant) d'ici là des méthodes pour casser le système auront été trouvées.
Les cracker créerons des outils pour dumper le code segment par segment, je n'en doute aucunement, et seront capable de recréer le vrai binaire.
Et le must, c'est qu'avec un truc pareil, ben, le binaire cracké, en plus d'être plus simple à utilisé, aura des perf plus élevées: pas de besoin de chiffrer/déchiffrer le code en permanence.
Je n'ai pas peur de la trouvaille du monsieur, personnellement. Les types qui font du RE sont loin d'être des imbéciles. Le mieux, c'est que dans l'article, il se la raconte tout le long... sauf au dernier paragraphe, ou il liste plusieurs moyens de contourner son truc, sans parler du ralentissement de "seulement 2%" du programme. Si toute la pile logicielle d'une machine, genre, un smartphone, se prend du 2% et 2% et 2%... ça risque de piquer sévère à la fin. Sur un smartphone? Huhu...
Mouai. Ah, et il oublie autre chose aussi: brute-force. Le code déchiffré sera toujours exécutable pas vrai? Alors, supposons que quelqu'un trouve le moyen de déterminer la taille des portions chiffrées, qu'est-ce qui empêcherai de faire une bonne vieille attaque par brute-force?
Je crois que ce genre de choses, il y avait une légende urbaine au sujet de MS+intel voulant l'implémenter... du temps de longhorn me semble?
[^] # Re: Pas libre
Posté par freem . En réponse à la dépêche Le projet Libre OS USB a besoin de vous. Évalué à 2.
La méthode de chiffrement de Torrey chiffre le code de sorte à ce qu'il soit déchiffré par le processeur le plus tard possible avant que le code ne soit exécuté.
Oui, ça risque d'être pénible... mais, le code qui déchiffre ne sera pas chiffré, sinon le processeur ne pourra pas déchiffrer le reste. Ou alors il faudra un processeur particulier, mais compte tenu du fait que le marché ne sera pas inondé avec un tel processeur d'ici, minimum, 5 ans (temps de conception, de production de masse, puis de se répandre sur le marché... ouai, 5 ans c'est pas déconnant) d'ici là des méthodes pour casser le système auront été trouvées.
Les cracker créerons des outils pour dumper le code segment par segment, je n'en doute aucunement, et seront capable de recréer le vrai binaire.
Et le must, c'est qu'avec un truc pareil, ben, le binaire cracké, en plus d'être plus simple à utilisé, aura des perf plus élevées: pas de besoin de chiffrer/déchiffrer le code en permanence.
Je n'ai pas peur de la trouvaille du monsieur, personnellement. Les types qui font du RE sont loin d'être des imbéciles. Le mieux, c'est que dans l'article, il se la raconte tout le long... sauf au dernier paragraphe, ou il liste plusieurs moyens de contourner son truc, sans parler du ralentissement de "seulement 2%" du programme. Si toute la pile logicielle d'une machine, genre, un smartphone, se prend du 2% et 2% et 2%... ça risque de piquer sévère à la fin. Sur un smartphone? Huhu...
Mouai. Ah, et il oublie autre chose aussi: brute-force. Le code déchiffré sera toujours exécutable pas vrai? Alors, supposons que quelqu'un trouve le moyen de déterminer la taille des portions chiffrées, qu'est-ce qui empêcherai de faire une bonne vieille attaque par brute-force?
Je crois que ce genre de choses, il y avait une légende urbaine au sujet de MS+intel voulant l'implémenter... du temps de longhorn me semble?