AllCrypter : Raymond, si tu nous lis... (très long mais définitif)

Bon...

Dans divers de tes posts, tu maintiens qu'il n'est pas vrai qu'il soit
possible de reconstituer tes clés lorsque celles-ci sont sauvegardées avec
le texte chiffré. J'ai essayé de te prouver le contraire, mais, tu n'en
crois rien.

À ta décharge, tu peux toujours arguer que je n'ai montré comment faire que
pour 32 bits. Pourtant, nombreux ici pourraient te confirmer que cela n'a
aucune espèce d'importance : quand c'est cassé, c'est cassé, point.

Je passe sous silence le fait que tu as insinué que j'ai triché ou utilisé
je ne sais quel diabolique logiciel brute-forceur qui saisit lui-même les
clés de manière exhaustive dans le champ de saisie de ton logiciel (!).
J'espère simplement, au passage, que tu te rends compte de l'impossibilité
de cette dernière hypothèse, ou alors, tes connaissances en programmation
Windows doivent être bien sommaires...

Mais bon, passons.

Voici donc un petit cours gratuit de comment craquer les clés d'un logiciel
bancal. Le tien, donc.

Tout d'abord, sache que je ne vais travailler que sur un ensemble de valeurs
{a,z}. Comme tu le comprendras à la fin de ce texte (si tu as bien assimilé
la méthode), cela n'est en rien un raccourci ou une magouille, tu peux
choisir l'ensemble de valeurs de la taille que tu veux, la méthode
fonctionne (il suffit d'ajuster les paramètres adéquats). Simplement, pour
la clarté de l'exposé, je me restreins à un "petit" ensemble.

Bien. Allons-y ! Heu, on m'a demandé de détailler plutôt que de filer du
code direct. Je vais faire mon possible. Au fait, je passe de l'hexa au
décimal et vice versa sans cesse hein, sois attentif au contexte.

En fait, c'est très simple. Ton idée de stocker la clé et tellement
grossière, que le simple diffing suffit. Cela, j'espère que tu t'en étais
rendu compte dans les divers .pdf que j'ai écrit et dont les liens figurent
dans divers posts.

Partons sur un exemple de 48 bits, soient 6 caractères. Le nombre de clés
possible est 26^6, soit 308.915.776 (je parle en caractères, pas en bits,
faisons simple). Avec un simple PC moderne, tu peux brute-forcer sans trop
de soucis, mais usons de plus de malice.

On va observer les variations d'octets dans tes résultats chiffrés. Pour
plus de commodité, je chiffre un fichier vide, je n'ai ainsi que la clé
chiffrée à étudier.

Pour être exact, tes fichiers chiffrés contiennent d'abord un court libellé
:

LogiciPC_AllCrypter

Suivi d'un saut de ligne : 0Dh 0Ah

Et d'un séparateur : 31h 31h

Les octets de la clé suivent alors. Si la clé est de longueur N, il y a 2*N
octets pour la clé chiffrée. Pour être exact, il semble que l'octet
2*N-1serve également, soit à coder le premier caractère des données à
chiffrer, ou a un rapport avec la longueur de la clé, etc. peu importe.

Dans ce qui suit, je ne traite donc que des octets de la clé (chiffrée),
notés z0, z1, z2, ..., z(2*N-1)

Pour 48 bits, on a 12 octets, de z0 à z11 (ça va Tweakie, c'est assez
détaillé là ;o) ? ).

Je commence par chiffrer une clé que j'appelle "vide", puisque je suppose
que c'est la référence de ton codage. Une clé composée de 6 caractères
espace (code ASCII 0x20h). Pour plus de facilité de lecture, je note le
caractère "espace" par "-".

J'obtiens les 12 octets suivants (hexa) :

81 83 85 87 89 ... 97

donc, pour la clé ------ j'ai 81 83 85 ... 97.

Remarque 0 : cela va de +2 en +2. Houlala, très très mauvais ça.

Dès maintenant, je nomme org[0], org[1], ..., org[2*N-1] ces valeurs.

Je vais maintenant chiffrer la clé a----- puis -a----, puis --a--- et ainsi
de suite jusqu'à -----a. Un seul caractère étant modifié à la fois. On note
évidemment que certains octets sont modifiés, il s'agit, encore plus
évidemment, des octets concernant le caractère "a" déplacé à chaque test.

Pour la clé a-----, sont modifiés les octets z0, z10 et z11.
Pour la clé -a----, sont modifiés les octets z1, z2, z8 et z9.
Pour la clé --a---, sont modifiés les octets z3, z4, z6 et z7.
Pour la clé ---a--, sont modifiés les octets z4, z5 et z6.
Pour la clé ----a-, sont modifiés les octets z2, z3, z7 et z8.
Pour la clé -----a, sont modifiés les octets z0, z1, z9 et z10.

Il suffit de refaire l'expérience avec une taille de clé de 4 (32 bits), 8
(64 bits), 10 (80 bits), etc. On remarquera toujours ce même schéma :

Pour le caractère en première position 3 octets utilisés.
Pour le caractère en position N/2 + 1, 3 octets.
Pour les autres caractères 4 octets.

Visuellement, par exemple pour 64 bits, ça donne ça (à afficher si possible
en police de largeur de caractère fixe...) :

a------- x - - - - - - - - - - - - - x x
-a------ - x x - - - - - - - - - x x - -
--a----- - - - x x - - - - - x x - - - -
---a---- - - - - - x x - x x - - - - - -
----a--- - - - - - - x x x - - - - - - -
-----a-- - - - - x x - - - x x - - - - -
------a- - - x x - - - - - - - x x - - -
-------a x x - - - - - - - - - - - x x -

Les vieux routiers du diffing sont déjà morts de rire mon ami :-). Tu
commences par un biais de -1 puis, par exemple en partant de la gauche,
chaque fois tu décale de 2 octets. Quand c'est négatif (position 1) tu
supprimes, quand les deux sens (gauche et droite) se croisent, t'inverse et
tu supprimes 1 aussi.

Mais le plus beau n'est pas là. On peut noter que, verticalement, il y a
toujours 2 croix. Sauf à un endroit. Et c'est là l'erreur qui va permettre
de passer :-). Tu ne vois pas pourquoi ?

Poursuivons.

Pour commencer notons A0_0, A0_1 et A0_2 les octets concernés pour le
premier caractère de la clé.
A1_0, A1_1, A1_2 et A1_3 ceux du caractère en seconde position de la clé.
A2_0, A2_1, A2_2 et A2_3 ceux du caractère en 3e position et ainsi de suite,
jusqu'à A5_0, A5_1, A5_2 et A5_3 pour le caractère en 6e position de notre
exemple de clé de 48 bits.

Je fais là oeuvre utile pour ceux qui auraient envie de recoder le tout en
passant par des matrices. Moi, j'ai eu la flemme. Pour être d'une honnêteté
sans faille, j'avais pas que ça à foutre non plus...

En regardant le schéma plus haut, tu vois que, toujours pour 48 bits, les
octets zi sont "concernés" comme suit (ne prends pas le signe = au premier
degré) :

z0 = A0_0 + A5_0
z1 = A1_0 + A5_1
z2 = A1_1 + A4_0
z3 = A2_0 + A4_1
z4 = A2_1 + A3_0
z5 = A3_1
z6 = A2_2 + A3_2
...
z10 = A0_1 + A5_3
z11 = A0_2

L'erreur est donc en z5. Elle se décalera de deux positions pour chaque clé
incrémentée de 16 bits, donc, z7 pour 64 bits, z9 pour 80 bits, etc.

Note, au passage, qu'un seul octet intervient aussi pour z(2*N-1). Mais,
comme dit plus haut, cet octet est utilisé pour autre chose également, donc,
on ne le traite pas comme l'autre.

Le fait que z5 n'utilise qu'un octet va nous permettre d'inverser le tout.
Hein ? Quoi ? Ben oui. Réfléchis.

Suppose que je sache comment déterminer les octets Ai_j d'un caractère.
Prenons par exemple A3_0, A3_1 et A3_2, les octets correspondant au 4e
caractère de la clé. Suppose que leur calcul est unique, par exemple, pour
un A3_1 donné, il ne peut y avoir qu'un seul A3_0 et un seul A3_2 (heu bon,
pour les puristes, au modulo près). Eh bien on peut inverser !

z5 me donne A3_1
A3_1 me donne A3_0 et A3_2 (on verra comment plus tard).

z4 et A3_0 me donnent A2_1
z6 et A3_2 me donnent A2_2

et ainsi de suite !

C'est une première erreur d'avoir laissé cet octet "solitaire".

Il faut d'abord savoir déterminer les Ai_j d'un caractère. Seconde erreur,
tu t'es pas foulé.

Prenons le caractère 'a', code ASCII 97. Il sera codé (seul) suivant une
formule à la noix :

(('a' - 32 (code ASCII du caractère espace) )*Coeff + org[i]) modulo 256.

Par exemple, pour la clé a-----, le premier octet du a, A0_0 vaudra :

((97-32)*3 + org[0]) % 256 = 44h

Le second octet de a-----, A0_1, vaudra :

((97-32)*1 + org[10]) % 256 = D6h

Le dernier octet, A0_2 vaudra :

((97-32)*4 + org[11]) % 256 = 9Bh

On enlève le code ASCII du caractère espace puisque c'est le caractère de
base (supposé, mais bon, je doute que tu te serves de caractères inférieur
au n° 32 tout de même).

Mais d'où sortent les valeurs des coefficients ? D'abord, pourquoi avoir eu
cette idée. Ben parce que ça fait 22 ans que je hacke mon ami, alors, au
bout d'un moment, tu vois vite quel genre de "formule" est utilisée,
carrément à l'oeil nu (surtout dans des cas simples comme ici). C'est le
fameux CK[i] = a*K[j] + b exprimé par Tweakie (enfin, un truc du genre) dans
un autre post.

Pour les valeurs des coefficients, il fallait d'abord espérer que tu n'aies
pas rusé et qu'ils soient fixes... C'est bien le cas, nouvelle erreur donc !

Pour déterminer leurs valeurs, c'est simple. Tu refais les mêmes
manipulation qu'avec les clés a-----, -a----, --a---, etc., mais avec
b-----, -b----, --b---, ..., -----b et tu notes les écarts.

Par exemple, pour b-----, A0_0 vaut 47h, donc, +3. A0_1 vaut C5h, donc +1 et
ainsi de suite.

Évidemment tu testes pour c-----, ..., -----c et pour 64 bits tu refais
pareil. tu notes que c'est constant. La larme à l'oeil de joie, tu notes
donc le résultat.

Pour les 3 octets du premier caractère, les coeffs sont +3 +1 +4.
Pour les 3 octets du caractère (N/2)+1, les coeffs sont +1 +4 +3 (bien la
ruse, j'ai passé 1 heure dessus...)
Pour les 4 octets des autres caractères, les coeffs sont +1 +3 +1 +3.

Cela sent le roussi non ?

Il nous reste à déterminer dans les équations :

z0 = A0_0 + A5_0
etc.

le "sens"du signe "=", quelle opération tu concoctes entre les deux octets
Ai_j et Ak_p pour obtenir zx.

Nouvelle erreur, du classique, du grand classique. Comme je te l'ai montré
dans un post ailleurs, c'est de la forme :

z0 = A0_0 + A5_0 - k

La constante k vaut 7Fh - 100h (pour le modulo) - 2xi. i étant le numéro de
l'octet zi.

Par exemple :

z0 = A0_0 + A5_0 + 7F - 100h, ou

z9 = A1_3 + A5_2 + 7F - 100h - 9*2.

Ce coup-ci, c'est cuit ! On peut tout remonter. Bien sûr, il y a les
problèmes de modulo, les collisions possibles, etc. En fait, quand tu
hackes, ce qui compte c'est le résultat pratique. Suppose qu'à cause des
modulo, collisions, etc. j'obtienne 10% de faux-positifs, que veux-tu que
cela me fasse ? Je peux hacker 90% de tes clients. Le hack réel, se soucie
peut d'une exactitude théorique hein :-).

Il reste bien sûr à programmer tout ça. L'idéal, serait de le faire sous
forme matricielle, systèmes linéaires, tout ça quoi. Je n'en ai pas le
temps. Tout ceci m'a déjà coûté mon dimanche après midi et, ce qui compte
avant tout, c'est de te montrer que je ne te mens pas.

Aussi, comme de toute façon tout ce que j'ai expliqué ci-dessus se "déplie"
très bien, je te donne un exemple "déplié" pour les clés de 80 bits. Courage
:-).

Tout d'abord, je précise que le premier caractère de la clé sera cherché par
brute-forcing. Juste pour le fun. C'est le dernier qui est retrouvé et ça ne
prend qu'une boucle de 26 itérations (pour notre ensemble {a,z} de cardinal
26).

Les caratères de la clé reconstruire sont noté i0, i1, i2, etc. i0 étant
toujours le dernier cherché.

Pour 80 bits, l'octet faible est z9. Voici comment on determine les octets
correspondant :

A5_1 = z9;

i5 = ( A5_1 - 0x97 ) / 4 + 'a';

A5_0 = ( org[8] + (i5-32) ) % 256;
A5_2 = ( org[10] + (i5-32) * 3 ) % 256;

Remarque 1) Le 0x97 est une valeur qui permet de determiner, par rapport à
la possition du zi de départ (ici z9), la valeur de 'a'. C'est 97h pour 80
bits, 93h pour 64 bits, 8Fh pour 48 bits, etc. On va de 4 en 4 par 16 bits,
ou de 2 en 2 pour 8 bits. te souviens-tu du +2 de la remarque 0 :-) ?

On commence par i5, le 5e caractère de la clé à trouver puisque z9 est sur
la ligne du 6e caractère de la clé (revois le schéma avec les x et les -
plus haut).

Une fois qu'on a i5, on passe à i4 :

A4_1 = z8 + org[8] - A5_0;
A4_2 = z10 + org[10] - A5_2;

i4 = ( A4_1 - 0x52 ) / 3 + 'a';

A4_0 = ( org[7] + (i4-32) ) % 256;
A4_3 = ( org[11] + (i4-32) * 3 ) % 256;

Remarque 2) Le 0x52 est la seconde (et dernière) constante à initialiser.
Même rôle que pour le 0x97 de la remarque 1) ci-dessus, 0x52 pour 80 bits,
0x4E pour 64 bits, 0x4A pour 48 bits, etc. Pour chaque ix qui va suivre,
t'enlève +2 (cela devrais te dire quelque chose maintenant).

Après i4, i6. Pour comprendre l'ordre des i6, c'est simple, trace le schéma
avec les x et i pour 80 bits et par de z9. Puis remonte les lignes, un coup
au-dessus de z9 un coup au-dessous, un coup au-dessus, un coup au dessous,
etc.

A6_1 = z7 + org[7] - A4_0;
A6_2 = z11 + org[11] - A4_3;

i6 = ( A6_1 - 0x50 ) / 3 +'a';

A6_0 = ( org[6] + (i6-32) ) % 256;
A6_3 = ( org[12] + (i6-32) * 3 ) % 256;

Le 0x50, c'est 0x52 - 2 (remarque 2).

Et ainsi de suite !!!

Voici le code intégral. Pas de panique, oui, c'est codé à l'arraché en une
grosse demi-heure. C'est pour prouver, pas pour gagner un oscar... Alors,
inutile de venir me dire qu'on peut largement simplifier, merci.

#include <windows.h>
#include <conio.h>
#include <stdio.h>

#define NK 10

void main(void)
{
char keyToFind[] = "E1E1CB9CA7AADCBBA1979DB3D6E0AFBEC3FD05";
int z0 = 0xE1;
int z1 = 0xE1;
int z2 = 0xCB;
int z3 = 0x9C;
int z4 = 0xA7;
int z5 = 0xAA;
int z6 = 0xDC;
int z7 = 0xBB;
int z8 = 0xA1;
int z9 = 0x97;
int z10 = 0x9D;
int z11 = 0xB3;
int z12 = 0xD6;
int z13 = 0xE0;
int z14 = 0xAF;
int z15 = 0xBE;
int z16 = 0xC3;
int z17 = 0xFD;
int z18 = 0x05;
int z19 = 0xDF;
char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int
A0_0,A0_1,A0_2,A1_0,A1_1,A1_2,A1_3,A2_0,A2_1,A2_2,A2_3,A3_0,A3_1,A3_2,A3_3,A4_0,A4_1,A4_2,A4_3,A5_0,A5_1,A5_2,A6_0,A6_1,A6_2,A6_3,A7_0,A7_1,A7_2,A7_3,A8_0,A8_1,A8_2,A8_3,A9_0,A9_1,A9_2,A9_3;
int
K00,K01,K02,K03,K04,K05,K06,K07,K08,K09,K10,K11,K12,K13,K14,K15,K16,K17,K18,K19;
int i;
int i1,i2,i3,i4,i5,i6,i7,i8,i9;

for ( i = 0; i < 2*NK; i++ ) org[i] = 129 + i*2;

A5_1 = z9;

i5 = ( A5_1 - 0x97 ) / 4 + 'a';

A5_0 = ( org[8] + (i5-32) ) % 256;
A5_2 = ( org[10] + (i5-32) * 3 ) % 256;

A4_1 = z8 + org[8] - A5_0;
A4_2 = z10 + org[10] - A5_2;

i4 = ( A4_1 - 0x52 ) / 3 + 'a';

A4_0 = ( org[7] + (i4-32) ) % 256;
A4_3 = ( org[11] + (i4-32) * 3 ) % 256;

A6_1 = z7 + org[7] - A4_0;
A6_2 = z11 + org[11] - A4_3;

i6 = ( A6_1 - 0x50 ) / 3 +'a';

A6_0 = ( org[6] + (i6-32) ) % 256;
A6_3 = ( org[12] + (i6-32) * 3 ) % 256;

A3_1 = z6 + org[6] - A6_0;
A3_2 = z12 + org[12] - A6_3;

i3 = ( A3_1 - 0x4E ) / 3 +'a';

A3_0 = ( org[5] + (i3-32) ) % 256;
A3_3 = ( org[13] + (i3-32) * 3 ) % 256;

A7_1 = z5 + org[5] - A3_0;
A7_2 = z13 + org[13] - A3_3;

i7 = ( A7_1 - 0x4C ) / 3 +'a';

A7_0 = ( org[4] + (i7-32) ) % 256;
A7_3 = ( org[14] + (i7-32) * 3 ) % 256;

A2_1 = z4 + org[4] - A7_0;
A2_2 = z14 + org[14] - A7_3;

i2 = ( A2_1 - 0x4A ) / 3 +'a';

A2_0 = ( org[3] + (i2-32) ) % 256;
A2_3 = ( org[15] + (i2-32) * 3 ) % 256;

A8_1 = z3 + org[3] - A2_0;
A8_2 = z15 + org[15] - A2_3;

i8 = ( A8_1 - 0x48 ) / 3 +'a';

A8_0 = ( org[2] + (i8-32) ) % 256;
A8_3 = ( org[16] + (i8-32) * 3 ) % 256;

A1_1 = z2 + org[2] - A8_0;
A1_2 = z16 + org[16] - A8_3;

i1 = ( A1_1 - 0x46 ) / 3 +'a';

A1_0 = ( org[1] + (i1-32) ) % 256;
A1_3 = ( org[17] + (i1-32) * 3 ) % 256;

A9_1 = z1 + org[1] - A1_0;
A9_2 = z17 + org[17] - A1_3;

i9 = ( A9_1 - 0x44 ) / 3 +'a';

A9_0 = ( org[0] + (i9-32) ) % 256;
A9_3 = ( org[18] + (i9-32) * 3 ) % 256;

//-- i0 par brute force

key[NK] = '\0';

key[1] = i1 - 32;
key[2] = i2 - 32;
key[3] = i3 - 32;
key[4] = i4 - 32;
key[5] = i5 - 32;
key[6] = i6 - 32;
key[7] = i7 - 32;
key[8] = i8 - 32;
key[9] = i9 - 32;

for ( i = 'a'; i <= 'z'; i++ )
{
key[0] = i - 32;

A0_0 = ( org[0] + key[0] * 3 ) % 256;
A0_1 = ( org[18] + key[0] ) % 256;
A0_2 = ( org[19] + key[0] * 4 ) % 256;

K00 = (A0_0 + A9_0 - org[0]) % 256;
K19 = A0_2;

K01 = (A1_0 + A9_1 - org[1]) % 256;
K02 = (A1_1 + A8_0 - org[2]) % 256;
K03 = (A2_0 + A8_1 - org[3]) % 256;
K04 = (A2_1 + A7_0 - org[4]) % 256;
K05 = (A3_0 + A7_1 - org[5]) % 256;
K06 = (A3_1 + A6_0 - org[6]) % 256;
K07 = (A4_0 + A6_1 - org[7]) % 256;
K08 = (A4_1 + A5_0 - org[8]) % 256;
K09 = A5_1;
K10 = (A4_2 + A5_2 - org[10]) % 256;
K11 = (A4_3 + A6_2 - org[11]) % 256;
K12 = (A3_2 + A6_3 - org[12]) % 256;
K13 = (A3_3 + A7_2 - org[13]) % 256;
K14 = (A2_2 + A7_3 - org[14]) % 256;
K15 = (A2_3 + A8_2 - org[15]) % 256;
K16 = (A1_2 + A8_3 - org[16]) % 256;
K17 = (A1_3 + A9_2 - org[17]) % 256;
K18 = (A0_1 + A9_3 - org[18]) % 256;

wsprintf(keyTemp,"%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X",K00,K01,K02,K03,K04,K05,K06,K07,K08,K09,K10,K11,K12,K13,K14,K15,K16,K17,K18);

if ( 0 == strcmp(keyTemp,keyToFind) )
{
for ( i = 0; i < NK; i++ ) key[i]+=32;

printf("\ntatatata tataaaaa! found! key = %s",key);

i = 'z';
}
}

printf("\nThe end!");

while ( !_kbhit() ) ;
}

Comment ça marche ? C'est simple !!! Une main innocente (si, si, je te jure
c'est pas moi qui rentre la clé, je ne la connais pas !) a crypté un texte
avec une clé de 10 caractères avec AllCrypter. Dans keyToFind[], tu rentres
les octets de la clé cryptée contenu dans le fichier chiffré obtenu. Et tu
rentres ensuite isolément dans les variables ki les octets séparés. Ha je
l'ai dit, c'est codé à l'arrache (si un volontaire veux améliorer...) !

keyToFind ne contient pas le dernier octet de la clé chiffré, z19, pour les
raisons expliqués ailleurs, c'est inutile de le tester.

Dans l'exemple ci-dessus, les octets fournis par AllCrypter sont :

E1 E1 CB 9C A7 AA DC BB A1 97 9D B3 D6 E0 AF BE C3 FD 05 et DF

Si tu veux, je fourni un lien vers le fichier chiffré pour que tu puisse
faire les tests toi-même et enfin me croire ?

Tu lances le programme, il mouline moins d'une seconde et affiche :

tatatata tataaaaa! found! key = xviveamcdx

Tu rentres cette clé "xviveamcdx" dans ton logiciel, du décrypte et
t'obtiens, dans le fichier en clair :

"Populus me sibilat, at mihi plaudo Ipse domi simul ac nummos contemplar in
arca"

Voilà. Du 80 bits cassé. 26^10 c'est 1.41 E14 clés alpha possibles. Et il
faut moins d'une seconde.

Donc, si tu as bien saisi les propos, je peux te craquer une clé de 1024
bits si tu veux, et sur l'ensemble {ASCII(32),ASCCI(255)} si ça te chante.
Toujours en 1 seconde...

Enfin convaincu que :

1) Je ne suis pas un âne ;
2) Je ne mens pas ;
3) Ton soft est mou du genou.

Oui ?

Pour l'anecdote, sur une échelle de difficulté de 1 à 100, je donne 2,5 à
ton soft. Tu vois, t'as de la marge encore... Au passage, avec des hooks et
compagnie, on peut aussi massacrer ton soft. Enfin bon, hein, moi, ce que
j'en dis...

Voilà, si un courageux veux généraliser ce code pour N, dépister les gags de
modulo, les collisions, libre à lui. Ce serait intéressant quand même. S'il
le désire, j'ai les "dépliés" pour 32 bits, 48 bits, 64 bits, etc. Moi,
j'arrête là. J'ai été suffisamment clair et ai passé assez de temps sur ton
soft faiblard, point trop n'en faut non plus. Surtout gratuitement...

Si cette dernière preuve ne te suffit pas, ne te convainc pas, je ne peux
plus rien pour toi.

Voilà, j'espère qu'il n'y a pas trop d'erreurs de frappe et que tu louera
mon altruisme légendaire (gnhihihi)...

Bien cordialement.

PS : merci à Tweakie pour l'illumination qui a jailli en moi après avoir
discouru du a*K[j] + b... Ce + b m'a fait patiner un moment, avouons-le ;-).

--
AMcD®

http://arnold.mcdonald.free.fr/