Узнал давеча, что Microsoft разрешил править свои длл-ки. Эта возможность появилась начиная с 3.5 SP1.
Для примера написал такой код:

OracleConnectionStringBuilder b = new OracleConnectionStringBuilder();
b.Pooling = false;
b.DataSource = "go";
Console.WriteLine(b.ConnectionString);

Взял длл-ку System.Data.OracleClient.dll из GAC, открыл в hex редакторе и "Pooling" заменил на "Looling".
Возвратил ее на место, запускаю программу и вуаля — вместо ошибки

Data Source=go;Looling=False

А что можно мутить используя IL редакторы?

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

OK>Взял длл-ку System.Data.OracleClient.dll из GAC, открыл в hex редакторе и "Pooling" заменил на "Looling".

* А если попробовать зареференсить её из проекта со строгим именем?
* DLL в GAC ты патчил под административным аккаунтом? А знаешь, что администратор ещё может установить на машину свою реализацию CLR, которая вообще все строки меняет на "Looling"?

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

OK>А что можно мутить используя IL редакторы?
можно еще в бутсектор всякой фигни записать, ну или по пальцам себе молотком ударить

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

OK>Узнал давеча, что Microsoft разрешил править свои длл-ки.
OK>Взял длл-ку System.Data.OracleClient.dll из GAC, открыл в hex редакторе и "Pooling" заменил на "Looling".
OK>Возвратил ее на место, запускаю программу и вуаля — вместо ошибки


Так всегда было — целостность сборки проверяется перед ее помещением в GAC.

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

N>Здравствуйте, o.kostya, Вы писали:

OK>>Взял длл-ку System.Data.OracleClient.dll из GAC, открыл в hex редакторе и "Pooling" заменил на "Looling".

N>* А если попробовать зареференсить её из проекта со строгим именем?

так и делал

N>* DLL в GAC ты патчил под административным аккаунтом? А знаешь, что администратор ещё может установить на машину свою реализацию CLR, которая вообще все строки меняет на "Looling"?

вирусня часто под админским и пролазит на комп.

если раньше чтобы подделать какую-то длл надо было всю цепочку перевыдавать, то сейчас в этом надобности уже нету.

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

TK>Так всегда было — целостность сборки проверяется перед ее помещением в GAC.

Если отключить Strong Name Bypass, то обычные длл-ки проверяются, а длл-ки из GAC не валидируются, а заменить длл в GAC можно обойдя проверку Strong Name.

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

N>>* DLL в GAC ты патчил под административным аккаунтом? А знаешь, что администратор ещё может установить на машину свою реализацию CLR, которая вообще все строки меняет на "Looling"?

OK>вирусня часто под админским и пролазит на комп.
OK>если раньше чтобы подделать какую-то длл надо было всю цепочку перевыдавать, то сейчас в этом надобности уже нету.

Не надо без необходимости работать под администратором, особенно с выключенным UAC. Full Control есть Full Control.
Проверку строгого имени сборки всегда можно было легко отключить, имея административные права. Я часто такое делаю на виртуальных машинах, для упрощения тестирования некоторых сценариев. Также, программа запущенная под администратором, может приаттачиться как дебаггер почти к любому процессу и наменять там чего угодно, включая code injection, независимо от строгости имён сборок.

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

N>Здравствуйте, o.kostya, Вы писали:

N>>>* DLL в GAC ты патчил под административным аккаунтом? А знаешь, что администратор ещё может установить на машину свою реализацию CLR, которая вообще все строки меняет на "Looling"?

OK>>вирусня часто под админским и пролазит на комп.
OK>>если раньше чтобы подделать какую-то длл надо было всю цепочку перевыдавать, то сейчас в этом надобности уже нету.

N>Не надо без необходимости работать под администратором, особенно с выключенным UAC. Full Control есть Full Control.
N>Проверку строгого имени сборки всегда можно было легко отключить, имея административные права. Я часто такое делаю на виртуальных машинах, для упрощения тестирования некоторых сценариев. Также, программа запущенная под администратором, может приаттачиться как дебаггер почти к любому процессу и наменять там чего угодно, включая code injection, независимо от строгости имён сборок.

Как я понимал топик стартер хотел сказать что он поменял подписанную сборку и при этом она без проблем загрузилась.
Как мне кажется это как то по крайней мере странно.

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


Tom>Как я понимал топик стартер хотел сказать что он поменял подписанную сборку и при этом она без проблем загрузилась.
Tom>Как мне кажется это как то по крайней мере странно.

Так и есть, для примера была выбрана сборка выпущенная Microsoft. Причем такое дефолтное поведение появилось только с .Net 3.5 SP1

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

Tom>Как я понимал топик стартер хотел сказать что он поменял подписанную сборку и при этом она без проблем загрузилась.
Tom>Как мне кажется это как то по крайней мере странно.

В GAC без административных прав не залезешь. А с административными можно сделать что угодно. Ничего странного в этом нет.

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

N>В GAC без административных прав не залезешь. А с административными можно сделать что угодно. Ничего странного в этом нет.

Всё-таки strong name для того и предназначалось, чтобы гарантировать идентичность сборок в любом случае.
Ну то есть отныне можно считать, что затея с подпиской сборок строгими именами провалилась?
Или всё-таки есть надежда, что сотрудники MS починят баг, вместо того чтобы писать отписки?

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

k> Или всё-таки есть надежда, что сотрудники MS починят баг, вместо того чтобы писать отписки?

В системах с дискреционным контролем доступа, да из-под привилегированных записей... и не такие чудеса возможны. Для полноты картины: http://www.codeproject.com/Articles/463508/NET-CLR-Injection-Modify-IL-Code-during-Run-time

Это не баг, а фича принятой в винде модели контроля доступа. Пофиксить ее, не меняя при этом модель — теоретически невозможно.

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

K>Всё-таки strong name для того и предназначалось, чтобы гарантировать идентичность сборок в любом случае.

Механизм строгих имён предназначен для защиты от внешних злоумышленников, не имеющих административного доступа к локальной машине, исключая возможность создания и распространения ими вредоносных сборок под именем доверенных издателей.

Очевидно, что имея административные привилегии, можно подменить нативную DLL, в которой реализован алгоритм проверки строгих имён, или скомпрометировать его другими способами. Механизм строгих имён никогда не предназначался и не разрабатывался, чтобы быть устойчивым в таких сценариях.

K>Ну то есть отныне можно считать, что затея с подпиской сборок строгими именами провалилась?

Нет, затея была успешно реализована и прекрасно работает в тех сценариях, для которых она предназначалась.

K>Или всё-таки есть надежда, что сотрудники MS починят баг, вместо того чтобы писать отписки?

Как я объяснил выше, это не баг.

Здравствуйте, nikov.

Всё-таки я не до конца понял. Почему же тогда до .Net 3.5 SP1 нельзя было такое сделать?

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

K>Здравствуйте, nikov.

K>Всё-таки я не до конца понял. Почему же тогда до .Net 3.5 SP1 нельзя было такое сделать?

А с чего вы решили, что нельзя?

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

ND>А с чего вы решили, что нельзя?

http://msdn.microsoft.com/en-us/library/cc713694.aspx

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

K>Всё-таки я не до конца понял. Почему же тогда до .Net 3.5 SP1 нельзя было такое сделать?

Оптимизация скорости запуска приложения.

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

k> Здравствуйте, nikov.
k> Всё-таки я не до конца понял. Почему же тогда до .Net 3.5 SP1 нельзя было такое сделать?

Starting with the .NET Framework version 3.5 Service Pack 1 (SP1), strong-name signatures are not validated when an assembly is loaded into a full-trust AppDomain object, such as the default AppDomain for the MyComputer zone.

Потому что с т.з. идеологии CAS, контроль целостности сборок в full-trust окружении — такой же оксюморон, как и с точки зрения идеологии DAC в привилегированном окружении системы.