fréquence d'interrogation

bah moi no pb avec les jsp arg suis je bête c'est normal ce sont des jsp

dfeprod a écrit:

avec mon-domaine.fr/vl/bc.jsp j'ai page introuvable

C'est qui ton hébergeur ? Il est pas sympa d'empêcher la redirection des erreurs 404 :|
A tout hasard tu peux essayer de remplacer le contenu du fichier .htaccess par :

Code:

RewriteEngine on
RewriteRule ^bc.jsp$  bc.php [L]

On sait jamais, s'il accepte les url rewrite...

Sinon je vois pas trop comment faire... A part faire comme clayde... :arrow:

J'ai un doute, tout d'un coup : il y a bien le fichier .htaccess dans ton mon-domaine.fr/vl/ ?

spi a écrit:

Est - ce que par hasard, il n'y aurait pas un port ouvert du lapin sur lequel je pourrai me connecter pour lui envoyer des commandes ?

nmap ne donne rien :
The SYN Stealth Scan took 165.72s to scan 1680 total ports.
Host 192.168.1.5 appears to be up ... good.
All 1680 scanned ports on 192.168.1.5 are filtered

donc à priori rien d'ouvert.

oaz a écrit:

C'est quoi cet encodage des caractères pour les URLs des mp3 dans le bloc 0a ?
Chaque octet semble avoir une influence sur 3 ou 4 caractères de l'URL et chaque caractère semble être influencé par 2 ou 3 octets...

J'ai capturé une trame qui a été suivie par un "GET /broad/.../444.mp3"
en alignant correctement, je peux le mettre en correspondance le "/444" avec , dans la trame et en hexa : "70 7b 43 43"

de plus,
1° dans le .mp3 ou le .chor qui arrive suite à un bloc en 7f 0a, si on a un morceau de texte qui correspond à "/4", si on aligne correctement sur le dump de la trame, le 4 est TOUJOURS codé en 7b.
2° dans le .mp3 ou le .chor qui arrive suite à un bloc en 7f 0a, si on a un morceau de texte qui correspond à "44", si on aligne correctement sur le dump de la trame, le 2° caractére "4" est TOUJOURS codé en 43.
3° pour trouver le le bit de poids faible du caractére dans le mp3, il suffit d'inverser le bit de poids faible de l'octet correspondant dans la trame.

4° en coupant la trame sur 11 f9 f2, on retrouve vite un alignement correct :
get /broad/151/867/444.mp3
11_f9_f2_ee_fb_fa_c6_c0_9b_86_0d_f9_f2_ee_fb_66_9e_b6_02_f4_f7_c5_e2_70_7b_43_43_2d_80_7f_c2
____________________________/__b__r__o__a__d__/__1__5__1__/__8__6__7__/__4__4__4__.__m__p__3

( cut & paste avec une police de largeur fixe pour mieux comprendre)

5°, j'ai essayé des xor dans tous les sens, cela n'a rien donné ( je ne suis pas non plus infaillible )

Avec tout ça, je vois 2 trucs assez fiables :
- le bit de poids faible est inversé entre la version codé et la version claire.
- un octet en "clair" dépend uniquement de la valeur de la valeur du caractére en clair précédent.( style table de transcodage ).

Reste à essayer sniffer dans le bootstrap envoyé lors de la 1° connection aprés un on/off éléctrique et/ou sniffer dans le firmware , cela donnera peut etre des choses ...
Mais là, j'ai pas trop le temps, peux etre le weekend prochain

Faudrait aussi voir si en mode test usine, il y a des choses au niveau réseau...

Si table de transcodage il y a, un proxy pourrait peut etre forger des blocs pour essayer de voir comment c'est repassé en clair dans le "GET /broad/..."

Mais chacun à ses limites, qui prends la relève ?

Rhhaaaa gi-aif soit maudit. Je m'étais promis de me coucher un peu plus tôt ce soir.
Mais bon...

J'ai extrait quelques données de mes logs pour voir si tes trouvailles se retrouvaient systématiquement sur tous les appels de ping. Et je dois dire que c'est vraiment bien vu !
Le /broad est toujours 860df9f2eefb, le mp3 est toujours 807fc2

Avec les autres pistes que tu donnes, je crois qu'on est sur le bon chemin

Voici quelques trames pour ceux que ça intéresse (à visualiser en police taille fixe). On constate que les URLs sont listées autant de fois que le mp3 ou la chorégraphie sont joués et dans l'ordre où ils sont joués (même si le tag/tag ne va chercher le fichier qu'une seule fois, il est vraiment fort ce tag/tag).

7f0a00014e
011e5b4fe1e63_251848a8a2095_88a80f
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9c5ecc6184abdc05b0f9_807fc2_9526834f_a28e2bf518cbb81d_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__s_i_g_n_a_t_u_r_e_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_6e292cee6c9c5ecca08c7eb5d6639cf9ee876efd_71882445_88fe8f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__a_n_i_m_/_s_i_g___c_i_r_c_l_e_._c_h_o_r
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9e6b06dcd1_807fc2_953ffb4f_201d_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__1_4_/_3_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9e6b06dcd1_807fc2_d1ee876efd_71882445_88a80f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__1_4_/_3_.__m_p_3__._c_h_o_r
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9c5ecc6184abdc05b0f9_807fc2_9526834f_a28e2bf518cbb81d_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__s_i_g_n_a_t_u_r_e_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_6e292cee6c9c5ecca08c7eb5d6639cf9ee876efd_71882445
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__a_n_i_m_/_s_i_g___c_i_r_c_l_e_._c_h_o_r

7f0a00014e
011e5b4fe1e63_251b31c945921_88a80f
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9c5ecc6184abdc05b0f9_807fc2_9526834f_675f5f25b36a7f79_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__s_i_g_n_a_t_u_r_e_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_6e292cee6c9c5ecca08c7eb5d6639cf9ee876efd_71882445_88fe8f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__a_n_i_m_/_s_i_g___c_i_r_c_l_e_._c_h_o_r
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9eb67c3dc5_807fc2_953ffb4f_63a9_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__1_5_/_3_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9eb67c3dc5_807fc2_d1ee876efd_71882445_88a80f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__1_5_/_3_.__m_p_3__._c_h_o_r
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9c5ecc6184abdc05b0f9_807fc2_9526834f_675f5f25b36a7f79_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__s_i_g_n_a_t_u_r_e_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_6e292cee6c9c5ecca08c7eb5d6639cf9ee876efd_71882445
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__a_n_i_m_/_s_i_g___c_i_r_c_l_e_._c_h_o_r

7f0a00010a
011e5b4fe1e63_20e1a2bb80121_88a80f
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_fdb0283fb8b5fcabb0a481aa1acbf5e9c0a5f0283fb8b5fcabb0a4811f00a9_807fc2_95882445_88fe8f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__r_e_s_p_i_r_a_t_i_o_n_/_5_4_6_2_5_R_e_s_p_i_r_a_t_i_o_n_0_1_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_9c7205dfe1641002dc8969b29ed59f428e80c6fbec7f34b9e3ed_807fc2_953ffb4f_63a9_26a74f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__s_u_r_p_r_i_s_e_/_f_r_/_1_2_0_3_9_c_a_d_e_p_e_n_d_.__m_p_3
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_9c7205dfe1641002dc8969b29ed59f428e80c6fbec7f34b9e3ed_807fc2_d1ee876efd_71882445_88a80f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__s_u_r_p_r_i_s_e_/_f_r_/_1_2_0_3_9_c_a_d_e_p_e_n_d_.__m_p_3__._c_h_o_r
11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_fdb0283fb8b5fcabb0a481aa1acbf5e9c0a5f0283fb8b5fcabb0a4811f00a9_807fc2_95882445
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__r_e_s_p_i_r_a_t_i_o_n_/_5_4_6_2_5_R_e_s_p_i_r_a_t_i_o_n_0_1_.__m_p_3

je suis po sur que le broad soit dans la trame 7f09, n'oubliez pas qu'il est dans le résult du locate...
dans le résult d'un p4 il peut y avoir plusieurs fichiers
7f 0a : id
les 4 octets suivant la taille
....... prog en bytecode jusqu'à
F6 BB 4F 11 tjrs aprés (n fois car le p4 retourne n demande de fichiers):

F9 F2 EE BB
FA C6 C0 9B 86 0D
F9 F2 EE BB
66
(le nom du fichier sans le broad )

oaz a écrit:

011e5b4fe1e63_251848a8a2095_88a80f
011e5b4fe1e63_20e1a2bb80121_88a80f

rigolo j'avais po moi 88a80f (quel firmware ?) mais F6 BB 4F (firmware 0.9)
donc je modifie ce que j'ai dis :

f 0a : id
les 4 octets suivant la taille
....... prog en bytecode jusqu'à
F6 BB 4F ou 88 a8 0f

puis
11
F9 F2 EE BB
FA C6 C0 9B 86 0D
F9 F2 EE BB
66
(le nom du fichier sans le broad )

clayde a écrit:

rigolo j'avais po moi 88a80f (quel firmware ?) mais F6 BB 4F (firmware 0.9)

0.10 pour moi

clayde a écrit:

donc je modifie ce que j'ai dis :

f 0a : id
les 4 octets suivant la taille
....... prog en bytecode jusqu'à
F6 BB 4F ou 88 a8 0f

puis
11
F9 F2 EE BB
FA C6 C0 9B 86 0D
F9 F2 EE BB
66
(le nom du fichier sans le broad )

Oui tu as raison : le broad peut tout aussi bien ne pas être présent dans ces trames. Cependant, je n'ai pas vu de '/broad' dans le bc alors qu'y figurent en clair '/locate.php?sn=', '/vl/p4.php?sn=' et '/vl/record.php?sn='
C'est d'ailleurs un mystère pour moi : pourquoi ces caractères sont-ils en clair dans le bc et pas dans le p4 ?

Donc ce dont on peut être 'à peu près sûr' dans un 7f0a:
- chaque 'bloc fichier' débute par 11f9f2ee....f2eefb66 (peu importe si le '/broad/' en fait partie ou pas)
- cette séquence est suivie du reste du chemin du fichier avec autant d'octets que de caractères mais avec un encodage qui fait dépendre chaque caractère du nom de fichier de l'octet qui lui correspond et (au moins) de l'octet précédent.

oaz a écrit:

- cette séquence est suivie du reste du chemin du fichier avec autant d'octets que de caractères mais avec un encodage qui fait dépendre chaque caractère du nom de fichier de l'octet qui lui correspond et (au moins) de l'octet précédent.

c'est clair, il va falloir lire en binaire pour faire la correspondance.

clayde a écrit:

rigolo j'avais po moi 88a80f (quel firmware ?) mais F6 BB 4F (firmware 0.9)

On le voit où le firmware ?
Car de mon coté, je serais plus à F6 BB 4F, ce qui voudrais dire un firmware 0.9 ... mais je voudrais vérifier...

Pixel du Rezo a écrit:

clayde a écrit:

rigolo j'avais po moi 88a80f (quel firmware ?) mais F6 BB 4F (firmware 0.9)

On le voit où le firmware ?
Car de mon coté, je serais plus à F6 BB 4F, ce qui voudrais dire un firmware 0.9 ... mais je voudrais vérifier...

sur l'appel du bc.jsp tu devrais voir un paramêtre firm il me semble

moi, j'ai ca:
/vl/bc.jsp?v=0.0.0.10&m=Mo:n_:ad:re:ss:e_&l=00:00:00:00:00:00&p=00:00:00:00:00:00&h=4

Pas de trace de "firm" dans mes logs...

Pixel du Rezo a écrit:

moi, j'ai ca:
/vl/bc.jsp?v=0.0.0.10&m=Mo:n_:ad:re:ss:e_&l=00:00:00:00:00:00&p=00:00:00:00:00:00&h=4

Pas de trace de "firm" dans mes logs...

oki mauvaise mémoire c'était v lol donc tu es en v 0.10

oui, j'aurais aussi pu le deviner tout seul.. je suis vraiment pas reveillé.

Par contre, ca veut dire que le bout de code 88 A8 0F ou F6 BB 4F n'est pas lié au firmware...

Citation :

get /broad/151/867/444.mp3
11_f9_f2_ee_fb_fa_c6_c0_9b_86_0d_f9_f2_ee_fb_66_9e_b6_02_f4_f7_c5_e2_70_7b_43_43_2d_80_7f_c2
____________________________/__b__r__o__a__d__/__1__5__1__/__8__6__7__/__4__4__4__.__m__p__3

first jet
je pense qu'il ne faut pas se péoccuper de l'octet mais de la séquence binaire (il y a découpe )on retrouve ainsi trois séquence pour le 444 qd on étudie le 7b 43 43 2d :
1111 011 _ 010 0011 _ 010 0011 _ 010 1101
on retrouve si on coupe en 2 l'octet :
011 010 | 011 010| 011 010
piste à suivre ...

gi-aif a écrit:

Si table de transcodage il y a, un proxy pourrait peut etre forger des blocs pour essayer de voir comment c'est repassé en clair dans le "GET /broad/..."

Mais chacun à ses limites, qui prends la relève ?

Dans ma précipitation d'hier, je n'avais pas lu ce message.
Si je comprends bien, tu suggères, puisque la valeur d'un octet transcodé dépend de (1) l'octet précédent (2) le caractère encodé, de reconstituer une table à 2 entrées permettant de programmer un tel encodage ?
Du genre :
Si le caractère précédent est un '/' alors :
1 est encodé 9e
3 est encodé dc
8 est encodé f7
4 est encodé 7b
5 est encodé 1a
a est encodé 6e
c est encodé ac
f est encodé 89
r est encodé fd
s est encodé 9c
....

C'est vrai que si une telle table se confirme, ça nous libèrerait des recherches sur les bits.
Je vais m'empresser de coder la reconstitution d'une telle table à partir des messages que reçois mon OpenNab.

oaz a écrit:

C'est vrai que si une telle table se confirme, ça nous libèrerait des recherches sur les bits.
Je vais m'empresser de coder la reconstitution d'une telle table à partir des messages que reçois mon OpenNab.

L'ideal serait de mettre tout ca dans une base de données, avec 3 colonnes: caractère, caractère avant, et encodage.

a partir de là, si tous les appels sont loggués, on devrait deja remplir une bonne partie de la table.

J'ai fais quelques tests avec les trames que tu as postés ici oaz.
Et ca semblerait (je dis bien semblerait) valider l'hypothèse d'une table de codage.

Ce que j'ai fait:
un tableau excel (oui, pas d'automatisation pour le moment) avec un tete comme ca:

Code:

  . _ / 0 1 2 3 4 5 6 7 8 9 a b c d ...
.
_
/
0
1
2
3
4
5
6
7
8
9
a
b
c
d

La ligne du haut est le caractère "décodé", tandis que la 1ere colonne correspond au caractère "décodé" précédent.
En utilisant les 2 premieres trames, il en ressort que après le "c", on a:
i => 7e
k => 6c
l => 63
o = 48

Si vous regardez de plus près, on peut trouver une suite (-9 entre chaque caractères)
Ce -9 n'est pas le meme pour les autres lignes, mais je pense qu'on s'approche

Citation :

C'est vrai que si une telle table se confirme, ça nous libèrerait des recherches sur les bits.

c'est clair que ça irait plus vite...

Arg !
sauf s'il y a une erreur dans les trames postées par oaz, j'ai un truc qui colle pas :-(

Code:

11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9eb67c3dc5_807fc2_d1ee876efd_71882445_88a80f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__1_5_/_3_.__m_p_3__._c_h_o_r

car on a /3.mp3 (le point serait codé C5 après un 3)
puis mp3.chor (le point serait codé D1 après un 3)

clayde a écrit:

je suis po sur que le broad soit dans la trame 7f09,

J'en suis arrivé à la meme conclusion aprés avoir reçu un /broad/config/anim/sig_nombril.chor
le codege du r dans nombril de correspond pas au r dans broad

oaz a écrit:

Si je comprends bien, tu suggères, puisque la valeur d'un octet transcodé dépend de (1) l'octet précédent (2) le caractère encodé, de reconstituer une table à 2 entrées permettant de programmer un tel encodage ?
Du genre :
Si le caractère précédent est un '/' alors :
1 est encodé 9e
3 est encodé dc
8 est encodé f7
4 est encodé 7b
5 est encodé 1a
a est encodé 6e
c est encodé ac
f est encodé 89
r est encodé fd
s est encodé 9c
....

C'est vrai que si une telle table se confirme, ça nous libèrerait des recherches sur les bits.
Je vais m'empresser de coder la reconstitution d'une telle table à partir des messages que reçois mon OpenNab.

C'est tout à fait ça,
Et je vais meme plus loin : on modifie 1 ou 2 octets dans le nom codé du fichier, et on vois ce que cela donne dans le GET qui va suivre
... ou ne pas suivre si plantage

oaz a écrit:

Rhhaaaa gi-aif soit maudit. Je m'étais promis de me coucher un peu plus tôt ce soir.
Mais bon...

Et tu penses que j'ai bien dormi aprés avoir trouvé ça ?

Pixel du Rezo a écrit:

Arg !
sauf s'il y a une erreur dans les trames postées par oaz, j'ai un truc qui colle pas :-(

Code:

11f9f2eefbfac6c09b_860df9f2eefb66ac4881cd3cccd0_ac63b62c6c988969b2_9eb67c3dc5_807fc2_d1ee876efd_71882445_88a80f
___________________/_b_r_o_a_d_/_c_o_n_f_i_g_/__c_l_o_c_k_/_f_r_/__1_5_/_3_.__m_p_3__._c_h_o_r

car on a /3.mp3 (le point serait codé C5 après un 3)
puis mp3.chor (le point serait codé D1 après un 3)

Sauf si il y a un ou 2 octets qui typent le fichier qui suit auquel cas, le suffixe mp3 ou chor serait superfétatoire inutile..