Подмена контроля

@.::.DIMA.::. · Регистрация: 26.10.2008

Студворк — интернет-сервис помощи студентам

В .NET возможна подмена контроля при доступе приложения к библиотекам? Т.е. когда приложение пытается получить доступ к библиотеке, а какое-нибудь другое риложение перехватывает запрос, и далее связь осуществляется через это приложение, и оно имеет контроль над всеми вызовами.

@NickoTin · 25.10.2010, 22:55

Если ты хочешь отлавливать обращение к библиотеке от любого приложения, то ты вряд ли этого добьёшься с помощью .NET, т.к. скорее всего придется перехватывать API.

И вообще, что ты имеешь ввиду под этим

Сообщение от .::.DIMA.::.

подмена контроля при доступе приложения к библиотекам

Обращаться к библиотеке можно разными способами.

@.::.DIMA.::. · 25.10.2010, 23:57 **[ТС]**

Я написал приложение на .NET. Можно ли гарантировать, что приложение будет напрямую обращаться к библиотекам, а не через посредника, котооый захочет контролировать мои действия.
Не обязательно программа, перехватывающая обращения написана на .NET. Меня пока только интересует, возможно контролировать приложения, написанные на .NET или эта платформа каким-либо образом контролирует подлинность библиотек и способов, через которые она с ними связывается.

@vikser · 26.10.2010, 00:10

Если ты о native dll с p/invoke - да, ставь хук (SetWindowsHookEx и дальше по гуглу) и наслаждайся ревом антивируса (хе-хе).
А если перехватить из .NET - обломаешься. Единственный способ - обойти GAC, внедрить в Assembly свою сборку, и замаскировать от этого же GAC-а исходную либу. Но если она подписана (что в 99% так и есть), то твой ковырный план обречен на провал ,)

Добавлено через 2 минуты

Сообщение от .::.DIMA.::.

Меня пока только интересует, возможно контролировать приложения, написанные на .NET или эта платформа каким-либо образом контролирует подлинность библиотек и способов, через которые она с ними связывается.

Эм, именно так. Поэтому твоя главная проблема - это простота дизассемблирования (ну до безобразия просто, и нет защиты) да открытость всех методов для глаз негодных (на это ставь атрибуты на классы и поля - кое как убережешься)

@.::.DIMA.::. · 26.10.2010, 00:24 **[ТС]**

Сообщение от vikser

да, ставь хук (SetWindowsHookEx и дальше по гуглу

Это для чего?

Добавлено через 1 минуту

Сообщение от vikser

Эм, именно так. Поэтому твоя главная проблема - это простота дизассемблирования (ну до безобразия просто, и нет защиты) да открытость всех методов для глаз негодных (на это ставь атрибуты на классы и поля - кое как убережешься)

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

@NickoTin · 26.10.2010, 01:23

.::.DIMA.::., можно создать dll посредника и заменить им твою dll, к которой будет обращаться твоя программа. Используй проверку целостности файла - CRC.

Советую сильно не заморачиваться, кто захочет, тот сделает как ему надо и ты об этом даже не узнаешь. Рефлекторы, дизассемблеры ещё никто не отменял.

vikser, интересно какой ты собрался ставить хук (через SetWindowsHookEx) на перехват dll, а нука посвяти не знающих

@.::.DIMA.::. · 26.10.2010, 01:46 **[ТС]**

Можно подробнее про рефлекторы?

Меня интересует такой вопрос: возможна ли такая схема, как на этой картинке, только доступ осуществляется не на сервер, а к dll.

Проверка контрольной суммы - хороший вариант, но меня интересует, какие методы защиты предоставляет .NET.

@NickoTin · 26.10.2010, 01:57

Сообщение от .::.DIMA.::.

Можно подробнее про рефлекторы?

Рефлектор позволяет просмотреть исходный код программы (если она не обфусцирована), вот рефлектор.

Сразу напишу: Обфускатор - это программа, которая затрудняет декомпилятору (в данном случае рефлектору, тот же декомпилятор) получить исходный код программы в первозданном виде. Хороший обфускатор стоит очень дорого )

Сообщение от .::.DIMA.::.

возможна ли такая схема

Да, возможна.

Сообщение от .::.DIMA.::.

какие методы защиты предоставляет .NET.

Изначально - никаких, всё открыто для третьих лиц.

@.::.DIMA.::. · 26.10.2010, 02:16 **[ТС]**

Сообщение от SSTREGG

Да, возможна.

И как можно подменить контроль?

@NickoTin · 26.10.2010, 02:27

Создать dll с такими же классами (методами, свойствами и т.д.) и при этом ссылаться на твою оригинальную dll, и твоя программа будет обращаться сначала к "псевдо" dll, а только потом к твоей.

Вот пример:
1)У тебя есть dll, написанная тобой:

C#
1
2
3
4
5
6
7
8
... // опускаем using и namespace
publiс class WriteInfo
{
    public void ToFile(byte[] data)
    {
          // здесь реализация записи куда-либо
    }
}

2) Атакующий пишет такую же dll (с такими же именами namespace, классов и т.д.), и при этом в reference к своей библиотеке прикрепляет твою (т.е. ссылается на неё):

C#
1
2
3
4
5
6
7
8
9
10
... // опускаем using и namespace
publiс class WriteInfo
{
    public void ToFile(byte[] data)
    {
          // здесь уже идет проверка, какие данные пишутся (к примеру)
          ...
          // а здесь идет обращение к твоей dll, если понадобится конечно
    }
}

Главное требование к атакующей dll, так это чтобы её имя совпадало с твоей dll, а твою можно переименовать во что-нибудь другое.

@Mikant · 26.10.2010, 02:35

SSTREGG, в корне не верно. проблема DllHell в .NET как раз решена - строгие имена и версии сборок четко изолируют логику. я даже больше скажу: если есть 3 длл: первая ссылается на вторую, вторая - на третью, то перекомпилировав вторую (отдельно от всех) весь тракт работать не будет как ты ожидаешь (ну всмысле если начнешь переопределять и перекрывать члены классов налево-направо во второй длл)... тут call и callvirt в IL (а вызов виртуальных методов - это далеко не так тривиально, как в книгах пишут) по точным сигнатурам уберегут или раскрошат связи

а вот по сабжу скажу, что точно можно производить инъекции бизнес-логики на лету и поменять и смотреть всё, что хочешь... любой профилировщик (трассировщик) - тому пример (качай JetBrains dotTrace). вот только сам я никогда с этим не сталкивался и не знаю(

@NickoTin · 26.10.2010, 02:37

Сообщение от Mikant

первая ссылается на вторую, вторая - на третью, то перекомпилировав вторую (отдельно от всех) весь тракт работать не будет как ты ожидаешь

Ну так речь не шла о 3х dll, речь походу шла об одной, но всё равно соглашусь

@.::.DIMA.::. · 26.10.2010, 11:05 **[ТС]**

А при доступе проверяется цифровая подпись или контрольная сумма?
И где можно прочитать про доступ к библиотекам: стандарты или где-нибудь ещё?

@NickoTin · 26.10.2010, 13:36

Сообщение от .::.DIMA.::.

А при доступе проверяется цифровая подпись или контрольная сумма?

Изначально ничто, нигде не проверяется. Поищите в гугле о Strong names. Ну а как использовать CRC думаю знаете.

Сообщение от .::.DIMA.::.

И где можно прочитать про доступ к библиотекам: стандарты или где-нибудь ещё?

Есть загрузка статическая - автоматическая загрузка вместе с приложением, а есть динамическая - ручная загрузка библиотеки по мере необходимости (больше применимо к native dll).

@_Sergei_ · 26.10.2010, 13:52

Если у вас strong named assembly,то проверяется. Вот из Рихтера цитата:

Подписание файла закрытым ключом гарантирует, что именно держатель соот-
ветствующего открытого ключа является производителем сборки. При установке
сборки в GAC система рассчитывает хэш содержимого файла с декларацией и
сравнивает полученное значение с цифровой подписью RSA, встроенной в РЕ-файл
(после извлечения подписи с помощью открытого ключа), Идентичность значе-
ний означает, что содержимое файла не было модифицировано, а также что ваш
открытый ключ соответствует закрытому ключу издателя. Кроме того, система
рассчитывает хэш содержимого других файлов сборки и сравнивает полученные
значения с таковыми из таблицы декларации FileDef. Если хоть одно из значений
не совпадает, то хотя бы один из файлов сборки был модифицирован, и установ-
ка сборки в GAC окончится неудачей.
.....
При загрузке сборки со строгим именем не из GAC, а из другого каталога (за-
данного значением элемента CodeBase в конфшурационном файле), CLR проверяет
ее хэш. Иначе говоря, расчет хэша для файла выполняется в данном случае при
каждом запуске приложения. Хотя при этом несколько снижается быстродействие,
без таких мер нельзя гарантировать, что содержимое сборки не подверглось не-
санкционированной модификации. Обнаружив во время выполнения несоответ-
ствие значений хэша, CLR генерирует исключение System.IO.FileLoadException.

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

@d0s'A · 26.10.2010, 14:08

А если ссылаться не на библиотеку, а работать через интерфейс?
Берешь реализовываешь в двух разных библиотеках один и тот же интерфейс. Указываешь твоей программе путь к dll не важно как она называется, главное чтобы в ней был класс с которым ты будешь работать за счет интерфейса. Вот и все

@.::.DIMA.::. · 26.10.2010, 14:42 **[ТС]**

Сообщение от SSTREGG

Изначально ничто, нигде не проверяется

SSTREGG, То есть нет гарантии, что моя программа обращается к подлинным библиотекам?

@NickoTin · 26.10.2010, 14:56

Без защиты (Strong name, обфускация, ещё что-нибудь) - гарантий нет.

@.::.DIMA.::. · 26.10.2010, 15:11 **[ТС]**

Сообщение от SSTREGG

Без защиты (Strong name, обфускация, ещё что-нибудь) - гарантий нет.

А разве библиотеки dll можно обфусцировать или задавать Strong Name? Я имею ввиду стандартные библиотеки, например, System.IO.

@_Sergei_ · 26.10.2010, 15:22

Все стандартные библиотеки и так strong named, иначе кто бы гарантировал их подлинность?

Добавлено через 9 минут
Вы создайте пустой проект, соберите его, откройте в ILDasm.exe, там выбираете show metainfo, и в нем в конце будет идти что-то типа такого:

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
AssemblyRef #1 (23000001)
-------------------------------------------------------
    Token: 0x23000001
    Public Key or Token: b7 7a 5c 56 19 34 e0 89 
    Name: mscorlib
    Version: 2.0.0.0
    Major Version: 0x00000002
    Minor Version: 0x00000000
    Build Number: 0x00000000
    Revision Number: 0x00000000
    Locale: <null>
    HashValue Blob:
    Flags: [none] (00000000)

это ссылка на mscorlib с Public KeyToken: b7 7a 5c 56 19 34 e0 89, соответственно при загрузке программы при помощи этого ключа будет извлечена цифровая RSA сборки, рассчитывается хэш и сравнивается с сигнатурой, если совпадают все ок, нет - ошибка

Новые блоги и статьи Все статьи Все блоги /
Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .
Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .

@.::.DIMA.::. 146 / 146 / 32 Регистрация: 26.10.2008 Сообщений: 782

	Подмена контроля 25.10.2010, 22:50. Показов 3767. Ответов 23 Метки нет (Все метки) В .NET возможна подмена контроля при доступе приложения к библиотекам? Т.е. когда приложение пытается получить доступ к библиотеке, а какое-нибудь другое риложение перехватывает запрос, и далее связь осуществляется через это приложение, и оно имеет контроль над всеми вызовами. 0

@.::.DIMA.::. 146 / 146 / 32 Регистрация: 26.10.2008 Сообщений: 782
	25.10.2010, 23:57 [ТС]
	Я написал приложение на .NET. Можно ли гарантировать, что приложение будет напрямую обращаться к библиотекам, а не через посредника, котооый захочет контролировать мои действия. Не обязательно программа, перехватывающая обращения написана на .NET. Меня пока только интересует, возможно контролировать приложения, написанные на .NET или эта платформа каким-либо образом контролирует подлинность библиотек и способов, через которые она с ними связывается. 0

@NickoTin Почетный модератор 8729 / 3681 / 404 Регистрация: 14.06.2010 Сообщений: 4,513 Записей в блоге: 9
	26.10.2010, 01:23
	.::.DIMA.::., можно создать dll посредника и заменить им твою dll, к которой будет обращаться твоя программа. Используй проверку целостности файла - CRC. Советую сильно не заморачиваться, кто захочет, тот сделает как ему надо и ты об этом даже не узнаешь. Рефлекторы, дизассемблеры ещё никто не отменял. vikser, интересно какой ты собрался ставить хук (через SetWindowsHookEx) на перехват dll, а нука посвяти не знающих 1

@.::.DIMA.::. 146 / 146 / 32 Регистрация: 26.10.2008 Сообщений: 782
	26.10.2010, 01:46 [ТС]
	Можно подробнее про рефлекторы? Меня интересует такой вопрос: возможна ли такая схема, как на этой картинке, только доступ осуществляется не на сервер, а к dll. Проверка контрольной суммы - хороший вариант, но меня интересует, какие методы защиты предоставляет .NET. 0

@Mikant 1322 / 995 / 127 Регистрация: 08.12.2009 Сообщений: 1,299
	26.10.2010, 02:35
	SSTREGG, в корне не верно. проблема DllHell в .NET как раз решена - строгие имена и версии сборок четко изолируют логику. я даже больше скажу: если есть 3 длл: первая ссылается на вторую, вторая - на третью, то перекомпилировав вторую (отдельно от всех) весь тракт работать не будет как ты ожидаешь (ну всмысле если начнешь переопределять и перекрывать члены классов налево-направо во второй длл)... тут call и callvirt в IL (а вызов виртуальных методов - это далеко не так тривиально, как в книгах пишут) по точным сигнатурам уберегут или раскрошат связи а вот по сабжу скажу, что точно можно производить инъекции бизнес-логики на лету и поменять и смотреть всё, что хочешь... любой профилировщик (трассировщик) - тому пример (качай JetBrains dotTrace). вот только сам я никогда с этим не сталкивался и не знаю( 1

@.::.DIMA.::. 146 / 146 / 32 Регистрация: 26.10.2008 Сообщений: 782
	26.10.2010, 11:05 [ТС]
	А при доступе проверяется цифровая подпись или контрольная сумма? И где можно прочитать про доступ к библиотекам: стандарты или где-нибудь ещё? 0

@d0s'A 153 / 113 / 25 Регистрация: 23.06.2008 Сообщений: 320
	26.10.2010, 14:08
	А если ссылаться не на библиотеку, а работать через интерфейс? Берешь реализовываешь в двух разных библиотеках один и тот же интерфейс. Указываешь твоей программе путь к dll не важно как она называется, главное чтобы в ней был класс с которым ты будешь работать за счет интерфейса. Вот и все 0

@NickoTin Почетный модератор 8729 / 3681 / 404 Регистрация: 14.06.2010 Сообщений: 4,513 Записей в блоге: 9
	26.10.2010, 14:56
	Без защиты (Strong name, обфускация, ещё что-нибудь) - гарантий нет. 1