Здравствуйте, ononim, Вы писали:
R>>Есть приложение, трафик передается с использование алгоритма потокового шифрования. Ключи есть. Я перехватил WSPSend и WSPRecv. С WSPSend никаких проблем не возникает, но они возникли с WSPRecv, так как используется асинхронный метод и вместо данные все время получаю -1 и IO_PENDING.
R>>Переписал приложение на winpcap. Но исходящие пакеты начали склеиваться. А при потоковом шифровании важна очередность пакетов.
С->>>S Пакет 1 R>>C<-S Пакет 2 C->>>S Пакет 3 R>>C<-S Пакет 4 C->>>S Пакет 5
R>>При перехвате через winpcap получается
С->>>S Пакет 1 R>>C<-S Пакет 2 C->>>S Пакет 3 + Пакет 5 R>>C<-S Пакет 4
R>>И таким образом на 3м этапе я трафик расшифровать уже не могу, так как нарушена очередность.
O>Если данные 3 и 5 склеились в один тсп пакет — значит клиент между их посылкой не дожидался никаких данных от сервера и сервер в состоянии расшифровать [как минимум] данный фрагмент стрима в склеенном, разбитом и переклееном виде.
клиент отправил 3й пакет (система ждет и не отправила его), получил 4й пакет, отправил 5й пакет (серверу улетел 3 и 5 пакет вместе).
Для клиента все соблюдено и шифрование не нарушено, для меня же при получении склееного пакета 4 + 5 шифрование уже не валидно при отработки 39 байта пакета.
Так как используется 2 пары ключей для разных направлений, то проблем не возникает, главное знать размеры пакетов.
Вот если мне в TCP пакете пришло 2 склееных пакета, как мне понять что там 2 пакета? Моя задача решается успешно при знании длин внутренних пакетов, то есть если пакет АААА и ББББ отправлены склеены и я получаю ААААББББ и я об этом знаю допустим из заголовка пакета (каким то образом) и знаю длины, что это 2 пакета по 4 байта — моя задача решена.
