Discussion :

[n5Rzn1D9dC]

Salut,

J'aurais besoin d'aide pour la réécriture de structure C en asm.
Pour les structures standard, pas de problème, mais voici un exemple où je bloque:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
struct ifreq {
#define IFHWADDRLEN	6
	union
	{
		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
	} ifr_ifrn;
 
	union {
		struct	sockaddr ifru_addr;
		struct	sockaddr ifru_dstaddr;
		struct	sockaddr ifru_broadaddr;
		struct	sockaddr ifru_netmask;
		struct  sockaddr ifru_hwaddr;
		short	ifru_flags;
		int	ifru_ivalue;
		int	ifru_mtu;
		struct  ifmap ifru_map;
		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
		char	ifru_newname[IFNAMSIZ];
		void *	ifru_data;
		struct	if_settings ifru_settings;
	} ifr_ifru;
};

J'ai essayé de l'écrire des tas de façon différentes, mais les valeurs ne tombent jamais où elles devraient.. Donc j'aurais quelques questions:

Ligne 6:
Faut-il réserver les 16 bytes de la longueur IFNAMSIZ, ou bien décompter la longueur du nom de ces 16 bytes ?
Exemple pour le nom "lo", ça ferait 14 bytes à réserver..

Ligne 10 à 14:
Est-ce que toutes ces lignes comptent pour le même espace mémoire ?
Ce qui donnerait donc en pseudo code:

Code :

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

1
2
3
4
5
6
 
	union {
                dd sockaddr
		short	ifru_flags;
		int	ifru_ivalue;
                ...etc...

Concernant les unions, ils sont sensé être sur le même espace, mémoire.
Voici comment j'imaginais l'entrée de la structure ifreq:

Code :

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

1
2
3
4
 
ifreq:
dd ifr_ifrn
dd ifr_ifru

Donc deux pointeurs qui pointent vers des adresses mémoires contenant les unions.
Mais ça ne fonctionne pas.
En faite, pour que les résultats tombent pile au bon endroit, j'ai l'impression qu'il faudrait une entrée sans pointeurs..

Exemple:

Code :

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

1
2
3
4
 
ifreq:
rb 16 ;(pour ifr_ifrn)
rb nbr ;(pour ifr_ifru)

Vous me confirmez que c'est bien cette dernière solution ?
C'est également ce qui fait que j'esquive le kernel mode autant que possible, que ce soit sous Linux ou Windows, vu qu'à ce niveau les structures deviennent longue comme le bras, même pour celles qui sont standard, avec de multiple pointage vers d'autres structures, c'est vite fatiguant à écrire, surtout pour au final me rendre compte que l'api ne fait pas ce que je souhaite faire.

[n5Rzn1D9dC]

J'ai refait plusieurs tests, et je trouve les résultats anormaux.
Alors soit il y a un truc que je ne connais pas, soit c'est un bug de l'api.
J'ai simplement utilisé un buffer pour voir à quel endroit son placé les arguments, et pas étonnant que je ne ne comprend pas, vu que les arguments sont également au mauvais endroit en procédant de cette façon.

Dword par dword, vous pouvez voir que l'if_index est rempli avant la brdaddr..
Et c'est pareil pour les quatres autres commandes d'adresses que j'ai testé. Elles sont toutes placées au même endroit, avec l'if_index toujours au dessus, alors qu'il devrait être en dessous.
De même que pour la commande d'if_index seule.

J'ai aussi testé avec les macro de structure / union de fasm, idem.

Si vous avez une explication à ça..

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
SIOCGIFBRDADDR
 
30687465 < "eth0"
00000000
00000000
00000000
00000002 < if_index
ff01a8c0 < bdraddr
00000000
00000000
00000000
00000000

edit:
Grosse confusion..
Le genre de truc qui arrive rarement, mais qui arrive.
Alors en faite, le "2", c'est le "2" de "sa_family" de la structure "sockaddr"

Là où j'ai confondu, c'est que le "2" de "if_index" vient se placer exactement au même endroit lors d'un appel à "SIOCGIFINDEX".
C'est ce qui m'a fait croire qu'il s'agissait du même "2" et que "SIOCGIFBRDADDR" et les autres appel addr que j'ai fait remplissaient automatiquement l'if_index en même temps que l'adresse.

lol !

[n5Rzn1D9dC]

C'est bon tout fonctionne parfaitement maintenant.
De plus il y a une erreur dans le nommage des structures de ifreq..

"ifru_addr" doit pointer sur "sockaddr_in", et non "sockaddr". Sinon il manque le word protocol..
Je sais pas si c'est vraiment une erreur, un oublie, ou si il y a une raison logique à ce qu'ils aient mis "sockaddr".
En tout cas maintenant ça remplie pile au bonne endroit, selon que c'est "sockaddr" pour "ifru_hwaddr" par exemple, ou "sockaddr_in" pour "ifru_addr".