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

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

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

Во-первых, нужно удалить интерфейс С1.win.U из списка наследуемых интерфейсов. Находим класс [.]class*C1TrueDBGrid и видим строку implements C1.Win.U. Она должна выглядеть так: implements /*C1.Win.U,*/ .

Немного ниже есть и атрибут: .custom instance void [System]System.ComponentModel.LicenseProviderAttribute. Его тоже комментируем. Теперь находим метод GetCallingAssembly(), который находится в строках 74511*74521.

Наконец-то мы избавились от всего кода, использующего классы пространства имен C1.Win, и теперь их можно подвергнуть благополучному удалению. Находим начало C1.Win [.]Namespace*C1.Win и, начиная со строки 144314 до строки 156166, комментируем этот код. Целых 11 тысяч строк IL-кода :), причем это еще не все. В листинге все классы и пространства имен существуют в коротком формате — тут представлен своего рода каталог, который описывает структуру сборки, и классы в нем пустые. Указывается только название класса и его атрибуты, такие как базовый класс, список интерфейсов, которые он обязуется реализовывать. Так что здесь мы должны также продублировать изменения. Закомментируем интерфейс C1.Win.U у класса C1TrueDBGrid в строке 606. Закомментируем и 19 классов в строках 1408*1499.

Теперь уделим внимание ненужным ресурсам. Их использовали trial’ные формы, которых теперь нет. Соответственно, из IL-листинга нужно удалить и сами ресурсы. Описание ресурсов начинается со строки 102. Необходимо закомментировать ресурсы: C1.Win.LicensingForm.resources, C1.Win.BetaAboutForm.resources, C1.Win.AboutForm.resources.

Теперь возвращаем наши исправления в конструкторе класса C1TrueDBGrid (они были проделаны в начале статьи, но потом мы отменили их). Компилируем, запускаем и видим, что все работает прекрасно. Теперь скомпилируем еще раз, но без флага /debug. В итоге размер файла составил 784 Кб, а размер оригинала — 888 Кб. Своими манипуляциями мы сэкономили 104 килобайта. Думаю, 15 минут работы стоили того. Однако нужно отметить еще один момент.

[если .NET-компоненты используют] другие сборки, то может быть задействована круговая ссылка зависимости, то есть в Reference сборки 1 будет ссылка на сборку 2, а в Reference сборки 2 — ссылка на сборку 1. При таком раскладе модификация любой из сборок приведет к ошибке загрузки сборки. Получается, что нужно убирать информацию о версиях и публичных ключах этих сборок. Вот пример ссылки на другую сборку:

.assembly extern System.Windows.Forms

{

.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )

.ver 1:0:3300:0

}

Она должна выглядеть так:

.assembly extern System.Windows.Forms

{

}

Нас настигнет та же самая проблема, если мы изменяем сборку, от которой зависит несколько других сборок. Придется сделать исправление во всех сборках.

[в заключение] Некоторые личности, чтобы использовать взломанные компоненты, упаковывают/шифруют сборки и хранят их либо во внешнем файле, либо в ресурсах, а при запуске программы расшифровывают и запускают динамически. Простой пример тому вынесен на врезку. В общем, побольше тебе красивых алгоритмов и удачи. Пей Фанту, будь Бамбучо