typedef struct header
{
	unsigned char action:4, compress:4;
	unsigned char csum;
} t_header;

typedef struct body
{
	unsigned short int orientation;
	unsigned short int pos_x;
	unsigned short int pos_y;
} t_body;

typedef struct message
{
	t_header head;
	t_body body;
} t_message; /* 8 bytes */

Notre message ressemble a ça :

|action|compress|csum|orientation|pos_x|pos_y|

Nous allons simuler le déplacement d’un personnage imaginaire suivant le chemin tracé ci-dessous (sur l’axe des x et des y).

Notez que sur le premier tronçon, le personnage ne change pas d’orientation et que sur les deux derniers il s’oriente aléatoirement. Il y a une dernière étape non visible sur le tracé et pour cause, le personnage ne bouge plus, il se contente juste de regarder à droite et gauche suivant son envie (aussi connue sous le nom “la pause du campeur”). Avec cette simulation nous allons voir de manière immédiate quel est l’intérêt de la delta compression. Vous me direz que je tourne autour du pot depuis le début, et bien c’est vrai. Prenons juste le paquet présenté plus haut.

|action|compress|csum|orientation|pos_x|pos_y|

Supposons que je le compare avec celui envoyé précédemment ou autrement dit p(t) avec p(t-1). Nous ne touchons pas à l’en-tête du paquet, mais seulement aux trois derniers champs. Ainsi si le personnage n’a pas bougé, une opération comme p(t) – p(t-1) nous donnera :

|action|compress|csum|

La delta compression est une technique basée sur la comparaison avec les précédents envois. Elle part du principe qu’il ne sert à rien de renvoyer une information qui n’a pas changé. Si l’on refait un exemple avec des valeurs numérique cette fois:

t-1 : |action|compress|csum|60|10|10| (personnage regardant à 60° et positionné en (10,10))

t : |action|compress|csum|60|15|10| (personnage regardant à 60° et positionné en (15,10))

Le paquet résultant sera :

|action|compress|csum|15|

Et là, vous devez immédiatement vous demander comment le destinataire va pouvoir recomposer le message original. Et bien grâce au champ de bits “compress”. Plongeons dans l’algorithme.

bool Network::Compress(unsigned short int *orig_arg, unsigned short int *old_arg, unsigned short int* current_ptr, int *len, char *mask)
{
	// true if no compression
	bool inc = false;
	// search changed
	if(*orig_arg != *old_arg)
	{
		// put it in buffer
		memcpy(current_ptr, orig_arg, sizeof(*orig_arg));
		*len += sizeof(short int);
		inc = true;
	}
	else
	{
		// save unchanged
		*mask += 1;
	}

	// shift
	*mask <<=1;

	return inc;
}

Déroulons l’algorithme dans l’ordre d’exécution. Les deux premiers arguments sont les mêmes paramètres séparés d’un intervalle de temps. Dans l’exemple précédent pour pos_x, les valeurs 10 et 15. Si ces deux valeurs sont différentes, la delta compression ne s’applique pas. On place la dernière valeur dans le buffer du message qui sera envoyé par un socket (en augmentant la taille du buffer de la taille de l’argument ajouté). La partie intéressante est juste après. Si les deux arguments avaient été égaux, on aurait juste ajouté 1 à la valeur du BITMAP. Et dans les deux cas nous décalerons ensuite. Le BITMAP permet de dire à l’autre bout qui devra recomposer le message quel morceaux ont été enlevé ou non. Je vous rappel que mon champ ‘compress’ tient sur 4 bits. Reprenons l’exemple précedent.

t-1 : |action|compress|csum|60|10|10| (personnage regardant à 60° et positionné en (10,10))

t : |action|compress|csum|60|15|10| (personnage regardant à 60° et positionné en (15,10))

Je compare 60 et 60. C’est égal donc je delta compresse. J’ajoute un au mask et je décale à gauche. Donc compress = ’0010′ Je prends ensuite 10 et 15 qui sont différents. Je ne delta compresse pas mais je décale encore une fois à gauche. Donc compress = ’0100′. Pour le dernier cas, 10 et 10, je delta compresse également. Donc compress = ’1001. (vous remarquerez le bug de mon implémentation, le deuxième zéro est faux car je n’aurai pas du décaler pour le premier passage). Pour corriger l’exemple disons que le résultat obtenu est compress =’0101′. Comme nous n’avons que 3 arguments, nous ne regardons que les trois derniers bits. Un 1 signifie que l’argument a été compressé et un 0 non. Ainsi le serveur sait en recevant ce message que pour le reconstituer il doit insérer les arguments désignés par les 1 (autrement dit, le premier argument et le dernier). L’algorithme complet donne ceci:

int Network::Send(t_message *message)
{
	char *snd_buffer;
	int snd_len = 0;

	if(delta_compress)
	{
		// can be allocate just one time, simpler to do it here dynamically
		snd_buffer = (char *)malloc(sizeof(t_message));
		snd_len = 2*sizeof(char);

		unsigned short int *current_ptr = (unsigned short int*)(snd_buffer + snd_len);

		// copy header into buffer
		memcpy(snd_buffer, &(message->head), snd_len);

		// change mask
		char mask = 0x00;

		if(Compress(&(message->body.orientation), &(old_message.body.orientation), current_ptr, &snd_len, &mask)) current_ptr++;
		if(Compress(&(message->body.pos_x), &(old_message.body.pos_x), current_ptr, &snd_len, &mask)) current_ptr++;
		if(Compress(&(message->body.pos_y), &(old_message.body.pos_y), current_ptr, &snd_len, &mask)) current_ptr++;

		// set new mask
		snd_buffer[1] = mask;

		// save (new) old buffer, we save the whole message but we can only save the body since compression only apply to it
		memcpy(&old_message, message, sizeof(t_message));

	}
	else
	{
		snd_buffer = (char*)message;
		snd_len = sizeof(t_message);
	}
	sendto(sock, snd_buffer, snd_len, 0, (struct sockaddr*)&sout, sizeof(struct sockaddr));

	if(delta_compress) free(snd_buffer);

	return snd_len;
}

La classe Network qui encapsule toute la logique permet de désactiver la delta compression (symbolisée par le booléen delta_compress). Voilà rien d’extraordinaire, j’ai quand même réussi à laisser passer un beau bug sur le bitmap. En terme de performance et d’optimisation de la bande passante, les résultats sont assez bons: Ce graphique représente la taille de messages (en octet) dans le temps. On distingue très nettement les 4 paliers (avancer sur x, diagonale en tournant, avancer sur x en tournant, immobile en tournant). La ligne rouge représente la même expérimentation sans delta compression (on retrouve bien la taille de 8 octets de notre message). On aperçoit des variations dans les 3 derniers paliers à cause du caractère aléatoire de la rotation. Calculons un ratio de compression juste pour avoir quelques chiffres tangibles. Chaque palier est constitué de 200 échantillons. Le pire des cas envoie donc 800*8 octets = 6400 octets. En oubliant les oscillations et en conservant le pire des résultats avec la delta compression, nous obtenons 4*200 + 8*200 + 6*200 + 4*200 = 4400 octets. Soit un ratio de 4400 / 6400 = 68% donc 32% de compression. Bon, ce n’est pas vraiment représentatif de l’activité réelle d’un joueur mais c’est tout de même un beau résultat. Surtout que dans le cas d’un si petit paquet, une compression de type Inflate (Zlib) était à proscrire car l’overhead de l’en-tête de zlib est déjà de 4 octets (au minimum).

Le but du jeu était à partir d’une image découpée en segments et réarrangée aléatoirement, de retrouver l’ordre original en régénérant l’image. L’analogie était faite avec un broyeur de documents qui découpe les feuilles de papier en des lamelles de tailles égales.

On voit bien les lamelles ici.

Après un peu de sang et de larmes, on arrive à cela.

Il se trouve que j’ai été sélectionné dans le groupe A (le groupe des winners mesdames et monsieurs). Je vais donc recevoir un superbe t-shirt, et pour la peine ça mérite un article.

Voici comment je m’y suis pris.

Je choisis une lamelle de l’image (dans les faits, la première à gauche mais cela n’a pas d’impact sur l’algorithme). Je cherche la lamelle à sa droite parmi toutes les autres. Pour ce faire je compare le bord droit de ma première lamelle avec le bord gauche de l’autre. Comparer un bord veut dire comparer pour une même hauteur le pixel de gauche et de droite.

for y in range(self.source_image.size[1]):
    # compare left pixel and right pixel with tolerance
    pixel_left = shred_left.get_right_pixels(y)
    pixel_right = shred_right.get_left_pixels(y)

    # score is a flat number (clarity)
    score += abs(pixel_left[0] - pixel_right[0])
    + abs(pixel_left[1] - pixel_right[1])
    + abs(pixel_left[2] - pixel_right[2])
    + abs(pixel_left[3] - pixel_right[3])

Dans les deux premières lignes, je récupère les pixels des bords. Je lis mon image en RGBA (Red, Green, Blue, Alpha). Ceci veut dire que chaque pixel est représenté par 4 valeurs, les 3 couleurs et sa transparence.

Ainsi, si deux pixels sont semblables, la soustraction de l’un avec l’autre devrait tendre vers 0.

Pour chaque pixel comparé, j’en retire un score (soustrayant chaque composante ensemble et en les sommant pour passer d’un vecteur à un scalaire).  Je n’oublie pas d’en tirer à chaque fois la valeur absolue pour ne pas fausser le résultat.

Ainsi, si deux pixels sont proches, leur soustraction tend vers 0, donc leur score sera petit. Ayant comparé toutes les lamelles entre elles, la bonne voisine est celle qui a le score le plus bas. Et ainsi de suite.

Cette approche m’a permis de réunifier avec quelques erreurs le dessin du dessus. Lorsque dans le commentaire du code je précise “with tolerance”, cela veut dire que je n’ai pas réellement comparé deux pixels entre eux. Et oui j’ai menti. Regardons le code des “get_left_pixels” (le code pour le pixel de droite est identique).

def get_left_pixels(self, y):
    """
    Given a height, get the average left pixel.

    """

    pixels = []

    for i in range(0, self.magic_average):
       pixels.append(self.get_pixel_value(self.x + i, y))

    average_pixel = reduce(self.get_average_pixel, pixels)

    return average_pixel

Au lieu de récupérer un seul pixel, je moyenne un nombre de pixels donné sur la même ligne (le nombre de pixels étant symbolisé par magic_average). La moyenne est effectuée par “get_average_pixel” et aidée d’un reduce parce que moi aussi je connais la programmation fonctionnelle, non mais. J’ai déterminé ce magic number de manière très empirique et sa valeur est trois. Point. Plus, vous augmentez les erreurs, moins, ce n’est pas assez. Tout simplement.

Vous vous dites, tu es sympa coco, ton article bien long, il commence à me fatiguer (ou bien tu t’es déjà arrêté de lire mais tu programmes surement en Java). Et bien ce serait dommage de s’arrêter de lire maintenant car l’algorithme ne résout pas encore le problème. Paradoxalement c’est la partie sur laquelle j’ai passé le plus de temps.

Pour l’instant, nous sommes incapables de déterminer la première lamelle de la dernière !

Et oui, le début n’est pas au début et la fin n’est pas à la fin, comme si l’image avait été coupée en deux. Naïvement je pensais qu’en conservant tous les scores et en choisissant comme début et fin les deux lamelles qui avaient eu le score le plus improbable (donc le plus haut) seraient les deux bords. A priori, les bords n’ayant pas de voisin par définition, le côté trouvé doit vraiment avoir un score haut. Et bien pas du tout. Et oui j’étais aussi déçu que vous.

J’ai donc fait ça.

while(len(self.shred_ordered) < len(self.shred_list) and loop):
    # search neighbor while all shred are not ordered
    current_shred = local_find(shred)

    # must not be possible
    assert(current_shred not in self.shred_ordered)

    if seek_right:
        # check if it is a good fit with its left side
        left_shred = self.find_left(current_shred)

        if left_shred.x != shred.x:
             # it is the right border
             loop = False

Je lance l’algorithme pour rechercher tous les voisins de droite successifs des lamelles. Pour m’assurer que ce n’est pas un bord, je cherche aussi à voir si le voisin de gauche de la lamelle potentiellement voisine de droite (vous suivez ?) est bien la même. Sinon, c’est un bord. Dans le code cela se caractérise par la dernière condition où je compare les abscisses des deux lamelles (j’identifie les lamelles par leurs abscisses du point en haut à gauche). “local_find” est dans l’exemple un pointeur de fonction sur “find_right”, ceci m’a permis de factoriser le code pour permettre la recherche à gauche et à droite dans la même fonction (symbolisé par le booléen seek_right).

Juste pour la beauté du geste, j’utilise une liste pour stocker les lamelles ordonnées (“shred_ordered”). Voici l’algorithme à son plus haut niveau d’abstraction.

# peek the first shred to start
self.shred_ordered.append(self.shred_list[VAR_START_WITH])
# order from left to right
self.order_shred(True, self.shred_ordered[-1])
# reverse to order from right to left
self.shred_ordered.reverse()
self.order_shred(False, self.shred_ordered[-1])
# reverse again to get the original order
self.shred_ordered.reverse()

Je renverse juste l’ordre de la liste avant de changer le sens de la recherche. Finalement je renverse une dernière fois cette liste afin qu’elle soit correctement lue par la fonction de sauvegarde de l’image ordonnée (sinon l’image aurait eu un effet miroir assez dérangeant).

Voilà, je me suis bien amusé et vous ?

Le code source de la chose est disponible sur mon github -> c’est par là et ça s’appelle Shreddator !

Nous étions 5 au début mais on dira que nos effectifs se sont sérieusement émoussés au fil des heures et que, finalement, je me suis retrouvé seul à valider mes challenges. Malheureusement, un certain jb a planté son serveur Windows 2008 en voulant charger une base Active Directory et une certaine école d’ingénieurs (INSA) bloque des (enormement est un euphémisme) ports de son réseau à ses étudiants, ce qui réduit leur potentiel (hein seb ). Ce sont les dommages collatéraux du weekend ! Mention spéciale au wiki intégré de redmine qui permet facilement de synchroniser et de garder une trace de sa progression.

Chaque catégorie comporte 3 challenges qui vont crescendo en difficultés. Les défis webs étaient tous des challenges avec injection sql. Nous avons identifié tous les points d’injections mais malheureusement nous sommes des buses en ce qui concerne la rédaction des requêtes. On me souffle dans l’oreillette qu’il est possible de dumper les schémas de la base de données (ce qui rend les choses beaucoup plus faciles, thx dr. obvious). La forensic se résume à l’étude d’image de la ram. La cryptographie: pas de grosses surprises non plus mais là encore aucun succès. Pour le reverse engineering, il y avait une rom de nintendo DS à cracker et une application android que j’ai reverse On en reparle plus bas.

Je vais décrire dans ce qui suit les techniques que j’ai employées pour résoudre les 3 challenges qui nous ont permis de finir 41eme (ce qui fait 550 points, le max étant 1200 sans compter les bonus). For lulz and glory. voir le classement

Dernière chose, si vous voulez vous aussi tester ce que je dis ou faire parler votre talent naturel (sisi) un mirroir des épreuves se trouve à cette adresse.

Forensic100 ou comment trouver un mot de passe de serveur VNC

Le but du jeu est de retrouver le mot de passe d’un serveur VNC (RealVNC). Pour cela, on nous fournit l’image de la ram de la machine sur laquelle tourne ce serveur. Etant un complet néophyte dans le domaine, je demande à mon Laurent préféré (le mec qui m’a fait aimer la discipline mais vous vous en foutez et je raconte ma vie comme je veux sur mon blog d’abord, meh) qui me conseille memorize.

Le soft est un freeware poussé par une grosse boite de forensic. L’outil permet de lister les processus ouvert et les fichiers associés et ainsi de découvrir les drivers qui tournent. Malheureusement il ne permet pas de dumper les fichiers ni de lire les clés de registres associées. Un bon outil qui fait rapidement la job (comme dirait ce Québecois de Laurent, non les français ne parlent pas comme ça), mais qui ne convient pas au problème.

En effet, j’ai installé entre temps un server RealVNC (la même version que listé par memorize cela dit, plutôt un bon point) pour regarder où le logiciel stockait son mot de passe. Et bien tout simplement dans la base de registre ! Chiffré par je ne sais quel algorithme (surement du DES).

Ayant constaté cela, la course va être facile. Je dump la base de registre de l’image mémoire et je vais lire la clé. Voilà de bien belles paroles mais je ne sais absolument pas faire ce genre de chose. C’est là que seb entend parler de volatility sur un site Grec (véridique). J’investigue la solution, compile le logiciel sur Windows (c’est du python) et je joue un peu avec. C’est de la ligne de commande. La communauté qui porte se logiciel a produit un certains nombre de plugins qui me seront utiles par la suite.

On commence l’épreuve à proprement dite maintenant (comme quoi l’adage réfléchir avant d’agir est toujours vrai:)).

On va utiliser volatility pour dumper des zones mémoires et récupérer ce qui nous intéresse. Pour cela nous allons utiliser les plugins volreg et volrip qui permettent de récupérer les informations systèmes de l’os en ram (je généralise un peu vite, il analyse du Windows XP, je n’ai aucune idée si cela marche avec autre chose que du Windows).

D:challengeVolatility-1.3_Beta>python volatility hivescan -f dump.raw
Offset (hex)
44759904 0x2aafb60
44765192 0x2ab1008
47600264 0x2d65288
49462112 0x2f2bb60
57268056 0x369d758
117583880 0x7023008
117586784 0x7023b60
138480480 0x8410b60
140337160 0x85d6008
144967512 0x8a40758
145000296 0x8a48768
146788360 0x8bfd008
167239688 0x9f7e008

La première chose que vous remarquez, c’est que je travaille surWindows pour le coup

La seconde c’est que je dump une liste d’adresse mémoire qui ne font aucun sens. hivescan trouve “juste” les adresses occupées par le registre dans la RAM.

Ne nous arrêtons pas là:

D:challengeVolatility-1.3_Beta>python volatility hivelist -f
dump.raw -o 0x2aafb60
Address Name
0xe1809008 Documents and SettingseleveLocal SettingsApplication
DataMicrosoftWindowsUsrClass.dat
0xe1986008 Documents and SettingseleveNTUSER.DAT
0xe17a9768 Documents and SettingsLocalServiceLocal
SettingsApplication DataMicrosoftWindowsUsrClass.dat
0xe179b758 Documents and SettingsLocalServiceNTUSER.DAT
0xe1770008 Documents and SettingsNetworkServiceLocal
SettingsApplication DataMicrosoftWindowsUsrClass.dat
0xe175fb60 Documents and SettingsNetworkServiceNTUSER.DAT
0xe13ffb60 WINDOWSsystem32configsoftware
0xe14ab008 WINDOWSsystem32configdefault
0xe14abb60 WINDOWSsystem32configSAM
0xe14e4758 WINDOWSsystem32configSECURITY
0xe12e8288 [no name]
0xe1035b60 WINDOWSsystem32configsystem
0xe102e008 [no name]

A partir d’une adresse physique en mémoire, on récupère la liste des adresses virtuelles des emplacements du registre. Pour la peine volatility nous donne le nom des entrées ce qui va nous simplifier la vie.

J’avoue que la première chose que j’ai faite a été de dumper le fichier SAM même si cela ne sert à rien ici:

D:challengeVolatility-1.3_Beta>python volatility hashdump -f
dump.raw -y 0xe1035b60 -s 0xe14abb60
Administrateur:500:bac14d04669ee1d1aad3b435b51404ee:fbbf55d0ef0e34d39593f55c5f2ca5f2:::
Invité:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:0f49d2f4d3c6fd9cdcf900189bc46b05:e9ee7219c4e84d50f2b5569b4f49a053:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:23120f1b3baae60f657745ccecffd511:::
eleve:1003:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Seul le mot de passe Administrateur est tout de suite tombé. C’est “TOTO”. J’ai bien sûr utilisé john the ripper. Peut être que le mot de passe de élève était un flag bonus. Avis aux amateurs.

Revenons à nos moutons, et dumpons la base de registre “software”, là ou se situe l’entrée de VNC. Volatility va me permettre de dumper toute la base software avec la valeur des clés associées là où memorize me permettait seulement de voir la clé sans la valeur (et encore pas la base software car VNC se trouve à plusieurs endroits dans la base de registre).

python volatility hivedump -f dump.raw -i 0xe13ffb60 -v

L’option -v est très importante car elle permet de dumper les valeurs des clés. Sans elle, vous aurez juste les clés ce qui ne sert pas à grand chose dans notre cas. Je me retrouve avec un fichier nommé “0xe13ffb60.csv” qui est juste une base de registre

Je récupère dans la clé “Password” la valeur suivante : da6e31849577ad6b.

Je recherche 2 minutes un soft pour cracker une clé vnc. J’avoue que la technique de chiffrement de leur clé ne m’intéresse pas vraiment, j’aurai l’occasion d’écrire un brute force en Python plus tard

D:challengevncpwdump-win32-1_0_6>vncpwdump.exe -k da6e31849577ad6b

VNCPwdump v.1.0.6 by patrik@cqure.net
-------------------------------------
Password: secretpq

Le flag est donc secretpq. Voilà un premier challenge de validé ! J’ai bien dû mettre 4h pour faire ça.

Forensic300 ou parlez vous netcat ?

Même topo que précédemment. On nous donne seulement une image vmem qui est une image de la ram d’une machine virtuelle VMWare. Seul problème, volatility ne marche pas dessus. Pour le coup cela m’a un peu refroidi, je comptais mettre à profit l’expérience acquise sur le soft au challenge précédent pour résoudre rapidement celui-ci. Je me souviens ensuite des logiciels de forensic : foremost et Autopsy. Le premier est un file carver (récupère les fichiers de l’image) et le second un outil d’analyse de disque dur. Le second ne reconnait pas non plus l’image. Le premier récupère une série d’image dont un portrait dont le visage est flouté avec en surimpression un point d’interrogation. Le logiciel a également récupéré une vingtaine d’éxécutables. Ayant la grande flemme d’utiliser la commande “strings” dessus pour énumérer toute les chaines harcodées pour trouver un logiciel qui attire mon attention, je décide de procéder autrement (pour ceux qui se demandent, un fichier récupéré par foremost est composé uniquement de chiffres, probablement l’adresse en mémoire ou le fichier a été récupéré, rien d’excitant sauf pour les necrophages).

Je ressorts memorize qui lui contrairement à volatility récupère la liste des processus lancé sur la machine au moment de la prise du dump mémoire. On voit donc qu’un certain processus nommé “nc” (le petit nom de netcat) tourne sur la machine et connecté en sus à l’adresse secte.serverofdark_hamster.com et sur le port 48625. On avance à pas de géant. Memorize ne peut rien nous apprendre de plus mais l’on sait où chercher maintenant. Netcat étant un couteau suisse réseau, la commande relevée indique que netcat est connecté au serveur des hamsters sur le port indiqué. Seul problème : ce nom de domaine n’est pas résolu. Je pense tout de suite à trouver le fichier host mais sans succès. Dans un dernier sursaut (aka 30 minutes avant la fin du challenge):

D:challengeforensic300>strings DumpRAM_CTF.vmem | grep i -A 3 -B 3 hamster
FILE0
FILE0
FILE0
secte.server_of_dark_hamster.com
88.190.230.12
+*Vt
vAgzv
--
...
---
Nnbf
INTL
secte
server_of_dark_hamster
test-PC
MSFT 5.0
'si.com
Secret pass is H4x0r
rver_of_dark_hamster
AleD
@PyL
@PyL

On affiche les trois lignes avant et après chaque occurrence de hamster dans la mémoire grâce à grep et à strings. On tombe sur deux choses intéressantes: un mot de passe et une ip. L’ip se trouve être en vérité le serveur du challenge. Je le scan avec nmap et en effet le port est bien ouvert.

A mon tour d’utiliser netcat:

D:challengeforensic300>nc 88.190.230.12 48625

J’initie de cette manière une connexion TCP entre moi et le server distant sur le port passé en argument. Fébrilement je rentre “H4x0r” comme mot de passe mais le serveur me coupe la connexion. Et là le doute s’immisce en moi. Mais je sais aussi que les organisateurs sont vicieux. Je tente donc à la place de “H4x0r” de rentrer le mot de passe : “Secret pass is H4x0r”.

deckard@Stephenson ~
$ nc 88.190.230.12 48625
Secret pass is H4x0r
Nice job!

The hash is 9vjgH368$hgHGjh

Note: je suis sous cygwin pour le coup.

Et bingo, le serveur répond un hash qui est le flag et qui me permet de marquer des points durement gagnés à la force du grep. Encore 4 heures de ma vie durement comblées.

RCE200 ou grossièretés et Android

Dernier challenge que j’ai résolu. On nous fournit juste un package d’une application Android. On peut lire à droite et à gauche sur la toile que le Java est un langage difficile à obfusquer et aisément décompilable.

Allons y !

Tout d’abord un apk est un fichier zip. On dézipe ça avec 7zip sans se poser de questions. On récupère ainsi plusieurs fichiers.

D:challengerce200rce200>ls -l
total 430
-rw-r--r--    1 deckard  Administ     1420 Mar 29 13:29 AndroidManifest.xml
drwxr-xr-x    2 deckard  Administ        0 Apr  3 09:47 META-INF
-rw-r--r--    1 deckard  Administ     4324 Mar 29 13:29 classes.dex
drwxr-xr-x    7 deckard  Administ     4096 Apr  3 09:40 res
-rw-r--r--    1 deckard  Administ     1544 Mar 29 13:29 resources.arsc

META-INF et res sont des dossiers qui ne nous intéressent pas. Il y a dedans le certificat qui signe l’application et une image.

Les classes java sont contenues dans le fichier classes.dex (thx again dr. obvious, oh c’est bon hein !). A noter que j’ai essayé d’incorporer directement le projet dans eclipse mais cela n’est pas possible. C’est balot, j’aurai pu ainsi profiter du debugger ce qui aurait rendu la résolution du problème enfantine. Le fichier AndroidManifest.xml est un binaire (et non un xml). Eclipse ne peut donc pas l’importer.

Peu importe, je télécharge dex2jar qui va me donner un jar contenant les fichiers classes à partir du fichier dex. Là encore il ne s’agit que d’un fichier zip qui contient les classes java. Cela ne s’arrêtera donc jamais ?

Finalement on utilise le décompilateur Java DJ pour transformer les .class en .java. Pas vraiment besoin de jouer de la ligne de commande jusque là, ces logiciels possèdent une interface graphique (détail inutile mais qui explique le manque de coloration syntaxique).

Nous avons enfin des fichiers sources que nous pouvons incorporer dans Eclipse.

D:challengerce200rce200secretndhprequalsrce>ls -l
total 976
D:challengeRCE200.srcndhprequalsrce>ls -l
total 4
-rw-r--r--    1 deckard  Administ     1814 Apr  2 16:58 ReverseMe.java
-rw-r--r--    1 deckard  Administ     2583 Apr  2 16:58 a.java
-rw-r--r--    1 deckard  Administ      846 Apr  2 16:58 b.java
-rw-r--r--    1 deckard  Administ     1335 Apr  2 16:58 c.java

Les choses étant bien faites pour les organisateurs, les fichiers ne compilent pas. J’ai bien réussi en réecrivant des sections de code à porter l’application sur le simulateur Android et à la faire marcher mais cela ne sert à rien à part tester si j’ai pu injecter des bugs dans le code (et en effet, ça déconne plein pot sic).

Une portion de code attire mon oeil dans le fichier c.java:

 private static byte[] a = { 90, 5, 88, 88, 13, 13, 90, 90, 10, 4, 9,11, 93, 90, 11, 15, 93, 95, 5, 93, 5,8,8, 88, 90, 95, 9, 14, 90, 8,13, 94 };
 private static byte[] b = { 91, 83, 83, 91, 80, 89, 99, 79, 88, 87 };
 private static byte[] c = { 113, 120, 9 };
 private static byte[] d = { 93, 82, 88, 78, 83, 85, 88, 18, 79, 76, 89, 89, 95, 84, 18, 93, 95, 72, 85, 83, 82, 18, 110, 121, 127, 115, 123, 114, 117, 102, 121, 99, 111, 108, 121, 121, 127, 116 };
 private static byte[] e = { 111, 116, 125, 17, 13 };

Un tableau avec des nombres obscurs. Si ce n’est pas de l’obfuscation de chaîne de caractère je ne m’appelle plus ** (hehe mince).

En observant le fichier a.java, on remarque qu’une fonction s’amuse avec ces chaînes:

for (Object localObject2 = Integer.toHexString(localObject1[i] & 0xFF); ; localObject2 = str)
{
    if (((String)localObject2).length() >= 2)
    {
        StringBuffer localStringBuffer2 = localStringBuffer1.append((String)localObject2);
        i += 1;
        break;
     }
     str = "0" + (String)localObject2;
}

Note : j’ai du réecrire des petites portions du code originel car il ne compilait pas.

Juste pour être sûr, je regarde le fichier ReverseMe.javaet b.java. L’application utilise la reconnaissance vocale et une fois un certain mot acquis, il le compare à une chaine de caractère récupérée par a.java.

ArrayList localArrayList =paramIntent.getStringArrayListExtra("android.speech.extra.RESULTS");
if ((!localArrayList.isEmpty()) && (a.b((String)localArrayList.get(0))))
{
    TextView localTextView = this.b;
    String str = a.a((String)localArrayList.get(0));
    localTextView.setText(str);
}

On voit ici clairement que l’on compare une chaîne de a.java avec la chaîne récupérée par la reconnaissance vocale. Je n’explique pas tout le code n’étant pas du tout un développeur android (mais J2ME pour la petite histoire, au pays du caribou on aime (trop) blackberry).

En réecrivant en partie a.java, j’arrive à dumper les chaînes de caractères encodés:

a:f9dd11ff6857af73ac9a944dfc52f41b
b:google_sdk
c:MD5
d:android.speech.action.RECOGNIZE_SPEECH
e:SHA-1

La chaîne ‘a’ correspond au MD5 de salope (que l’on trouve sur Google). C’est vraiment charmant. Je n’explique pas le SHA-1. Cet indice a sûrement permis aux non francophones de finir ce challenge.

J’installe (enfin) l’application apk sur mon HTC DESIRE HD (torse mis en avant). Fort de mon petit mot salope je le prononce a tue tête à mon téléphone. Cela ne fonctionne pas. Mon téléphone est en anglais. Je passe la reconnaissance de voix en français. Ca ne marche toujours pas. Impossible.

Et là, une petite subtilité qui aurait pu me faire passer à côté du flag. Le filtre sur les mots à connotations sexuelles est activé par défaut. Merci Google. Et voilà, l’application me donne un hash après avoir prononcé ces belles paroles à mon téléphone. Plus précisement il me donne le SHA-1 de “salope”.

Encore 4 petites heures pour faire tout ça.

Conclusion

J’ai passé un superbe week-end grâce à tout cela. C’était ma première participation à un évenement du genre. Je regrette juste de ne pas avoir eu le temps de regarder certains challenges (notamment Crypto300 qui était une application client/serveur en python) mais je n’ai pas eu le temps. Pour pouvoir plus marquer il n’y a pas de secret: s’entrainer plus et lire plus nibbles, mais également motiver son équipe. Je remercie seb qui était toujours présent pour nous relancer dans la course, ça m’a motivé à rester concentré sur le même problème pendant 4 heures d’affilé. N’ayant pas l’habitude de l’exercice, la phase de compréhension des outils est très importante. Je retiens qu’il ne sert à rien de sauter d’étape en étape en esperant gagner des flags facile. Pour moi, la technique est vraiment de se concentrer avec tout ses moyens sur un problème. C’est ce qui a coulé mon équipe, les gens se sont éparpillés sur tous les problèmes en même temps, et n’arrivant à en résoudre aucun, ils se sont découragés. Culture fast food (je donne des leçons de vie maintenant, on aura tout vu). On va essayer de faire mieux la prochaine fois.

Je suis vraiment admiratif de mecs comme rootBSD ou nibbles que j’ai déjà cité pour leur boulot de vulgarisation. Et voilà j’essaye moi aussi de poser ma petite pierre (un petit caillou) à l’édifice.

Alors un proxy c’est quoi (serveur mandataire en bon Français) ?

Un proxy est un logiciel qui se place entre un émetteur que nous appellerons Alice et un récepteur que nous appellerons Bob. Un proxy est donc un intermédiaire entre deux entités. Par entité j’entends, une personne, un ordinateur, un téléphone, etc.

L’unique but de cet intermédiaire est suivant la nature du message de le relayer ou non. Imaginez un portier dans un hôtel de luxe (faut pas déconner quand même), si vous ressemblez à un clochard il ne vous laissera pas entrer, sinon si vous avez une allure élégante et de bonnes manières je pense que tout ira bien pour vous.

L’image de la poste est (presque) toujours excellente pour décrire ce qui se passe sur l’Internet. Ici, Alice envoie une lettre à Bob. Cependant son ordinateur est configuré pour utiliser un proxy donc sa lettre passe par monsieur le gentil proxy. Celui-ci va ouvrir la lettre, lire son contenu et ensuite refaire une enveloppe pour l’envoyer à Bob. Enfin, il ne l’a renvoie pas toujours suivant son utilisation.

Vous avez donc compris qu’un proxy est un super intermédiaire. Mais pourquoi donc devrions nous utiliser un proxy ? Tout simplement parce qu’il peut fournir des services comme :

• Partager une connexion Internet
• Identifier des utilisateurs
• Offrir un (relatif) anonymat
• Filtrer les virus
• Modifier le contenu des messages

Cette petite bête est donc bien utilisée pour faire plusieurs choses. L’usage le plus courant est l’identification et le filtrage de virus. Dans un registre plus large, on peut dire que le proxy permet d’offrir de la sécurité et de la traçabilité.

Je vous propose une implémentation très basique en Python d’un proxy Socks4. Socks4 est un protocole très simple qui permet à une application d’utiliser un proxy de manière transparente. Pour que cela marche, il faut bien entendu que l’application le supporte. Pour ceux que ça intéresse, voici la spécification socks4.

Dernière petite note avant de commencer à montrer du code. Je vais utiliser des sockets asynchrones. Le principe est bien plus simple à appréhender pour des non programmeurs (pour les autres, c’est un bon moyen de faire des sockets asynchrones). Retenez juste que le programme “dort” tant que personne ne lui parle ou s’il n’a rien à envoyer.

Voyez tout le code qui suit non pas comme un didacticiel pour apprendre à écrire du code Python ou un proxy. Ceci est juste une implémentation naïve que je partage ici. Culture !

import socket, asyncore
import sys
import os

from Fpair import *

var_socks_addr = ''
var_socks_port = 1080

class Fmanager(asyncore.dispatcher):
    def __init__(self):
        print("....Starting....")
        asyncore.dispatcher.__init__(self)
        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
        self.bind((var_socks_addr, var_socks_port))
        self.listen(3)
        self.dict_pair = dict()

    def delete_key(self, key):
        try :
            del self.dict_pair[key]
            print("........Deleted : " + str(key))
        except :
            pass

    def handle_accept(self):
        conn, addr = self.accept()
        print("....Connecting : " + str(addr))
        self.dict_pair[addr] = Fpair(conn, addr, self)

    def handle_close(self):
        print("exit !")
        self.close()

if __name__ == '__main__':
    sock = Fmanager()
    asyncore.loop()

Voilà notre première classe Fmanager qui sert de point d’entrée. Vous remarquerez que le programmeur est “trappé” dans sa fonction main par l’objet asyncore. Fmanager écoute sur toutes les interfaces de la machine sur le port 1080 en attendant une connexion. Vous remarquerez que j’ai vu les choses en grand, un dictionnaire gère en effet une paire de sockets (client / serveur). Permettant virtuellement de placer un nombre illimité de clients sur le proxy.

Voici cette classe de paire de socket très simple :

from Fsock import * 

class Fpair:
    def __init__(self, conn, key, manager):
        self.key = key
        self.manager = manager
        self.left_socket = Fsock(conn, self, True)
        self.right_socket = None

    def connect_other_side(self, so, conn):
        if(so == self.left_socket):
            self.right_socket = Fsock(conn, self, False)

    def send_other_side(self, so, mess_hdl):
        if(so == self.left_socket):
            self.right_socket.buffer = mess_hdl
        else:
            self.left_socket.buffer = mess_hdl

    def close(self):
        try:
            self.left_socket.close()
        except:
            pass
        try:
            self.right_socket.close()
        except:
            pass
        self.manager.delete_key(self.key)

Rien de très extraordinaire dans ce bout de code. La paire de sockets s’emploie à connecter un client et un serveur (quand un bout est connecté par le biais de Fmanager, l’autre bout se connectera alors). De la même manière cela sert pour faire transiter un message de bord à bord. Notez que cela aurait pu être fait dans le code de chaque socket mais cela aurait brisé un principe d’encapsulation.

Voici la reine, le joyau et l’élément le plus important de tous, la classe Fsock.

import socket, asyncore
import sys
import os

from Fhandler import *

class Fsock(asyncore.dispatcher):

    def __init__(self, conn=None, pair=None, left=True):
        if(left == True):
            asyncore.dispatcher.__init__(self, sock=conn)
        else:
            asyncore.dispatcher.__init__(self)
            self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
            self.connect(conn)
        self.pair = pair
        self.buffer = ''

    def handle_write(self):
        sent = self.send(self.buffer)
        self.buffer = self.buffer[sent:]

    def handle_read(self):
        mess_rcv = self.recv(8192)
        mess_hdl = Fhandler.handler(mess_rcv, self)
        self.pair.send_other_side(self, mess_hdl)

    def handle_close(self):
        try:
            print("........Closing : " + str(self.socket.getpeername()))
        except socket.error as e:
            print("............" + str(e))
        self.pair.close()

Encore un socket asynchrone. Encore une classe extrêmement simple. A chaque fois qu’un message est reçu, la fonction handle_read est appelée. Une fonction du “handler” est ensuite appelée. C’est ici que l’on filtre les données. Ensuite on envoie les données modifiées (ou non) par le “handler” à l’autre socket. Cela marche quelque soit le sens.

Nous avons vu donc que le cœur de notre programme se situe dans la classe “handler”. C’est cette classe qui va nous permettre de modifier ou du moins examiner les paquets qui transitent par notre programme.

class Fhandler:

    def handler(mess_rcv, so):
        mess_hdl = mess_rcv
        hex_data = mess_rcv.encode("hex")
        #print(hex_data)
        # handle socks4 protocol
        if(hex_data[:4] == h_socks4 and len_socks4 == len(hex_data)):
            Fhandler.socks4(hex_data, so)
            mess_hdl = ''
        return mess_hdl
    handler = staticmethod(handler)

    def socks4(mess_socks, so):
        # get ip : port
        addr_port = int(mess_socks[4:8], 16)
        addr_ip = binascii.unhexlify(mess_socks[8:16])
        addr_ip = str(int(mess_socks[8:10], 16)) + '.' + str(int(mess_socks[10:12], 16))
            + '.' + str(int(mess_socks[12:14], 16)) + '.' + str(int(mess_socks[14:16], 16))
        print(addr_port)
        print(addr_ip)
        # connect right socket
        so.pair.connect_other_side(so, (addr_ip, addr_port))
        # send confirmation to the client
        so.send(binascii.unhexlify(d_socks4))

    socks4 = staticmethod(socks4)

C’est un peu moche mais le “handler” utilise des fonctions statiques. Cela évite de devoir l’instancier à tout bout de champ.

Pour conclure, voici un rapide aperçu d’un proxy socks4 écrit en python. Les sockets asynchrones permettent de s’affranchir de l’aspect thread et concurrence.

Petit exemple pratique : si je veux modifier le paquet qui commence par disons les 2 premiers octets par “aa:bb”, je dois rajouter la ligne suivante dans la fonction Fhandler.handler(mess_rcv, so).

 if(hex_data[:4] == "aabb"):
      # modification super cool

C’est aussi simple que cela. Le concept est utilisé par l’outil de sécurité Webgoat édité par l’association OWASP. Webgoat permet de modifier à la volée les données envoyées à un serveur tel que le cookie, les arguments d’un GET mais aussi les champs cachés, etc … Le concept d’un point de vue sécurité permet à un attaquant de corrompre un logiciel légal sans pour autant le modifier en lui même.

Je vous laisse y réfléchir !

La slow released attack est une attaque qui porte sur une erreur de conception du protocole HTTP. Pour bien comprendre le concept nous devons jeter un coup d’oeil à l’en-tête d’une requête. Voilà à quoi cela ressemble.

POST /w/index.php?title=Hypertext_Transfer_Protocol&action=submit HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; U; fr) Presto/2.6.30 Version/10.63
Host: fr.wikipedia.org
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: fr-FR,fr;q=0.9,en;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Connection: Keep-Alive
Content-Length: 21784
Content-Type: text/plain

C’est un peu verbeux mais simple à comprendre. J’ai effectué un HTTP POST sur la page de Wikipedia concernant HTTP. La requête POST permet d’envoyer une requête avec des données. Ici ces données sont renseignées par les champs de l’en-tête avec le préfixe Content. J’envoie donc ici 21784 octets sous forme de texte (respectivement renseigné par les champs Content-Length et Content-Type).

Le protocole renseigne la longueur des données que je vais envoyer. Mais pourquoi donc ? Ne suffirait-il pas pour connaître la taille de mesurer la longueur des données ?

Et bien non car il peut arriver d’envoyer cette requête en plusieurs tronçons. Le champ Content-Length sert donc à prévenir le serveur du nombre d’octets que le client va lui envoyer avant de pouvoir faire quelque chose des données.

C’est sur ce point que nous allons intervenir. Le principe de ne jamais croire le client n’a jamais été ici aussi vrai. Tout le concept réside ici dans l’exploitation de ce champ afin de parvenir à un déni de service.

Je ne vous propose pas un logiciel pour réaliser le déni de service mais pour mesurer cette vulnérabilité. Des organismes comme OWASP ont sorti des outils graphiques et un peu plus sexy (enfin en Java mais bref) donc amusons nous avec les possibilités du code

Un serveur Web utilise plusieurs timers pour gérer les connexions avec les clients. Par exemple j’initie une connexion TCP et je n’envoie aucune requête, le serveur à un timer pour ça. Si ce timer déborde, le serveur ferme ma connexion. Même chose avec le Content-Length. J’annonce au serveur que je vais envoyer 60 octets. Je ne lui envoie que 10 octets, le serveur va me laisser un temps donné avant de fermer ma connexion. Là où la chose est belle, c’est que si je renvoie un bout de données, ce compteur est remis à zéro et redémarré en attendant la suite. Vous pouvez donc imaginer une attaque qui consiste à envoyer des données à intervalles réguliers (prenons au hasard la valeur du timer) pour maintenir la connexion ouverte et vous avez un DDOS ne nécessitant pas beaucoup de bande passante. SI vous voulez en savoir plus, je vous invite à lire la présentation de ‘OWASP sur leur site (je n’ai plus le lien sous la main mais ça me reviendra !).

import random
import urlparse

class httpWorker:

    # const
    # array are used to build random packets
    # HTTP
    HTTP_POST = "POST"
    HTTP_VERSION = ["HTTP/1.1"]
    # serious stuff, courtesy for my mac*** girlfriend
    USER_AGENT = ["User-Agent: Opera/9.80 (Windows NT 6.1; U; en) Presto/2.6.30 Version/10.63",
        "Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12",
        "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; fr-ca)",
        "AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4",
        "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.12 (KHTML, like Gecko) Chrome/9.0.581.0 Safari/534.12",
        "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.18) Gecko/2010042101 Iceweasel/3.0.6 (Debian-3.0.6-3)",
        "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)",
    ]
    HTTP_ACCEPT = ["text/html, application/xhtml+xml, */*",
        "text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1",
    ]
    HTTP_ACCEPT_LANGUAGE = ["Accept-Language: fr-FR,fr;q=0.9,en;q=0.8",
        "fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4",
        "en-CA;q=0.8,en;q=0.6",
    ]
    HTTP_ACCEPT_CHARSET = ["ISO-8859-1,utf-8;q=0.7,*;q=0.3",
        "ISO-8859-1,utf-8;q=0.7,*;q=0.7",
    ]
    HTTP_ACCEPT_ENCODING = ["gzip,deflate,sdch",
        "gzip, deflate",
        "deflate, gzip, x-gzip, identity, *;q=0",
    ]
    HTTP_CONNECTION  = ["Keep-Alive"]
    HTTP_CONTENT_TYPE = ["text/plain",
        "text/html",
    ]

    # SETTINGS
    # magic number
    MIN_LENGTH = 150
    MAX_LENGTH = 2458

    PAYLOAD_CHARSET = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.=?!"

    # init http worker without knowing of timeout timer
    # on server side
    def __init__(self, url="http://localhost/?lol=true&urlparse=1"):
        self.url = urlparse.urlparse(url)
        print(self.url)
        # generate length of the packet
        # note : do not generate data
        self.data_length_max = random.randint(self.MIN_LENGTH, self.MAX_LENGTH)
        self.data_length_index = random.randint(1, self.MIN_LENGTH)

        # must be called at the end
        self.forgePOST();

    def forgePayload(self, length):
        payload = ""
        for i in range(0, length):
            payload += self.PAYLOAD_CHARSET[random.randint(0, len(self.PAYLOAD_CHARSET)-1)]
        return payload

    # forge http packet with random settings
    # not very elegant
    def forgePOST(self):

        if(self.url.query != ""):
            url_trailer = "?"
        else:
            url_trailer = ""

        # build http header
        self.http_header = self.HTTP_POST + " "
        self.http_header += self.url.path + url_trailer + self.url.query + " "
        self.http_header += random.choice(self.HTTP_VERSION) + "rn"
        self.http_header += "User-Agent: " + random.choice(self.USER_AGENT) + "rn"
        self.http_header += "Host: " + self.url.netloc + "rn"
        self.http_header += "Accept: " + random.choice(self.HTTP_ACCEPT) + "rn"
        self.http_header += "Accept-Language: " + random.choice(self.HTTP_ACCEPT_LANGUAGE) + "rn"
        self.http_header += "Accept-Charset: " + random.choice(self.HTTP_ACCEPT_CHARSET) + "rn"
        self.http_header += "Accept-Encoding: " + random.choice(self.HTTP_ACCEPT_ENCODING) + "rn"
        self.http_header += "Connection: " + random.choice(self.HTTP_CONNECTION) + "rn"

        # WARNING : THIS IS THE ONLY INTERESTING PART OF THE CODE
        self.http_header += "Content-Length: " + str(self.data_length_max) + "rn"

        # boring again
        self.http_header += "Content-Type: " + random.choice(self.HTTP_CONTENT_TYPE) + "rn"

        self.http_header += "rn"

        print(self.http_header)

        # build body
        self.http_msg = self.http_header
        self.http_msg += self.forgePayload(self.data_length_index)

Créons une classe pour forger une requête HTTP POST. Rien d’extraordinaire. Comme nous sommes un peu vicieux, on rend aléatoires certains champs afin d’éviter de générer tout le temps la même signature. C’est assez simpliste et vraiment très louche mais soit.
Je rends aléatoire également la chaîne de caractère envoyée ainsi que sa longueur.

Nous avons maintenant besoin d’une nouvelle classe que j’appellerai Probe.

from httpWorker import *
import time
import urlparse
import socket
import sys

class Probe:
    def __init__(self, url="http://localhost/", port=80):
        # i know
        self.http = httpWorker(url=url)
        self.port = port

    def probe(self):
        # set time
        a_time = time.time()

        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.sock.connect((self.http.url.netloc, self.port))

        data = "2"

        self.sock.send(self.http.http_msg)

        # wait disconnection
        while(data != ""):
            data = self.sock.recv(1024)

        b_time = time.time()

        slow = b_time - a_time

        print("PROBING :" + str(slow))

if __name__ == "__main__" :
    if(len(sys.argv) < 2):
        print("help : python probe.py URL [PORT-OPTIONNAL]")
        sys.exit(0)
    if(len(sys.argv) == 3):
        port = sys.argv[2]
    else:
        port = 80

    if(sys.argv[1][:len("http")] != "http"):
        url = "http://" + sys.argv[1]
    else:
        url = sys.argv[1]
    test = Probe(url, port)
    test.probe()

Très simple encore ici, on mesure juste le temps entre la requête HTTP et la déconnexion (un paquet TCP avec pas de données). Vous noterez que j’ai fait un effort pour l’utilisation en ligne de commande Le temps résultant est la valeur du compteur configuré sur le serveur pour jeter les connexions n’ayant pas fini d’envoyer leurs données dans le temps imparti.

Voilà c’est tout, une preuve de concept très simple et une attaque relativement facile à mettre en œuvre.

Pour information, le temps de se faire déconnecter sur ce blog avec un Content-Length incorrect est de 30 minutes soit le temps par défaut pour un serveur Apache. Google.fr tourne aux alentours de 4 minutes. Ceci n’a pas vraiment d’impact pour se défendre contre ce genre d’attaque, just say’in

Note : la première version comportait un bug, si vous tentiez d’atteindre une url à la racine d’un site sans ajouter de “/” à la fin, le programme plantait tout simplement. J’ai vraiment pas un métier facile.

Mini post mortem :
Après avoir fait quelques expérimentations, les serveurs Apaches rejettent les requêtes POST si elles ne sont pas dirigés à l’encontre d’un formulaire en témoigne cette superbe réponse du serveur (sur ce blog):

HTTP/1.0 501 Unsupported method ('POST')

Server: BaseHTTP/0.3 Python/2.5.2

Date: Fri, 03 Dec 2010 06:02:31 GMT

Content-Type: text/html

Connection: close

Unsupported method (‘POST’)

Server does not support this operation

Après lecture du compte rendu de l’OWASP, Apache ne permet comme je l’avais remarqué les POST n’importe où mais d’après leur dire, IIS serait plus laxiste.

La nouvelle version de l’utilitaire est bien plus maligne j’espère pouvoir vous montrer quelque chose qui marche vraiment très bientôt.

Prenons une analogie postale pour expliquer le concept. J’utilise une enveloppe pour envoyer un message par le biais de la poste. Cette enveloppe à un timbre, une adresse et une adresse de retour. Forger un paquet revient à construire cette enveloppe et à remplir les champs d’adresses à la main. Je vais plus précisément forger un paquet ICMP de type ping. ICMP est un protocole qui se situe juste au dessus de la couche IP. Il ne repose pas ainsi sur UDP ou TCP.

Je me suis aidé de l’excellent tutorial de mixter. Ce dernier forge un paquet TCP sur Unix. Je vous propose de faire un paquet ICMP sur Windows (pour changer !).

Tout d’abord précisons les types de données. Nous utiliserons la définition des sockets BSD.

/*
* type.h
* Internet Protocol Stack
*/

struct ipheader {
 unsigned char ip_hl:4, ip_v:4; /* this means that each member is 4 bits */
 unsigned char ip_tos;
 unsigned short int ip_len;
 unsigned short int ip_id;
 unsigned short int ip_off;
 unsigned char ip_ttl;
 unsigned char ip_p;
 unsigned short int ip_sum;
 unsigned int ip_src;
 unsigned int ip_dst;
}; /* total ip header length: 20 bytes (=160 bits) */
typedef struct ipheader ipheader_t;

struct icmpheader {
 unsigned char icmp_type;
 unsigned char icmp_code;
 unsigned short int icmp_cksum;
 /* The following data structures are ICMP type specific */
 unsigned short int icmp_id;
 unsigned short int icmp_seq;
}; /* total icmp header length: 8 bytes (=64 bits) */
typedef struct icmpheader icmpheader_t;

Je vous sers tout cela d’un coup car cela n’a pas réellement d’importance. Nous forgeons un paquet à partir de la couche IP. Donc nous avons besoin de définir les champs de la couche IP puis de la couche ICMP. Si vous n’avez aucune idée à quoi cela peut ressembler, regardez ce schéma Wikipedia. Vous y avez la description de l’en-tête IP. Tout ce que la structure de données représente, ce sont les champs de cet en-tête. Et nous faisons de même avec l’en-tête ICMP.

Rentrons ensuite dans le vif du sujet. Définissons les en-têtes de notre programme :

/* platform dependent */
#ifdef _WIN32

#include <winsock2.h>
#include <ws2tcpip.h>

#endif

/* common headers */
#include "type.h"
#include "stdio.h"
#include "utils.h"

#define SOURCE "192.168.2.10"
#define TARGET "192.168.2.1"

#define ICMP_PING 8

A noter que le fichier utils.h est le fichier qui contient les en-têtes IP et ICMP (en d’autre termes, vous devez créer ce fichier et mettre les structures dedans). Le reste c’est du très classique avec les en-têtes Windows pour les sockets et la bibliothèque standard. Vous noterez que les adresses sont codées en dur. Pour débugger j’utilise mon ordinateur et mon routeur (la boucle locale sur Windows 7 n’est pas capturable avec Wireshark, enfin). Le ICMP_PING désigne le type de paquet ICMP, ici un ping (ou 8 en langage machine).

Plaçons nous ensuite dans une fonction main. On déclare nos variables :

/* init data type */
    int c_socket = 0;
    icmpheader_t *h_icmp = NULL;
    ipheader_t *h_ip = NULL;
    struct sockaddr_in sin_in;
    struct sockaddr_in sin_out;
    char *packet = NULL;
    int len_packet = 0;
    char buffer[4096];
    int sizelen;

    int ret = 0;

    #ifdef _WIN32
    /* Init stack */
    WSADATA wsaData;

    WSAStartup(MAKEWORD(2,2), &wsaData);
    #endif

    /* init socket */
    c_socket = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP);

    {   /* force kernel to not add header before packet */
        int one = 1;
        const int *val = &one;
        if (setsockopt(c_socket, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0)
            printf ("Warning: Cannot set HDRINCL!n");
    }

On initialise donc nos buffers et nos pointeurs. On s’en servira plus tard. Le seul point à retenir est la création d’un socket en mode RAW. On s’assure ensuite que le kernel n’ajoutera pas accidentellement des headers de son jus ce qui ferait doublon avec les nôtres (et forcement ça marche moins bien après). Ce bout de code est mixter approved, donc pas de commentaire haineux s’il vous plait (des accolades au milieu du code, toussa toussa) !

/* init packet */
        len_packet = sizeof(ipheader_t) + sizeof(icmpheader_t); /* set packet size */
        packet = malloc(len_packet);
        h_ip  = (ipheader_t*) packet; /* put ip header at the beginning */
        h_icmp = (icmpheader_t*)(packet + sizeof(ipheader_t));
                            /* put icmp header after ip header */

        memset(packet, 0, len_packet); /* clear */

On calcul la taille du paquet qui ne contiendra que des en-têtes (on pourrait rajouter du payload facilement mais ce n’est pas le sujet). On fait ensuite pointer nos en-têtes sur les parties du paquet qui leur conviennent. Comme ICMP est encapsulé dans IP, il est normal que l’en-tête IP se situe avant celui d’ICMP mais je ne vous apprend rien. Il est très important de mettre à 0 tous les champs du paquets. Et oui ami de Java, C ne fait pas ça pour vous.

/* init ip header */
        h_ip->ip_hl = 5;
        h_ip->ip_v = 4;
        h_ip->ip_tos = 0;
        h_ip->ip_len = len_packet;
        h_ip->ip_id = htonl(54321);
        h_ip->ip_off = 0;
        h_ip->ip_ttl = 255;
        h_ip->ip_p = IPPROTO_ICMP;
        h_ip->ip_sum = 0; /* 0 means filled by the kernel before transmission */
        h_ip->ip_src = inet_addr(SOURCE);
        h_ip->ip_dst = inet_addr(TARGET);

        /* init icmp header */
        h_icmp->icmp_type = ICMP_PING;
        h_icmp->icmp_code = 0;
        h_icmp->icmp_id = 0;
        h_icmp->icmp_seq = 0;
        h_icmp->icmp_id = htons(0x01);
        h_icmp->icmp_seq = htons(0x0a);

        h_icmp->icmp_cksum = 0; /* serious stuff */
        h_icmp->icmp_cksum = csum((unsigned short*)h_icmp, sizeof(icmpheader_t));

Nous initialisons les champs des en-têtes. La seule chose importante à retenir à mon sens est le cheksum ICMP. Ce dernier est calculé de la même façon que celui d’IP. Cependant le kernel calcul tout seul le checksum pour le paquet IP, ICMP n’a pas le droit à cette faveur. Nous utilisons donc un bout de code issu de la RFC 1705. Cette RFC date de 1988 et comportait une erreur. A la vue d’une erreur j’étais excité à l’idée de faire un rapport de bug mais il semble que le bug ait été rapporté en 2004. Donc bref voici la fonction de checksum.

unsigned short      /* this function generates header checksums RFC 1705*/
csum (unsigned short *addr, int count)
{
    /* Compute Internet Checksum for "count" bytes
    *         beginning at location "addr".
    */
    long sum = 0;

    while( count > 1 )
    {
        /*  This is the inner loop */
        sum += * (unsigned short *) addr++;
        count -= 2;
    }

    /*  Add left-over byte, if any */
    if( count > 0 )
        sum += * (unsigned char *) addr;

    /*  Fold 32-bit sum to 16 bits */
    while (sum>>16)
        sum = (sum & 0xffff) + (sum >> 16);

    return ~sum;
}

Il y a des manières plus malignes de le faire (mixter encore lui !).

Maintenant nous sommes prêt à envoyer ce maudit paquet et à recevoir le pong en retour.

        sin_out.sin_family = AF_INET;
        sin_out.sin_addr.s_addr = inet_addr(TARGET);

        /* send icmp echo */
        ret = sendto(c_socket, packet, h_ip->ip_len, 0, (struct sockaddr*)&sin_out, sizeof(struct sockaddr));
        printf("ret : %dn", ret);
        if(ret != h_ip->ip_len)
            printf("ERROR sendto");

        sizelen = sizeof(struct sockaddr);
        /* receive echo reply */
        ret = recvfrom(c_socket, buffer, len_packet, 0, (struct sockaddr*)&sin_in, &sizelen);

        if(ret != len_packet)
            printf("ERROR rcvfrom");

Rien d’extraordinaire non plus ici. Vous noterez le stockage inutile de l’adresse de l’émetteur du pong.

Et enfin un peu de code pour nettoyer tout ça.

    /* clean the mess */

    #ifdef _WIN32
    closesocket(c_socket);
    WSACleanup();
    #endif

    if(h_icmp)
        free(h_icmp);
    if(h_ip)
        free(h_ip);
    if(packet)
        free(packet);

    return 0;

Voilà une implémentation basique mais néanmoins complète d’un ping. A noter qu’il faut être root ou administrateur pour faire marcher le bousin. Vous pouvez maintenant imaginer forger à peut près n’importe quoi et même inventer votre propre protocole de couche 3 ou 4.

Edit : Je mélange allègrement Anglais et Français dans cet article, je m’excuse mais c’est une déformation professionnelle

Départ et arrivée

Nous nous sommes embarqués donc depuis Montréal vers Québec en bus. La compagnie était Orléans Express, la seule qui fasse le trajet de 3h15. La conférence ouvrait ses portes à 9h du matin, nous avions donc le temps de nous embêter. Heureusement que les gares de bus sont vraiment trop bien climatisées la nuit car nous avons eu très froid. En témoigne la photo de cet animal en voie de disparition, tragique :

Nous avons également tenté le petit déjeuner à la gare de bus. Bien nous en a pris, c’était non seulement cher mais également dégueulasse. Mention spéciale au cuistot qui mettait un petit coup de bombe aérosol avant de faire réchauffer les sandwichs dans les plaques.
S’en est suivie une grande aventure pour trouver un arrêt de bus (la conférence étant dans un hôtel excentré du centre).

La conférence

Nous arrivons en bus une heure en avance. Nous décidons donc d’attendre l’ouverture. Vers 8h40 nous sommes en tête de la file d’attente. Le seul hic est que nous n’avions rien réservé. La nana en charge de la caisse nous fera un petit clin d’oeil : “vous aimez vivre dangereusement vous”. Et nous voila à l’intérieur avec un joli badge avec marqué au dos la liste des conférences. Je vous déroule conférence par conférence avec mes petits commentaires.
Vous pouvez trouver une biographie des intervenants sur le site de HackFest

Le GPU à la rescousse du CPU

Présentée par Charles Demers-Trembley, cette présentation nous a introduit au calcul parallèle (CUDA) avec des GPU pour notamment casser des hash de mots de passe en local. La machine était impressionnante mais chauffait très rapidement. En moins de 4 minutes, les 4 Geforce GTI montaient à 90°C. Le mec avait même un indicateur de Watt branché sur la prise pour éviter l’accident technique. Ce n’était certes pas une présentation très intéressante techniquement mais elle avait le mérite d’introduire les outils gratuit et payant. Après l’intérêt venait de la démonstration qui est impressionnante de part la configuration qui n’est pas commune.

Comment détecter des virus inconnus en utilisant des “honey pots” et d’autres technologies”

Une présentation de David Girard qui travaille chez Trend Micro. Peut être la conférence la plus intéressante ou du moins qui a mis le projecteur sur un domaine très inconnu du grand public, le monde des éditeurs d’anti-virus. Un “honey-pot” est une sorte de piège à virus. Un éditeur de virus essayera en effet pour mettre à jour ses logiciels d’attraper le plus de virus possible pour pouvoir les observer en milieu clos et ainsi en extraire les informations nécessaires à leur détection. S’en suit des détails techniques et des noms de logiciels utilisés dans cette quête.

Stack Smashing Protector

Présentation faite par Paul Rascagneres. Un bon gros nerd Unix qui n’arrive pas à configurer la résolution de son écran pour un rétroprojecteur. A sa décharge, les deux rétroprojecteurs étaient de résolutions différentes. Peut-être que X ne sait tout simplement pas le faire. Donc une petite présentation avec beaucoup de code et de dbg sur le mécanisme de protection de pile avec fanion (canary dans le jargon). Intéressant et vraiment documenté avec les bouts de code. Il est juste dommage qu’il n’ait pas présenté un petit benchmark suivant les plateformes testées et avec le mécanisme de protection ou sans.

Data Leakage Protection

Monsieur Guy Bruneau nous a présenté les techniques utilisant des expressions régulières pour l’administration système. C’était du niveau de l’utilisation de grep pour construire des rapports un peu plus sexy qu’avec syslog. Pas transcendant lorsqu’on a mangé de la théorie des langages pendant sa scolarité mais toujours utile de faire un petit rappel.

Postnet : Une nouvelle ère de Botnet résilient

Présenté par deux étudiants, Julien Desfossez et David Goulet, cette conférence portait sur les réseaux de botnet. Mais si vous savez, tous ces pc transformés en zombie pour envoyer du spam. Et bien là, les deux compères ont présenté les concepts sous-jacents à de tels réseaux. N’entrant pas dans les détails techniques, il fallait attraper les “buzzword” pour comprendre le fonctionnement sous-jacent de tout ça. Cependant extrêmement intéressant car c’est un sujet mal documenté et très obscur. Ça m’a donné envie d’en écrire un

Mot de passe et mécanismes d’authentification

Peut être la meilleure présentation réalisé par Thomas Pornin. Il reprend des concepts très simples (compréhensibles sans pré-requis particulier) et les explique de manière posée. C’est ce que j’aime dans les études françaises. On part du bas pour aller vers le haut. De la preuve mathématique vers l’algorithme. C’est ce qu’il manque dans ce beau Canada, un peu de théorie fondamentale. Et mine de rien cela pose les bases d’une meilleure compréhension de la sécurité et des outils associés. Rien que pour ça, cette conférence est nécessaire. Ce serait un très bon cours de sécurité en soi.

Into the black : Explorations in DPRK

Quand un type farfelu vous parle de l’Internet en Corée du Nord et que ce type a des cheveux trop longs, cela ne peut être que Mike Temp. Complétement déjanté et délibérément provocateur, sa présentation était suffisamment dans le registre tragico-comique pour nous faire au moins un peu réfléchir. Mention spéciale tout de même aux diapos composées seulement d’images.

Bilan

Très bonne impression. On se marre bien, les sujets sont tous intéressants. Le choix des conférences est varié et les conférenciers bons. Que demande le peuple de plus ? Des photos ? Bon ok. Avec en bonus un nouveau concept de boisson. Après les boissons énergisantes, les boissons qui rendent molasson. Et c’est fait à Québec (les mauvaises langues diront qu’il y a un rapport).

Salut les jeunes, bon j’ai presque fini mes examens mais pas totalement. En réalité il m’en reste un mais c’est du Java donc ça compte pas.

Passons aux choses sérieuses. Pour situer le contexte, je suis en 5eme année d’ingénieur. J’ai fait toute ma scolarité en France. Je finis maintenant tout ça au Canada et plus précisément à Montréal. Je suis aussi dans les télécommunications mais ça tout le monde s’en fout alors que c’est vachement cool.

Pour avoir un diplôme d’ingénieur au Canada (je généralise le système du Québec mais je ne sais pas si je peux, dans le doute je fonce), il faut finir un Baccalauréat. C’est en 4 ans et c’est un peu glandouille. Là-bas, tout marche par session ou trimestre. A chaque trimestre l’étudiant choisit ses cours et ainsi de suite jusqu’à un certain nombre de crédits où on lui donne un diplôme. En 4 ans grosso modo donc. Là où c’est drôle et triste à la fois, c’est que le fait de choisir ses cours fait que les mecs ne se connaissent jamais. C’est simple personne ne se connait dans les classes. Il n’y a pas comme je le disais dans un autre article d’esprit de corps. C’est tout à fait hallucinant pour quelqu’un comme moi qui vient d’une école où le monde se connaissait et s’amusait dans la bonne humeur. Et pourtant je suis un peu associable.

Sinon il y a la maîtrise qui se fait en 6 ans mais c’est un peu branlette. Les mecs ne font pas de travaux pratiques et remplacent cela par des lectures d’articles scientifiques. C’est une formation à broyer du papier et à faire du copier/coller d’article. C’est ce que j’ai entendu dire, c’est pourquoi on retrouve majoritairement dans ces formations des Français ou des populations maghrébines (beaucoup, mon meilleur binôme est par exemple Tunisien).

Je rajoute que pendant le baccalauréat, trois stages sont obligatoires et je rajouterai même que beaucoup d’étudiants bossent pendant leurs études ce qui n’arrange pas le côté un peu perso et individualiste de toute la gang (oui au Québec les mots anglais sont féminins alors ferme ta switch s’il te plaît).

Sinon le Québecois n’est pas très nerveux au boulot. Je sais que je ne suis pas quelqu’un de facile pour travailler avec, mais il y a des limites. Cela vient du fait non seulement que le rapport d’autorité est complètement inversé (les élèves font des commentaires et des réclamations d’un niveau qu’on ne peut pas imaginer en France même avec beaucoup de mauvaise foi et j’en ai) mais les travaux pratiques (ici laboratoire) sont très facilement notés. Les systèmes de quizz(petit devoir de 20 minutes assez facile) le sont également. Tout cela fait que le Québecois ne connait pas la pression et qu’il est pépère car le taux d’échec est très très bas. Cela peut s’expliquer par le fait que les cours sont payants, les associations étudiantes sont très puissantes (les profs mal notés passent devant la commission des élèves, j’en connais qui serrent les fesses).

Mais je m’égare totalement dans mon exposé. Pour peu qu’on trouve les bons, certains Québecois sont vraiment cool et brillants. Juste pas tous. J’ai juste fini pas plus tard que hier un devoir à 5h30 du matin parce que mon binôme de maîtrise (censé être un semi dieu par rapport à moi) pense qu’un code unitaire mal codé vaut preuve de bon fonctionnement. J’ai appris J2EE et JavaME en une soirée bien condensée et je n’en veux plus non merci.

Bref, j’allais parler des examens. Toujours dans la veine zen, cela ne gêne personne que certains arrivent en retard (pas stressés non plus, ça me rappelle quand je jouais ma vie sur chaque ds de maths en prépa), se lèvent pour interroger le professeur. On est pas dans la révision intense, si je révise la veille au soir c’est bien et si j’ai plus d’un devoir par jour c’est déjà trop. Ici, on ne répond pas à une question si l’on ne connait pas la réponse !

Je m’égare encore. Les examens sont presque exclusivement réalisés avec des crayons de bois. Je dois être le seul à utiliser mon stylo plume (qui est un concept inédit ici). On nous donne des feuillets de pages à remplir. Le papier est trop fin pour mon stylo plume donc j’écris sur seulement un recto. A cause de mon style d’écriture, j’écris beaucoup de feuillets et cela semble assez peu banal. Je n’ai pas d’examen de matière calculatoire, seulement du blabla donc c’est assez aisé.

Voilà vous savez tout !

Comme personne n’avait de voiture, nous avons loué un monstre de Toyota, une sorte de van 8 places. La voiture en soi était moche mais le luxe était là avec la petite caméra sur le tableau de bord lorsque la marche arrière était enclenchée.

Nous sommes allés à Morin Heights, une station de ski à 1h30 de route au nord de Montréal. Nous avons escaladé tant bien que mal une piste de ski. Le terrain était boueux à cause des pluies des derniers jours. Après cette petite aventure à côté des remonte pentes, nous sommes allés faire un tour le long d’une rivière où nous avons pique-niqué. Les promeneurs étaient nombreux et beaucoup de personnes profitaient de l’accro-branche du coin.

Une journée bien sympathique à l’air libre loin de la ville. Il faut en profiter, la température maximale pendant la journée a dû être 14°c.

Tout ça pour dire que le ski au Canada ça ne fait pas rêver. La station est juchée sur une colline pas très haute. Ils n’ont pas de pistes rouge, verte, bleue. La signalisation est faite avec des carrés et des losanges. A côté de cette station se situe un camping assez grand. Sinon c’est le désert.

Tout d’abord parlons de mes petites aventures culinaires. J’ai pu tester un pub Irlandais. Bonne ambiance avec un groupe qui reprenait des gros hits comme Rage against the machine (en version très calme !) et des morceaux plus pop. La bière est toujours aussi chère, une pinte de Guiness coûte dans les 8$50. Ajoutez à cela les 1$ de pourboire usuel. On n’en commande pas plusieurs ! S’en suit une petite virée dans un restaurant indien de la rue Saint Denis. Vous avez tout ce qu’il faut pour sortir dans cette rue, des bars et des restaurants. Pour les boîtes de nuit et les clubs, il faut aller un chouïa plus loin (mais vraiment un chouïa) dans la rue Laurier. C’est simple, il y avait tellement à manger pour 25$ que j’ai dû prendre un doggy bag. C’est un petit sac qui permet d’emmener chez soi ce que l’on a pas consommé. C’est tout à fait dans les mœurs. J’ai testé ensuite Les trois brasseurs. Tout le monde me dit qu’il y en a aussi en France. C’est très sympa, la musique y est un peu forte mais le choix des plats est pas mal. L’assortiment de légumes (brocolis et poivrons) a été servi avec tous les plats (même avec une choucroute !). La bière est plus abordable que chez l’Irlandais aussi.

Parlons maintenant de ma première semaine de cours. Je me fais assez bien au rythme de mon emploi du temps. Je commence souvent l’après-midi et je finis soit à 20h, soit à 21h30. Mon binôme tunisien me dit que les rapports de TP sont souvent très bien notés car l’encadrant ne prend pas la peine de tous les lire. De plus, les examens semblent assez faciles selon ses dires (c’est sa troisième session) car ils ne comportent que des questions de cours et pas de problèmes. Cela me semble très possible car le taux d’échec est très bas.

Un dernier petit mot sur mes relations avec les Québecois. J’ai deux binômes québecois pour l’instant. Le reste étant étranger ou français. Ils ne se mélangent pas du tout et même entre eux vivent entre petits clans. C’est une société très individualiste. La notion d’ami tel que nous l’entendons ne semble pas vraiment exister. Par exemple j’ai vu dans un cours un Québecois pure souche demander au professeur de lui trouver un binôme car il n’en trouvait pas. C’était pourtant un mec qui faisait partie d’un gros club d’informatique, bref quelqu’un de sûrement très compétent. Et aucun Québecois ne s’est mis avec lui. Il se retrouve donc avec un tunisien de 40 berges. De la même façon, il n’est pas rare de voir des gens seuls manger au restaurant ou aller au bar. C’est très bizarre. Et si tu ne fais pas partie d’un groupe, tu ne t’insères pas comme ça. Il n’existe pas de notion d’esprit de promotion comme on en voit en France ou de camaraderie. Ceci est sûrement renforcé par le fait qu’il y ait beaucoup de personnes qui travaillent ou qui sont assez âgées dans mes cours. Ce n’est peut être pas vrai pour les niveaux d’études inférieurs.

Bientôt des articles techniques. J’ai un sujet de TP sur JavaMe pour des cibles BlackBerry. Cela semble, à défaut d’être très utile, assez rigolo.