C ++ Странный шестнадцатеричный дамп WSAsend Packets

http://prntscr.com/2ctnoz

Я перехватываю функцию WSAsend и выкидываю пакеты. Дамп ASCII работает, но дамп HEX иногда показывает такие вещи, как вы можете видеть на экране (FFFFFFDD), есть идеи, почему?

код:

int WINAPI myWSASend(SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, LPDWORD lpNumberOfBytesSent, DWORD dwFlags, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine)
{
//Packet Log
if (bLogPacketS == TRUE)
{
for (unsigned int i = 0; i < lpBuffers->len; i = i + 8)
{
printf("%02X %02X %02X %02X %02X %02X %02X %02X\t\t%c %c %c %c %c %c %c %c\n",
(unsigned int)lpBuffers->buf[i], (unsigned int)lpBuffers->buf[i+1], (unsigned int)lpBuffers->buf[i+2],
(unsigned int)lpBuffers->buf[i+3], (unsigned int)lpBuffers->buf[i+4], (unsigned int)lpBuffers->buf[i+5],
(unsigned int)lpBuffers->buf[i+6], (unsigned int)lpBuffers->buf[i+7],
(drawable((unsigned int)lpBuffers->buf[i])) ? (unsigned int)lpBuffers->buf[i] : '.',
(drawable((unsigned int)lpBuffers->buf[i+1])) ? (unsigned int)lpBuffers->buf[i+1] : '.',
(drawable((unsigned int)lpBuffers->buf[i+2])) ? (unsigned int)lpBuffers->buf[i+2] : '.',
(drawable((unsigned int)lpBuffers->buf[i+3])) ? (unsigned int)lpBuffers->buf[i+3] : '.',
(drawable((unsigned int)lpBuffers->buf[i+4])) ? (unsigned int)lpBuffers->buf[i+4] : '.',
(drawable((unsigned int)lpBuffers->buf[i+5])) ? (unsigned int)lpBuffers->buf[i+5] : '.',
(drawable((unsigned int)lpBuffers->buf[i+6])) ? (unsigned int)lpBuffers->buf[i+6] : '.',
(drawable((unsigned int)lpBuffers->buf[i+7])) ? (unsigned int)lpBuffers->buf[i+7] : '.');
}
printf("\n\n");
}
return (oWSASend)(s, lpBuffers, dwBufferCount, lpNumberOfBytesSent, dwFlags, lpOverlapped, lpCompletionRoutine);
}

bool drawable(unsigned int value)
{
if (value > 32 && value < 127)
return true;
else
return false;
}

4

Решение

Вы используете неверный тип.

Вы хотите изменить только подпись, но вы расширяете каждый байт до четырехбайтового слова. При наличии преобразования со знаком в без знака (и получающегося в результате обтекания отрицательного значения) это приводит к чудовищно высокой стоимости.


Каждый «элемент» lpBuffers->buf[i] это char, но вы используете unsigned int, Если твой char подписан в вашей системе, то 0xDD вне пределов диапазона типа, поэтому он оборачивается -35, Затем приведение к unsigned int результаты в 0xFFFFFFDD,

printf спецификатор %02X не будет усекать это.

Предположительно, вы хотите интерпретировать все байты как unsigned, чтобы получить полный 0x000xFF спектр. Лично я бы обратился в unsigned char (вместо unsigned int), для которого значение 0xDD является 221,

В приведенном ниже коде я также сделал корректировку безопасности для вашего состояния цикла.

for (unsigned int i = 0; i < lpBuffers->len-8; i = i + 8)
//                                         ^^
{
printf(
"%02X %02X %02X %02X %02X %02X %02X %02X""\t\t%c %c %c %c %c %c %c %c\n",

static_cast<unsigned char>(lpBuffers->buf[i]),
static_cast<unsigned char>(lpBuffers->buf[i+1]),
static_cast<unsigned char>(lpBuffers->buf[i+2]),
static_cast<unsigned char>(lpBuffers->buf[i+3]),
static_cast<unsigned char>(lpBuffers->buf[i+4]),
static_cast<unsigned char>(lpBuffers->buf[i+5]),
static_cast<unsigned char>(lpBuffers->buf[i+6]),
static_cast<unsigned char>(lpBuffers->buf[i+7]),
(drawable(lpBuffers->buf[i]))   ? static_cast<unsigned char>(lpBuffers->buf[i])   : '.',
(drawable(lpBuffers->buf[i+1])) ? static_cast<unsigned char>(lpBuffers->buf[i+1]) : '.',
(drawable(lpBuffers->buf[i+2])) ? static_cast<unsigned char>(lpBuffers->buf[i+2]) : '.',
(drawable(lpBuffers->buf[i+3])) ? static_cast<unsigned char>(lpBuffers->buf[i+3]) : '.',
(drawable(lpBuffers->buf[i+4])) ? static_cast<unsigned char>(lpBuffers->buf[i+4]) : '.',
(drawable(lpBuffers->buf[i+5])) ? static_cast<unsigned char>(lpBuffers->buf[i+5]) : '.',
(drawable(lpBuffers->buf[i+6])) ? static_cast<unsigned char>(lpBuffers->buf[i+6]) : '.',
(drawable(lpBuffers->buf[i+7])) ? static_cast<unsigned char>(lpBuffers->buf[i+7]) : '.'
);
}
3

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]