> >> La manipulation inverse, retrouver le code compréhensible depuis le code machine est impossible
>Faux, dans la mesure où l'on peut écrire du code machine directement, juste à l'aide de mnémoniques (quiconque a fait de l'ASM sur HP48 versera une larme nostalgique). Un desassembleur donnera donc le code source.
> Le problème est que l'on perd le recul qui permet de comprendre le « grand design » et que l'on a juste accès à une information dont le grain est trop fin.
La phrase de départ me semble totalement juste : on ne peut remonter au code source à partir du code machine.
Le cas litigieux d'un programme écrit en assembleur n'est à mon sens même pas une exception. D'abord parce qu'il est très rare, et presque toujours sur des portions de programme uniquement. Et ensuite parce que le code source utilise par exemple des macros qui seront pas déductibles du code machine. Enfin, de l'assembleur sans commentaire est vite épuisant. Le code désassemblé est donc différent du code source.
Il y a quelques années, j'ai passé des journées entières sur du code désassemblé (IDA rulez!), dans des débogueurs (Softice) et à écrire de l'ASM i86 (ah, l'apparition du "memory flat mode" sur i286 !). On en vient même à connaître les opcodes (74 03). Mais le code source, c'est plus que des opcodes.
> Mon ordinateur ne comprend pas plus le C que les chiffres
Pas d'accord. Un ordinateur ne comprend que les chiffres. Que tu les représentes en binaire, en hexadécimal ou en décimal ne change rien. Si tu édites un fichier quelconque dans un éditeur hexa, tu ne verras que des chiffres. C'est le rôle de l'ordinateur de traduire, dans certains cas, ces chiffres en instructions.
Le document d'origine n'est pas parfait, mais il ne faut pas aller lui chercher des poux sur les orteils. Surtout quand on n'a pas ses lunettes ;-)
[^] # Re: Commentaires
Posté par rogo . En réponse à la dépêche Le logiciel libre : comment ça marche ?. Évalué à 3.
> >> La manipulation inverse, retrouver le code compréhensible depuis le code machine est impossible
>Faux, dans la mesure où l'on peut écrire du code machine directement, juste à l'aide de mnémoniques (quiconque a fait de l'ASM sur HP48 versera une larme nostalgique). Un desassembleur donnera donc le code source.
> Le problème est que l'on perd le recul qui permet de comprendre le « grand design » et que l'on a juste accès à une information dont le grain est trop fin.
La phrase de départ me semble totalement juste : on ne peut remonter au code source à partir du code machine.
Le cas litigieux d'un programme écrit en assembleur n'est à mon sens même pas une exception. D'abord parce qu'il est très rare, et presque toujours sur des portions de programme uniquement. Et ensuite parce que le code source utilise par exemple des macros qui seront pas déductibles du code machine. Enfin, de l'assembleur sans commentaire est vite épuisant. Le code désassemblé est donc différent du code source.
Il y a quelques années, j'ai passé des journées entières sur du code désassemblé (IDA rulez!), dans des débogueurs (Softice) et à écrire de l'ASM i86 (ah, l'apparition du "memory flat mode" sur i286 !). On en vient même à connaître les opcodes (74 03). Mais le code source, c'est plus que des opcodes.
> Mon ordinateur ne comprend pas plus le C que les chiffres
Pas d'accord. Un ordinateur ne comprend que les chiffres. Que tu les représentes en binaire, en hexadécimal ou en décimal ne change rien. Si tu édites un fichier quelconque dans un éditeur hexa, tu ne verras que des chiffres. C'est le rôle de l'ordinateur de traduire, dans certains cas, ces chiffres en instructions.
Le document d'origine n'est pas parfait, mais il ne faut pas aller lui chercher des poux sur les orteils. Surtout quand on n'a pas ses lunettes ;-)