Отголосок прошлого :)

    На cracklab-е обсуждается тема взлома конверта, разработкой которого я занимался раньше :) Интересно, сколько времени потребуется на решение задачки (восстановление извлеченных инструкций). Судя по всему, версия конверта достаточно древняя.
    Кстати, технику выдергивания одной инструкции (а это и делает опция /RIP_CODE) используют достаточно большое количество протекторов. Очень часто таким образом запутывают граф потока управления. Armadillo, к примеру, ставит int 3 вместо извлеченной инструкции. В некоторых конвертах ставится call, что накладывает ограничения на размер инструкции (>= 5 байт).
    При кажущейся простоте подхода восстановить исходные инструкции может быть и не так просто. Все зависит от того, насколько защищен интерпретатор извлеченной инструкции. Можно, в принципе, попробовать восстановить посредством анализа входов и выходов, но здесь возникает проблема идентификации этих входов и выходов. Например, как определить, что была извлечена инструкция mov eax, [imm]? Поставить бряк на память? А если есть фальшивые чтения памяти? А если флаги доступа к страничке эпизодически меняются тем же VirtualProtect-ом? Плюс ко всему, необходимо полное покрытие исследуемеого файла дизассемблером, что в случае перехваченных инструкций еще более затруднительно. Т.е. задачка то в общем случае вовсе нетривиальная :)
    Другой вопрос в том, какой защитный механизм срабатывает при интерпретации такой перехваченной инструкции. Может так случиться, что восстанавливать исходные нет никакой необходимости. Проще подкорректировать интерпретатор так, чтобы он всегда работал как надо :)
    В случае с конвертами, идущими в качестве бесплатного (или платного) приложения к донглам, упор делается на поддержку всех выпускаемых ключей. А значит и младших (медленных и устаревших), и сетевых моделей. Это значит, что вызывать электронный ключ каждый раз при вызове интерпретатора перехваченной инструкции даже при использовании профайлера нельзя (именно поэтому мы пока не видим хороших автоматических решений для ключей с загружаемым кодом). Особенно четко это проявляется в случае сетевых ключей. Поэтому используется либо периодический опрос (когда клиент сам задает период опроса донгла), либо кеширование информации, полученной с помощью донгла.
    В случае периодического опроса вся вина при потере производительности ложится на клиента, который осуществляет защиту. Период опроса он, как правило, задает самостоятельно.  
    В случае кеширования информации необходим хитрый механизм, который, в зависимости от платформы, на которой запущено защищенное приложение, будет определять время, в течение которого информация будет храниться в кеше. Или надо придумать некоторый параметр, который это время регулировал бы, свалив всю вину на клиента :) Информация в этом случае достаточно стандартная (расшифрованные с помощью донгла код, байт-код или данные,  ключ для расшифрования чего-либо, какое-нибудь инициализирующее значение для чего-либо, полученное с помощью донгла).
    Самое интересное в том, что для задачи привязки софта к ключу (или лицензирования вообще) глубокой разницы между полноценной обфускацией кода программы и выдергиванием по несколько (или даже по одной) инструкций с последующим встраиванием интерпретатора нет. В случае лицензирования ведь нет необходимости защищать пользовательский код от анализа, а надо, чтобы он не работал при невалидной или отсутствующей лицензии. А вот механизм лицензирования должен быть действительно качественным, что сложно обнаружить в унифицированных решениях в силу объективных причин.