D'après ce qu'ils disent c'est du SSL donc c'est normal que ce ne soit pas lisible... on peut essayer de décrypter en force brute, mais ça risque d'être long. L'autre solution, qu'ils expliquent un tout petit peu, revient à intercepter des appels au système ou aux bibliothèques: la petite application COM, il y a peu de chance qu'elle fasse elle-même le cryptage, elle doit donc à un moment ou un autre avoir quelque part en mémoire le paquet en clair avant d'appeler la fonction de cryptage, ou utiliser une série d'appel pour construire le paquet (déjà, le deuxième cas voudrait dire que les développeurs se sont bien pris la tête pour rien).
À l'époque ou je bidouillais encore un peu sous Windows, il y avait des debuggers qui permettant de stopper le système à tout moment (un peu comme un noyau Linux qui tourne dans un gdb) et de voir ce qu'il s'y passe. On pouvait placer des points d'arrêt un peu partout, éditer le code en direct, faire des recherches dans la mémoire... et justement, s'il s'agit bien d'un paquet SOAP, il me paraît assez simple (enfin bon, ça ne se fait pas en 1 minute) de trouver un '<SOAP:Enveloppe' dans la mémoire de la petite appli COM. Une fois cela trouvé, il ne reste normalement plus qu'à lire la suite.
[^] # Re: Suuuurpriiiiiise !
Posté par pas_moi . En réponse au journal Suuuurpriiiiiise !. Évalué à 4.
À l'époque ou je bidouillais encore un peu sous Windows, il y avait des debuggers qui permettant de stopper le système à tout moment (un peu comme un noyau Linux qui tourne dans un gdb) et de voir ce qu'il s'y passe. On pouvait placer des points d'arrêt un peu partout, éditer le code en direct, faire des recherches dans la mémoire... et justement, s'il s'agit bien d'un paquet SOAP, il me paraît assez simple (enfin bon, ça ne se fait pas en 1 minute) de trouver un '<SOAP:Enveloppe' dans la mémoire de la petite appli COM. Une fois cela trouvé, il ne reste normalement plus qu'à lire la suite.