<i>> Rien ne t'empeche de connecter un debugger et voir quelle cle est utilisee, hooker ton debugger et chopper les infos avant qu'elles soient cryptees et envoyees.
Ah oui mais là ça n'a rien à voir. Pour "hooker" ton débuggeur il faut bien que tu accèdes aux programmes de la machine, à sa RAM, et que tu saches où aller chercher la clé en RAM. Avec un protocol de chiffrement correct, sniffer les packets sur le réseau ne t'avance à rien (sinon le procédé de chiffrement ne vaut pas une cacahuète). Donc on en revient au problème: comment fais-tu pour savoir identifier la clé de chiffrement (qui peut être générée aléatoirement) sans savoir comment le programme de chiffrement fonctionne, sans avoir accès à son code source, avec seulement un binaire sans symboles de debug?
<i>> MS te file meme un soft pour detourner les API Win32
Je ne vois pas le rapport, la clé peut être générée en C standard, sans faire un seul appel à l'API Win32, tout ce que verra l'API Win32, c'est le flux crypté, ni plus ni moins que ce qui transite par le réseau.
<i>> hors les sources de Windows sont dispo
Non. Toujours pas vu la couleur. Dispo pour certaines personnes peut-être. Mais j'imagine que ces personnes doivent signer de jolis accords de non-divulgation avant de les lire ces sources? Ont-ils le droit de pointer les failles de sécurités, les bugs, les oeufs de pâques, les backdoors dès qu'ils tombent dessus, et de les rendre publique? J'en doute. Auquel cas le fait que ces gens aient accès au code source ne nous avance pas beaucoup car s'ils ont découvert des choses ignobles ils n'ont peut-être pas eu l'occasion de nous faire part de leur expérience...
[^] # Re: Quand microsoft s'invite un peu trop à l'école !!
Posté par ufoot . En réponse à la dépêche Quand microsoft s'invite un peu trop à l'école !!. Évalué à 5.
Ah oui mais là ça n'a rien à voir. Pour "hooker" ton débuggeur il faut bien que tu accèdes aux programmes de la machine, à sa RAM, et que tu saches où aller chercher la clé en RAM. Avec un protocol de chiffrement correct, sniffer les packets sur le réseau ne t'avance à rien (sinon le procédé de chiffrement ne vaut pas une cacahuète). Donc on en revient au problème: comment fais-tu pour savoir identifier la clé de chiffrement (qui peut être générée aléatoirement) sans savoir comment le programme de chiffrement fonctionne, sans avoir accès à son code source, avec seulement un binaire sans symboles de debug?
<i>> MS te file meme un soft pour detourner les API Win32
Je ne vois pas le rapport, la clé peut être générée en C standard, sans faire un seul appel à l'API Win32, tout ce que verra l'API Win32, c'est le flux crypté, ni plus ni moins que ce qui transite par le réseau.
<i>> hors les sources de Windows sont dispo
Non. Toujours pas vu la couleur. Dispo pour certaines personnes peut-être. Mais j'imagine que ces personnes doivent signer de jolis accords de non-divulgation avant de les lire ces sources? Ont-ils le droit de pointer les failles de sécurités, les bugs, les oeufs de pâques, les backdoors dès qu'ils tombent dessus, et de les rendre publique? J'en doute. Auquel cas le fait que ces gens aient accès au code source ne nous avance pas beaucoup car s'ils ont découvert des choses ignobles ils n'ont peut-être pas eu l'occasion de nous faire part de leur expérience...