Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #66, МАЙ 2006 г.

недетское вскрытие .NET

N|M{INT3 TEAM}{NIM@INT3.RU}

Спецвыпуск: Хакер, номер #066, стр. 066-044-5


В Reflector’е (C#) то, что мы должны закомментировать, выглядит так: this.get_Verbs().Add(new DesignerVerb(11.Z1("About ComponentOne C1TrueDBGrid..."), new EventHandler(this.DisplayAboutBox))), а в IL этот код находится по меткам IL_0018*IL_003e. Нужно закомментировать его, и тем самым убьем еще одного зайца: теперь в контекстном меню контрола, когда мы находимся в дизайнере формы, не будет меню About ComponentOne C1TrueDBGrid. Однако если просто перекомпилировать контрол, изменения не будут видны. Дело в том, что Studio имеет свой собственный референс, поэтому дизайнер форм смотрит не на наш модифицированный контрол, а на оригинал. Чтобы увидеть изменения, заходим в дизайнер форм, удаляем с формы контрол, добавляем наш контрол на панель контролов, рисуем этот Grid на форме еще раз. Теперь все изменения видны. То же самое проделаем с классом TDBGridDesigner.

Находим метод [.]class*TDBGridDesigner -> Initialize. Комментируем инициализацию EventHandler по меткам IL_0018*IL_003e. Далее находим метод, обрабатывающий данное событие DisplayAboutBox*object. Комментируем строки 143177*143187.

[остался последний, пятый пункт] Класс C1TrueDBGrid наследует реализацию от интерфейса C1.Win.U. В Reflector’е смотрим на этот интерфейс. Он содержит всего один метод — Assembly GetCallingAssembly(), а значит, в классе C1TrueDBGrid тоже есть этот метод (он наследуется от этого интерфейса). Придется удалить его, поскольку теперь никто не будет вызывать его, но на всякий случай перед удалением проверим анализером, где он используется. Получается, что нигде? На самом деле все-таки используется, но по-хитрому. Вспомни начало статьи — то место, где делали исправление в конструкторе класса

C1TrueDBGrid, this.0WB = LicenseManager.Validate(typeof(C1.Win.C1TrueDBGrid.C1TrueDBGrid), this).

В этой строке в виде параметра передается ссылка this (ссылка на текущий класс). LicenseManager в свою очередь проверяет, имеет ли этот объект атрибут <LicenseProvider(...)>. В виде параметра должен выступать класс, производный от System.ComponentModel.LicenseProvider. Если все нормально, то LicenseManager создает объект с заданным в атрибуте типом, где и происходит проверка ключа. В нашем случае ключ проверяется в классе С1.win.ProviderInfo.

Вдруг в мою голову пришла мысль о том, что было бы неплохо удалить данный атрибут. Схема этого встроенного лицензирования сводится к тому, что платформа .NET делает CallBack, создавая объект, указанный в виде параметра атрибута <LicenseProvider(...)>. Наверное, в Microsoft считают, что в хорошо обфусцированном коде найти проверку ключа тяжело, при условии что вызов проверки пойдет через этот странный CallBack. До того как начал писать статью, я не имел даже представления о том, как это работает, но разобрался менее чем за пару минут. Однако вернемся к делу.

Назад на стр. 066-044-4  Содержание  Вперед на стр. 066-044-6