Avant de m'étendre là dessus un petit mot sur la courbe utilisée par Armadillo. Déjà plutôt que d'utiliser les courbes "standards" du NIST ou du SECG il fait le malin et utilise une courbe sortie de "nulle part". La seule information que l'on a est l'ordre premier du générateur que l'on trouve dans les SDR : 5192296858534827627896703833467507

Une recherche sur google nous informe que l'ordre premier correspond à une courbe de Koblitz sur GF(2^113) décrite dans les specs WAP WTLS de 1999.

La courbe utilisée est donc : y² + xy = x^3 + x² + 1. Qui est utilisée dans GF(2^113) construit à l'aide du polynôme x^113 + x^9 + 1. (à vérifier pour le polynôme)

On vérifie avec Pari GP (au passage petite pub pour ce merveilleux outil dev par des français (cocorico)) :

(21:47) gp >  gf = ffgen(Mod(1,2)*(x^113+x^9+1))                                time = 0 ms.
%1 = x
(21:47) gp > e = ellinit([1,1,0,0,1])                                           time = 0 ms.
%2 = [1, 1, 0, 0, 1, 5, 0, 4, 5, 25, -989, -557, -15625/557, [-1.627524374728508475847551213, 0.1887621873642542379237756065 - 0.7607883796077915001151281354*I, 0.1887621873642542379237756065 + 0.7607883796077915001151281354*I]~, 4.319289634023725525717193601, 2.159644817011862762858596801 - 1.130485447887283043983103252*I, 2.614355328193713389891272325 - 5.04870979 E-29*I, 1.307177664096856694945636163 + 0.7704263744753850346564148888*I, 4.882894076474210213866946808]
(21:47) gp > ellpow(e,[gf+1,ellordinate(e,gf+1)[1]],5192296858534827627896703833467507)
time = 12 ms.
%3 = [0]

youpi !

Bon maintenant il reste à chercher le générateur utilisé (est ce le standard ou un autre ?), à voir comment le sérial est transformé en abscisse, a confirmé que Armadillo utilise bien Nyberg-Rüeppel etc. et pour ça il faut bien mettre les mains dans le code ...

Armadillo ne nous aide pas vraiment, la librairie de bignum utilisée semble être maison (enfin j'espère vu la qualité du code ...), elle est compilée visiblement en mode debugg, il y a des traces de variables de debugg un peu partout, le code n'est ABSOLUMENT PAS optimisé par le compilo etc.

On se retrouve donc à tracer du code dégueulasse sous olly en essayant de défricher un peu le tout à l'aide de IDA et là on tombe sur des énormités sans noms ...

Des BigNums constants créés et détruits à chaque tour de boucle au lieu de les crée une fois avant la boucle et de les détruire après.

Une ENORME routine utilisant les modulos / divisions / décalages / multiplications (le tout sur des bignums je le rappelle ...) pour transformer un BigNums en sa représentation hexadécimale en little endian .... représentation directement accessible dans la structure du bignum, un memcpy aurait suffit ...

Bref, c'est horrible à tracer, c'est une saloperie sans nom et n'ayant pas de twitter pour me plaindre, je me permet de le faire sur mon blog :p

Je vous tiens au courant de mon avancé concernant ce reverse, par contre je suis aussi en stage donc je ne pourrai bosser dessus qu'en dehors de mes horaires de boulot ;)