My Opera
It's fun to play with the D.M.C.A.
Sunday, September 6, 2009 9:40:00 PM
Ca fait quelques mois que mes outils pour lire directement sa musique sur le site Imeem ne fonctionnent plus. On tombe à la place sur une espèce de message de répondeur où quatre voix féminines nous informent qu'il faut passer par le site Internet.
J'avais étudié quelques captures réseau pour comprendre ce qu'il cloche sans jamais voir d'où ça pouvait venir, j'ai essayé différentes clés d'API sans meilleur résultat.
En fin de compte il s'avère que Imeem a quelque peu modifié sa fonction non documentée mediaGetStreamInfo. Auparavant un paramêtre "referrer" était passé et pouvait contenir plusieurs valeurs possibles, celle habituelle étant la chaine de caractères "web".
Ce paramêtre a été modifié : à l'ancienne valeur est maintenant accolé un pipe "|" puis une longue chaine de caractères (118 caractères) formatée (à priori) selon l'algorithme utilisé pour les urls des flux.
D'après le code décompilé, Imeem a rajouté une fonction baptisée "authenticateRequest" qui génère un hash MD5 qui sera envoyé au serveur comme variable de referrer.
Les codes Flash décompilés étant généralement à la limite du compréhensible
j'ai fait le lien grâce au fait que cette fonction utilise une constante nommée "REFERRER_ENCRYPTION_KEY" de type string et de valeur "faad2ae444233f97367cc35da6de80b51767f182".
Dans le code il reste tout de même deux variables dont l'identité reste mystérieuse... l'une semble liée au temps, l'autre est probablement un caractère de délimitation (voire rien du tout).
On remarque si on joue plusieurs titres à la suite, ce referrer "magique" ne change pas même après 10 minutes passées. On trouve dans le code des références à l'heure courante, ce qui laisse supposer qu'un indicatif d'heure (arondi) est utilisé.
Enfin une autre variable constante fait référence au temps : "REFERRER_TIMESTAMP_THRESHOLD" de valeur 30000 (secondes ?)
Pour le moment je n'ai fait que quelques tests rapides. Il faut tout de même que ces deux variables soient assez longues pour que la forme encodée atteigne 118 octets... L'hypothèse qu'un "vrai" referrer (http://bidule...) soit utilisé n'est donc pas exclue
J'avais étudié quelques captures réseau pour comprendre ce qu'il cloche sans jamais voir d'où ça pouvait venir, j'ai essayé différentes clés d'API sans meilleur résultat.
En fin de compte il s'avère que Imeem a quelque peu modifié sa fonction non documentée mediaGetStreamInfo. Auparavant un paramêtre "referrer" était passé et pouvait contenir plusieurs valeurs possibles, celle habituelle étant la chaine de caractères "web".
Ce paramêtre a été modifié : à l'ancienne valeur est maintenant accolé un pipe "|" puis une longue chaine de caractères (118 caractères) formatée (à priori) selon l'algorithme utilisé pour les urls des flux.
D'après le code décompilé, Imeem a rajouté une fonction baptisée "authenticateRequest" qui génère un hash MD5 qui sera envoyé au serveur comme variable de referrer.
Les codes Flash décompilés étant généralement à la limite du compréhensible
j'ai fait le lien grâce au fait que cette fonction utilise une constante nommée "REFERRER_ENCRYPTION_KEY" de type string et de valeur "faad2ae444233f97367cc35da6de80b51767f182".Dans le code il reste tout de même deux variables dont l'identité reste mystérieuse... l'une semble liée au temps, l'autre est probablement un caractère de délimitation (voire rien du tout).
On remarque si on joue plusieurs titres à la suite, ce referrer "magique" ne change pas même après 10 minutes passées. On trouve dans le code des références à l'heure courante, ce qui laisse supposer qu'un indicatif d'heure (arondi) est utilisé.
Enfin une autre variable constante fait référence au temps : "REFERRER_TIMESTAMP_THRESHOLD" de valeur 30000 (secondes ?)
Pour le moment je n'ai fait que quelques tests rapides. Il faut tout de même que ces deux variables soient assez longues pour que la forme encodée atteigne 118 octets... L'hypothèse qu'un "vrai" referrer (http://bidule...) soit utilisé n'est donc pas exclue
