unix4fun

Yo yo yo.

J'avais une base de code, avec pas mal de fonctions déjà implémentées, et puis je me suis dit "ooooomm, faudrait que je trace le temps d'exécution de chacune de ces fonctions, pour savoir où concentrer mes efforts, en faisant telle et telle stat'". Bon alors je vous entends déjà barir au loin "hey mais pauvre naze, y'a plein d'outils de profiling", et c'est vrai. Seulement je voulais faire un truc à ma sauce d'une part (histoire de voir un peu comment ça fonctionne), et surtout pouvoir ajouter les stats qui m'intéressent, faire des trucs aux p'tits oignons quoi. Et puis c'est pas comme si ça prenait des jours à coder.

Alors après avoir cherché un peu, je tombe sur la doc GCC (même le man en parle, à vrai dire) :

void __cyg_profile_func_enter(void *func, void *callsite); 
void __cyg_profile_func_exit(void *func, void *callsite);

Ces fonctions sont appelées respectivement à l'entrée et la sortie de chacune des fonctions de votre programme. Il y a une linuxerie ensuite pour obtenir le nom de l'appelant, ie. passer par dladdr() ou __build_return_address(0). Ensuite vous stockez les infos comme vous voulez, perso j'utilise une hashtable dont les clefs sont les symboles (aka noms de fonctions), avec chaque cellule contenant des stats, sur le nombre d'appel, le temps d'exécution moyen, etc.

J'ai utilisé ça pour un code sur lequel je passe un peu de temps en ce moment, et la sortie ressemble à (le > correspond à l'entrée dans la fonction, le < à la sortie, faudrait rendre le truc plus joli avec un système de pile pour avoir la profondeur d'appel de chacune en fonction d'un décalage horizontal, mais bon, ça viendra après) :

[...]
1297941768.719531 > dfs_mkdir@0x40f534
1297941768.719607 > dfs_mkdir_timeout@0x41398f
1297941769.416415 < dfs_mkdir_timeout@0x41398f -- 696ms
1297941769.416445 < dfs_mkdir@0x40f534 -- 696ms
1297941769.416469 > dfs_getattr@0x40c16c
1297941769.416684 > dfs_namei_timeout@0x413ef7
1297941769.534098 < dfs_namei_timeout@0x413ef7 -- 117ms
1297941769.534161 > dfs_getattr_timeout@0x413690
1297941770.104592 < dfs_getattr_timeout@0x413690 -- 570ms
1297941770.104874 < dfs_getattr@0x40c16c -- 570ms

                                -- report --
symbol dfs_getattr_timeout: #calls: 46, average call duration: 266ms
symbol dfs_opendir_timeout: #calls: 1, average call duration: 780ms
symbol dfs_namei_timeout: #calls: 47, average call duration: 299ms
symbol dfs_chdir_timeout: #calls: 1, average call duration: 0ms
symbol dfs_mkdir: #calls: 1, average call duration: 696ms
symbol dfs_getattr: #calls: 48, average call duration: 275ms
symbol dfs_mkdir_timeout: #calls: 1, average call duration: 696ms

Le code (crados, pas encore nettoyé) est visible ici. Comme je disais, le truc vraiment sympa c'est juste d'avoir à appeler profile_init() et profile_fini() dans mon code. Et encore, on peut faire mieux en générant un .so qu'on charge avec LD_PRELOAD, histoire d'avoir vraiment 0 code impacté. Faut juste compiler les objets avec -fPIC et -finstrument-functions. That's all folks.

OK c'est un profiler du pauvre, mais ici à unix4fun, on est prolos. Et on vous emmerde !

Un peu de proselytisme ne fait jamais de mal, alors voilà Junkie, un sniffer releasé en Open Source par la société SecurActive.

Pour l'instant il a été programmé pour tourner sur du Linux debian-like, donc...

Un extrait du README:

Compared to previously available tools junkie lies in between tcpdump and
wireshark. Unlike tcpdump, its purpose is to parse protocols of any depth;
unlike wireshark, through, junkie is designed to analyze traffic in real-time
and so cannot parse traffic as completely as wireshark does.

In addition, junkie's design encompasses extendability and speed:

- plug-in system + high-level extension language that eases the development and
  combination of new functionalities;
- threaded packet capture and analysis for handling of high bandwidth network;
- modular architecture to ease the addition of any protocol layer;
- based on libpcap for portability;
- well tested on professional settings.

Il manque un "IPv6 compliant" je pense, dans ce README.

Seuls les parseurs sont releasés en Open Source, mais c'est déjà bien sympa. Le design est fait de telle sorte qu'il est facile d'ajouter un plugin d'analyse pour un protocole particulier 1. Et pour ceux qui n'aiment pas le C, il y a possibilité d'exercer vos talents de codeurs Scheme (guile plus précisemment), car il est scriptable à l'aide de ce langage ! Ouh ouh !

Un petit exemple d'utilisation ? OK, c'est parti :

$ sudo ./src/junkie -i wlan0 -c config/start-repl.scm
2010-12-22 00:36:45: J-main: log.c/log_set_file: Opening log file.

OK, là on lui a dit de loguer sur stdout, d'écouter l'interface wireless wlan0, et de prendre le fichier de conf par défaut qui active le REPL. Donc, dans un autre terminal, je vais me connecter sur la machine, en tcp/29000 pour ajouter des settings sur la mouche comme disent nos amis anglais (ie. "on the fly"... ok c'est nul).

$ rlwrap telnet localhost 29000
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
junkie> (set-iface-filter "wlan0" "icmp")
#t
junkie> (set-log-level 6)
#<unspecified>
junkie>

Les valeurs de retour affichées sont celles de guile, à savoir #t pour true, et #<unspecified> pour dire qu'il n'y a pas de code de retour. C'est un peu curieux au début, mais ceux qui ont utilisé ce langage ne seront pas dépaysés.

Là je lui ai demandé de prendre en compte le filtre BPF (tcpdump, vous connaissez, hein ?) "icmp" pour l'interface wlan0.

Hey ouais, c'est ça qui est cool, on peut écouter sur différentes interfaces avec des filtres différents. Bref, dans un autre terminal je tape :

$ ping free.fr -c1
PING free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=118 time=37.1 ms

--- free.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 37.176/37.176/37.176/0.000 ms

Et si on repasse dans la console de log, on a :

Capture@0x23f0068: head_len=48, payload=60, dev_id=0, tv=1293009623s 788239us
Ethernet@0x2413ea8: head_len=14, payload=46, vlan_id=0, source=00:1b:2f:2e:e0:fa, dest=ff:ff:ff:ff:ff:ff, proto=2054

Capture@0x23f0068: head_len=48, payload=74, dev_id=0, tv=1293009880s 139307us
Ethernet@0x2413ea8: head_len=14, payload=60, vlan_id=0, source=00:1c:bf:9d:2e:21, dest=00:15:e9:f2:30:67, proto=2048
IPv4@0x2414e38: head_len=20, payload=40, version=4, addr=10.0.63.10->82.237.175.5, proto=6, ttl=64
TCP@0x23bcf08: head_len=40, payload=0, ports=42007->1234, flags=Syn, win=5840, ack=0, seq=902941316

Capture@0x23f0068: head_len=48, payload=98, dev_id=0, tv=1293009631s 741103us
Ethernet@0x2413ea8: head_len=14, payload=84, vlan_id=0, source=00:1c:bf:9d:2e:21, dest=00:15:e9:f2:30:67, proto=2048
IPv4@0x2414e38: head_len=20, payload=64, version=4, addr=10.0.63.10->212.27.48.10, proto=1, ttl=64
ICMP@0x23bb198: head_len=64, payload=0, type=EchoRequest, err=NONE

Capture@0x23f0068: head_len=48, payload=98, dev_id=0, tv=1293009631s 744391us
Ethernet@0x2413ea8: head_len=14, payload=84, vlan_id=0, source=00:15:e9:f2:30:67, dest=00:1c:bf:9d:2e:21, proto=2048
IPv4@0x2414e38: head_len=20, payload=64, version=4, addr=212.27.48.10->10.0.63.10 (hashed the other way), proto=1, ttl=122
ICMP@0x23bb198: head_len=64, payload=0, type=EchoReply, err=NONE

Un lecteur attentif verra qu'il n'y a pas que de l'ICMP qui a été logué (cf. les premières lignes). Il a raison ! Mais comme je l'ai dit plus haut, on a changé la config à chaud, donc Junkie a eu le temps de loguer quelques paquets avant de prendre en compte le filtre BPF.

Et voilà ! Bon, c'est un exemple parmi des tonnes hein, chacun peut y trouver son compte, là c'est vraiment pour expliquer le fonctionnement. Pour plus d'infos :

$ junkie -h

Ou bien pour des détails vraiment poussés, dans le REPL :

junkie> (help)
[...]
junkie> (help 'commande)

1 Tutorial de codage d'un parseur : parser implementation

Il y a quelques semaines, une connaissance postait ce truc la en discutant, après avoir jeté un oeil, je ne trouve pas de solution triviale et je me dis bon... c'est juste je suis une quiche en crypto y a un truc incroyable a faire, j'y comprendrais rien... j'apprends ensuite qu'un pote qui mattait aussi l'a pété en 30 minutes... alors bon ok c'est une grosse brute poilue qui a une sorte de "don" pour voir la matrice, mais voilà, ca me fait chier de me sentir comme une merde et pourquoi pas ? je suis peut-être moins mediocre que je pense.

Je me suis dit bon faudra que j'essaye, le temps passe, je tourne autour un peu comme un puceau autour de sa premiere meuf, je flippe et quand je commence a m'approcher, oula trop dur beaucoup trop dur et je rebrousse chemin !

Après quelque temps a tergiverser, à me fouetter et a me sentir comme un clochard, je m'y suis mis hier soir et comme je suis un gros newbie en crypto, je me suis dit que j'allais ecrire comment j'avais attaqué la chose, sans la paperasse de "docteur en crypto" (ou chiffrement, j'en sais rien, j'm'en fous).

Etape 1 - Le probleme

#include <iostream>
#include <cstdlib>

using namespace std;

char *key = "????????";
//char secret[] = "ZJ]]_Y2ec%_hXH]P\\%k_eS2OSW4n\\]f+RJincNUS.QU_eLW].Ngn7F^^.IY17XUSZZYmjJ^!";
//char out[100];

void decrypt(char *secret, char *key){
char c;
char *k = key;
while ((c = *secret) != 0){
*secret++ = (c-32) - ((*k)-64) + 32;
k = *(k+1) ? k+1 : key;
}
}

int main(int argc, char *argv[]){

strcpy(secret, "ZJ]]_Y2ec%_hXH]P\\%k_eS2OSW4n\\]f+RJincNUS.QU_eLW].Ngn7F^^.IY17XUSZZYmjJ^!");
decrypt(secret,key);
cout << "SECRET MESSAGE: " << secret << endl;

return EXIT_SUCCESS;
}

Et là faut retrouver le plaintext.

Etape 2 - C'est quoi ce bordel..?!

On se dit : première hypothèse, si c'est un "challenge" la taille de la clef dans le code source doit bien etre de 8 chars et le "plaintext" doit etre un texte standard en anglais. Ensuite on matte la routine de decryption, on voit que ca "rotate" sur la taille de la key, donc des blocs encrypted de 8 chars à chaque fois, chaque bloc est chiffré avec la même clef.

• c'est un "challenge" donc le plaintext est certainement une phrase, donc des caractères imprimables.
• c'est un "challenge" donc la clef est probablement un mot anglais un truc du genre (vu le language du forum).
• c'est un "challenge" donc le \?\?\?\?\?\?\?\? veut aussi probablement dire que la clef fait 8 bytes"

Etape 3 - Par où je commence !?

Première idée... bon-je-sais-pas-quoi-faire, "when in doubt, use brute force", alors hop on bricole un bruteforcer en carton avec un trombonne, un chewing gum et de l'ammoniac et on se dit que "youpi youpi" dans 10 minutes on a la reponse et pfiou je suis pas trop une grosse tanche comme je pensais, après tout, mon bruteforcer, il est recursif, il verifie que pour chaque byte de clef teste, le "plaintext" sur tous les blocs reste un caractere "possible" (comprendre printable à l'ecran soit entre 0x20 et 0x7D ou 0x7E} et la récursivité arrive pour aller bruteforcer le bytes de clef suivant, si j ai verifié cette condition.

Naif que j'étais je me suis dit... "wai tranquille, devrait pas trop y en avoir", mes fesses wai.. lancant le bruteforce et en loggant dans un fichier, je me suis retrouve avec un file de plus de 18 Go de candidats possibles (./bruteforcer^C^C^C^C^C) qui matchaient mes conditions, pleins de garbage et wai... il fallait tester rien que :

$ bc
bc 1.06.94
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
255^8
17878103347812890625

hmm merde...je pensais pas autant...hmm et pis ma machine est sur les genoux avec tout ça et mon disque en prends plein la gueule... bruteforce..meme apres triturage pas une bonne idée...

Etape 4 - Le *plaign* et le-pote-qui-connaît-la-crypto (tm)

Un vague optimisation apres exposition du problème a votre "local guru crypto", equation bla, limiter le range des bytes a tester, verifier correlations binaire bla, ne pas bruteforcer tout les chars, effectivement, j'enlève un TAS de candidats, je sais plus je crois que j'etais descendu aux alentours des 12 Go pour le file et la aussi ./bruteforcer-DrCrypto^C^C^C^C, bon j'ai aucun bagage en math, ni aucune technique pour trouver des super algo de pétage de crypto, donc hopla retour case depart, ma bite et mon couteau.

Entre temps j'ai dû passer deja 8 heures effectives sur cette connerie...c'etait il y a 1 ou 2 semaines.

Etape 5 - La bonne vieille haine des familles ou l'envie profonde de soumission !

Alors ma bite et mon couteau, hmm j'ai un cerveau, regardons ça de plus pres a nouveau...je me ré-ouvre tout ca (Featuring la grosse haine) hier soir... je regarde curieusement le ciphertext et je commence par le séparer en bloc comme au debut..

ZJ]]_Y2e  c%_hXH]P  \%k_eS2O  SW4n\]f+  RJincNUS  .QU_eLW]  .Ngn7F^^  .IY17XUS  ZZYmjJ^! 

Hmm pas top lisible.. comme ca so..ouais beaucoup mieux..

0 1 2 3 4 5 6 7

Z J ] ] _ Y 2 e    
c % _ h X H ] P 
\ % k _ e S 2 O 
S W 4 n \ ] f + 
R J i n c N U S 
. Q U _ e L W ] 
. N g n 7 F ^ ^ 
. I Y 1 7 X U S 
Z Z Y m j J ^ ! 

Je reviens a mes hypotheses.. je me dis bon, si c'est une phrase, il y aura des espaces et peut etre des virgules, mais pour un challenge mettre de la ponctuation ca me parait chiant.. alors je me dis ok, espaces seulements... ensuite mon oeil est attiré par les 3 . . . sur la colonne du byte 0 de la clef.. en mattant la ligne plus haut je me dis que ca passe pas mal si c'est un espace ca separe bien des mots.., je me bricole vite fait 2 ptits tools a la con... pour bruteforcer la valeur de la clef pour obtenir le plaintext et un autre juste pour encoder 1 byte en lui filant le byte de la clef.

alors, si '.' est un espace quelle est la clef necessaire pour l'obtenir:

$ ./findk . " "
cipher: . -> plain:  
key: 0x4e (N)

Ok "N" bon ca serait eventuellement le premier byte de la clef, c'est possible c'est "printable", on va verifier avec les autres bytes de la meme colonne:

$ ./usek Z N
cipher: Z - N -> plain: 4c(L)
$ ./usek c N
cipher: c - N -> plain: 55(U)
$ ./usek \\ N
cipher: \ - N -> plain: 4e(N)
$ ./usek S N
cipher: S - N -> plain: 45(E)
$ ./usek R N
cipher: R - N -> plain: 44(D)
$ ./usek . N
cipher: . - N -> plain: 20( )
$ ./usek Z N
cipher: Z - N -> plain: 4c(L)

Hmm là je me dis, intéressant, il n'y a pas un seul caractère relou, genre virgule, caractères de contrôles a la noix, #, @ etc... que des chars et étrangement ils sont tous en majuscule. Je me refais une petite ligne :

//char dasecret[] = "ZJ]]_Y2ec%_hXH]P\%k_eS2OSW4n\]f+RJincNUS.QU_eLW].Ngn7F^^.IY17XUSZZYmjJ^!";
//                   =       =       =       =       =       =       =       =       =            
//                   L       U       N       E       D       .       .       .       L          KEY: N???????

Je représente les "espaces" par des "." histoire de rendre ça un peu plus lisible pour mon cerveau de mollusque ! Je reviens sur ma petite matrice de caractères, je matte la colonne #2 et je me dis, tiens les "%" ca pourrait être les espaces du début de la phrase, vu que j'ai trouvé les espaces de la fin de la phrase (enfin je crois), alors j'essaye..

$ ./findk % " "
cipher: % -> plain:  
key: 0x45 (E)
$ ./usek J E
cipher: J - E -> plain: 45(E)
$ ./usek % E
cipher: % - E -> plain: 20( )
$ ./usek W E
cipher: W - E -> plain: 52(R)
$ ./usek Q E
cipher: Q - E -> plain: 4c(L)
$ ./usek N E
cipher: N - E -> plain: 49(I)
$ ./usek I E
cipher: I - E -> plain: 44(D)
$ ./usek Z E
cipher: Z - E -> plain: 55(U)

Et là je me dis, ca sent le mouflon ! J'ai de nouveau que des lettres capitales et le second byte de ma clef est aussi en lettre capitale, ca ne me semble plus etre une coincidence... Yes j'ai 2 bytes de la clef ! NE.. hmm

//char dasecret[] = "ZJ]]_Y2ec%_hXH]P\%k_eS2OSW4n\]f+RJincNUS.QU_eLW].Ngn7F^^.IY17XUSZZYmjJ^!";
//                   =       =       =       =       =       =       =       =       =            
//                   LE      U.      N.      ER      DE      .L      .I      .D      LU         KEY: NE??????

Bon première idée qui me vient en tête, NE, NET ?! 'vais essayer donc "T" pour la 3ème lettre...

//                   LEI     U.K     N.W     ER.     DEU     .LA     .IS     .DE     LUE        KEY: NET????? NET could be a word but..

Alors je cherche des mots anglais commencant par NET (comme NETWORK) pour la clef, mais je ne trouve rien dont la 4ème lettre passe..hmm Ensuite en mattant de le plaintext avec 3 lettres, LEI, DEU, LUE, je trouve pas ou peu de mots en anglais.. j'ai pas ou peu d'idées de comment passer à la prochaine étape, hmm mais j'ai dit que j'allais te soumettre alors tu m'echapperas pas $#@!$#@!$!@$!

Etape 6 - Le breakthrough

Grmlgrmlgrm, quelques verres dans le nez avec une copine, une bonne discussion, du vibe... je rentre chez moi vers 0h00, je mange rapidos, je rouvre mon petit fichier.. et hmm Je commence à douter de ma 3ème lettre... je fais marche arrière pour la 3ème lettre et je réfléchis...

0 1 2 3 4 5 6 7

N E ? ? ? ? ? ?

Z J ] ] _ Y 2 e    
c % _ h X H ] P 
\ % k _ e S 2 O 
S W 4 n \ ] f + 
R J i n c N U S 
. Q U _ e L W ] 
. N g n 7 F ^ ^ 
. I Y 1 7 X U S 
Z Z Y m j J ^ ! 

4ème colonne 3 x n, hmm le coup des espaces peut-être, je retente, groumpf je tombe sur des caractères relous en decodant la colonne.. pas la bonne partie de la clef, je refais la même chose pour le reste... 2x7, 2x_, etc... ca passe pas.. grmlbmlbmb..

Je me dis bon... qu'est-ce que j'ai là.. et je me rends compte que j'ai de nouvelles hypothèses de base sur mes trouvailles précédentes..

• phrase entièrement en majuscules.
• clef entièrement en majuscules.
• 1 byte de clef valide devrait vérifier une colonne entière en majuscule ou avec un espace

Chassez le naturel, il revient au galop : when in doubt, use brute force! Cette fois je bruteforce uniquement 2 blocs de ciphertext, je prends entre 0x41 et 0x5A pour les bytes de la clef, je ne teste que isupper(), isblank() et isdigit() on sait jamais si il y a du "leet speak"..

$ ./bf2 > bf2results
$ ls -la bf2results 
-rw------- 1 eau users 41570100 2010-02-05 01:33 bf2results

Hmm 41 Mo de results, ca va, c'est très très loin des 12 Go, je dois pas être loin! Je matte le contenu :

key: NEITVARW, index: 8 buffer: LETIIX NU VTBGK9N
key: NEITVARX, index: 8 buffer: LETIIX MU VTBGK8N
key: NEITVARY, index: 8 buffer: LETIIX LU VTBGK7N
key: NEITVARZ, index: 8 buffer: LETIIX KU VTBGK6N
key: NEITVBRK, index: 8 buffer: LETIIW ZU VTBFKEN
key: NEITVBRL, index: 8 buffer: LETIIW YU VTBFKDN
key: NEITVBRM, index: 8 buffer: LETIIW XU VTBFKCN
key: NEITVBRN, index: 8 buffer: LETIIW WU VTBFKBN

Bon signe, les candidats font à peu pres tous la meme taille, et y a ces 2 chars partout, ensuite je commence par virer les trucs improbables à coup de grep

$ cat bf2results | grep -v QQ | grep -v GKD | grep -v VXM | grep -v KDN \
   | grep -v K9N | grep -v K8N | grep -v K[0-9]N | grep -v YSN | grep -v EZX \
   | grep -v XTF | grep -v KBN | grep -v NTT | grep -v KCN | grep -v YRF \
   | grep -v SQL
[...]
key: NETYPSRO, index: 8 buffer: LEIDOF VU KOH5KAN
key: NETYPTRK, index: 8 buffer: LEIDOE ZU KOH4KEN
key: NETYPTRO, index: 8 buffer: LEIDOE VU KOH4KAN
key: NETYPURK, index: 8 buffer: LEIDOD ZU KOH3KEN
key: NETYPURO, index: 8 buffer: LEIDOD VU KOH3KAN
key: NETYPVRK, index: 8 buffer: LEIDOC ZU KOH2KEN
[...]

Etape 7 - Finish HIM!!

Et la je me dit tiens c'est bizarre... VU ca veut rien dire en anglais, mais ZU en ALLEMAND.. c'est TO... et la je commence a me dire merde, c'etait pas en anglais, on va verifier... je filtre que les " ZU ", du coup je vois que les 2 derniers bytes de la clef sont toujours "RK" :

key: NEZZWRRK, index: 8 buffer: LECCHG ZU ENA6KEN
key: NEZZWSRK, index: 8 buffer: LECCHF ZU ENA5KEN

Et là ca devient de plus en plus des mots, alors je m'excite, mais peut-être que mon "T" pour le 3ème char était bon !!!!!! Hop hop hop!

$ cat bf2results | grep -v QQ | grep -v GKD | grep -v VXM \
  | grep -v KDN | grep -v K9N | grep -v K8N | grep -v K[0-9]N \
  | grep -v YSN | grep -v EZX | grep -v XTF | grep -v KBN \
  | grep -v NTT | grep -v KCN | grep -v YRF | grep -v SQL \
  | grep " ZU " | grep "key: NET" | wc -l
4146

Je matte vite fait les results :

key: NETZWDRK, index: 8 buffer: LEICHU ZU KNADKEN
__key: NETZWERK, index: 8 buffer: LEICHT ZU KNACKEN__
key: NETZWFRK, index: 8 buffer: LEICHS ZU KNABKEN
key: NETZWGRK, index: 8 buffer: LEICHR ZU KNAAKEN
key: NETZWORK, index: 8 buffer: LEICHJ ZU KNA9KEN

Et là je me dis BORDEL C'EST DE L'ALLEMAND DE MERDE $#@! $#@!$#@!$!#@$#@! Je vérifie sur translate bidule.... "Easy to crack" RAH $#@ $ #@!$ #@! $#@! $ #@!$ #@! Hop je passe le tout avec la super clef que je viens de recover, NETZWERK :

Et voilà le plaintext :

"LEICHT ZU KNACKEN WENN DER TEXT DEUTLICH LAENGER IST ALS DE SCHLUESSEL"

Et sa traduction :

"Easy to crack WHEN THE TEXT IS SIGNIFICANTLY LONGER THAN DE KEY"

Juste pour les relous, il y a certainement 10000321432 moyens de faire mieux et plus simple, les commentaires sont les bienvenus pour les critiques constructives ! N'hesitez pas, c'etait certainement pas la methode la plus élégante, mais c'est passé et le temps effectif passé dessus est de bien une 15 aines d'heures, pas vraiment les quelques jours que je pensais... mais je suis toujours très loin des 30 minutes :)

Enjoy !

wai toujours pareil, un type (poilu) il s'ennuie et il a un clavier drole, mais qui ne marche que sous win32, alors il se dit bon je vais reverser ce $#@!$#@! de driver win32 et faire un driver open avec... gentil et poilu le monsieur, il explique ce qu il a fait ici:

• http://www.jespersaur.com/drupal/book/export/html/21

comme quoi c'est accessible a n'importe qui, meme a des tubbes comme moi... nom de dieu!$#@!$@! :)

Bon ben il a remis le couvert, le bougre. Cette fois, il explique comment fonctionne l'intéraction avec le matériel, via une bibliothèque d'abstration (comment discuter avec le port série, etc).

Le lien, c'est par ici.

Enjoy.

Conficker est un worm recent, il n'est pas aussi "Stealth" que son confrere (qui n'est pas vraiment un confrere mais bon... comme j'ai qu'un panier y a tout dedans) rustock.C mais il fait deja de belles choses sympathiques.

tout ca est analyse la: http://mtc.sri.com/Conficker/

merci dave pour le lien!

Alors dans le cadre de mon job je suis tombé sur un article qui m'intéresse. Peut-être que ça sera le cas pour toi aussi, ami lecteur. La problématique est la suivante : sur des gros liens (Gbps typiquement), comment reconnaître les applications utilisées ? Ça peut être pour un admin, qui cherche à identifier les flux qui circulent sur son réseau, ou autre.

La technique "de base" consiste à inspecter les payloads à la recherche d'une signature applicative (à la snort, ou qosmos en propriétaire et plus exhaustif). Le "hic", c'est que sur des liens chargés, ça rame sa mère. Ou alors faut se payer la super solution corporate pouic pouic de Qosmos à 50KEUR, avec une bécane de 32 procs, des cartes DAG (Endace) d'acquisition et tout le bousin.

Mais nous, chez Unix4fun, on est pauvres, et on pense à la plèble, alors on écarte cette solution. Durant ma visite du Web je suis donc tombé sur un article pas mal, qui explique comment en 4 ou 5 paquets TCP (hors établissement de la connexion, SYN, SYN/ACK, ACK), on peut taguer un flux comme étant telle ou telle application, avec un taux d'erreur acceptable (de l'ordre de 5%). L'idée est évidemment d'utiliser des mécanismes d'apprentissage statistique (chaînes de Markov, etc) ; mais avec ça on n'est pas avancé, le problème étant de mesurer et d'apprendre sur les bonnes métriques. Ici, on s'inquiète uniquement de la taille des payloads, et du "sens" du paquet (client -> serveur, ou serveur -> client), qui est un facteur discriminant supplémentaire, et indépendant du contexte (type de réseau, type d'appli, besoin de performance, etc).

Bref, c'est ma pause déjeuner au bureau, je vais pas m'attarder.

L'article Early Application Identification

La thèse sur le sujet (même auteur principal) : Classification temps réel d'applications sur l'Internet. Elle se lit vite, et la dernière partie est en français, pour madame Michu, mais sans les formules et un peu allégée.