Discussion :

[manry]

Bonjour,

Je suis actuellement sur un projet de socket en assembleur, la définition de la socket en elle meme est bonne mais lorsque je fais la méthode connect j'ai un problème je n'arrive pas à lui faire passer le port.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
; connect
        mov eax, 362
        mov ebx, edx    ; fd de la socket
        ; utilisation de la stack pour l'ip / port cible à l'envers
 
        push 0x3905     ; port de la machine ou se connecter 1337 -> 14597 avec htons
;       push DWORD 0x2b03210a   ; ip de ma machine 10.33.3.43
        push DWORD 0x0100007f   ; ip de ma machine 127.0.0.1
        push 0x2        ; AF_INET
 
        mov ecx, esp    ; adresse de la structure sur la stack
        mov edx, 16     ; taille de la structure (2eme parametre)
        int 0x80

et lorsque je strace le tout j'ai ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)

on peut voir le htons(0).

je en comprends pas bien comment ca se fait mais si quelqu'un pouvais m'aider

merci bien à vous

[BufferBob]

salut,

tu n'as pas précisé l'OS et l'architecture, on suppose que c'est une machine 32bits sous Linux, où __NR_socketcall vaut normalement 102 (en décimal), du coup ma première interrogation; d'où sort la valeur "362" ligne 3 ?

aussi quand tu push le port il est stocké sur 16bits donc il faut le spécifier explicitement avec un push word

et vu d'ici je pense que tu pousses les paramètres de connect() à l'envers sur la pile, si dans l'ordre tu dois avoir inet_family, port, addr, alors tu dois push dans cet ordre addr, port, inet_family, là tu push le port avant l'addr

précise un peu plus le contexte/le reste du code si tu veux qu'on puisse tester

[manry]

salut,

oui au temps pour moi c'est du linux 32 bits,

voici le choix des appels systèmes que j'utilise:

en fait lorsque tu fais un man socketcall (qui l'appel système 102 dont tu parles) sur linux il disent :

NOTES
On a some architectures—for example, x86-64 and ARM—there is no socket‐
call() system call; instead socket(2), accept(2), bind(2), and so on
really are implemented as separate system calls.

On x86-32, socketcall() was historically the only entry point for the
sockets API. However, starting in Linux 4.3, direct system calls are
provided on x86-32 for the sockets API. This facilitates the creation
of seccomp(2) filters that filter sockets system calls (for new user-
space binaries that are compiled to use the new entry points) and also
provides a (very) small performance improvement.

et comme je suis en 4.5 je vais regarder du côté du socket (qui correspond au 359 sur du 32 bits), la tout se passe bien mais je copie-colle mon code quand même

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
mov eax, 359	; sys_socket
	mov ebx, 2	; protocol 0 -> le noyau determine 
	mov ecx, 1	; SOCK_STREAM
	mov edx, 0	; AF_INET
	int 0x80

je vois avec strace que tout se passe bien, ma socket est créer je passe donc au connect et il correspond au 362 que tu peux apercevoir dans mon précédent post

ce qui se vérifie avec un :
grep -i connect /usr/include/x86_64-linux-gnu/asm/unistd_32.h
#define __NR_connect 362

de la je regarde le man connect et je vois :
int sockfd, const struct sockaddr *addr, socklen_t addrlen

mon sockfd est bien enregisté sur le filedescriptor 3 (et il est correct avec strace) et j'ai vu que lorsque je suis en AF_INET je peux utiliser la structure sockaddr_in à la place de la sockaddr dont le prototype est le suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
struct sockaddr_in {
    short            sin_family;   // e.g. AF_INET
    unsigned short   sin_port;     // e.g. htons(3490)
    struct in_addr   sin_addr;     // see struct in_addr, below
    char             sin_zero[8];  // zero this if you want to
};
 
struct in_addr {
    unsigned long s_addr;  // load with inet_aton()
};

la en effet je suis d'accord avec toi je pousse mes arguments sur la stack pas dans le bon ordre mais je ne comprends pas pourquoi avec strace il me renvoie bien la bonne IP (comme dans mon précedent post) seulement comme le dis le prototype de fonction c'est une structure pour l'IP mais il à l'air de comprendre quand je lui passe.

et pour finir je dois passer 14 edans edx (la taille de la sctructure en 2ème argument, j'ai mis 16 pour faire un test mais pas vraiment concluant et j'ai pas rechangé derrière)

voila je ne comprends pas pourquoi il ne me prends pas mon port

[BufferBob]

(...) je suis en 4.5 (...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
grep -i connect /usr/include/x86_64-linux-gnu/asm/unistd_32.h
#define __NR_connect 362

ok au temps pour moi, quand j'ai regardé la correspondance ce matin j'étais sur une VM un peu vieillissante

(...) je dois passer 14 edans edx (...) j'ai mis 16 pour faire un test

sin_family 2 octets, sin_port 2 octets, s_addr 4 octets, plus le padding 8 octets, ça fait bien 16 octets la structure sockaddr_in

voila je ne comprends pas pourquoi il ne me prends pas mon port

en même temps on sait pas quelle modification tu as apporté concrètement à ton code, notamment si tu as pris en compte ma troisième remarque concernant l'alignement des données poussées sur la stack

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
push dword 0          ; sin_zero
push dword 0          ; sin_zero
push dword 0x0100007f ; s_addr 127.0.0.1
push word 0x3905      ; sin_port 14597
push word 2           ; sin_family AF_INET

ça devrait marcher normalement. à tester.

[manry]

MERCI BufferBob,

J'ai pas compris pourquoi ca fonctionnais pas avant et maintenant oui(d'ailleurs si jamais tu repasses par la je veux bien si tu à le temps une explication ), par contre j'ai d'autres problèmes mais si besoin je ferai une autre discussion

[BufferBob]

J'ai pas compris pourquoi ca fonctionnais pas avant et maintenant oui(d'ailleurs si jamais tu repasses par la je veux bien si tu à le temps une explication )

pas de problème, c'est pas le temps qu'il manque ici, comme dit précédemment c'est plutôt des détails/une question qui font défaut (non je suis pas très bon pour deviner, quand tu parles de "avant" et "maintenant" je sais pas à quoi tu fais référence, quand tu dis "je comprends pas" je sais pas ce que tu ne comprends pas exactement, ce genre de détails...)
je peux éventuellement te donner une excellente recette de crêpes en attendant mais ton connect ne s'établira pas mieux

[manry]

oui en effet ^^

en fait je ne comprends pas pourquoi mon ancien code (celui qui ne fonctionne pas) avait quand même la bonne IP (127.0.0.1) alors que l'ordre des arguments n'étaient pas bon puisque j'envoyais le port en 1er et l'IP en second.

De plus je ne comprend une fois j'ai lu dans un bouquin que la structure sockadd et sockaddr_in avait la même taille (14 octets) alors que la tu me dis 16 (par calcul )

et lorsque tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
push dword 0
push dword 0

un dword ce n'est pas deja 8 octets?

merci

[BufferBob]

un dword ce n'est pas deja 8 octets?

nope, c'est 4, 32bits (word 16bits, dword 32, qword 64, et comme tu es sous une machine 32bits, c'est normal que tu ne puisses pas push 64bits d'un coup sur la pile)

en fait je ne comprends pas pourquoi mon ancien code (celui qui ne fonctionne pas) avait quand même la bonne IP (127.0.0.1) alors que l'ordre des arguments n'étaient pas bon puisque j'envoyais le port en 1er et l'IP en second.

pour rappel tu faisais ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
push 0x3905
push DWORD 0x0100007f
push 0x2

et à la fin tu récupère l'adresse du début de ta stack dans ecx qui contient donc l'adresse du début de ta structure (ben oui, faut la lire à l'envers du coup)
donc en dépilant connect() trouve en priorité ton push 2, qui sans autre spécification est par défaut un push dword 2 (32bits donc, pour des raisons d'alignement, donc 0x00000002), donc les 16 premiers bits de la stack sont 0x0002, suivis de 0x0000, suivis de 0x0100007f, pour connect() le compte y est, mais le numéro de port provient de l'oubli d'un push word 2, cqfd

[manry]

(...)cqfd

ah ok merci BufferBob je ferai plus attention aux tailles parce que en effet ça peut avoir des effets secondaires dévastateurs