C Comportement étrange de memcpy

Question

Pour un FCT, je suis en train de construire une application WinSock vulnérable à un simple dépassement de mémoire tampon, mais je suis tombé sur un, pour moi au moins, un comportement très étrange de memcpy. Toutes les mesures de sécurité dans Visual Studio ont été désactivées.

char recvbuf[1024]; 
char sendbuf[300]; 
int recvbuflen=1024; 
iResult = recv(ClientSocket, recvbuf, recvbuflen, 0); 
memcpy(sendbuf, recvbuf, recvbuflen); 
if (iResult > 0) { 
    printf("Bytes received: %d\n", iResult); 

    // Echo the buffer back to the sender 
    iSendResult = send(ClientSocket, sendbuf,sizeof(sendbuf) , 0); 

    ......... 

Comme vous pouvez le voir ci-dessus extrait de code, ceci est une application très simple qui répond simplement avec les octets reçus. Maintenant, j'ai deux questions concernant le comportement de memcpy:

1. Pourquoi est-ce pas déclencher un dépassement de mémoire tampon? Il me semble que j'essaie de copier un tampon de 1024 caractères dans un tampon de 300 caractères. En essayant la même chose en utilisant un char *, cela provoque un débordement de buffer.

2. iSendResult = envoyer (ClientSocket, SendBuf, sizeof (SendBuf), 0); Quand je change la taille en iResult (c'est le total des octets reçus) l'application répond correctement avec tous les caractères reçus, mais j'ai sélectionné sendbuf qui est seulement 300 caractères, où obtient-il les caractères restants à partir de (une sorte de tampon temp?)

Donc, ce sont deux comportements que je ne suis pas sûr de savoir comment expliquer. Ce serait bien si quelqu'un pouvait quelqu'un jeter quelque lumière sur ce sujet.

Meilleures salutations!

Answer 1

Vous débordent le tampon. Qu'espérez-vous qu'il se passe? Un débordement de tampon est un cas de comportement non défini. Dans un programme très simple comme celui-ci, un comportement indéfini a l'habitude de fonctionner correctement. C'est ce qui rend le comportement indéfini si insidieux.

Lorsque votre programme est exécuté, il écrit 300 octets à sendbuf et les octets restants à tout ce qui suit sendbuf en mémoire. Ma conjecture est que recvbuflen contient les octets 300 à 304. Si vous ajoutez une nouvelle variable char unused[1024] = {0} après sendbuf vous pourriez être en mesure de voir où les octets sont écrits en examinant leur contenu après le memcpy.