Пропатчить код может любое ПО с достаточными правами. Но код CSP здесь абсолютно не при чем. Еще раз, смотрим список обязательных функций для экспорта CSP.
Вариативность работы, очевидно, в полном спектре объектов со стороны штатного API Crypt(Encode/Decode)ObjectXXX.
Что касается штатного API поиска сертификата в хранилище по идентификатору (CryptFindCertificateInStore) - там нет ограничений (в отличии от серийного номера) на длину поля. Отладчик/дизассемблер в помощь. Намного лучше, чем абстрактные размышления на тему "как это могло бы быть".


Вообще, меня несколько удивила такая бурная дискуссия на замечание, что идентификатор ключа в уже сделанных кем-то сертификатах надо брать как есть и целиком, а не делать предположений, что там обязательно какой-то хеш или 20 байт.
Пошли аргументы про "левое" и правильное ПО. Чтож, вот то, что сделано с помощью исключительно правильного ПО КриптоПро:
var_keyid_certs.zip (3kb) загружен 5 раз(а).

В аттаче три сертфиката на ОДИН ключ с кастомным содержимым поля subject key identifier длиной 4, 20 и 21 байт.
Наглядная демонстрация, что надо не на ПО надеяться, а голову включать.

И, пожалуйста, не надо больше "все равно это нечестно или нетипично". Софт должен быть расчитан на то, что он работает с частично недоверенными данными. Иначе зачем постоянно подписи на сертификатах проверять и цепочки строить?

Отредактировано пользователем 1 сентября 2020 г. 14:47:24(UTC)  | Причина: Не указана