[C] Socket + envoie de commande

[notfound]

[supersnail]

Et t'as quoi si tu fais "Follow TCP Stream" ?

[notfound]

Et t'as quoi si tu fais "Follow TCP Stream" ?

J'ai la chose suivante :





EDIT :
Avec le logiciel EPSON, j'obtiens la chose suivante en analysant la trame :



Or, j'arrive à obtenir le début, mais pas la suite. Malgré le fait que j'envoie ensuite les autres instructions ...




Quelqu'un aurait une idée de génie ?

[gruik]

Si quelqu'un aurait une idée

ben j'ai l'impression que tu causes simplement pas exactement le même protocole que l'appareil en face

sur la capture des paquets, on voit clairement l'établissement de connexion (SYN - SYN/ACK - ACK), tu envoies 1 paquet de données (PUSH), le serveur te répond un truc lui aussi (PUSH), puis l'un des deux met fin à la connexion (toi avec ton FIN à priori ?)

et au niveau du "follow tcp stream" dans wireshark, on voit bien qu'un dialogue normal avec le videoprojecteur, on envoit un paquet (probablement pour dire bonjour), on recoit un paquet du serveur (le meme que tu recevais en envoyant ton PWR OFF), puis on envoit un 2nd paquet à priori pour lui demander la version du protocole ou du logiciel ou autre, le serveur répond et après seulement on renvoit un paquet avec la commande PWR OFF

difficile de dire beaucoup plus, si vraiment tu galères ca pourrait etre une bonne idée de mettre les .pcap en piece jointe éventuellement...

[notfound]

Est-ce que ça ne viendrait pas de mon code C ?

Code C :


recv(sock, reponse, MAX, 0);
printf("[+] Reponse du serveur : %s \n", reponse);
close(sock);
 

Peut-être ne faut-il pas que je close ma socket ?

[supersnail]

Ben ça dépend (comme le dit gruik) de comment c'est implémenté au niveau de ton vidéoprojecteur.

Et comme j'ai dit iirc, le plus simple dans ce cas c'est de faire du reverse-engineering sur l'application "officielle" pour comprendre comment c'est fait.

Et comme dit gruik (again :>), file-nous le .pcap de la transmission "officielle" faite par le prog epson pour y voir plus clair

[notfound]

Le fichier .pcap du trafic entier "officiel" avec le logiciel EPSON

http://dl.free.fr/getfile.pl?file=/lSJuWFKk

[Kiwazaru]

[gruik]

je crois plutot que le probleme vient du fait qu'il n'envoit qu'un seul paquet et ferme la connexion, à mon avis envoyer un paquet bonjour / attendre la reponse du videoprojecteur / envoyer la commande IMPWR OFF doit suffire

edit:
paquet bonjour : "ESC/VP.net\x10\x03\x00\x00\x00\x00"
=> doit recevoir du vp : "ESC/VP.net\x10\x03\x00\x00\x20\x00"
paquet commande : "IMPWR OFF\n"
=> et là encore le vp renvoit qqes données

suite à ça... j'imagine que le vp shutdown donc qu'on peut fermer la connexion comme un sale, à tester...

[Kiwazaru]

"ESC/VP.net\x10\x03\x00\x00\x00\x00" les \xXX\ derrière servent à quoi?

[gruik]

c'est une notation hexadecimale, 0x41 == \x41 == 'A' == 101o (octal) == 0o101
sinon c'est très exactement ce qu'on voit transiter dans la capture en l'occurence, pour des raisons de lisibilité wirehsark remplace les caractères ASCII non-printable par des points '.'

[Kiwazaru]

Yep mais comment tu as su que c'était \x10\x03\x00\x00\x00\x00 0x10 puis 0x03 etc ? Vu qu'on ne vois que des points.

[gruik]

ben en fouillant dans les bons paquets (tcp push)et en regardant le détail, ou dans la vue "follow tcp stream" tu peux aussi switcher vers "raw" ou "C array"

edit: typiquement le paquet n°14 de la capture, dans la fenetre principale cliquer sur "data" met en surbrillance dans le paquet les octets en question par exemple

[notfound]

BTW, j'ai réussi hein (cf. edit 1er post)

[Kiwazaru]

Yep j'ai look

Code C :

char peer1_0[] = {
0x45, 0x53, 0x43, 0x2f, 0x56, 0x50, 0x2e, 0x6e,
0x65, 0x74, 0x10, 0x03, 0x00, 0x00, 0x20, 0x00 };

On vois bien la chaîne "0x10, 0x03, 0x00, 0x00, 0x20, 0x00" qui donne ton code ensuite