Здравствуйте, gear nuke, Вы писали:

I>>А если ты заглянешь в свою ссылку, то заметишь, что я спросил про исключение и нигде не утверждал что его не будет.

GN>Если честно, то не вижу особой разницы.

После твоего ответа в той теме я взял да и проверил вот таким примерно кодом

char f [] = {0x8d, 0xC3, 0xC3};

     int (*pF)(void) = (int (__cdecl *)(void))f;

     pF();

Соответсвенно разница есть и вполне четкая.

Здравствуйте, Ikemefula, Вы писали:

I>После твоего ответа в той теме я взял да и проверил вот таким примерно кодом

I>

I>char f [] = {0x8d, 0xC3, 0xC3};

I>     int (*pF)(void) = (int (__cdecl *)(void))f;

I>     pF();
I>

Может показать всё, что угодно: компилятор вправе заоптимизировать содержимое массива, кроме того выполнение в стеке вызовет STATUS_ACCESS_VIOLATION на системах с DEP.

Как минимум, тестировать можно на

  __asm __emit 0x8d
  __asm __emit 0xC3

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

I>Соответсвенно разница есть и вполне четкая.

Какая? Я вижу разницу между упомянутой формой LEA и UD2 — последняя рекомендуется для генерации #UD явно. Так же есть разница с инструкциями генерирующими STATUS_INVALID_LOCK_SEQUENCE, но это только на уровне винды. Между вопросами "будет ли невалидный опкод генерировать исключение" и "какое исключение будет генерировать невалидный опкод" разницы не вижу, дока на оба отвечает в одном месте.

Здравствуйте, gear nuke, Вы писали:

GN>Может показать всё, что угодно: компилятор вправе заоптимизировать содержимое массива, кроме того выполнение в стеке вызовет STATUS_ACCESS_VIOLATION на системах с DEP.

Ты ты думаешь, что мне мозгов хватило только на написание кода ?

I>>Соответсвенно разница есть и вполне четкая.

GN>Какая? Я вижу разницу между упомянутой формой LEA и UD2 — последняя рекомендуется для генерации #UD явно

смотри сюда "ведь с командой LEA EAX, EAX у вас двоих те же проблемы"

и далее "I>А если ты заглянешь в свою ссылку, то заметишь, что я спросил про исключение и нигде не утверждал что его не будет.

Если честно, то не вижу особой разницы..."

Проверяй контекст по дереву иногда, это два клика мышом.

Здравствуйте, Ikemefula, Вы писали:

I>Ты ты думаешь, что мне мозгов хватило только на написание кода ?

Я уверен, что если ты сам начал писать какой-то код, то есть занялся изучением проблемы, то ответ найдеш, даже если и не сразу. А если кто-то из праздного инетерса скопипастит кусок и запустит — то может быть удивлён.

I> Проверяй контекст по дереву иногда, это два клика мышом.

А, разница не в вопросе, а в вас двоих и под "никто не будет разбираться" имелся ввиду мыщъх. Прошу прощения, погорячился с обобщением

Здравствуйте, gear nuke, Вы писали:

М>> если вы мне сообщите о существовании способа такой оценки, который работает, то я признаю свою неправоту.

GN>

Стойким считается алгоритм, который для успешной атаки требует от противника недостижимых вычислительных ресурсов

GN>здесь

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

С Уважением, Andir!