Я бы не рекомендовал это, но вы должны иметь возможность модифицировать IL-код, который проверяет слабые ключи, используя Reflector и надстройка ReflexIL
редактировать:
Извините, мне потребовалось некоторое время, чтобы загрузить все это в мою виртуальную машину (под управлением Ubuntu), и я не хотел связываться с Mono.
- Установите надстройку ReflexIL: Вид -> Надстройки -> Добавить
- Откройте ReflexIL: Инструменты -> ReflexIL v0.9
- Найдите функцию IsWeakKey(). (Вы можете использовать поиск: F3)
- Появятся две функции, дважды щелкните ту, что находится в System.Security.Cryptography.TripleDES.
- ReflexIL тоже должен был подойти. На вкладке «Инструкции» прокрутите до строки 29 (смещение 63).
- Измените ldc.i4.1 на ldc.i4.0, это означает, что функция всегда будет возвращать false.
На панели сборок (слева) теперь вы можете прокрутить вверх и щелкнуть Common Language Runtime Library, панель ReflexIL предоставит вам возможность сохранить ее.
Важные заметки:
- Сначала сделайте резервную копию своей оригинальной сборки! (mscorlib.dll)
- mscorlib.dll — это подписанная сборка, и вам понадобится .NET SDK (инструмент sn.exe) для ReflexIL, чтобы пропустить проверку. Я только что проверил это сам, у вас уже должно быть это с установленным Visual C#. Просто нажмите Зарегистрировать для пропуска проверки (на этом компьютере), когда вас попросят.
- Я не думаю, что должен говорить вам, чтобы вы использовали это только на своей машине разработки :)
Удачи! Если вам нужны дополнительные инструкции, пожалуйста, не стесняйтесь использовать поле для комментариев.
редактировать2:
Я смущен!
а>
Я полностью убрал проверку IsWeakKey из функции set_Key в сборке mscorlib. Я абсолютно уверен, что изменил правильную функцию и сделал это правильно. Дизассемблер Reflector больше не показывает чек. Забавно, однако, что Visual C# по-прежнему выдает такое же исключение.
Это наводит меня на мысль, что mscorlib должен каким-то образом где-то кэшироваться. Однако переименование mscorlib.dll в mscorlib.dll_ приводит к сбою MSVC#, поэтому он по-прежнему должен зависеть от исходной dll.
Это довольно интересный материал, но я думаю, что достиг точки, когда я понятия не имею, что происходит, это просто не имеет никакого смысла! См. прикрепленное изображение. :(
редактировать3:
Я заметил в Олли, что в отличие от таких сборок, как mscoree, mscorsec и mscorwks; mscorlib.dll на самом деле не находится в: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\
Но вместо этого в несуществующем месте: C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\6d667f19d687361886990f3ca0f49816\mscorlib.ni.dll
Я думаю, что я что-то здесь упускаю :) Буду исследовать это еще немного.
редактировать4:
Даже после того, как я исправил ВСЕ в IsWeakKey и поигрался с удалением и созданием новых собственных образов (x.ni.dll) mscorlib.dll с помощью ngen.exe, я получаю то же исключение. Я должен отметить, что даже после удаления собственных образов mscorlib он по-прежнему использует mscorlib.ni.dll... Мех.
Я сдаюсь. Я надеюсь, что кто-то сможет ответить, что, черт возьми, происходит, потому что я точно не знаю. :)
person
Community
schedule
13.04.2009