Donc, Tout le monde sera d'accord pour dire que ::

@del C:\WINDOWS\system32\fichier1.exe
@del C:\WINDOWS\system32\fichier2.exe
...
n'est pas vraiment un virus car : Il n'infecte pas un hôte, ne se reproduis pas par diverses méthodes ( ecrasement / ajout de code ... ) et ne s'envoit pas

Et parce qu'il ne détruit rien non plus, grâce à la restauration système ?

Pour faire plus constructif, je rajouterais que la fonctions ms-dos del ne peut fonctionner que si le fichier est fermé. Ce qui est rarement le cas des fichiers systèmes. La plupart de ces codes diffusés sur des sites de lamz ne sont que théoriques, à l'instar des codes comme "format C:\"  qui ne fonctionnent pas (ici d'abord car la commande format demande une confirmation).

Les virus ne sont pas tabous, mais si tu ne veux rien détruire avec tes connaissances (et je te crois), évite les pseudos du genre DarK-CrasH  Je ne pense pas être le seul à avoir relevé la contradiction entre ton post initial et ton pseudo 

Salut !

Les algorithmes CRC sont très documentés sur le web. Tu trouveras sur developpez.com un descriptif très précis et en français du principe de fonctionnement.

http://dvsoft.developpez.com/Articles/CRC/

Pour ce qui est de la variable mystérieuse valant "edb88320", elle n'a pas du tout été choisie au pif par le concepteur. Voilà un paragraphe explicatif :

There are many C examples of this code around, and they include the
   --  magic constant EDB88320 without comment. This constant has my vote for
   --  obscure constant of the year.  It is not the CRC polynomical.
   --  Just because it bugs me to see it undocumented, here is the derivation.
   --  The CRC polynomial is stated in the standard to be::
   --  x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
   --  If you set a bit for each non-zero x exponent, NUMBERING FROM THE LEFT,
   --  STARTING AT 1 (as hardware designers used to do in the old days before
   --  most current programmers were born) you'd get:
   --     1101 1011 0111 0001 0000 0110 0100 0001 (DB710641)
   --  This *IS* the CRC polynomial.
   --  But C programmers want to squeze the last cycle out of their
   --  code, so instead of XORing with this obvious constant, and then
   --  shifting, and setting the high order bit, they shift, and then XOR with
   --  a shifted constant with the high order bit set..
   --  So the C programmer needs the real CRC constant shifted right one bit
   --  with the high order bit set (since CRC's shift in one bits) so what they
   --  use is:
   --     1110 1101 1011 1000 1000 0011 0010 0000 (EDB88320)
   --  Which is the constant you find in the reference C code.

Source : http://www.cc.utah.edu/~nahaj/ada/crc/png_crc_table_generator.adb.html

J'en profite pour t'avertir qu'il existe différentes versions de CRC32. L'algorithme est le même, seule le polynome change. Méfie toi donc en cherchant de la documentation et ne t'inquiète pas si tu trouves des images différentes avec d'autres sources.

Enfin, pour éclairer Iansus, MD5 utilise bien des "constantes" de départ à partir desquelles il fabrique l'image renvoyée. Il y en a de deux types :
 - Les quatre constantes qui forment l'image "par défaut", avant toute modification. On les trouve en page 3 de la RFC

word A: 01 23 45 67
word B: 89 ab cd ef
word C: fe dc ba 98
word D: 76 54 32 10

Le choix est évident. Il s'agit d'avoir une représentation égale de chaque chiffre.
On trouve d'aillleurs dans d'autres versions :

a = 0x67452301; b = 0xEFCDAB89; c = 0x98BADCFE; d = 0x10325476;

Ce qui montre bien que c'est cette représentation égale qui importe, car seule

l'ordre des chiffres a changée.
Mais MD5 utilise aussi un tableau de 44 entiers auquel il applique des fonctions trigonométriques. C'est la partie que tu as cité dans ton post. En réalité, ces constantes ne sont pas si grandes au départ. Voilà leur vraie valeur de départ, tel que l'algorithme a été conçu :

r[ 0..15] := {7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22}
r[16..31] := {5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20}
r[32..47] := {4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23}
r[48..63] := {6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21}

Et encore, si on observe, on voit qu'il y a des répétitions de séquences. En réalité, les seules constantes de départ sont {7, 12, 17, 22}{5, 9, 14, 20} {4, 11, 16, 23}{6, 10, 15, 21}

Soit dans un autre ordre : {4,5,6,7}{9,10,11,12}{14,15,16,17} et {20,21,22,23}
Rien de bien mystérieux en fait 

Si Iansus n'as pas la même chose dans sa source, c'est simplement que son implémentation contient les constantes après certaines opérations fixes. Les calculs ont été fait à part et les résultats inscrits directement dans la source, pour un léger gain de rapidité 

J'avais complètement décortiqué le fonctionnement de md5() il y a pas mal de temps, je crois que je vais essayer de retrouver mes notes pour les partager ici.

J'espère que les liens t'aideront et que c'est maintenant un peu plus clair 

geogeo, je pense quand même que ça vaille le coup d'aller voir la police. C'est sûr, concrètement, il ne s'agit que d'un compte msn, mais le phishing et quand même largement connu et répréhendé. Alors si en plus Gelope met en avant le fait que ce compte contient des informations pouvant lui causer des dommages financiers, ils bougeront peut-être le petit doigt.

En tout cas, quelque soit la réponse, ce ne sera pas du temps perdu car ça te permettra (et à nous aussi par la même occasion) de savoir ce qu'il en est réellement de la lutte contre le piratage.

J'espère en tout cas que tu vas au moins tout récupérer, ça frustrera au moins de se faire retirer le compte wow de la bouche.

Tout à fait hisoka69, et donc "xgscc" signifie toujours "salut", mais avec une clé de 5.

Il est d'ailleurs inutile de coder quoi que ce soit pour percer la clé, l'applet d'Ars Cryptographica suffit si on triche un peu...

on décode xgscc, puis axgscc, puis aaxgscc, puis aaaxgscc, etc... jusqu'à ce que les 5 dernières lettres du message décrypté aient une signification. La clé correspond alors au nombre de "a" qu'on a ajouté devant le message crypté.

Bonne initiative tout de même, DomJ 

Des fonctionnaires et des profs... Mais où va NewbieContest  ?

Bon personnellement, je suis un terminale S de plus ici... Pour intégrer un fac de droit après (non non ce n'est pas de faute de frappe  )

 

Tout a fait normal, tu es sur la bonne voie, tu t'es juste un peu raté dans ton injection... Revoie-là, et tu obtiendras une chaîne de cette même longueur significative, mais comprenant des caractères hexadécilaux cette fois 

Moi je sais 

83 est un nombre premier, et sa racine carrée (environ 9,11) est plus proche de 7 que de 6

Mais je doute que ça suffise pour supplanter CommComm 

[difficulté]

serait il possible que les épreuves soient classées suivant un ordre de difficulté ?

Un ordre de difficulté ? On peut difficilement faire plus subjectif ! Par exemple, je peux trouver une épreuve de logique facile parce que j'ai vu la leçon à appliquer le jour même en maths, alors que je trouverais une stegano compliquée. Pareil, en ce qui concerne les programmations, si je ne connais pas Java, je vais avoir beaucoup plus de difficulté à faire les deux épreuves de java que les autres qui utilisent ce language, etc, etc...

Le nombre de validations n'est certes pas un sysème de classement parfait (il n'en existe pas), je crois que le nombre de validation est encore le meilleur indicateur de difficulté d'une épreuve (il faut aussi prendre en compte la date de parution pour les épreuves très recentes.

'jour les challengers

J'ai moi aussi un petit problème pour valider l'épreuve : j'ai trouvé les failles et compris la manip à executer. J'ai uploadé le script de Romano sur mon compte free et mon exploitation marche très bien (free me marque que la fonction validation() n'a pas été déclaré donc j'en juge qu'il a essayé de l'executer). Par contre quand je teste ça sur le site de l'épreuve, ça ne semble pas marcher

Je ne comprends pas du tout d'où ça peut venir, alors si une âme charitable pouvait me contacter par MP pour comparer mon mode opératoire avec le sien, ça m'aiderait beaucoup

si tu veus savoir les récupérer, contact en mp.

J'imagine que tu dépouilles les tables sensibles avec un UNION non ?

Concernant le BF de ce code, ce n'est pas plus compliqué que de brute-force un MD5 dans la théorie, seulement il te faudra trouver l'équivalent de cette fonction encrypt() dans un language compilé que tu maîtrises, et ça c'est beaucoup plus délicat...

Tout a fait exact s3th  Les caractères constituants et le nombre de bits correpondent.

hamaliceck, j'imagine que ce code a été calculé à partir de la fonction SQL Encrypt(). Le salt a l'air d'être ZJ. Si tu veux faire un mini brute-force, tu peux tester quelques combinaisons manuellement en executant sur une base SQL:

Code:

SELECT ENCRYPT('pass testé','ZJ')

Sans indiscretion, où as tu trouvé ce code ?

- inutile de demander si une épreuve fonctionne ou pas.

Si le mot de passe te paraît hashé, il paraît normal d'essayer d'obtenir le pass en clair non ?

MyBrain = Mon Cerveau

Tu sais où le trouver;)

s3th avait très bien compris, rassure-toi (étant donné qu'ici on fait cette blague en moyenne deux fois par jour)

Envoi moi un petit mp, je te dirais si tu es bien sur la bonne voie

Changer la signature virale de chaque fichier c'est legerement disproportionné^^

Norton dispose bel et bien de l'exclusion du scan :
 - Clic-droit sur l'icone de Norton dans le systrai
 - "Configurer Norton". Tape ton pass si tu en a mis un
 - Dans le menu de droite clique sur "Auto-protect" (tout en haut)
 - Sélectionne "Exclusion"
 - Exclu de l'autoprotect "tonfichiermalveillant.exe". Tu peux également bannir de l'exclusion un répertoire ou une extension particulière.
 - Valide et ferme.

http://img164.imageshack.us/img164/566/nortonexclusionls0.png