• Обзор методов: когда и зачем применять каждый из них

• Повышение производительности с помощью файловых менеджеров

• Назначение и структура демонстрационного приложения

• Короткий тест

• Краткие итоги

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

Таблица 1.1. Обзор методов

Таблица 1.1. Обзор методов (продолжение)

Таблица 1.1. Обзор методов (продолжение)

На протяжении большей части книги мы будем работать с одним и тем же демонстрационным приложением. Оно не отличается особой сложностью, но содержит основной набор компонентов, встречающихся в большинстве автономных программ на Java. В этом разделе описаны само приложение и его реализация.

Chat - простая реализация чата на Java, работающего по TCP/IP. Она позволяет пользователям обмениваться мгновенными сообщениями по сети. Chat хранит историю разговора и выделяет отправленные и полученные сообщения разными цветами. В приложении есть строка меню и диалоговое окно About. Chat можно запустить с помощью сценария chat.bat из каталога distrib/bin. Работающее приложение Chat показано на рисунке 1.2.

Chat реализовано с помощью Java Swing для пользовательского интерфейса и RMI для сетевого обмена. Во время работы каждый экземпляр Chat создаёт внутрипроцессный реестр RMI, который другие экземпляры используют для отправки сообщений пользователю. Пользователь должен ввести имя узла того адресата, которому он хочет отправить сообщение. При отправке сообщения Chat находит удалённый объект сервера и вызывает его метод. В целях тестирования сообщения можно отправлять на localhost: в этом случае одно и то же сообщение добавляется в разговор и как отправленное, и как полученное.

Рисунок 1.2. Приложение Chat

Диаграмма классов UML приложения Chat показана на рисунке 1.3.

Рисунок 1.3. Диаграмма классов Chat

Структура каталогов Chat соответствует стандартам де-факто для разработки приложений на Java. «Домашняя» папка каталогов приложения называется CovertJava. Содержащиеся в ней подкаталоги перечислены в таблице 1.3.

Таблица 1.3. Структура каталогов приложения Chat

Приложение Chat можно собрать с помощью Ant, используя файл build.xml из каталога build.

1. Какие методы можно использовать, чтобы узнать о внутренней реализации приложения?

2. Какие методы можно использовать, чтобы изменить внутреннюю реализацию приложения?

3. Какие методы можно использовать, чтобы перехватить обмен данными между клиентом и сервером?

4. Какие приложения Windows заменяют FAR и Total Commander?

• Различные методы, представленные в этой книге, позволяют изучать внутреннюю реализацию, чтобы взломать приложение или работать с JDK на системном уровне.

• Интегрированные приложения для управления файлами повышают производительность и стоят вложенных средств.

• Когда следует выполнять декомпиляцию

• Лучшие декомпиляторы

• Декомпиляция класса

• Благодаря чему возможна декомпиляция?

• Возможные проблемы с декомпилированным кодом

• Короткий тест

• Краткие итоги

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

• восстановление случайно утраченного исходного кода;

• изучение реализации какой-либо функции или приёма;

• устранение неполадок в приложении или библиотеке, для которых нет хорошей документации;

• срочное исправление ошибок в стороннем коде, исходный текст которого отсутствует;

• изучение способов защиты собственного кода от взлома.

Декомпиляция восстанавливает исходный код из байт-кода Java. Это процесс, обратный компиляции, и он возможен благодаря стандартной, хорошо документированной структуре байт-кода. Подобно тому как компилятор создаёт байт-код из исходного текста, декомпилятор позволяет получить исходный текст из имеющегося байт-кода. Декомпиляция - мощный способ изучения логики реализации при отсутствии документации и исходного кода. Именно поэтому многие поставщики программ прямо запрещают декомпиляцию и обратную разработку в лицензионном соглашении. Если вы не уверены в законности своих действий, обязательно проверьте лицензионное соглашение или получите явное разрешение поставщика.

Кто-то может возразить, что прибегать к таким крайним мерам, как декомпиляция, не следует и что поддержку и исправление ошибок нужно оставлять поставщикам байт-кода. Но в профессиональной среде разработчик приложения отвечает за безупречную работу его функций. Пользователям и руководству безразлично, находится ошибка в вашем или в стороннем коде. Им важно, чтобы проблема была устранена, и отвечать за это придётся вам. Предпочтительным способом должно быть обращение к поставщику стороннего кода. Однако в срочной ситуации, когда решение необходимо предоставить за считаные часы, умение работать с байт-кодом даст вам дополнительное преимущество перед коллегами, а возможно, принесёт ещё и премию.

Чтобы приступить к декомпиляции, нужны подходящие инструменты. Хороший декомпилятор способен создать исходный код, который почти не уступает оригиналу, скомпилированному в байт-код. Одни декомпиляторы бесплатны, другие распространяются на коммерческой основе. Хотя я поддерживаю принципы, лежащие в основе коммерческого программного обеспечения, чтобы я стал им пользоваться, оно должно давать заметные преимущества перед бесплатными аналогами. В случае декомпиляторов мне не удалось обнаружить недостатка функций у бесплатных программ, поэтому лично я рекомендую бесплатный инструмент, например JAD или JODE. В таблице 2.1 перечислены некоторые распространённые декомпиляторы и кратко описано качество каждого из них.

Приведённые URL могут со временем устареть, поэтому обычно проще всего найти домашнюю страницу декомпилятора и последнюю доступную для загрузки версию с помощью поиска Google.

Очень важный критерий - качество поддержки декомпилятором более сложных конструкций языка, например внутренних классов и анонимных реализаций. Хотя формат байт-кода почти не менялся со времён JDK 1.1, важно пользоваться декомпилятором, который авторы часто обновляют. Новые возможности языка в JDK 1.5 потребуют обновления декомпиляторов, поэтому обязательно проверяйте дату выпуска используемой версии.

Таблица 2.1. Декомпиляторы

Хотя на рынке можно найти и другие декомпиляторы, JAD и JODE, безусловно, достаточно хороши и поэтому широко применяются. Многие продукты предоставляют графический пользовательский интерфейс (GUI), но для самой работы используют входящий в комплект декомпилятор. Например, Decafe, DJ и Cavaj представляют собой GUI-инструменты, поставляемые вместе с JAD, и потому не вошли в обзор. В остальной части книги для получения исходного кода мы будем использовать консольную версию JAD. В большинстве случаев консольный декомпилятор - это всё, что вам нужно. Если же вы предпочитаете GUI, обязательно убедитесь, что в его основе лежит надёжный декомпилятор, например JAD или JODE.

Если вы прежде не пользовались декомпиляторами, давайте посмотрим, насколько хорошо они справляются со своей задачей. Мы будем работать с немного расширенной версией класса MessageInfo, который Chat использует для отправки текста сообщения и его атрибутов на удалённый узел. Файл MessageInfoComplex.java, приведённый в листинге 2.1, содержит анонимный внутренний класс (MessageInfoPK) и метод main(), демонстрирующие несколько более сложных случаев декомпиляции.

Листинг 2.1. Исходный код MessageInfoComplex (начало)

Листинг 2.1. Исходный код MessageInfoComplex (продолжение)

Листинг 2.1. Исходный код MessageInfoComplex (окончание)

После компиляции MessageInfoComplex.java с помощью javac и параметров по умолчанию мы получаем три файла классов: MessageInfoComplex.class, MessageInfoComplex$MessageInfoPK.class и MessageInfoComplex$1.class. Как вам, возможно, известно, внутренние и анонимные классы появились в Java в JDK 1.1, однако одной из целей проектирования было сохранение совместимости формата байт-кода с более ранними версиями Java. Поэтому эти конструкции языка порождают в определённой мере самостоятельные классы, хотя связь с родительским классом сохраняется. На последнем этапе проверки мы запустим декомпилятор для файла класса, а затем сравним созданный исходный код с оригиналом. Если вы загрузили и установили JAD и добавили его в путь поиска, программу можно запустить следующей командой:

Завершив работу, JAD создаёт файл MessageInfoComplex.jad. Мы переименовали его в MessageInfoComplex_FullDebug.jad; содержимое файла показано в листинге 2.2.

Листинг 2.2. Декомпилированный код MessageInfoComplex (начало)

Листинг 2.2. Декомпилированный код MessageInfoComplex (продолжение)

Листинг 2.2. Декомпилированный код MessageInfoComplex (окончание)

Уделите несколько минут просмотру созданного кода. Как видите, он почти на 100% совпадает с оригиналом! Порядок объявлений переменных, методов и внутреннего класса, а также форматирование различаются, но логика совершенно одинакова. Комментарии тоже потеряны, однако хорошо написанный код Java, подобный нашему, и без того понятен, не правда ли?

В нашем случае результат оказался хорошим, поскольку javac включает полные отладочные сведения при использовании параметра -g. Если исходный код скомпилировать без отладочных сведений (с параметром -g:none), декомпилированный код станет менее понятным: например, будут утрачены имена параметров методов и локальных переменных. Ниже показаны конструктор и использующий локальные переменные метод класса MessageInfoComplex, скомпилированного без отладочных сведений:

Исходный код Java, в отличие от исходного кода C/C++, компилируется не в двоичный машинный код. Результатом компиляции исходного текста Java становится промежуточный байт-код - не зависящее от платформы представление исходного кода. После загрузки байт-код можно интерпретировать или компилировать, поэтому преобразование высокоуровневого языка программирования в низкоуровневый машинный код выполняется в два этапа. Именно промежуточный этап делает декомпиляцию байт-кода Java почти безошибочной. Байт-код несёт всю существенную информацию исходного файла. Хотя комментарии и форматирование утрачиваются, все методы, переменные и программная логика, разумеется, сохраняются. Поскольку байт-код не является машинным языком самого низкого уровня, формат кода остаётся близок к исходному. Спецификация JVM определяет набор инструкций, соответствующих операторам и ключевым словам языка Java, поэтому такой фрагмент кода Java:

представляется следующим байт-кодом:

Формат байт-кода подробно рассматривается в главе 17 «Понимание и изменение байт-кода», однако сходство заметно уже при беглом взгляде на байт-код. Декомпилятор загружает его и пытается восстановить исходный текст на основе инструкций байт-кода. Имена методов и переменных класса обычно сохраняются, тогда как имена параметров методов и локальных переменных теряются. Если имеются отладочные сведения, они предоставляют декомпилятору имена параметров и номера строк, делая восстановленный исходный файл ещё понятнее.

В большинстве случаев декомпиляция создаёт читаемый файл, который можно изменить и снова скомпилировать. Однако иногда результат декомпиляции не удаётся скомпилировать повторно. Такое возможно, если байт-код был обфусцирован, а заданные обфускатором имена создают неоднозначность при компиляции. Байт-код проверяется во время загрузки, но средства проверки предполагают, что целый ряд ошибок уже был обнаружен компилятором. Поэтому проверка байт-кода не так строга, как компиляция, и обфускаторы могут воспользоваться этим для более надёжной защиты интеллектуальной собственности. Например, ниже приведён результат JAD для анонимного внутреннего класса из метода main() класса MessageInfoComplex, обфусцированного с помощью Zelix ClassMaster:

Как видите, это полный провал, нисколько не похожий на исходный код Java. Ещё тревожнее то, что JAD создал исходный код, который невозможно скомпилировать. Два других декомпилятора сообщили об ошибке в файле класса. Само собой разумеется, JVM без проблем распознаёт и загружает рассматриваемый байт-код. Обфускация подробно рассматривается в главе 3 «Обфускация классов».

Мощный способ защиты интеллектуальной собственности состоит в кодировании файлов классов и применении собственного загрузчика классов, который декодирует их при загрузке. В этом случае декомпиляторы нельзя использовать ни для одного класса приложения, кроме точки входа и самого загрузчика. Кодирование не является непреодолимой защитой, но значительно усложняет взлом. Сначала злоумышленнику придётся декомпилировать загрузчик классов, чтобы понять механизм декодирования, затем декодировать все файлы классов, и только после этого он сможет приступить к декомпиляции. Сведения о наилучших способах защиты интеллектуальной собственности в приложениях Java приведены в главе 19 «Защита коммерческих приложений от взлома».

1. По каким причинам выполняют декомпиляцию байт-кода?

2. Какие параметры компилятора влияют на качество декомпиляции и каким образом?

3. Почему декомпилированный байт-код Java почти идентичен исходному коду?

4. Как защитить байт-код от декомпиляции?

• Декомпиляция создаёт из байт-кода исходный код, почти идентичный оригиналу.

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

• Для декомпиляции необходимо загрузить и установить декомпилятор.

• Декомпиляция классов Java эффективна благодаря тому, что байт-код представляет собой промежуточный этап между исходным и машинным кодом.

• Хороший обфускатор способен сделать декомпилированный код крайне трудным для чтения и понимания.

• Защита идей, лежащих в основе вашего кода

• Обфускация как средство защиты интеллектуальной собственности

• Преобразования, выполняемые обфускаторами

• Лучшие обфускаторы

• Возможные проблемы и распространённые решения

• Обфускация приложения Chat с помощью Zelix KlassMaster

• Взлом обфусцированного кода

• Короткий тест

• Краткие итоги

Обратная разработка и взлом существуют с самых первых дней разработки программного обеспечения. Более того, кража или воспроизведение чужих идей всегда были самым простым способом создания конкурентоспособных продуктов. Разумеется, есть и вполне приемлемый способ опираться на прежние открытия других людей, и пока эти люди не возражают, он прекрасно работает. Однако большинство изобретателей и исследователей хотели бы получить признание и, возможно, финансовое вознаграждение за свой труд. Проще говоря, им тоже нужно выплачивать ипотеку и ездить в отпуск.

Хороший способ защитить интеллектуальную собственность - получить авторские права и патенты на уникальные особенности работы. Это, безусловно, рекомендуется для изобретений и крупных открытий, потребовавших значительных вложений в исследования и разработку. Оформление авторских прав на программу - довольно простой и экономичный процесс, но он защищает только «оригинальный» код приложения, а не заложенные в нём идеи. Другие люди не смогут без разрешения автора взять защищённый авторским правом код и использовать его в своих приложениях, но собственная реализация той же функции нарушением считаться не будет. Патенты обеспечивают гораздо более надёжную защиту, поскольку охватывают идеи и алгоритмы, а не конкретную реализацию, однако подача патентной заявки обходится дорого, а получение патента может занять годы.

Реален ли риск взлома вашего приложения? Если в нём есть хорошие идеи, то безусловно. На момент написания книги большинство широко освещавшихся случаев обратной разработки не относилось к продуктам Java, однако вот выдержка из сообщения одного поставщика Java-продуктов, DataDirect Technologies:

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

В реальном мире авторское право на код и патент на подход не обеспечивают достаточной защиты, если конкурент или злоумышленник может без труда изучить реализацию по исходному коду. Вопросы юридической защиты рассматриваются в отдельной главе, а пока сосредоточимся на разумных способах защиты интеллектуальной собственности (ИС) приложений Java.

Обфускация - процесс преобразования байт-кода в менее понятную человеку форму с целью затруднить обратную разработку. Обычно он включает удаление всех отладочных сведений, например таблиц переменных и номеров строк, а также переименование пакетов, классов и методов с присвоением им имён, созданных машиной. Более развитые обфускаторы идут дальше: изменяют поток управления кода Java, перестраивая существующую логику и вставляя фиктивный код, который никогда не будет выполнен. Основное условие обфускации состоит в том, что преобразования не должны нарушать корректность байт-кода или изменять предоставляемые извне функции.

Обфускация возможна по тем же причинам, что и декомпиляция: байт-код Java стандартизован и хорошо документирован. Обфускаторы загружают файлы классов Java, разбирают их формат, а затем применяют преобразования в соответствии с поддерживаемыми возможностями. После выполнения всех преобразований байт-код сохраняется в новом файле класса. Новый файл имеет другую внутреннюю структуру, но ведёт себя точно так же, как исходный.

Обфускаторы особенно необходимы для продуктов и технологий, в которых логика реализации передаётся пользователю. Так происходит со страницами HTML и JavaScript, где продукт распространяется в форме исходного кода. Положение Java ненамного лучше: хотя программы обычно распространяются в виде двоичного байт-кода, декомпилятор, подобный описанному в предыдущей главе, способен получить исходный текст, почти не уступающий оригиналу.

Существует множество обфускаторов, и большинство из них предлагает один и тот же набор основных функций. В таблице 3.1 приведены лишь несколько самых популярных бесплатных и коммерческих продуктов.

Таблица 3.1. Популярные обфускаторы

Для коммерческих приложений, содержащих интеллектуальную собственность, я рекомендую Zelix KlassMaster прежде всего благодаря уникальной обфускации потока управления. Этот приём делает обфусцированный код действительно трудным для взлома, поэтому продукт стоит каждого заплаченного за него доллара. На момент написания это единственный известный обфускатор с такой возможностью. ProGuard бесплатно доступен на <www.sourceforge.net> и является лучшим выбором для экономного пользователя, чьи приложения не требуют защиты коммерческого уровня.

Хотя у каждого обфускатора свой формат настройки преобразований, все они поддерживают общий набор функций. В приложении Chat нет передовых алгоритмов или ожидающих патента изобретений, но оно дорого нашему сердцу, поэтому мы воспользуемся Zelix KlassMaster, чтобы защитить его от любопытных взглядов злоумышленников и воров.

Сначала получим копию Zelix KlassMaster и установим её на локальную машину. Напомним, что домашний каталог приложения Chat мы называем CovertJava. Затем скопируем ZKM.jar из каталога установки KlassMaster в каталог lib нашего проекта, чтобы иметь возможность обращаться к нему из сценария. Проще всего создать сценарий обфускации с помощью GUI KlassMaster. Из каталога lib запустим GUI командой:

В появившемся начальном вспомогательном диалоговом окне выберем Set Classpath. Затем укажем библиотеки времени выполнения используемой JDK, а в появившемся после этого диалоговом окне Open Classes выберем CovertJava/lib/chat.jar. KlassMaster должна загрузить все классы приложения Chat, после чего станет доступен просмотр внутренней структуры байт-кода. Экран должен выглядеть примерно так, как показано на рисунке 3.1.

Рисунок 3.1. Классы Chat, загруженные в GUI KlassMaster

При работе с GUI сразу становится видно, насколько гибка KlassMaster. Можно вручную менять имена классов, методов и полей; изменять видимость классов и методов; объявлять методы final; менять текстовые строки и выполнять другие полезные действия. KlassMaster пытается распространить изменения по всему загруженному коду: если на метод с изменённым именем ссылаются другие классы, ссылки в них также обновляются. После внесения всех изменений классы можно сохранить в текущем виде либо сначала сократить и обфусцировать. Загруженные в среду GUI классы можно изменять и после обфускации, хотя я не могу придумать, зачем это кому-либо понадобится. Подробное описание функций KlassMaster и способов их применения приведено в руководстве пользователя.

Хорошо написанное приложение Java предоставляет сценарии сборки, поэтому встроим обфускацию в наш сценарий. Сначала с помощью GUI KlassMaster создадим сценарий обфускации, затем вручную изменим его, чтобы сделать гибче. Сценарий вполне можно написать вручную либо скопировать и изменить пример. Запустим GUI, выберем ZKM Script Helper в меню Tools, а затем выполним следующие действия:

1. Прочитайте инструкции на странице Introductory Page и нажмите Next.

2. На странице Classpath Statement выберите rt.jar и нажмите Next.

3. На странице Open Statement перейдите к CovertJava/distrib/chat.jar и нажмите >, чтобы выбрать файл для открытия. Нам нужен только один файл, поскольку в нём упакованы все классы приложения. Нажмите Next.

4. На странице TrimExclude Statement по умолчанию уже заданы исключения для случаев, в которых обфускация, вероятнее всего, приведёт к ошибке. Например, переименование методов класса реализации EJB делает его непригодным к использованию, поэтому EJB по умолчанию исключаются.

5. На странице Trim Statement установите флажки Delete Source File Attributes и Delete Deprecated Attributes, чтобы избавиться от отладочных сведений, затем нажмите Next.

6. В раскрывающемся списке Don’t Change Main Class Name на странице Exclude Statement выберите covertjava.chat.ChatApplication, чтобы сохранить это имя. Благодаря этому записи манифеста JAR останутся действительными, а пользователи по-прежнему смогут запускать чат с помощью понятного человеку имени.

7. На странице Obfuscate Statement выберите Aggressive в списке Obfuscate Control Flow. Затем выберите Aggressive в списке Encrypt String Literals и Scramble в списке Line Number Tables. Это обеспечит коду достаточную защиту, но позволит впоследствии преобразовывать трассировки стека. Убедитесь, что установлен флажок Produce a Change Log File, и нажмите Next.

8. На странице SaveAll Statement перейдите к CovertJava/distrib, создайте подкаталог obfuscated, выберите его в качестве каталога вывода и нажмите Next.

9. На следующей странице должен появиться текст сценария и возможность сохранить его в каталог. Сохраните сценарий под именем obfuscate_script.txt в каталоге CovertJava/build и завершите работу GUI.

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

Листинг 3.4. Сценарий обфускации, созданный GUI (начало)

Листинг 3.4. Сценарий обфускации, созданный GUI (окончание)

Стоит заменить абсолютные пути к файлам относительными, чтобы вместо C:\Projects\CovertJava\distrib\chat.jar сценарий открывал distrib\chat.jar. Наконец, встроим обфускацию в процесс сборки, объявив собственную задачу и добавив цель, которая её вызывает. KlassMaster написана на Java, поэтому её можно вызывать из любого сценария сборки. К счастью, она предоставляет класс-обёртку для интеграции с Ant, так что нам достаточно добавить в build.xml приложения Chat следующий код:

Теперь можно запустить Ant для цели obfuscate. Если сборка завершится успешно, в CovertJava/distrib/obfuscated будет создан новый файл chat.jar. Он содержит обфусцированную версию Chat, которую по-прежнему можно запустить командой java -jar chat.jar. Уделите несколько минут изучению содержимого этого JAR и попробуйте декомпилировать некоторые классы.

Прежде чем закончить разговор об использовании KlassMaster, я хотел бы привести ещё несколько примеров синтаксиса файла сценария для исключения классов и членов классов из обфускации. Формат из таблицы 3.2 можно применять в инструкциях сценария обфускации, принимающих имена в качестве параметров. Язык сценариев ZKM поддерживает подстановочные знаки, например * (любая последовательность символов) и ? (любой один символ), а также логические операции, например || (или) и ! (не). Подробное объяснение и полный синтаксис приведены в документации KlassMaster.

Таблица 3.2. Часто используемые шаблоны имён KlassMaster

После столь долгого разговора о защите интеллектуальной собственности с помощью обфускации следует сказать несколько слов о прочности этой защиты. Затрудняет ли хороший обфускатор взлом приложения? Безусловно. Гарантирует ли он, что приложение не будет взломано? Вовсе нет!

Если обфускация потока управления не применяется, читать обфусцированный код и работать с ним не так уж трудно. Главное - найти хорошую исходную точку для декомпиляции. В главе 2 «Декомпиляция классов» представлено несколько методов обратной разработки приложений, но обфускация способна нейтрализовать многие из них. Например, самый эффективный способ найти исходную точку - искать текст в файлах классов. При кодировании строк поиск ничего не даст, поскольку строки не хранятся как обычный текст. Имена пакетов и классов тоже больше нельзя использовать для изучения структуры приложения и выбора хорошей исходной точки. Технически всё ещё возможно декомпилировать точку входа приложения среднего размера и двигаться по потоку управления, но на практике это неосуществимо.

Для кода с обфусцированным потоком управления самый разумный способ изучить реализацию приложения - воспользоваться старым добрым отладчиком. Большинство IDE имеет средства отладки, однако в нашем случае потребуется мощный отладчик, способный работать без исходного кода. Чтобы найти хорошую исходную точку для декомпиляции, приложение нужно запустить в режиме отладки. В Java есть стандартный программный интерфейс для отладчиков под названием Debugger API (кто бы мог подумать!), поддерживающий как локальную, так и удалённую отладку. Удалённая отладка позволяет отладчику подключиться к приложению, работающему в режиме отладки, и является предпочтительным способом взлома приложения. Хорошие отладчики показывают подробные сведения о выполняющихся потоках, стеки вызовов каждого потока, загруженные классы и находящиеся в памяти объекты. Они позволяют устанавливать точки останова и трассировать выполнение методов. Главное при работе с обфусцированными приложениями - использовать обычный интерфейс (UI или программный API), чтобы перейти к интересующей функции, а затем с помощью отладчика выяснить, какой класс или классы её реализуют. После определения классов их можно декомпилировать и изучить, как описано в главе 2. Работа с отладчиками подробно рассматривается в главе 9 «Взлом кода с помощью нестандартных отладчиков».

1. Какие средства позволяют защитить интеллектуальную собственность в приложениях Java?

2. Какие преобразования обфускаторов обеспечивают наиболее надёжную защиту?

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

4. Какой способ изучения обфусцированного кода наиболее эффективен?

• Обфускация может быть лучшим способом защиты интеллектуальной собственности в байт-коде Java.

• Обфускаторы выполняют некоторые или все из следующих преобразований: удаляют отладочные сведения, искажают имена, кодируют строки, изменяют поток управления, вставляют повреждённый код, удаляют неиспользуемый код и оптимизируют байт-код.

• Обфускация затрудняет сопровождение, но эти трудности можно свести к минимуму правильной настройкой обфускатора.

• Обфусцированный код по-прежнему остаётся читаемым, если не применяются обфускация потока управления и кодирование строк.

• Проблема инкапсуляции

• Доступ к членам класса с пакетной и защищённой видимостью

• Доступ к закрытым членам класса

• Короткий тест

• Краткие итоги

Инкапсуляция - один из столпов объектно-ориентированного программирования. Её назначение состоит в отделении интерфейса от реализации и обеспечении модульности компонентов приложения. Обычно рекомендуется объявлять члены данных закрытыми или защищёнными и предоставлять открытые функции доступа и изменения, также известные как функции чтения и записи. Иногда также рекомендуют объявлять внутренние методы реализации закрытыми или открытыми, чтобы защитить класс от неправильного использования. Следование принципу инкапсуляции помогает создать более качественное приложение, но порой становится препятствием для такого применения, которого разработчик класса не предусмотрел.

В наших экспериментах будет использоваться java.awt.BorderLayout. Возможно, это когда-нибудь побудит инженеров JavaSoft добавить открытые методы. Исходный код BorderLayout мы получим из файла src.jar в каталоге установки JDK.

Сначала продемонстрируем, как легко получить доступ к переменным и методам с пакетной видимостью. В примере используется переменная с пакетной видимостью, но этот приём столь же хорошо работает и с защищённой видимостью. Переменная или метод имеют пакетную видимость, если при объявлении не указано явное ключевое слово видимости, такое как public, protected или private. BorderLayout хранит компонент, добавленный с ограничением BorderLayout.CENTER, в переменной center, объявленной следующим образом:

Напомним, что члены с пакетной видимостью доступны объявившему их классу и всем классам того же пакета. В нашем примере любой класс пакета java.awt может напрямую обратиться к переменной center. Поэтому простое решение состоит в том, чтобы создать в пакете java.awt вспомогательный класс AwtHelper и через него обращаться к членам экземпляров BorderLayout с пакетной видимостью. В AwtHelper есть открытая функция, которая принимает экземпляр BorderLayout и возвращает компонент для заданного ограничения компоновки:

Напишем тестовый класс covertjava.visibility.PackageAccessTest, который с помощью AwtHelper получает экземпляр разделённой панели из MainFrame приложения Chat. Больше всего нас интересует следующий фрагмент исходного кода:

Мы получаем компоновку контейнера и, если это BorderLayout, с помощью AwtHelper извлекаем центральный компонент. В центре MainFrame приложения Chat находится разделённая панель, поэтому при правильном коде в системной консоли должен появиться экземпляр JSplitPane. При запуске PackageAccessTest мы получаем следующее исключение:

Исключение создаётся потому, что java.awt считается системным пространством имён, которым обычные классы пользоваться не должны. При попытке взломать член стороннего класса с пакетной видимостью этого бы не произошло, но мы намеренно выбрали системный класс, чтобы показать реальный пример.

Единственная возможная проблема при применении этого приёма к несистемному пространству имён, например com.mycompany.mypackage, возникает, если пакет запечатан. Чтобы добавить вспомогательный класс в запечатанный пакет, нужен тот же приём, который применяется для добавления исправленного класса в главе 5 «Замена и исправление классов приложения».

Добавить системный класс несколько сложнее, поскольку такие классы загружаются и обрабатываются иначе, чем классы приложений. Системные классы всесторонне рассматриваются в главе 16 «Перехват потока управления». Пока достаточно сказать, что класс, добавляемый в системный пакет, должен находиться в пути загрузки основных классов. Каталог или файл JAR можно поместить в начало или конец этого пути с помощью параметра -Xbootclasspath в командной строке java. Поскольку у приложения Chat уже есть подкаталог patches, воспользуемся им и для системных классов. Изменим build.xml, чтобы переместить каталог java.lang с AwtHelper в distrib/patches, и создадим в distrib/bin новый сценарий package_access_test.bat:

Запуск package_access_test.bat даёт следующий результат:

Необходимость помещать классы в путь загрузки основных системных классов несколько усложняет развёртывание, поскольку требует изменить сценарий запуска. Например, веб-приложение, развёртываемое в веб-контейнере наподобие Tomcat или WebLogic, уже нельзя просто развернуть через консоль или каталог развёртывания приложений. Сценарий запуска сервера приложений придётся изменить, добавив параметр -Xbootclasspath. Другой недостаток этого приёма заключается в том, что он не работает с закрытыми членами. И последнее, но не менее важное: добавление классов в пакеты может нарушать лицензионное соглашение. Именно так обстоит дело с BorderLayout, поскольку один из разделов лицензионного соглашения Java компании Sun прямо запрещает добавлять классы в пакеты, имена которых начинаются с java. В следующем разделе представлена другая возможность, устраняющая некоторые из этих проблем.

Закрытые члены доступны только объявившему их классу. Это одно из основных правил языка Java, обеспечивающих инкапсуляцию. Но так ли это на самом деле? Всегда ли правило соблюдается? Если вы подумали: «Раз этот человек об этом пишет, значит, какая-то лазейка должна быть», то оказались правы. Компилятор Java контролирует закрытость членов во время компиляции. Поэтому другие классы не могут содержать статических ссылок на закрытые методы и переменные класса.

Однако в Java есть мощный механизм рефлексии, позволяющий запрашивать метаданные экземпляров и классов и обращаться к полям и методам во время выполнения. Поскольку рефлексия динамична, проверки времени компиляции к ней неприменимы. Вместо этого среда выполнения Java полагается на диспетчер безопасности, если он существует, чтобы проверить достаточность привилегий вызывающего кода для конкретного вида доступа. Диспетчер безопасности обеспечивает достаточную защиту, поскольку все функции API рефлексии перед выполнением своей логики делегируют проверку ему. Ослабляет эту защиту то, что диспетчер безопасности часто не задан. По умолчанию он отсутствует, и если код явно не устанавливает стандартный или собственный диспетчер, проверки управления доступом во время выполнения не действуют. Даже установленный диспетчер безопасности обычно настраивается файлом политики, который можно расширить, разрешив доступ к API рефлексии.

Если вы внимательно посмотрели на класс BorderLayout, то могли заметить, что в нём уже есть метод, возвращающий дочерний компонент по ключу положения. Неудивительно, что он называется getChild и имеет следующую сигнатуру:

Это хорошая новость: писать собственную реализацию не требуется. Проблема в том, что метод объявлен закрытым и вызвать его через открытый метод невозможно. Чтобы воспользоваться существующим кодом JDK, нужно вызвать BorderLayout.getChild() посредством API рефлексии. Мы используем ту же структуру теста, что и в предыдущем разделе. Но на этот раз тестовый класс вместо AwtHelper делегирует работу собственной вспомогательной функции getChild():

Реализация getChild() составляет суть приёма. Она получает объект метода посредством рефлексии, а затем вызывает setAccessible(true). Значение true подавляет проверку управления доступом и разрешает вызов метода. Остальная часть метода представляет собой обычное применение API рефлексии. Запуск covertjava.visibility.PrivateAccessTest даёт тот же результат, что и в предыдущем разделе:

Это оказалось пугающе просто. Если диспетчер безопасности установлен посредством System.setSecurityManager или из командной строки, как бывает в большинстве серверов приложений и связующего программного обеспечения, придётся потрудиться чуть больше. Если запустить наш тест, передав в командной строке java параметр -Djava.security.manager, мы получим следующее исключение:

Чтобы код работал при установленном диспетчере безопасности, необходимо предоставить разрешения на доступ к объявленным членам посредством рефлексии и на подавление проверок доступа. Для этого добавим файл политики Java, предоставляющий нашей базе кода два разрешения:

Наконец, создадим в каталоге distrib\bin новый тестовый сценарий private_access_test.bat, который добавляет параметр командной строки java.security.policy для установки нашего файла политики:

Если файл политики уже установлен, нашу инструкцию grant нужно вставить в него. Файлы безопасности Java позволяют подключать дополнительные файлы политики с помощью атрибута policy.url.n. Безопасность Java и файлы политики подробно рассматриваются в главе 7 «Управление безопасностью Java».

Приём, основанный на API рефлексии, можно применять и для доступа к членам с пакетной и защищённой видимостью. Благодаря этому больше не нужно вставлять вспомогательные классы в сторонние пакеты. Недостаток API рефлексии - общеизвестная медлительность, поскольку ему приходится работать со сведениями времени выполнения и, возможно, проходить несколько проверок безопасности. Когда важна скорость, для членов с пакетной и защищённой видимостью предпочтительнее вспомогательные классы. Ещё одна возможность - сериализовать экземпляр в поток массива байтов, а затем разобрать поток и получить значения переменных-членов. Очевидно, это утомительный процесс, который не работает с переходными полями.

1. Какой приём позволяет получить значение защищённой переменной?

2. Какой приём позволяет получить значение закрытой переменной?

3. Каковы преимущества и недостатки каждого приёма?

• Доступ можно получить даже к методам и переменным, которые не объявлены открытыми.

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

• К члену с закрытой видимостью можно обратиться с помощью API рефлексии.

• Если установлен диспетчер безопасности, политику Java необходимо изменить так, чтобы разрешить API рефлексии неограниченный доступ.

• Что делать, когда мы испробовали все пути, но потерпели неудачу?

• Поиск класса, который необходимо исправить

• Пример ситуации, требующей исправления

• Исправление класса для реализации новой логики

• Перенастройка приложения для загрузки и использования исправленного класса

• Исправление запечатанных пакетов

• Короткий тест

• Краткие итоги

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

Разумеется, всегда лучше решать вопросы мирным путём. Если можно убедить поставщика изменить код или вы сами вправе это сделать, непременно так и поступите. Но уже один тот факт, что вы читаете эту книгу, доказывает: в реальной жизни традиционный подход работает не всегда. И вот тут начинается самое интересное. Итак, когда следует прибегать к замене и исправлению классов? Ниже перечислены несколько ситуаций, требующих хакерского подхода:

• Вы используете стороннюю библиотеку, в которой есть нужная возможность, но она не предоставлена через открытый API. Например, до JDK 1.4 Java Swing не предоставляла метода для получения списка слушателей JComponent. Компонент хранил слушателей в переменной с пакетной видимостью без открытого доступа, поэтому программно выяснить, имеются ли у него слушатели событий, было невозможно.

• Вы используете сторонний класс или интерфейс, но предоставляемые им функции недостаточно гибки для вашего приложения. Простое изменение API может сэкономить несколько дней работы или оказаться единственным решением проблемы. В таком случае вас устраивает 99% библиотеки, но оставшийся 1% мешает эффективно ею пользоваться.

• В используемом продукте или API есть ошибка, а ждать исправления от поставщика нельзя. Например, JRun 3.0 содержал ошибку определения версии JVM в HP UX. Разбирая строку версии, сообщаемую средой выполнения Java, он ошибочно заключал, что работает под управлением старой версии JDK, и отказывался запускаться.

• Вам нужна очень тесная интеграция с продуктом, но его архитектура недостаточно открыта для ваших требований. Многие каркасы отделяют интерфейсы от реализации. Внутри программы доступ к функциям осуществляется через интерфейсы, а реализацию предоставляют экземпляры конкретных классов. Основные библиотеки Java по большей части позволяют указывать классы реализации через системные свойства. Так обстоит дело с AWT Toolkit и анализатором SAX: классы реализации можно задать системными свойствами java.awt.toolkit и org.xml.sax.driver соответственно. Взлом потребуется, если нужно предоставить другой класс реализации для библиотеки, не имеющей средств настройки.

• Вы пользуетесь сторонним кодом, но ожидаемая функция не работает. Вы не знаете, вызвано ли это неправильным использованием или ошибкой в коде. В документации проблема не упоминается, а обходного решения нет. Временная вставка отладочной трассировки и сообщений в сторонний код поможет понять происходящее в системе.

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

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

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

Теперь, когда известно, что именно нужно исправить, сама работа относительно проста. Получите исходный файл непосредственно из дистрибутива или декомпилируйте файл .class, предварительно убедившись, что лицензия этого не запрещает. Для удобства сопровождения все исправленные классы следует держать в отдельном каталоге, например patches. Воспроизведите структуру каталогов, соответствующую структуре пакета класса, и внесите изменения с помощью любимой IDE либо обычного редактора и консольного компилятора. Помните, что библиотеку, скорее всего, когда-нибудь придётся обновить, поэтому каждый вставленный фрагмент кода необходимо снабдить комментариями. Тогда после получения новой версии исходного класса изменения будет легко повторить.

По той же причине изменения следует изолировать и держать вместе в одном месте файла. Если добавляется заметный объём кода, подумайте о создании вспомогательного класса и делегировании ему работы, чтобы как можно меньше менять исправляемый файл.

В нашем примере нужно предоставить новую реализацию метода getDisplayName(), использующую шаблон UserName (HostName). Создадим в каталоге установки приложения новый каталог patches с подкаталогом covertjava.chat, скопируем туда MessageInfo.jad и переименуем его в MessageInfo.java. В MessageInfo уже есть метод getUserName(), поэтому требуется лишь соединить две строки. Перепишем getDisplayName() следующим образом:

Затем скомпилируем MessageInfo.java. Теперь можно обновить приложение, чтобы новая логика вступила в силу. Изменения также следует задокументировать для последующего сопровождения кода.

Именно эта задача заставляет весь приём работать. Нужно добиться, чтобы JVM использовала предоставленную нами исправленную версию класса вместо старой. Это приводит нас к краеугольному камню программирования на Java - правильной настройке CLASSPATH. Да, всё настолько просто. Нужно лишь убедиться, что архив Zip или JAR либо каталог с исправленной версией класса находится в пути поиска классов раньше архива или каталога с оригиналом. В сценарии запуска приложения, настраивающем CLASSPATH, этот архив или каталог следует указать первым. Если держать все исправления вместе, но отдельно от исправляемых продуктов и библиотек, их легко сопровождать. Получив новую версию библиотеки, можно перезаписать старые файлы JAR, не опасаясь потерять исправления. Разумеется, всё нужно снова протестировать, а поскольку исправление опирается не только на открытые интерфейсы, но и на закрытые реализации, его может потребоваться привести в соответствие с новой библиотекой. И последнее: если понадобится объяснить кому-либо, что, чёрт возьми, вы сделали с системой, можно указать на каталог patches и документацию.

Как говорится, «всё не то, чем кажется». Иногда можно думать, что система загружает новый класс, хотя в действительности загружается старая версия. Лучший способ убедиться в использовании новой версии - добавить в новый класс отладочную трассировку или хотя бы грубый вызов System.out.println(). Запустив приложение, обязательно проверьте появление трассировки, после чего её можно удалить. В демонстрационном коде мы добавили статический инициализатор, выводящий сообщение о действующем исправлении:

Чтобы увидеть изменения в действии, обновим сценарий запуска Chat, включив каталог patches. Скопируем bin/chat.bat в bin/chat_patched.bat и откроем копию в редакторе. Затем изменим инициализацию CLASSPATH, чтобы каталог исправлений предшествовал файлу приложения chat.jar:

Сохраним файл и запустим его. Отправим несколько тестовых сообщений на localhost; если всё сделано правильно, новый экран будет выглядеть так, как на рисунке 5.2.

Рисунок 5.2. Главное окно исправленного приложения Chat

Если исправляется системный класс, задача становится сложнее. Системным называется класс, загруженный из пути основных классов, например java.lang.String. Даже если поместить исправленную версию первой в CLASSPATH, она не заменит оригинал. Исправление системных классов рассматривается в главе 15 «Замена и исправление основных классов Java».

Java поддерживает понятие запечатанных пакетов. Если пакет запечатан, все его классы должны загружаться из одного файла JAR. Для разработчиков приложений и поставщиков инструментов это замечательная возможность, призванная предотвратить только что изученный приём. Чтобы запечатать пакет, в файле манифеста JAR необходимо задать атрибут Sealed со значением true. Если файл chat.jar приложения Chat запечатан, запуск bin\chat_patched.bat создаёт следующее исключение:

К несчастью для поставщиков и к счастью для взломщиков и любознательных людей вроде нас, запечатанные пакеты часто легко вскрыть. Достаточно изменить значение атрибута Sealed в манифесте JAR на false либо извлечь содержимое JAR в рабочий каталог и изменить сценарий запуска так, чтобы вместо исходного файла JAR использовался этот каталог. Это пример благого намерения, которое так и не было реализовано всерьёз.

1. Какие подходы можно использовать для поиска исправляемого класса?

2. Почему класс можно искать по тексту и в каких случаях этот способ не работает?

3. Как получить стек вызовов в произвольной точке приложения, находящейся не внутри блока catch?

4. Каковы требования к установке исправления?

Чтобы исправить логику приложения, необходимо:

• найти класс, содержащий нужную логику;

• получить исходный код класса;

• изменить исходный код, реализовав новую логику;

• скомпилировать и развернуть новый файл класса;

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

• Введение в трассировку

• Трассировка как эффективный способ изучения программы

• Инструменты и API трассировки и журналирования

• Что следует и чего не следует делать при трассировке

• Короткий тест

• Краткие итоги

Трассировка - это запись отладочных сообщений в поток вывода во время выполнения приложения. Она в реальном времени создаёт зафиксированный след операций, выполняемых работающим приложением. Для трассировки приложение не обязательно запускать в режиме отладки. Кроме того, поскольку сообщения трассировки обычно записываются в файл журнала, она предоставляет сведения для изучения поведения приложения и устранения неполадок. Трассировка используется уже много лет, но особую популярность приобрела в серверном программировании. Небольшое приложение легко загрузить в отладчик и выполнить по шагам, исследуя проблему. Распределённые системы обычно значительно сложнее на стороне сервера и часто работают внутри продуктов связующего программного обеспечения, например сервера приложений или веб-сервера. Из-за этого пользоваться отладчиком непрактично, а пошаговое выполнение может нарушить многопоточную работу. Для работающих промышленных приложений отладка вообще невозможна, поэтому трассировка остаётся единственным правдоподобным способом получить сведения о происходящем в системе.

Трассировка вставляется в код почти так же, как комментарии, а качественная трассировка делает комментарии ненужными. Поскольку трассировка приводит к вызовам методов и записи сообщений в поток, она может обходиться дорого, особенно внутри циклов и часто вызываемых методов. Каркасы журналирования разрабатываются так, чтобы создавать минимальные накладные расходы при выполнении кода, и позволяют уменьшать уровень сообщений трассировки, записываемых в поток вывода. Однако важно понимать: даже не слишком хорошо оптимизированная трассировка всё равно лучше полного её отсутствия. Если проблема возникает в промышленном приложении без трассировки, единственным источником сведений остаются отзывы пользователей, которые, как всем известно, часто ненадёжны или неточны. Грамотная трассировка позволяет проследить действие пользователя и ответ приложения, чего в большинстве случаев достаточно для определения источника проблемы. В каждую запись следует включать идентификатор пользователя, чтобы журнал можно было фильтровать по операциям конкретного человека.

До JDK 1.4 в Java не было стандартного API журналирования. Учитывая популярность и важность журналирования для приложений J2EE, это несколько прискорбно. Из-за столь поздней стандартизации каждому поставщику и многим разработчикам приложений пришлось создавать собственную версию API трассировки и журналирования. Сегодня часто встречаются разные версии API журналирования, иногда даже внутри одного приложения. Например, приложение J2EE, работающее в WebLogic, может использовать Log4J для собственных отладочных трассировок, но API журналирования WebLogic для сообщений о критических ошибках системного уровня. Все API журналирования поддерживают уровни сообщений, определяющие, сколько сообщений записывается в файл журнала.

Мы уже говорили о важности трассировки для устранения неполадок в крупных системах. Сведения из журналов трассировки не менее ценны для понимания потока выполнения приложения и определения исходных точек обратной разработки. Поскольку трассировка предназначена для создания понятной человеку истории операций продукта, читать её легче, чем декомпилированный код Java. Файл журнала представляет снимок уже выполненной работы. Поэтому, если ошибка вызывает исключение без трассировки стека, можно включить самый подробный уровень трассировки, воспроизвести ошибку и найти последнее сообщение, попавшее в журнал до исключения. Тот же приём применим для поиска кода, который нужно исправить. Если приложение не предоставляет достаточной трассировки, в классы можно добавить сообщения и даже дампы стеков потоков посредством исправления. Работа утомительна, но может оказаться единственным эффективным способом изучения обфусцированного кода, особенно после обфускации потока управления. Трассировка устраняет необходимость гадать, поскольку её сообщения служат бесспорным доказательством того, что определённый фрагмент кода выполнялся в конкретный момент.

Если приложение ещё не выводит сообщения журнала, добавление трассировки может занять много времени и, признаем откровенно, это не та задача, о которой мечтает хороший разработчик. Быстрый и грубый способ взглянуть на состояние времени выполнения - вывести стек вызовов текущего потока из исследуемого метода, как описано в главе 5 «Замена и исправление классов приложения». Напомним: добавление вызова метода dumpStack() класса java.lang.Thread заставляет его вывести имена методов, образующих стек вызовов. Всего одна строка кода позволяет хорошо понять, какие вызовы привели к выполнению рассматриваемого метода.

Сегодня господствуют два API журналирования. Первый - Apache Log4J, появившийся в 1999 году в группе AlphaWorks компании IBM. С тех пор он прошёл долгий путь и сегодня, вероятно, является самым развитым и гибким API журналирования. Он бесплатен и может распространяться как отдельный файл JAR, совместимый со всеми версиями JDK начиная с 1.1. Узнаваемость бренда Apache и прекрасный набор функций Log4J принесли ему огромную популярность среди разработчиков Java; его можно считать стандартом де-факто журналирования Java.

Второй каркас - Java Logging API компании Sun, ставший официальным стандартом. Хорошо это или плохо, JCP решила не использовать Log4J, а создать новый стандарт. Java Logging API также мощен и гибок, хотя в нём отсутствуют некоторые развитые функции Log4J, в том числе:

• запись в системные журналы, например журнал событий Windows NT и Unix Syslog;

• ротация файлов журнала по дате;

• шаблоны форматирования в стиле функции языка C printf;

• повторная загрузка файла конфигурации.

Повторная загрузка файла конфигурации - важная возможность для высокодоступных приложений. Обычно конфигурация читается при инициализации каркаса, то есть, как правило, во время запуска приложения. Изменения уровней и категорий журналирования не подхватываются до перезапуска приложения. При устранении неполадок в работающей промышленной системе частые перезапуски исключены, поэтому без повторной загрузки уровень журналирования приходится выбирать до запуска приложения.

Для взлома и обратной разработки Log4J явно предпочтительнее, поскольку работает со всеми версиями JDK. Загрузка и документация в Интернете доступны по адресу jakarta.apache.org.

1. Чем трассировка отличается от отладки?

2. Как использовать трассировку для взлома приложения?

3. Почему возможность повторной загрузки конфигурации журналирования во время выполнения так важна?

4. Чем опасно использование оператора + для соединения строк?

• Трассировка - это запись отладочных сообщений в поток вывода во время выполнения приложения.

• Трассировка вставляется в код приложения в виде вызовов API.

• Трассировка создаёт накладные расходы, но они оправданы упрощением устранения неполадок.

• Добавление трассировки помогает понять поток выполнения приложения.

• И Log4J, и Java Logging API являются хорошими каркасами журналирования. Log4J более развит и может использоваться с версиями JDK до 1.1, поэтому лучше подходит для взлома.

• Обзор безопасности Java

• Обход проверок безопасности

• Короткий тест

• Краткие итоги

Java с самого начала проектировалась как безопасный язык. Безопасность включает такие возможности языка, как проверка границ индексов массивов, проверка байт-кода и управляемый доступ к критически важным системным ресурсам, например файлам и сведениям о пользователе. Первоначально модель безопасности предполагала, что всем локально установленным классам следует предоставлять доступ к системным ресурсам, а весь байт-код, загруженный по сети, необходимо ограничивать в доступе к конфиденциальной информации и операциям. По мере развития Java граница между локальными и удалёнными классами несколько размылась. Серверы приложений и веб-серверы полагаются на модель безопасности, чтобы один компонент, например веб-приложение, не нарушал работу другого. Подписанные апплеты позволяют загруженному коду обращаться к локальным файлам, буферу обмена и системным свойствам.

Различные основные классы во время выполнения используют каркас безопасности для проверки того, разрешено ли вызывающей стороне выполнить запрошенную операцию. В центре модели безопасности находится экземпляр java.lang.SecurityManager, служащий фасадом для пакета java.security. В Java доступ к системным сведениям или ресурсу представляется разрешением. Например, PropertyPermission представляет доступ к системным свойствам. Перед выполнением логики метода основные классы обращаются к диспетчеру безопасности, чтобы проверить наличие у вызывающей стороны нужных разрешений. Работу механизма проще всего понять на примере реализации метода System.setProperty(), приведённой в листинге 7.1.

Листинг 7.1. System.setProperty

Сначала реализация получает системный диспетчер безопасности. Если он установлен и параметры корректны, диспетчер проверяет, предоставлено ли разрешение PropertyPermission на запись в указанный ключ. Метод checkPermission диспетчера безопасности создаёт исключение SecurityException, если разрешение отсутствует. Новое значение системного свойства задаётся только после успешного возврата из checkPermission. В таблице 7.1 перечислены операции, контролируемые диспетчером безопасности.

Таблица 7.1. Операции, защищаемые диспетчером безопасности

Сведения о том, какие разрешения предоставлены каким классам, хранятся в файлах политики Java. Сначала из каталога ${java.home}/lib/security, где ${java.home} - каталог установки JRE, загружается общесистемный файл java.policy. Затем, если он существует, загружается ${user.home}/.java.policy. Собственный файл политики Java можно задать в командной строке параметром -Djava.security.policy. Подробное описание безопасности и разрешений Java находится по адресу java.sun.com.

Безопасность Java включает API шифрования (JCE), аутентификации и авторизации (JAAS), поддержки защищённых сокетов (JSSE) и многие другие. Эти дополнительные API предоставляют мощные средства защиты информации, но в обычном приложении напрямую не используются. Мы сосредоточимся на возможностях безопасности, с которыми разработчик приложения сталкивается чаще всего.

1. Какой класс служит фасадом для каркаса безопасности Java?

2. Какую роль играют разрешения?

3. Какие файлы и в каком порядке загружаются для определения предоставляемых разрешений?

• Безопасность Java управляет доступом к системным сведениям и ресурсам посредством разрешений.

• Диспетчер безопасности находится в центре модели безопасности. Если он не установлен, проверки не выполняются.

• Разрешения можно предоставлять в файлах политики Java.

• Файлы политики можно указывать в командной строке или через файл конфигурации безопасности Java.

• Ценность понимания среды выполнения

• Системные свойства

• Сведения о системе

• Сведения о памяти

• Сведения о сети

• Доступ к переменным среды

• Короткий тест

• Краткие итоги

Взлом систем и устранение неполадок в приложениях часто требуют изменения различных системных параметров. Например, чтобы установить исправленную версию класса в главе 5 «Замена и исправление классов приложения», мы изменили значение переменной CLASSPATH. В главе 7 «Управление безопасностью Java» было показано, как установить диспетчер безопасности посредством системного свойства. Понимание среды выполнения и знание точных значений системных параметров позволяет опираться в работе на факты, а не на предположения. В этой главе вы узнаете, как получать значения системных свойств, проверять наличие диспетчера безопасности и извлекать различные сведения о памяти и сети.

Большая часть полезных сведений легко доступна через классы API Java, если знать, где искать. Из-за кроссплатформенной природы Java сведения о базовом оборудовании и физических ресурсах ограничены. В этой главе мы создадим класс исследования, который собирает и выводит все полезные сведения о среде. Его можно вызвать из работающего приложения или запустить отдельно, указав covertjava.snoop.RuntimeInfo как главный класс либо воспользовавшись snoop_re.bat. Например, серверы приложений обычно запускаются через последовательность пакетных файлов или сценариев оболочки, настраивающих переменные среды и параметры приложения. Код запуска сервера может изменить стандартное состояние среды, и единственный надёжный способ узнать текущие значения - вывести их посредством трассировки.

Системные свойства - пары «имя-значение», содержащие сведения о среде выполнения. В них входят данные об операционной системе, поставщике и версии JVM, пути загрузки классов и библиотек, домашний и текущий каталоги пользователя и другие полезные свойства. Значение каждого свойства можно найти в Интернете, и я рекомендую с ними познакомиться. Хорошая исходная точка - JavaDoc класса java.lang.System по адресу java.sun.com. В листинге 8.1 показано, как вывести все системные свойства.

Листинг 8.1. Исходный код printSystemProperties

Выполнение этого метода даёт примерно следующий результат:

Системные свойства можно изменять методом System.setProperty(). Если диспетчер безопасности установлен, он проверяет наличие у вызывающей стороны разрешения на запись в нужное свойство. Некоторые свойства читаются только при инициализации и потому фактически ведут себя как доступные только для чтения. Например, свойство java.class.path описывает путь загрузки классов. Хотя его значение можно изменить, желаемого результата это не даст, потому что системный загрузчик классов читает его лишь один раз и последующего изменения не видит. Управление безопасностью Java подробно рассматривалось в главе 7.

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

Листинг 8.2. Исходный код printSystemInfo

JVM управляет памятью, доступной приложению Java. Когда приложение запрашивает дополнительную память, JVM сначала проверяет, можно ли удовлетворить запрос за счёт свободной памяти, уже выделенной процессу. Если свободной памяти недостаточно, JVM может принудительно запустить сборку мусора, пытаясь освободить память, занятую мёртвыми объектами. Если сборка не освобождает достаточно памяти, JVM пытается получить её у операционной системы, увеличивая общий выделенный объём. Она продолжает получать память от ОС до разрешённого максимума, который по умолчанию равен 16 Мбайт, но может быть задан параметром -Xmx.

Управление памятью имеет решающее значение для стабильности и производительности приложений Java. Подробности сборки мусора и эффективного использования памяти выходят за рамки книги, но вы узнаете, как получать размеры различных пулов памяти. Лучше всего наблюдать за использованием памяти приложения с помощью профилировщика, например JProble или OptimizeIt. Однако для них приложение требуется запустить в режиме отладки, что неприемлемо в промышленных системах. Инструменты нового поколения, например Wily Introscope и Borland Server Trace, способны с минимальными накладными расходами наблюдать за памятью любого работающего приложения и отображать её использование. Но они опираются на тот же метод, который применим и мы, и могут оказаться слишком дорогими для многих приложений Java. В листинге 8.3 показана реализация метода, выводящего текущий профиль памяти JVM.

Листинг 8.3. Исходный код printMemoryInfo

Вспомогательная функция toMb преобразует переданное значение из байтов в мегабайты с точностью до двух знаков. Она находится в классе RuntimeInfo.

Приложение Java способно узнать о сетевой среде не так уж много. Java - кроссплатформенный язык высокого уровня, поэтому плохо подходит для реализации низкоуровневых служебных программ ОС и драйверов. Практически единственные полезные сведения, доступные из среды выполнения, - имя и IP-адрес локального узла. Их можно использовать при лицензировании, когда лицензии выдаются на отдельный сервер и привязываются к узлу. Дополнительные сведения о базовой конфигурации сети и оборудования можно получить через JNI и библиотеки C, выполняющие нативные вызовы ОС. В листинге 8.4 показано получение сведений об узле.

Листинг 8.4. Исходный код printNetworkInfo

Переменные среды - удобный способ параметризации приложения. Например, каталог установки приложения может различаться на разных узлах, а надёжного способа определить место установки в Java нет. Поэтому часто определяют переменную среды APP_HOME и передают её приложению Java.

Не следует использовать слишком много переменных среды, поскольку это усложняет программирование пакетных файлов и сценариев оболочки. Лучше хранить настройки в конфигурационных файлах формата свойств Java или XML, а переменной среды задавать расположение этих файлов. Правильный способ получить переменные среды в Java - передать их в командной строке ключом -D. Для ясности я предпочитаю добавлять ко всем их именам префикс env. Следующий пример показывает, как передать значения переменных среды Windows TEMP и COMPUTERNAME создаваемой в этой главе служебной программе исследования:

Затем приложение Java может получить значение переменной методом System.getProperty(), используя имя, заданное в командной строке. В нашем примере значение TEMP можно получить вызовом System.getProperty("env.temp").

1. В каких случаях следует исследовать среду выполнения?

2. Какие сведения о среде выполнения доступны через стандартный API Java?

3. Как получить недоступные через стандартные API сведения, зависящие от ОС или оборудования?

• Получение снимка значений среды - надёжный способ понять конфигурацию работающего приложения.

• Системные свойства, доступные через метод System.getProperty(), предоставляют большую часть сведений о среде выполнения.

• Снимок объёмов памяти помогает оценить эффективность управления памятью приложения в промышленной среде.

• Сетевые сведения ограничиваются именем и IP-адресом локального узла.

• Значения переменных среды можно передавать приложению Java параметром командной строки -D.

• Понимание внутреннего устройства неизвестных приложений

• Обычные отладчики и их ограничения

• Взлом с помощью всеведущего отладчика

• Короткий тест

• Краткие итоги

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

• вы работаете с большим приложением, в котором нет хорошей трассировки;

• чтение исходного кода не даёт ясного понимания внутренней логики из-за сложной иерархии объектов и неуклюжих приёмов программирования;

• вы работаете с приложением, подвергнутым агрессивной обфускации.

Java с самого начала проектировалась с учётом отладки. Стандартный Java Debug API опирается на представление об удалённом наблюдателе за отлаживаемым процессом. Этот стандарт позволяет поставщикам создавать собственные отладчики с самым разным набором функций. Некоторые почти не выходят за рамки установки точек останова и пошагового выполнения кода приложения. Более развитые отладчики предоставляют дополнительные возможности, например условные точки останова, приостанавливающие выполнение при определённом значении переменной или создании определённого исключения.

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

Предположим, вы получили приложение Chat и хотите узнать, как оно обрабатывает входящие сообщения. Его можно загрузить и запустить в режиме отладки, но откуда знать, где поставить точку останова? Даже в небольшом приложении вроде Chat пошаговое выполнение не поможет, потому что сообщения доставляются асинхронно в потоке RMI. Только декомпиляция и внимательное изучение кода способны привести к методу receiveMessage, который определён в ChatServerRemote и реализован в ChatServer. Если попытаться выполнить обратную разработку версии Chat, обфусцированной с помощью Zelix KlassMaster, задача станет, мягко говоря, трудной. Нужен более подходящий инструмент. На сцену выходит Omniscient Debugger.

1. Зачем использовать отладчик при взломе?

2. Каковы ограничения обычных отладчиков?

3. Какой принцип лежит в основе реализации ODB?

4. Какие подходы позволяют находить логику реализации в ODB?

• Отладчик может сократить путь к логике реализации в большом приложении или обфусцированном коде.

• Главные ограничения обычных отладчиков - необходимость устанавливать точки останова в ключевых местах и отсутствие истории изменений состояния и вызовов методов.

• ODB записывает временные метки выполняющегося приложения и позволяет перемещаться по ним, чтобы понять внутреннюю логику.

• ODB - лучший подход к взлому обфусцированных приложений.

• Почему и когда следует применять профилирование

• Лучшие профилировщики Java

• Исследование использования кучи и частоты сборки мусора для повышения производительности

• Просмотр размещения объектов и ссылок для поиска и устранения утечек памяти

• Исследование распределения и синхронизации потоков

• Поиск дорогостоящих методов для повышения производительности

• Исследование приложения во время выполнения с помощью дампа потоков

• Короткий тест

• Краткие итоги

Термином «профилирование» традиционно называют измерение времени выполнения методов для поиска и устранения узких мест производительности. Однако в мире Java это понятие расширилось и теперь охватывает сбор различных показателей, а также отладку потоков и объектов во время выполнения. Вот несколько причин использовать профилировщик для приложения Java:

• исследовать использование кучи и частоту сборки мусора с целью повысить производительность;

• просматривать размещение объектов и ссылки для поиска и устранения утечек памяти;

• исследовать распределение и синхронизацию потоков, чтобы находить проблемы блокировок и гонок данных и повышать производительность;

• выявлять дорогостоящие методы для повышения производительности;

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

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

Для эффективной работы нужны правильные инструменты. Три самых известных профилировщика Java - JProbe Suite компании Quest Software, первоначально разработанный KLGroup, OptimizeIt Suite компании Borland и JProfiler компании ej-technologies. Все три хороши и почти одинаково успешно справляются с задачей. Мне нравится, что JProfiler объединяет все функции в одном приложении, а не разделяет профилирование, отладку памяти и потоков между отдельными инструментами. JProbe, вероятно, был первым инструментом такого рода и по-прежнему остаётся лучшим. Помимо функций других средств, он предоставляет удобное окно графа кучи, где объекты показаны прямоугольными узлами, а по графу объектов можно перемещаться разными способами. Другие инструменты показывают граф только как дерево, что упрощает отображение, но снижает наглядность. Эта и другие дополнительные функции JProbe делают его моим предпочтительным инструментом для отладки памяти. В остальной части главы мы будем в основном пользоваться им, но вы вправе выбрать инструмент по вкусу или имеющейся лицензии.

Сборка мусора - замечательная возможность Java, избавляющая разработчиков от необходимости явно освобождать выделенные объекты. Цена этой простоты - накладные расходы во время работы сборщика. Последние версии JVM применяют сборку мусора по поколениям, способную выполняться асинхронно, однако даже после этих усовершенствований накладные расходы остаются значительными. Влияние сборки мусора на производительность приложения легко недооценить.

JProbe, как и другие профилировщики, показывает сводный график кучи работающего приложения. Он позволяет наблюдать за общим объёмом выделенной и доступной свободной памяти, как показано на рисунке 10.1.

Рисунок 10.1. Сводный график кучи во время выполнения при неоптимизированном размере кучи

Когда свободной памяти недостаточно для удовлетворения запроса, JVM запускает сборку мусора первого поколения, освобождая память неиспользуемых объектов. Первое поколение рассматривает только недавно выделенные объекты, избегая длительного перебора всего графа объектов. Если освобождённой памяти недостаточно, запускается полная сборка мусора. Она начинается с корней дерева объектов, которыми обычно являются объекты, доступные из активных потоков и статических переменных, и определяет все объекты, достижимые из корня. Объекты, недостижимые из корня, то есть не входящие в граф ссылок, начинающийся корневым объектом, помечаются для сборки. Если полная сборка не освобождает достаточно памяти, JVM проверяет, разрешено ли выделить дополнительную память операционной системы. Если достигнут предельный объём или ОС не может предоставить память, создаётся исключение OutOfMemory.

Как видите, создание множества новых объектов способно привести к сложным и длительным операциям. Вместо выполнения бизнес-логики JVM может расходовать процессорное время на управление памятью. На рисунке 10.1 показано использование памяти приложением с неоптимизированным максимальным размером кучи. Каждое падение объёма используемой кучи является результатом сборки мусора. Видно, что JVM вынуждена часто запускать сборщик из-за малого объёма свободной памяти. Максимальный размер кучи задаётся параметром -Xmx в командной строке java. При увеличении максимума с 5 до 16 Мбайт сводный график принимает вид, показанный на рисунке 10.2.

Рисунок 10.2. Сводный график кучи во время выполнения при оптимизированном размере кучи

Производительность приложения значительно выросла, поскольку сборка мусора выполнялась всего 3 раза вместо почти 30. Фиксированного правила определения оптимального размера кучи нет. Иногда несколько циклов сборки выполняются почти так же быстро, как один цикл, которому приходится перебирать больше объектов. Единственный надёжный способ найти лучшую настройку конкретного приложения - экспериментировать с начальными и максимальными размерами кучи.

Утечки памяти в приложениях Java давно перестали быть неожиданностью. Это не те же утечки, которыми изобилуют языки более низкого уровня, например C++, но память всё равно не возвращается в свободный пул. Как вы уже узнали, сборщик Java освобождает память, занятую недостижимыми объектами. Если на объект существует ссылка, он не подлежит сборке, даже если больше никогда не используется. Например, объект, помещённый в массив и никогда из него не удаляемый, навсегда остаётся в памяти. Такие объекты, иногда называемые задержавшимися, со временем могут поглотить всю свободную память и вызвать исключение OutOfMemory. Проблема усиливается, когда объект ссылается на большое дерево других объектов, что часто встречается в приложениях.

Ещё одна опасность - задержавшиеся объекты, представляющие ресурсы, например соединения с базой данных или временные файлы. Чем дольше объект остаётся в памяти, тем дороже сборка мусора, поскольку ей приходится обходить больше объектов. Профилировщики предоставляют лучшие средства поиска задержавшихся объектов и определения причин, мешающих их сборке.

Рассмотрим простой пример, создающий задержавшиеся объекты, и найдём их с помощью JProbe. Предположим, мы разрабатываем графический редактор и нуждаемся в фабрике, предоставляющей слой абстракции для создания объектов Point. Фрагмент реализации фабрики показан в листинге 10.1.

Листинг 10.1. Реализация PointFactory

Метод createPoint создаёт экземпляры Point и помещает их в массив. removePoint удаляет точку из массива, а вместе с PointFactory поставляется тестовый метод, создающий через фабрику несколько точек. Его код приведён в листинге 10.2.

Листинг 10.2. Метод проверки создания точек

Метод main класса PointFactory показывает диалоговое окно с кнопкой Print Test Points. Нажатие кнопки вызывает printTestPoints() класса PointFactory. Реализация кажется совершенно корректным кодом Java, но её выполнение приводит к утечкам памяти. Если увеличить размер выделяемого объекта и число повторений цикла, всю доступную память можно быстро исчерпать. Вы, несомненно, уже поняли причину утечки. В нашем примере она очевидна, поскольку есть один класс менее чем с 50 строками кода, но при сотнях классов со сложной логикой проблема была бы далеко не столь заметна. Здесь профилировщики становятся незаменимыми.

Чтобы исследовать управление памятью демонстрационного кода, настроим covertjava.profile.PointFactory как самостоятельное приложение в JProbe Memory Debugger. После запуска начальное представление показывает сводку кучи и список классов. Поскольку приложение небольшое, в списке видно лишь несколько классов, но в крупной программе можно применить фильтр по имени класса или пакета. Когда появится диалоговое окно приложения, по списку классов и числу экземпляров видно, что объекты java.awt.Point ещё не созданы. Нажмём Print Test Points и вернёмся к представлению классов. Теперь видно пять созданных экземпляров Point и пять экземпляров StringBuffer. Это очевидный результат вызова printTestPoints, поэтому удивляться нечему. JProbe позволяет принудительно запустить сборку мусора; сделаем это. После её завершения экземпляры StringBuffer исчезнут, но точки останутся в памяти. Повторение теста начиная с кнопки Print Test Points увеличит число экземпляров Point до 10. Утечка подтверждена, и теперь выясним, почему точки задерживаются в памяти.

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

Просмотр исходного кода и поиск всех мест создания экземпляра помогает выяснить, какие ссылки не выходят из области видимости и не обнуляются. Обычно профилировщик показывает точку выделения экземпляра, что облегчает работу. Это прямолинейный подход, способный занять много времени. Более развитый, а иногда единственно осуществимый способ - сделать снимок кучи во время выполнения и просматривать в нём нужный объект. Вместо ручного отслеживания возможных ссылок в исходном коде снимок позволяет перемещаться по фактическим ссылкам времени выполнения, удерживающим объект в памяти. Большинство профилировщиков показывает ссылающиеся объекты и объекты, на которые ссылается рассматриваемый объект. Очень мощная возможность - отображение всех путей от объекта до корня. Графы объектов на снимке могут быть сложны для навигации. Если интересует один объект, весь граф не нужен; достаточно увидеть, какие объекты мешают его сборке. Напомним, сборщик освобождает объект только тогда, когда он недостижим из корней. Следовательно, если выявить и устранить все пути от объекта к корню, он станет пригоден для сборки.

Перед созданием снимка кучи всегда полезно запросить сборку мусора. Она удалит объекты, на которые больше нет ссылок, и упростит поиск утечек. В JProbe для этого выберите Request Garbage Collection в меню Program. Затем создайте снимок, выбрав Take Heap Snapshot в том же меню. Когда JProbe захватит снимок, выберите Class View в меню Snapshot. Теперь можно изучать состояние кучи и графы объектов. Нас интересуют java.awt.Point, поэтому щёлкнем этот класс правой кнопкой в Class View и выберем Instance Detail View. Новый экран показывает все находящиеся в памяти экземпляры Point и позволяет просматривать деревья входящих и исходящих ссылок. Дерево ссылающихся объектов состоит из иерархии предков, для которых экземпляр прямо или косвенно является дочерним: непосредственных родителей, родителей родителей и так далее. Перемещение по дереву даёт хорошее представление об удерживаемых ссылках. Для нашего экземпляра Point видно, что на него ссылается ArrayList, на который, в свою очередь, ссылается PointFactory.

У JProbe есть другое представление, которым я предпочитаю пользоваться. Оно называется Reference Graph и нагляднее показывает граф объектов. Чтобы открыть его для Point, щёлкните экземпляр правой кнопкой и выберите Instance Referrers and References. Появится окно, где все объекты представлены именованными прямоугольниками, а выбранный объект находится в центре. Поскольку мы выясняем, почему точки задерживаются в памяти, нажмите значок Paths to Root на панели графа. Результат показан на рисунке 10.3.

Рисунок 10.3. Граф путей от точки к корню

Мы снова видим, что на объект Point ссылается ArrayList класса PointFactory. Можно заключить, что точки остаются в памяти потому, что никогда не удаляются из массива. В реализации printTestPoint() видно, что метод вызывает createPoint, который сохраняет созданный Point в массиве points. Для исправления нужно добавить в printTestPoint вызов removePoint, как показано в листинге 10.3.

Листинг 10.3. Исправленная реализация проверки создания точек

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

Гонка данных возникает, когда два потока одновременно пытаются обратиться к общему ресурсу и изменить его. Типичный пример потенциальной гонки - изменение остатка банковского счёта без синхронизации. Допустим, класс BankAccount предоставляет методы getBalance() и setBalance() для чтения и записи текущего остатка, а также deposit() для внесения или снятия средств. Реализация deposit() сначала получает текущий остаток, затем прибавляет сумму и устанавливает новое значение. Если два потока, thread1 и thread2, одновременно вносят средства, thread1 может прочитать остаток и прибавить сумму, но прежде чем записать результат, быть прерванным потоком thread2. Тот прочитает старый остаток и увеличит его, а затем уступит thread1. thread1 запишет рассчитанное значение, но после этого thread2 продолжит выполнение и перезапишет его собственным.

В таком случае сумма, внесённая thread1, будет потеряна. Клиентам, возможно, понравилась бы подобная аномалия при снятии средств, но с внесением они её не потерпят. Профилировщики, например JProbe Threadalizer, способны обнаруживать различные виды гонок и сообщать о них. Обычное решение - добавить синхронизацию, защищающую доступ к данным. Чтобы исправить внесение средств, соответствующий метод следует объявить ключевым словом synchronized. Синхронизация гарантирует, что блокировку получит только один поток, а любой другой, пытающийся получить ту же блокировку, будет остановлен до её освобождения владельцем. Вместо синхронизированных методов можно объявить объект блокировки и передавать его синхронизированному блоку, как в листинге 10.4.

Листинг 10.4. Защита доступа к данным синхронизированным блоком

Синхронизация создаёт накладные расходы, поэтому применять её следует только при необходимости. Кроме того, не каждая обнаруженная профилировщиком гонка является проблемой, которую нужно устранять. Например, одновременное чтение остатка несколькими потоками безвредно, поэтому getBalance() не обязательно синхронизировать. В многоуровневом приложении синхронизацию можно переложить на другие уровни. Например, уровень изоляции транзакций базы данных способен предотвратить параллельное чтение и запись одних данных.

Взаимная блокировка возникает, когда поток ожидает блокировку, захваченную другим потоком, но никогда им не освобождаемую. Это распространённая проблема многопоточных приложений, способная полностью остановить программу. Например, если thread1 получает lock1, а затем ждёт lock2, удерживаемую thread2, взаимная блокировка возникнет, если thread2 попытается получить lock1, не освободив сначала lock2. Рассмотрим демонстрационный класс с двумя блокировками и двумя методами, которые синхронизируют работу с их помощью. В листинге 10.5 фактическая работа неважна: нас интересует логика синхронизации.

Листинг 10.5. Код с возможностью взаимной блокировки

Оба метода используют lock1 и lock2, но получают их в разном порядке. При выполнении в отдельных потоках method1 может войти в первый синхронизированный блок и захватить lock1. Если его прервёт method2, тот войдёт в свой внешний блок и захватит lock2. После продолжения выполнения возникает взаимная блокировка, поскольку оба потока бесконечно ждут занятые блокировки. Класс ThreadTest пакета covertjava.profile демонстрирует этот сценарий. Его запуск создаёт взаимную блокировку, мешающую корректно завершить JVM, потому что два потока, порождённые main(), никогда не возвращаются.

В примере проблему легко заметить при внимательном изучении ThreadTest, но в реальном приложении с сотнями классов это было бы значительно труднее. Хорошие профилировщики обнаруживают взаимные блокировки и сообщают, что к ним привело. JProbe Threadalizer от Quest и OptimizeIt Thread Debugger от Borland умеют их находить, но OptimizeIt также предоставляет наглядную временную шкалу выполнения потоков, поэтому воспользуемся им. Запустите OptimizeIt и настройте ThreadTest как приложение с главным классом covertjava.profile.ThreadTest. В диалоговом окне параметров обязательно установите Auto-start Analyzer, чтобы автоматически начать анализ работающей программы. Запустите ThreadTest из меню или кнопкой панели; через несколько секунд OptimizeIt должен показать потоки, как на рисунке 10.4.

Рисунок 10.4. Представление потоков работающего ThreadTest в OptimizeIt

Представление показывает все потоки и временную шкалу их состояний. Зелёный цвет означает выполнение, жёлтый - блокировку в ожидании занятого другим потоком монитора, красный - ожидание уведомления, фиолетовый - блокировку в нативном коде. ThreadTest порождает два потока со стандартными именами Thread-1 и Thread-2. На временной шкале видно, что после короткого выполнения они блокируются навсегда. Остальные потоки запускаются JVM для системных задач, поэтому сосредоточимся на потоках приложения. OptimizeIt показывает как удерживаемые каждым потоком блокировки, так и блокировки, которых он ждёт. Поскольку мы включили анализатор, воспользуемся его подсказкой. Через меню File перейдём к Analyzer, затем нажмём Stop Recording. Инструмент должен обнаружить одну взаимную блокировку с описанием Locking order mismatch. Выбор записи покажет подробные сведения о потоках и удерживаемых блокировках. В нашем случае текст гласит: Thread Thread-2 enters monitor java.lang.Object 0xabf9280 first and then java.lang.Object 0xabf72f0 while thread Thread-1 enters the same monitors in the opposite order. OptimizeIt даже показывает строки кода, где были захвачены блокировки, поэтому исправить проблему легко.

Чтобы избежать взаимной блокировки, блокировки следует получать в одном порядке. В нашем случае method2 должен сначала получить lock1, а затем lock2. И последнее: хотя анализатор обнаруживает многие распространённые ошибки, ведущие к взаимной блокировке, он не способен выявить любую возможную ситуацию. Хорошее проектирование и надёжные приёмы программирования значительно помогают предотвратить будущие проблемы.

Зависанием потока называют ситуацию, когда поток ждёт уведомления, которое никогда не приходит. Это происходит, если поток вызывает для объекта wait(), но никакой другой поток не вызывает для того же объекта notify(). Зависание - ещё одна проблема многопоточности, обнаруживаемая профилировщиком.

Оптимизация производительности - сложная тема, далеко выходящая за рамки главы. Производительность Java прошла долгий путь, и современные JIT-компиляторы обеспечивают превосходную скорость и оптимизацию кода. Самый важный фактор конечной скорости - качество проектирования и реализации приложения. Известные ловушки и типичные обходные решения способны повысить производительность на сотни процентов. Нередко переписывание нескольких ключевых методов ускоряет отклик приложения в 10 раз. Оптимизация начинается с поиска узких мест. Естественно, производительность следует учитывать уже при проектировании, хотя жертвовать чистотой архитектуры ради ожидаемого небольшого выигрыша не рекомендуется. По мере разработки и модульного тестирования код следует профилировать, выясняя, какие методы расходуют больше всего времени. Основная часть профилирования обычно выполняется при интеграционном тестировании.

Профилирование собирает различные статистические показатели выполнения, позволяющие понять, на что фактически уходит время. Ниже перечислены самые полезные показатели JProbe:

• Время метода. Время выполнения данного метода без учёта времени вызванных им методов.

• Число вызовов метода. Количество вызовов; позволяет выявить методы, оптимизация которых сильнее всего повлияет на общую производительность.

• Среднее время метода. Среднее время выполнения, равное времени метода, делённому на число вызовов; позволяет находить самые медленные методы.

• Накопленное время. Общее время выполнения метода с учётом вызванных им методов; позволяет определить методы, потребляющие основную часть процессорного времени.

• Среднее число объектов на метод. Среднее количество объектов, созданных внутри метода. Поскольку сборка мусора сильно влияет на производительность Java, сокращение числа создаваемых объектов может ускорить выполнение.

После сбора и анализа статистики можно оптимизировать плохо работающие части приложения.

Поскольку профилировщик требует запуска JVM в режиме отладки, он непригоден для промышленных приложений. Было бы полезно получать снимок потоков и их работы для любого приложения, даже запущенного в обычном режиме. К счастью, JVM можно приказать создать полный дамп потоков с их состояниями и стеками вызовов. В Unix выполните kill -3 <pid>, где <pid> - идентификатор процесса JVM; в Solaris также работает kill -QUIT <pid>. В Windows нажмите Ctrl+Break в окне консоли. Дамп Chat приведён в листинге 10.6.

Листинг 10.6. Частичный дамп потоков Chat (начало)

Листинг 10.6. Частичный дамп потоков Chat (окончание)

Листинг 10.6 показывает некоторые потоки, работающие внутри JVM Chat. Например, видно, что поток соединения RMI спит в методе run класса sun.rmi.transport.tcp.TCPChannel$Reaper. Поток AWT-EventQueue ждёт следующего события, а поток финализатора ожидает монитор методом wait().

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

1. Зачем профилировать приложение?

2. Почему сборка мусора столь сильно влияет на производительность?

3. Что может вызывать утечки памяти в приложении Java?

4. Как найти и устранить утечки памяти?

5. Какие проблемы распространены в многопоточных приложениях?

6. Какой процесс следует использовать для повышения производительности приложения?

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

• Исследование использования кучи и частоты сборки мусора подсказывает способы повышения производительности.

• Просмотр размещения объектов и ссылок во время выполнения помогает находить и устранять утечки памяти.

• Исследование распределения и синхронизации потоков помогает находить проблемы блокировок и гонок данных и повышает производительность.

• Выявление дорогостоящих методов при профилировании повышает производительность приложения.

• Исследование приложения в профилировщике позволяет понять его внутреннюю структуру.

• Дамп потоков, создаваемый JVM в ответ на SIGQUIT, предоставляет полезные сведения о потоках и мониторах приложения, не работающего в режиме отладки.

• Важность нагрузочного тестирования

• Нагрузочное тестирование серверов RMI с помощью JUnit

• Нагрузочное тестирование с помощью JMeter

• Короткий тест

• Краткие итоги

К серверным приложениям предъявляются требования к уровню обслуживания, определяющие доступность, масштабируемость и аварийное переключение:

• Доступность задаёт требования ко времени непрерывной работы, то есть продолжительность работы приложения без перезапуска.

• Масштабируемость определяет способность приложения обеспечивать тот же уровень обслуживания при увеличении числа запросов.

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

Обычный цикл разработки предусматривает время для модульного и интеграционного тестирования, обычно сосредоточенного на функциях, но не всегда оставляет время на испытание нагрузкой. Цель нагрузочного тестирования - оценить, насколько производительность системы под нагрузкой отвечает требованиям к уровню обслуживания. Разумеется, время отклика любой системы ухудшается с ростом нагрузки, но пока оно укладывается в заданные требования, система считается масштабируемой.

Игнорировать нагрузочное тестирование рискованно, особенно если приложение должно обслуживать сотни или тысячи пользователей. При большой аудитории маленькая проблема превращается в крупную, поскольку затрагивает множество людей. Некоторые сбои возникают лишь при определённой нагрузке. Это возможно в операциях, зависящих от таких ресурсов, как потоки, соединения с базой данных и память. Большинство проблем многопоточных приложений проявляется при определённом числе параллельных запросов. Только испытание нагрузкой и длительная работа системы воспроизводят промышленную среду, поэтому до ввода системы в эксплуатацию такое тестирование совершенно необходимо. Наконец, оно показывает, как приложение отреагирует на атаки отказа в обслуживании и попытки взлома. Нагрузочное тестирование выявляет не способ построения приложения, а его долговечность. Оно помогает извлечь больше пользы из методов других глав. Например, профиль приложения под нагрузкой отличается от профиля без нагрузки.

Имитировать нагрузку на систему непросто, поэтому важно выбрать правильные инструменты. На рынке есть множество продуктов, большинство из которых предназначено для веб-сайтов, обслуживающих содержимое HTML по HTTP. Помимо HTTP серверные приложения Java работают с другими протоколами, например JRMP для клиентов RMI и IIOP для клиентов CORBA и RMI. Лучшие инструменты стоят дорого, однако альтернативы с открытым исходным кодом предоставляют большинство базовых функций. Мы испытаем работающее по RMI приложение Chat с помощью открытого каркаса JUnit. Затем применим другой открытый инструмент, JMeter, к веб-приложению WebCream с браузерными клиентами.

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

JUnit - открытый проект Java, предоставляющий каркас написания и выполнения модульных тестов. Он поощряет создание тестового кода, утверждающего корректность функций приложения. Тест JUnit - класс Java, который компилируется и выполняется для проверки кода приложения. Такой подход сочетает автоматическое повторное тестирование с простотой синхронного сопровождения тестового и прикладного кода. И наконец, разработчики пишут Java, а не нажимают кнопки в отладчиках и тестовых инструментах, что, вероятно, немало способствует популярности каркаса.

Для работы с JUnit разработчик пишет тест, расширяющий junit.framework.TestCase или реализующий junit.framework.Test. Тест вызывает проверяемые классы и утверждает соответствие возвращаемых значений ожидаемым. Например, тест банковского счёта получает текущий остаток, вносит сумму и проверяет, что новый остаток равен прежнему плюс внесённая сумма. Качество теста прямо пропорционально усердию разработчика. Следует охватить все возможные сценарии, включая ошибочные. После написания тесты компилируются и выполняются отдельно или группами. JUnit хорошо документирован и прост в изучении; если вы с ним не работали, потратьте пару часов на руководство и примеры. Не забудьте обновить резюме: хорошие руководители увидят в этом признак качественного разработчика. Каркас и документация бесплатно доступны на junit.org. Остальная часть раздела посвящена нагрузочному тесту Chat на основе JUnit.

Chat не создавался неразрушимым, но и не предназначался для сотен пользователей. Если он выдерживает от трёх до шести одновременных пользователей, этого, вероятно, достаточно для демонстрационного приложения. В любом нагрузочном тесте верхнюю планку следует ставить немного выше ожидаемого максимума. Поэтому в примере мы потребуем поддержки 10 виртуальных клиентов, одновременно отправляющих сообщения одному приложению Chat. Вызовы также нужно разнести во времени, имитируя реальное поведение. Это означает отправку запросов примерно в одно время, а не точно одновременно. Иногда «одновременными» называют клиентов, отправляющих запрос строго в один момент, а «параллельными» - поддерживающих разговор с сервером, но посылающих запросы примерно в одно время. В однопроцессорной системе истинной параллельной обработки нет, поэтому различия между этими понятиями фактически не существует.

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

Тест написан в классе covertjava.loadtest.ChatTestCase. Он расширяет TestCase, а основная логика находится в методе testSendMessage(), приведённом в листинге 11.1.

Листинг 11.1. Исходный код testSendMessage

ChatTestCase создаёт тестовое сообщение и отправляет его целевому узлу через ChatServer. Ключевой момент - вызов assertTrue() в блоке catch со вторым параметром false, сообщающий JUnit о неудаче. В противном случае метод просто возвращает управление, что означает успех. Такая проверка, разумеется, далека от идеального подтверждения правильной обработки сообщения сервером Chat. Она не проверяет разбор сообщения и правильное добавление в окно истории. Однако для испытания сетевого обмена и пропускной способности удалённого сервера это вполне достойный приём, достаточный для иллюстрации.

Следующий шаг - создание набора с экземплярами ChatTestCase. Это выполняется в классе ChatLoadTest; код показан в листинге 11.2.

Листинг 11.2. Создание набора тестов (начало)

Листинг 11.2. Создание набора тестов (окончание)

Такие параметры, как clientsNumber и lagTime, читаются из файла свойств. Наборы JUnit служат контейнерами тестов и упрощают их совместный запуск. ActiveTestSuite одновременно запускает все тесты и ждёт их завершения. JUnit применяет шаблон декоратора, чтобы добавлять тестам функции. Например, RepeatedTest многократно выполняет заданный поток. Для разнесения выполнения мы добавили декоратор DelayedTest, который перед запуском засыпает на заданное время. Итог листинга 11.2 - clientsNumber клиентов, которые после случайной задержки одновременно отправят сообщения.

Тест JUnit можно запускать разными способами, но мы воспользуемся Swing GUI, чтобы видеть ход испытания. Если Chat на localhost ещё не работает, запустим его файлом CovertJava\distrib\bin\chat.bat. Затем откроем GUI JUnit и выполним набор с помощью loadtestJUnit.bat из каталога CovertJava\bin. Вскоре после начала GUI должен выглядеть примерно так, как на рисунке 11.1.

Рисунок 11.1. GUI JUnit, показывающий ход тестирования

Большинство тестов завершилось неудачей, а на панели результатов видно сообщение testSendMessage(covertjava.loadtest.ChatTestCase): Exception java.lang.NullPointerException: null. В приложении Chat область истории превратилась в беспорядок, а в консоли появилось несколько NullPointerException. Вот и первые плоды нагрузочного тестирования. Если уменьшить число клиентов до двух, тесты проходят успешно, следовательно, проблема связана с многопоточностью. В главах 9 «Взлом кода с помощью нестандартных отладчиков» и 10 «Использование профилировщиков для анализа приложения во время выполнения» представлены способы поиска и устранения ошибок параллельного выполнения. Попробуйте применить их к Chat.

Для достаточно опытных читателей раскрою причину: новые сообщения неправильно добавляются в историю. Swing не является потокобезопасным, и взаимодействовать с его компонентами обычно рекомендуется из потока диспетчеризации событий AWT. Проектировщики Swing пожертвовали надёжностью ради скорости, и их трудно винить, поскольку производительность Swing давно подвергалась критике. Chat получает входящие сообщения в потоке RMI и передаёт обработку классу MainFrame. Метод appendMessage класса MainFrame, добавляющий сообщение в JEditorPane, не использует синхронизацию. Поэтому при одновременной отправке несколькими пользователями несколько потоков пытаются записать данные в один JEditorPane. Это классическая проблема перезаписи данных, устраняемая объявлением appendMessage синхронизированным. После изменения повторный нагрузочный тест проходит чисто, и работу можно с радостью считать выполненной.

Преимущество JUnit для нагрузочного тестирования - простота и возможность использовать уже написанные тесты. Кроме того, он эффективен для серверов RMI, поскольку автоматическая запись сценариев инструментами нагрузочного тестирования не всегда даёт сопровождаемый результат.

1. Какова цель нагрузочного тестирования?

2. Чем отличаются одновременные и параллельные пользователи?

3. Какие клиентские протоколы можно тестировать с помощью JUnit?

4. Как тесты JUnit утверждают корректность ответа?

5. Какие клиентские протоколы можно тестировать с помощью JMeter?

6. Какие узлы конфигурации и семплеров используются в планах JMeter?

7. Как наблюдать за ходом и результатами выполняющегося плана JMeter?

8. Каковы преимущества и недостатки JUnit и JMeter?

• Цель нагрузочного тестирования - оценить соответствие производительности системы требованиям к уровню обслуживания под нагрузкой.

• Коммерческие и открытые продукты могут автоматически записывать виртуальных пользователей, программно создавать сценарии, поддерживать несколько языков и протоколов и создавать графики и отчёты.

• JUnit - открытый каркас, пригодный для простых нагрузочных испытаний серверов RMI или обычных серверов Java. Тест JUnit представляет собой компилируемый и выполняемый класс Java.

• JMeter - открытый инструмент нагрузочного тестирования и измерения производительности веб-сайтов и приложений Java. Он поддерживает HTTP и FTP, а также базы данных, сценарии Perl и объекты Java.

• JMeter поддерживает динамическое содержимое посредством экстракторов регулярных выражений и переменных.

• Слушатели JMeter создают отчёты о производительности и графики.

• Элементы пользовательского интерфейса и ресурсы

• Взлом текста

• Взлом изображений

• Взлом файлов конфигурации

• Короткий тест

• Краткие итоги

В главе 5, «Замена и исправление классов приложения», мы говорили об исправлении классов для изменения логики приложения. В этой главе мы обсудим изменение таких элементов пользовательского интерфейса, как сообщения, предупреждения, приглашения, изображения, значки, меню и цвета. Здесь применяются те же принципы, которые описаны в главе 5. Первая задача - найти ресурс, который нужно изменить. Затем можно внести изменение и обновить приложение, чтобы новый ресурс использовался вместо старого. В таблице 12.1 показано соответствие между элементами пользовательского интерфейса и ресурсами, которые необходимо исправлять.

Таблица 12.1. Соответствия между элементами пользовательского интерфейса и ресурсами

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

В Chat текст Send message используется и как текст пункта меню, и как подсказка ToolTip для кнопки панели инструментов. Хотя он превосходно передаёт смысл действия, молодое поколение пользователей может счесть его немодным. Чтобы угодить этой аудитории, взломаем Chat так, чтобы вместо Send message использовался текст Unleash the fury. Мы будем работать с распространяемой версией приложения, делая вид, будто исходный код нам недоступен.

Поскольку Chat поставляется в файле JAR, прежде всего нужно распаковать CovertJava/distrib/lib/chat.jar командой jar во временный рабочий каталог. Затем необходимо найти классы, задающие текстовые строки, которые сейчас отображает Chat. С помощью FAR или средства поиска выполняем двоичный поиск текста Send message во всех файлах рабочего каталога и его подкаталогов. Результатом поиска должен стать файл MainFrame.class, который мы декомпилируем, как описано в главе 2, «Декомпиляция классов». Поиск текста Send message в декомпилированном исходном коде приводит к методу jbInit, фрагмент которого показан в листинге 12.1.

Листинг 12.1. Фрагмент jbInit, показывающий текстовые строки

Применяя приём исправления, представленный в главе 5, можно просто заменить Send message на Unleash the fury в декомпилированном исходном коде и добавить его в Chat как исправление. Это было достаточно просто, и, к счастью, в большинстве реальных приложений всё должно быть столь же просто. Сложности могут возникнуть, если код приложения обфусцирован с кодированием строк, но знания, полученные в предыдущих главах, не позволят этому помешать нам найти класс для исправления.

Хорошие приложения не задают текстовые строки в коде жёстко. Вместо этого сообщения хранятся в пакетах ресурсов или файлах конфигурации, что упрощает сопровождение и локализацию. Если строки не закодированы, двоичный поиск по содержимому рабочего каталога всё равно даст нужные результаты. Найдя файл, содержащий строку, его можно обновить новым текстом. После этого приложение необходимо упаковать заново, чтобы изменение вступило в силу.

Работать с изображениями немного сложнее, чем с текстом. В отличие от текста, изображение нельзя просто найти, поскольку неизвестно, что использовать в качестве критерия поиска. Поэтому первый шаг - выяснить имя изображения и определить, как приложение его загружает, после чего можно применить исправление. Прямого и простого способа найти имя изображения нет. Вероятнее всего, приложение загружает его в коде, относящемся к пользовательскому интерфейсу, но разработчики нередко используют каркас или класс-диспетчер, который выполняет подготовительную работу, необходимую для загрузки изображения в Java. Опыт подсказывает изучить развёрнутое приложение (то есть не хранящееся в JAR) или, возможно, найти все файлы .jpg и .gif. Чаще всего имя изображения лучше всего подсказывает, где оно используется. Например, заставка может называться примерно splash.gif, а значок кнопки «Создать» на панели инструментов - new.gif. В обычном приложении Java изображений не так много, поэтому нужное должно найтись без труда. Очевидно, что просмотр изображения подтвердит, того ли кандидата вы нашли. (Мне ведь не обязательно было это говорить, правда?)

А что, если изображений слишком много, а программист, написавший приложение, использовал такие имена файлов, как img0045.gif? По размеру всё ещё можно догадаться, какое изображение вам нужно, либо просто последовательно просмотреть их все. Помните, что приложение может хранить изображения в другом файле JAR, поэтому при поиске нужно открыть их все.

Теперь рассмотрим худший случай: вы видите, что приложение отображает изображение, и отчаянно хотите его изменить, но, просмотрев все упакованные с приложением графические файлы, так его и не находите. Определить, откуда оно берётся, можно несколькими способами. Поскольку простой путь не сработал, придётся копнуть глубже и добраться до места в коде, где загружается изображение. Приёмы обратной разработки уже рассматривались в предыдущих главах, а в качестве отправной точки я предлагаю искать в файлах классов строки .gif или .jpg. Я никогда не видел приложения, которое хранит файлы GIF с расширением .txt, и искренне надеюсь никогда не дожить до такого дня. Например, чтобы изменить изображение в диалоговом окне «О программе» приложения Chat, можно найти в рабочем каталоге все файлы GIF и JPG. Это приведёт нас в каталог covertjava.chat.images, содержащий несколько изображений. Поскольку их там совсем немного, можно просто просмотреть файлы и определить, какой из них используется в диалоговом окне «О программе». Либо можно было искать строку .gif, что снова привело бы к файлу класса MainFrame. Декомпилировав его, мы обнаружили бы, что для диалогового окна «О программе» Chat использует saturn_small.gif.

Наконец, можно искать вызов метода getImage класса java.awt.Toolkit, поскольку это самый распространённый способ загрузки изображения. Ниже приведена пара примеров кода Java, загружающего изображение:

Найдя код, загружающий изображение, вы должны суметь понять, откуда оно берётся. Если изображение не упаковано вместе с приложением, скорее всего, доступ к нему осуществляется по внешнему URL наподобие mycompany.com. Теперь вы, образованный хакер, точно знаете, как подступиться к задаче. Загрузите изображение с этого URL с помощью веб-браузера, сохраните его локально, отредактируйте и упакуйте с приложением. Затем исправьте загружающий его класс и вместо URL с HTTP используйте либо URL jar:file/ для загрузки из своего JAR, либо Toolkit.getImage() для загрузки из каталога. Вуаля - готово.

Файлы конфигурации - всего лишь ещё один вид ресурсов приложения, и подход к их взлому такой же, как для текста и изображений. Речь не о хранящихся в каталоге приложения конфигурационных файлах, которые легко изменить, а о файлах, которые могут находиться внутри файла .jar или .zip и не обязательно предназначены для редактирования. Как и прежде, распакуем архив приложения командой jar и изучим структуру каталогов в поисках подозрительных файлов. Если структура каталогов велика, можно найти все файлы с расширением .properties или .xml. Скорее всего, такой простой просмотр даст результат. Если нет, можно вернуться к описанным в предыдущих главах приёмам обратной разработки, чтобы найти участок кода, использующий этот параметр. Затем можно проследить путь до кода, загружающего конфигурацию, и получить достаточно сведений для выбора стратегии исправления.

1. Предположим, вы используете библиотеку, которая при перехвате обобщённого исключения выводит сообщение Unknown error. Как заменить его текстом Internal error, please contact technical support?

2. Как изменить диалоговое окно «О программе» приложения Chat, чтобы на изображении было ваше имя?

3. Как выяснить, можно ли настроить установленное используемым вами приложением максимальное число одновременных соединений?

• Для взлома элементов пользовательского интерфейса необходимо найти и исправить ресурсы, из которых они были созданы.

• Для взлома текста необходимо найти файл CLASS или файл конфигурации (.properties, .xml либо .resource), в котором он задан, и изменить этот файл.

• Для взлома изображений необходимо найти файл изображения (обычно GIF или JPG).

• Взлом файлов конфигурации сводится к простому редактированию текста после того, как найден файл, задающий интересующие свойства.

• Определение подслушивания

• Подслушивание HTTP

• Подслушивание протокола RMI

• Подслушивание драйвера JDBC и операторов SQL

• Короткий тест

• Краткие итоги

Предыдущие главы были в основном посвящены работе с байт-кодом и ресурсами приложения. Многоуровневые приложения, господствующие на стороне сервера, дают дополнительные направления для обратной разработки и взлома. Уровни приложения обычно развёртывают как отдельные процессы, обменивающиеся данными по сетевым протоколам. Например, веб-браузер, отображающий интерфейс HTML на рабочей станции пользователя, взаимодействует с веб-сервером по протоколу передачи гипертекста (HTTP). В свою очередь веб-сервер обычно взаимодействует с сервером приложений посредством RMI или IIOP. Сервер приложений использует JDBC для взаимодействия с базой данных. Классическая схема развёртывания распределённых многоуровневых приложений Java показана на рисунке 13.1.

Рисунок 13.1. Схема развёртывания многоуровневого приложения

В этой главе представлены несколько приёмов подслушивания разговора между распределёнными уровнями. Подслушивание - это перехват и регистрация обмена сообщениями между клиентом и сервером. Оно может помочь в устранении неполадок или настройке производительности сложной распределённой системы, а также позволяет понять устройство приложения и принципы его взаимодействия.

Большинство серверных приложений использует базу данных для хранения и получения данных. Знание того, как приложение взаимодействует с базой данных и какие операторы SQL применяет, может значительно помочь в настройке производительности или обратной разработке. Безусловно преобладающей технологией хранения данных является JDBC, и в ближайшее время это не изменится. Чтобы использовать JDBC, приложение должно определить и загрузить драйвер, получить соединение, а затем выполнять операторы для обновлений и запросов. С точки зрения настройки производительности и обратной разработки наиболее интересны структура и параметры операторов SQL. Общеизвестно, что производительность базы данных во многом зависит от эффективности операторов SQL приложения. Анализ SQL и времени выполнения может привести к улучшениям на стороне приложения, базы данных или с обеих сторон.

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

API JDBC предоставляет способ регистрировать операции с базой данных на уровне драйвера посредством метода setLogWriter класса DriverManager. Он выводит такие сведения, как регистрация драйверов, URL для создания соединений с базой данных и имена классов соединений. Проблема журналирования диспетчера драйверов в том, что оно не даёт наиболее важных сведений: операторов SQL и переданных базе данных значений. Я перенаправил журналирование драйвера JDBC в System.out и проверил его простой программой, которая регистрирует драйвер, получает соединение с базой данных и выполняет несколько параметризованных операторов SELECT. В выводе журнала драйвера в листинге 13.1 нет и следа выполненных программой операторов SELECT.

Листинг 13.1. Вывод журналирования драйвера JDBC

Чтобы надёжно подслушивать вызовы базы данных, необходимо заменить драйвер JDBC оболочкой, которая регистрирует оператор, а затем делегирует его «настоящему» драйверу. Есть прекрасная старая максима: хорошая технология или продукт делает «простые вещи лёгкими, а сложные возможными». P6Spy, который мы применим для журналирования JDBC, как раз это демонстрирует. Меньше чем за десять минут, после минимальных изменений конфигурации, он позволяет регистрировать вызовы базы данных существующих приложений без каких-либо изменений кода. P6Spy - бесплатное приложение с открытым исходным кодом, доступное на SourceForge.

После загрузки и установки P6Spy файлы p6spy.jar и spy.properties необходимо поместить в CLASSPATH целевого приложения. Чтобы активировать шпион, применяемый приложением класс настоящего драйвера следует заменить классом драйвера-шпиона. Имя настоящего драйвера нужно задать в spy.properties, чтобы шпион мог делегировать ему вызовы. Остальные параметры приложения, относящиеся к базе данных, менять не требуется. Например, если приложение соединяется с базой Oracle через стандартный драйвер, имя класса настоящего драйвера - oracle.jdbc.driver.OracleDriver. Чтобы активировать шпион, в файле конфигурации приложения это имя следует заменить на com.p6spy.engine.spy.P6SpyDriver, а в spy.properties настоящий драйвер нужно задать так:

После перезапуска приложения создаётся журнал с перехваченными вызовами базы данных. Например, настроив P6Spy для стандартного демонстрационного приложения JDK TableExample и введя в таблице несколько операторов SELECT, я получил следующий журнал:

P6Spy использует Log4J и допускает широкую настройку. Дополнительные сведения см. в документации продукта.

1. Каковы общие подходы к подслушиванию?

2. Почему взаимодействие HTTP легко подслушивать?

3. Как можно защитить взаимодействие HTTP?

4. Благодаря чему возможно сетевое прослушивание?

5. Как подслушивать взаимодействие RMI?

6. Какой способ перехвата операторов SQL в JDBC самый надёжный?

• Подслушивание - это перехват и регистрация обмена сообщениями между клиентом и сервером. Оно возможно потому, что взаимодействие должно пересекать границы процессов или компьютеров.

• Туннелирование - приём, при котором между клиентом и сервером помещается посредник, а клиент перенастраивается на отправку сообщений посреднику. Посредник передаёт запросы серверу, пересылает ответ обратно клиенту и попутно регистрирует обмен.

• Подслушивать HTTP легко благодаря простой текстовой природе протокола и широкому разнообразию инструментов.

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

• Подслушивать RMI можно с помощью такого сетевого анализатора, как Ethereal. Для этого требуется изучать низкоуровневые сетевые пакеты, несущие двоичное содержимое сообщений RMI.

• Подслушивание JDBC легко осуществляется с помощью оболочек над настоящим драйвером и объектами соединения. Оболочки регистрируют каждый оператор, прежде чем передать его настоящим классам драйвера.

• Внутреннее устройство JVM с точки зрения загрузки классов

• Написание собственного загрузчика классов

• Короткий тест

• Краткие итоги

Загрузчики классов загружают и инициализируют классы и интерфейсы в виртуальной машине Java (JVM). В этой главе дан обзор данного процесса и показано, как разработать собственный загрузчик классов, позволяющий декорировать загружаемый байт-код.

Виртуальная машина Java, работающая поверх операционной системы (ОС), предоставляет уровень абстракции приложениям, написанным на Java. Спецификация языка и стандартизованные интерфейсы программирования приложений (API) обеспечивают межплатформенную разработку и развёртывание, поскольку приложения не обращаются непосредственно к ОС с платформенно-зависимыми вызовами. Большая часть основных API Java сама написана на Java; лишь небольшая доля машинного кода вызывается через JNI. Приложения Java могут содержать байт-код и машинные динамические библиотеки. В Windows машинные библиотеки распространяются как динамически подключаемые библиотеки (.dll), а в Unix - как разделяемые библиотеки (.so). Чтобы выполнить приложение Java, JVM применяет загрузчик классов, который загружает и инициализирует системные и прикладные классы, что может привести к загрузке машинных библиотек приложения. JVM с точки зрения загрузки классов показана на рисунке 14.1.

Рисунок 14.1. JVM с точки зрения загрузки классов

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

Процесс загрузки приложения начинается с начального класса, переданного средству запуска Java (обычно как параметр командной строки среде выполнения Java). Все родительские классы и любые классы, на которые ссылается метод main() начального класса, лениво загружаются и инициализируются по мере обращения к ссылкам. Если явно не указано иное, для загрузки упомянутого класса используется загрузчик класса, который на него ссылается. Если загрузчики классов загружают классы Java, спросите вы, то чем загружаются сами загрузчики классов? Ответ - начальным загрузчиком классов, реализованным в машинном коде и применяемым для загрузки таких основных классов Java, как java.lang.Object и java.lang.ClassLoader. Загрузчик расширений служит для загрузки библиотек расширений, обычно из каталога lib/ext среды JRE, причём помещённые туда файлы JAR автоматически становятся доступны приложениям Java. Загрузчик классов приложения создаётся внутри средством запуска JVM для загрузки классов из стандартного CLASSPATH. Наконец, загрузчик, называемый системным загрузчиком классов, обычно совпадает с загрузчиком классов приложения.

Загрузчики классов организованы в цепочку, где дочерний загрузчик позволяет родительскому найти класс, прежде чем пытается найти его сам. Обычно загрузчик классов сначала проверяет, не загрузил и не инициализировал ли он уже этот класс. Если класс ещё не загружен, загрузчик пытается создать или загрузить его и, если находит, инициализировать в JVM. Начальный загрузчик находится в корне иерархии загрузчиков классов и соответствует значению null, тогда как системный загрузчик по умолчанию становится родителем делегирования для новых загрузчиков. В таблице 14.1 перечислены загрузчики классов и сведения об источниках данных классов.

Таблица 14.1. Загрузчики классов и источники их файлов CLASS

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

Листинг 14.1. Исходный код PrintClassLoaders

Класс PrintClassLoaders находится в пакете covertjava.classloader. Его выполнение даёт следующий вывод:

Из вывода можно заключить, что иерархия загрузчиков классов соответствует порядку, в котором среда выполнения пытается найти и загрузить класс. Экземпляр AppClassLoader, возвращаемый вызовом getClassLoader() из начального класса, является загрузчиком, связанным с PrintClassLoaders. Этот же экземпляр используется как системный загрузчик, возвращаемый ClassLoader.getSystemClassLoader(), а его непосредственный родитель - загрузчик расширений ExtClassLoader. Родителем загрузчика расширений служит null, что подразумевает начальный загрузчик. Поскольку загрузчики делегируют работу родителю, прежде чем пытаются загрузить класс сами, классы в начальном пути классов всегда загружаются начальным загрузчиком. Если класс там не найден, следующим проверяется путь классов расширений. Путь классов приложения проверяется, только если класс не найден ни в одном из этих путей. Если его не находит и загрузчик приложения, выбрасывается печально известное исключение ClassNotFound.

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

• Загрузчик, который загрузил и определил класс в процессе, связывается с ним и называется определяющим загрузчиком классов.

• Загруженный класс определяется не только именем, но парой из имени и определяющего загрузчика. Два класса с одним именем, но разными загрузчиками считаются различными.

• Если класс A ссылается на ещё не загруженный класс B, для загрузки B используется определяющий загрузчик A.

Таким образом, если класс был загружен из начального пути начальным загрузчиком, он не способен ссылаться на классы из пути приложения, если только явно не обращается к ним через системный или собственный загрузчик. С потоком связан загрузчик классов, который можно получить методом getContextClassLoader(). Обычно ему назначается загрузчик класса, запустившего поток. Иногда для доступа к классам из другого источника вместо определяющего загрузчика нужно использовать контекстный загрузчик потока. Это может потребоваться сервлетам, загруженным собственным загрузчиком веб-контейнера. Загрузчик контейнера может быть настроен на загрузку только классов веб-приложения, и тогда классы из системного пути окажутся недоступны.

Java позволяет приложениям управлять созданием или загрузкой классов посредством собственных, то есть пользовательских, загрузчиков. Например, веб-серверы и серверы приложений предоставляют каждому развёрнутому приложению отдельный загрузчик, чтобы лучше изолировать логические приложения, работающие в одной JVM. Напомним: даже два класса, загруженные из одного файла, считаются различными, если их определили разные загрузчики. Когда у каждого приложения собственный загрузчик, статические переменные, которые так часто служат для реализации шаблона «одиночка» и хранения глобальных данных, становятся общими в пределах приложения, а не всей JVM. Собственные загрузчики также позволяют веб-серверам и серверам приложений перезагружать классы без перезапуска JVM. Ещё один мощный приём - применение собственного загрузчика для создания классов на лету или изменения двоичной структуры данных класса до его определения в среде выполнения Java.

В этом разделе мы создадим в пакете covertjava.classloader собственный загрузчик DecoratingClassLoader, позволяющий на лету изменять загруженные двоичные данные классов. После написания этот класс можно будет использовать для поддержки зашифрованных файлов классов или декорирования байт-кода, которые рассматриваются далее в книге. Пока сосредоточимся на загрузке классов из заданного пользователем пути и вызове метода обратного вызова, который получает возможность изучить и изменить двоичные данные. Код будет в общих чертах основан на реализации загрузчика классов в JUnit. Все загрузчики должны расширять абстрактный класс java.lang.ClassLoader и как минимум переопределять метод findClass, чтобы загружать или создавать класс по заданному имени. Реализация findClass в DecoratingClassLoader показана в листинге 14.2.

Листинг 14.2. Реализация findClass

Метод findClass вызывается только в том случае, если класс не найден ни одним родительским загрузчиком в иерархии. Благодаря этому основные классы наподобие java.lang.Object загружаются начальным загрузчиком. После загрузки двоичных данных класса декоратору предоставляется возможность дополнить байт-код. Затем байты класса передаются методу defineClass класса java.lang.ClassLoader, который преобразует двоичное представление класса во внутренний объект Class. Чтение двоичных данных класса выполняется в методе getClassBytes(), показанном в листинге 14.3.

Листинг 14.3. Реализация getClassBytes

Метод перебирает элементы настроенного пути классов и пытается найти и загрузить данные файла .class в соответствующем каталоге. Если данные класса не найдены, выбрасывается ClassNotFoundException. DecoratingClassLoader принимает путь классов как параметр конструктора, а конструктор по умолчанию инициализирует его путь значением системного свойства decorate.class.path. Полный исходный код DecoratingClassLoader находится в каталоге CovertJava/src/covertjava/classloader.

Чтобы использовать собственный загрузчик, его нужно явно указать для загрузки класса, недоступного родительским загрузчикам. Это можно сделать, передав экземпляр загрузчика методу Class.forName() или непосредственно вызвав метод loadClass() собственного загрузчика. Помните, что загрузчики делегируют загрузку родительской цепочке, и если родитель может найти класс, метод findClass() дочернего загрузчика не вызывается. Поэтому самый чистый способ позволить собственному загрузчику загрузить класс - обеспечить отсутствие этого класса в системном, начальном и расширенном путях классов. Этот вариант часто выбирают реализации веб-серверов и серверов приложений, предупреждающие, что классы приложения не следует помещать в системный CLASSPATH. Если требуется полный контроль над загрузкой, можно переопределить метод loadClass(String name, boolean resolve). Он вызывается для начала загрузки класса, а стандартная реализация сначала позволяет загрузить класс родителю. После переопределения собственный загрузчик вызывается для каждого класса в системе независимо от того, где находятся данные класса. Другой вариант - использовать начальный загрузчик как родителя, передав конструктору ClassLoader значение null. Однако лучше всего убрать из системного CLASSPATH те JAR и каталоги с классами, которые должен загружать собственный загрузчик: это обеспечивает разделение системных и пользовательских классов.

Чтобы проверить делегирование DecoratingClassLoader, добавим декоратор PrintingClassDecorator, который просто выводит имя класса, для которого вызван (см. листинг 14.4).

Листинг 14.4. Реализация PrintingClassDecorator

Чтобы увидеть DecoratingClassLoader в действии, испытаем его на классе PrintClassLoaders, рассмотренном ранее. Понадобится класс запуска, который создаёт экземпляр собственного загрузчика, а затем загружает с его помощью тестовый класс. Класс DecoratingLauncher из пакета covertjava.classloader

принимает имя запускаемого тестового класса и загружает его через DecoratingClassLoader. Затем посредством API отражения он вызывает функцию main() тестового класса. Метод main() класса DecoratingLauncher показан в листинге 14.5.

Листинг 14.5. Метод main() класса DecoratingLauncher

Обратите внимание: экземпляр нашего загрузчика передаётся методу forName(). Перед выполнением теста нужно удалить класс PrintClassLoaders из CLASSPATH и поместить его в каталог, на который будет указывать системное свойство decorate.class.path. Придётся изменить цель release в build.xml, чтобы до создания JAR перемещать covertjava.classloaders.PrintClassLoaders в каталог CovertJava/lib/classes. Также нужно создать в каталоге bin новый пакетный файл, который вызывает средство запуска и передаёт ему PrintClassLoaders как параметр. Содержимое пакетного файла показано в листинге 14.6.

Листинг 14.6. Код classLoaderTest.bat

Выполнение classLoaderTest.bat даёт следующий вывод:

Из вывода видно, что загрузчик, связанный с классом PrintClassLoaders, является экземпляром DecoratingClassLoader. В качестве родителя DecoratingClassLoader получил системный загрузчик классов, а остальная иерархия не изменилась.

1. Каково назначение загрузчика классов?

2. Что такое начальный загрузчик и какие классы он загружает?

3. Что такое загрузчик расширений и какие классы он загружает?

4. Какие классы считаются одинаковыми внутри JVM?

5. Для чего можно использовать собственный загрузчик классов?

6. Можно ли с помощью собственного загрузчика загружать все классы, включая основные классы Java?

7. Почему DecoratingClassLoader использует собственный путь классов?

• Загрузчики классов загружают и инициализируют классы и интерфейсы в JVM.

• Процесс загрузки приложения начинается с начального класса, переданного средству запуска. Все родительские классы и любые классы, на которые ссылается метод main() начального класса, лениво загружаются и инициализируются по мере обращения к ссылкам.

• Начальный загрузчик реализован в машинном коде и применяется для загрузки таких основных классов Java, как java.lang.Object и java.lang.ClassLoader.

• Загрузчики классов организованы в цепочку, где дочерний загрузчик позволяет родительскому найти класс, прежде чем пытается найти его сам.

• Загруженный класс определяется не только именем, но парой из имени и определяющего загрузчика классов.

• Собственные загрузчики позволяют приложениям Java управлять загрузкой классов. Они применяются для перезагрузки классов, разделения логических приложений внутри одной JVM и декорирования либо создания байт-кода на лету.

• Зачем это нужно?

• Исправление основных классов Java с помощью начального пути классов

• Пример исправления java.lang.Integer

• Короткий тест

• Краткие итоги

В главе 5, «Замена и исправление классов приложения», мы говорили об исправлении классов Java для изменения или расширения лежащей в их основе логики. Представленные там приёмы работают для классов приложений и библиотек, загружаемых системным либо собственным загрузчиком. Однако попытки применить их к основным классам в пакете, имя которого начинается с java, не дают результата: продолжает использоваться исходная версия класса. В главе 14, «Управление загрузкой классов», подробно рассматривалось, как загружаются классы, и после небольшого размышления становится понятно, почему для системных классов требуется другой подход. Напомним, что системные классы загружает машинный начальный загрузчик, который не использует переменную среды CLASSPATH. Хотя общий подход к исправлению системных классов подобен исправлению классов приложения, есть несколько тонких различий, и именно им посвящена эта глава.

Действительно ли нужно исправлять основные классы? За свою карьеру мне приходилось исправлять классы приложений гораздо чаще, чем системные классы. Одна из причин, возможно, в том, что основные классы хорошо спроектированы и к настоящему времени созрели до формы, устраивающей большинство разработчиков. Тем не менее время от времени можно наткнуться на недостаток основного класса, для которого нет хорошего обходного решения.

Определённо не рекомендуется использовать исправление основных классов Java как постоянное решение. Оно влечёт правовые последствия (лицензия JDK запрещает изменять основные классы) и может потребовать дополнительной работы при переходе на новую версию JDK. Однако этот приём даёт разработчику гораздо больше контроля. С его помощью можно вставлять трассировку в код JDK и временно менять реализацию основной логики в соответствии с потребностями приложения. И последнее, но не менее важное: это просто здорово, и вооружиться столь мощным приёмом не помешает. Только обязательно прочтите лицензионное соглашение, прежде чем встать на этот путь.

Как уже упоминалось, подход к исправлению основных классов подобен подходу для классов приложений. Необходимо получить исходный файл класса, который требуется исправить. JDK предусмотрительно распространяется с исходным кодом (спасибо, Sun!), поэтому чаще всего код можно просто взять из src.jar. Обратите внимание, что некоторые системные классы поставляются без исходного кода; это справедливо для классов внутри пакета sun и других непубличных пакетов. Файлы классов можно декомпилировать, как описано в главе 2, «Декомпиляция классов», однако при этом необходимо соблюдать лицензионное соглашение.

Получив исходный код, можно вставить новую логику. Скомпилируйте класс так же, как любой другой, и, пожалуйста, постарайтесь не добавить ошибок. Теперь, когда у вас есть новая версия байт-кода, остаётся указать JVM использовать её вместо исходного байт-кода. Этого можно добиться, управляя начальным путём классов, как объяснялось в главе 14. Начальный загрузчик использует этот путь для поиска основных классов. По умолчанию путь включает только rt.jar и, возможно, несколько других системных библиотек. Файл rt.jar, расположенный в JRE_HOME\lib, содержит большинство основных классов, поэтому, если исходного кода класса нет и нужно найти его байт-код, сначала проверьте rt.jar. Начальный путь классов задаётся параметром -Xbootclasspath в командной строке средства запуска Java. Выполнение java -X выводит следующую справку:

Параметр командной строки позволяет задать или дополнить начальный путь классов. Поскольку нас интересует замена существующего класса, используем -Xbootclasspath/p:, чтобы добавить каталог с исправлениями перед стандартным путём. При запуске JVM с этим параметром вместо исходного класса применяется исправленный.

Чтобы применить теорию на практике, напишем простое исправление для java.lang.Integer. По причинам, неизвестным сообществу Java, объект Integer неизменяем. После задания значения его нельзя изменить. Вероятно, замысел состоял в том, чтобы объекты Integer вели себя подобно объектам String: если нужно изменить значение, представленное объектом Integer, следует создать новый экземпляр и использовать его вместо старого. Проблема такого подхода в неэффективном расходе памяти приложениями, которым нужны динамические коллекции целых чисел. Java не предоставляет классов коллекций для примитивных типов, поэтому единственный способ получить динамический массив целых чисел - использовать java.util.Array из экземпляров Integer. Если сохранённое целое требуется изменить, необходимо создать новый экземпляр Integer и поместить его в массив на место прежнего значения. Разумеется, выделение памяти и последующая сборка мусора создают значительные накладные расходы. Гораздо лучше было бы изменить внутреннее значение объекта Integer. Однако поскольку java.lang.Integer неизменяем, единственное законное обходное решение - создать и использовать собственный класс, имитирующий Integer и предоставляющий метод setValue().

Тем не менее мы исправим существующий класс java.lang.Integer и наделим его методом setValue(). Сделаем это исключительно из академического интереса и для практики проповедуемых нами приёмов, поскольку не хотим нарушать лицензионное соглашение Java. Из исходного кода java.lang.Integer видно, что значение объекта хранится в закрытом поле value. Поэтому нужно скопировать исходный файл в каталог CovertJava\src\java\lang и вставить метод setValue (см. листинг 15.1).

Листинг 15.1. Исходный код метода setValue()

Следующий шаг - создать тестовый класс CorePatchTest, обращающийся к только что добавленному методу setValue(). Код тестового класса показан в листинге 15.2.

Листинг 15.2. Использование исправленного java.lang.Integer

Компиляция классов, использующих исправленные версии основных классов, может быть несколько хитрой, если открытый интерфейс основного класса изменился. Попытка запустить javac для нашего тестового класса приводит к ошибке, поскольку в реализации Integer из JDK нет метода setValue(). По этой причине применить Ant для компиляции исправленного java.lang.Integer невозможно. Самый простой обходной путь - вручную скомпилировать исправленный Integer с помощью javac, а затем скопировать файл класса в каталог CovertJava/distrib/patches. Теперь компилятор можно настроить так, чтобы он использовал в нашем проекте исправленную версию Integer: для этого исправленный класс помещается в начальном пути классов перед исходной версией.

javac, как и задача javac в Ant, принимает параметр -bootclasspath, позволяющий переопределить стандартный начальный путь классов. Однако при переопределении начального пути для javac необходимо указать расположение rt.jar и всех остальных системных библиотек. В результате сценарии сборки начинают зависеть от пути установки JDK или переменных среды. Более простой способ - передать -Xbootclasspath/p: той JVM, в которой работает Ant, чтобы не переопределять стандартный путь, а всего лишь добавить элемент перед ним. Сценарий ant.bat передаёт параметры командной строки вызову Java через переменную среды ANT_OPTS, чем мы и воспользуемся, добавив следующую строку в CovertJava\bin\build.bat:

Теперь с помощью Ant можно собрать проект и библиотеки дистрибутива (цель release). Последняя задача после сборки проекта - создать в каталоге CovertJava\bin пакетный файл corePatchTest.bat, выполняющий CorePatchTest. Чтобы гарантировать применение исправленной версии Integer, снова передаём Java параметр -Xbootclasspath. Соответствующий исходный код corePatchTest.bat показан в листинге 15.3.

Листинг 15.3. Выполнение теста исправления основного класса

corePatchTest.bat даёт следующий вывод:

Вуаля! В нашей копилке появился ещё один приём.

1. Можете ли вы придумать случай, когда захотелось бы исправить основной класс?

2. Чем процесс исправления основных классов отличается от исправления классов приложения?

3. Зачем нужно изменять начальный путь классов?

• Исправление основных классов Java может помочь при отладке и изучении JVM.

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

• Чтобы исправить основной класс, новую версию необходимо поместить в начальном пути перед старой.

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

• Определение потока управления

• Перехват системных ошибок

• Перехват системных потоков

• Перехват вызова System.exit

• Реакция на завершение работы JVM с помощью перехватчиков

• Перехват методов динамическим заместителем

• Интерфейс профилировщика виртуальной машины Java

• Короткий тест

• Краткие итоги

Поток управления - это последовательность выполнения методов и инструкций потоком. Виртуальная машина Java (JVM) выполняет инструкции байт-кода Java в том порядке, в котором они находятся в файле класса. Поток управления можно программировать условными конструкциями, например if, else и for, или вызовом метода. Перехват потока управления подразумевает знание выполняемой инструкции или метода и возможность изменить ход выполнения во время работы. Например, может потребоваться перехватить вызов System.exit(), чтобы не дать JVM завершить работу. Пока вы не слишком воодушевились возможностями, сразу уточню ожидания. Прямого способа перехватить любую инструкцию или вызов метода в работающей JVM нет, если только она не запущена в режиме профилирования. Методы выполняются JIT-компилятором, и стандартного API Java, позволяющего добавить к вызовам методов слушатель или перехватчик, не существует. Однако мы рассмотрим несколько косвенных подходов к перехвату управления в распространённых сценариях. Кроме того, мы изучим интерфейс профилировщика JVM, с помощью которого в режиме отладки можно перехватить любой вызов.

Системные ошибки сообщаются JVM при ненормальных условиях, предположительно находящихся вне управления приложения. Они выбрасываются как подклассы java.lang.Error и поэтому не объявляются, то есть могут быть выброшены любым методом, даже если его сигнатура явно их не объявляет. К системным относятся ошибки виртуальной машины, например OutOfMemoryError и StackOverflowError, ошибки связывания, такие как ClassFormatError и NoSuchMethodError, и другие сбои. По принятому соглашению программисты приложений должны перехватывать только экземпляры java.lang.Exception, а значит, такое состояние, как нехватка памяти, не обнаруживается логикой обработки ошибок приложения. Для большинства реальных приложений это нежелательно: даже если при ошибке ничего нельзя сделать, приложение обычно должно записать её в файл журнала и попытаться освободить удерживаемые ресурсы. Хорошее проектное решение - поместить на вершине стека вызовов основных потоков приложения блок try-catch, перехватывающий java.lang.Error или java.lang.Throwable и передающий управление методу, который анализирует ошибочное состояние, регистрирует его и пытается аккуратно завершить работу. Например:

Если JVM не хватает памяти или класс не найден, приложение может попытаться исправить положение, освободив содержимое кэшей либо отключив функцию, затронутую отсутствующими классами. Всё лучше, чем постыдно исчезнуть без следа.

До того как журналирование стало фактическим требованием к приложениям Java, отладочную трассировку часто выводили с помощью System.out.println. Недостатки этого подхода многочисленны и очевидны. Такие трассировки после написания нельзя включать или отключать без изменения кода. Хотя поток вывода приложения можно перенаправить в файл для постоянного хранения, ротация отсутствует, а поскольку файл остаётся открытым, его невозможно удалить до завершения приложения (поэтому размер файла может стать непомерным). При работе с унаследованным кодом Java, испещрённым вызовами System.out.println(), часто возникает задача заменить их вызовами каркаса журналирования (обсуждение журналирования и трассировки см. в главе 6, «Эффективная трассировка»). Важно также захватывать стандартный поток ошибок, в который выводят данные такие методы, как printStackTrace() класса Exception. Одно из изящных решений - перехватывать вывод в System.out и System.err и вместо этого отправлять его в файл журнала.

Приём основан на том, что системный поток вывода можно перенаправить в собственный PrintStream с помощью метода setOut класса java.lang.System. PrintStream - класс-декоратор вокруг экземпляра OutputStream, отвечающего за собственно вывод. Следовательно, задача состоит в том, чтобы разработать перенаправляющий OutputStream, который пишет в файл журнала вместо стандартного вывода процесса, а затем назначить его потоку System.out.

Мы разработаем класс LogOutputStream, расширяющий java.io.OutputStream и записывающий вывод в файл журнала посредством Apache Log4J. Каркас ввода-вывода Java спроектирован очень хорошо, и все методы OutputStream в конце концов делегируют работу единственному методу write(), принимающему целочисленный параметр. LogOutputStream накапливает в StringBuffer символы, получаемые методом write(int), а после обнаружения разделителя строк записывает весь буфер на диск через Log4J. Единственная хитрость реализации - обнаружение конца строки. Как вам, несомненно, известно, в Unix конец строки отмечается одним символом: \n (новая строка). В Windows конец строки отмечается сочетанием двух символов: \r и \n (возврат каретки и новая строка). Чтобы написать действительно межплатформенный код Java, необходимо опираться на системное свойство line.separator. Поскольку это свойство является строкой, реализация должна искать подстроку, а не сравнивать символы. Наша реализация оптимизирована так, чтобы сначала сравнением символов проверить возможный конец строки, а затем поиском подстроки убедиться, что это действительно конец. Переопределённый метод write() показан в листинге 16.1.

Листинг 16.1. Метод write() класса LogOutputStream

Здесь logger - ссылка на статическую переменную типа org.apache.log4j.Logger, объявленную в LogOutputStream следующим образом:

Таким образом, весь вывод в System.out перенаправляется каркасу Log4J как сообщения уровня INFO от класса LogOutputStream. Чтобы увидеть наш класс в действии, нужно настроить файловый добавитель в log4j.properties и установить перехватчик, как показано в листинге 16.2.

Листинг 16.2. Установка перехвата System.out

При выполнении метода main() класса LogOutputStream сообщение Installing the interceptor... появляется в консоли, а сообщения Hello, world и Done записываются в файл журнала. Тот же перехватчик можно установить для потока System.err. Для гибкости его можно параметризовать, чтобы конструктор принимал уровень журналирования и имя потока. Аналогичным образом поток System.In можно программно задать методом System.setIn(), чтобы передавать приложению требуемый ввод.

Процесс JVM обычно завершается, когда не остаётся активных потоков. Потоки, работающие как демоны (Thread.isDaemon() == true), не мешают завершению JVM. В многопоточных приложениях, включая графические интерфейсы Swing и серверы RMI, добиться аккуратного завершения естественным окончанием всех потоков нелегко. Для принудительного завершения JVM и процесса часто вызывают System.exit(). Полагаться на System.exit() стало обычным делом даже в не очень сложных программах; хотя это облегчает жизнь разработчику приложения, такой вызов может создать проблему для продуктов среднего уровня, например веб-серверов и серверов приложений. Неосторожный вызов System.exit() из веб-приложения способен, например, остановить процесс веб-сервера и, возможно, лишить пользователей доступа к другим веб-приложениям и статическим страницам HTML. Так с системными администраторами не подружишься, а каждый хороший разработчик знает цену здоровых отношений с этой командой.

В этом разделе рассматривается простой способ перехватить вызов System.exit() и предотвратить завершение JVM. Этот приём можно обнаружить, изучив исходный код метода exit() класса java.lang.System. Первым делом метод проверяет, установлен ли диспетчер безопасности. Если установлен, метод проверяет наличие у вызывающей стороны разрешения на завершение JVM. Поэтому наша задача - установить собственный диспетчер безопасности (или изменить политику безопасности, если диспетчер уже установлен), запрещающий завершение до тех пор, пока оно не будет явно разрешено. Класс InterceptingSecurityManager из пакета covertjava.intercept расширяет класс SecurityManager и переопределяет метод isExitAllowed(), чтобы управлять завершением JVM. Внутренний флаг, который можно задать методом setExitAllowed(), определяет, разрешено ли JVM завершиться. Если завершение запрещено, для изменения потока управления выбрасывается непроверяемое SecurityException. Метод main() в листинге 16.3 показывает установку перехватывающего диспетчера безопасности и его влияние на ход выполнения.

Листинг 16.3. Перехват System.exit()

Для простоты примера настоящая деловая логика, которая обычно вызывалась бы внутри блока try, заменена сообщением Run some logic.... Главное - перехватить класс Throwable, а не обычный Exception, поскольку перехваченный System.exit() сообщается как непроверяемое исключение. Выполнение метода main() из листинга 16.3 даёт следующий вывод:

Вместо завершения JVM после вызова System.exit() внутри блока try программа продолжает работать, пока завершение не будет разрешено.

В предыдущем разделе показано, как перехватить программную попытку завершить JVM вызовом System.exit(). Иногда завершение JVM инициирует пользователь командой kill в Unix или сигналом Ctrl+C в Windows. JVM также может завершиться из-за выхода пользователя из системы или завершения работы ОС. Может ли программа Java перехватить сигнал завершения? Нет, перехватить его она не может, но способна отреагировать. Начиная с JDK 1.3 приложение может установить перехватчик завершения методом addShutdownHook() класса java.lang.Runtime. Перехватчики завершения - это инициализированные, но не запущенные экземпляры java.lang.Thread. При завершении JVM все потоки перехватчиков запускаются параллельно с остальными потоками JVM. Перехватчикам доступен весь API Java, но они должны учитывать уязвимое состояние JVM. Эти потоки не должны выполнять длительные операции и должны быть потокобезопасными. Нельзя рассчитывать на доступность системных служб, поскольку те сами могут находиться в процессе завершения. Подходящая задача для перехватчика - записать строку в файл журнала перед его закрытием и освободить прочие ресурсы, например открытые соединения с базой данных и файлы. Пример установки перехватчика завершения показан в листинге 16.4.

Листинг 16.4. Установка перехватчика завершения

Иногда до и после вызова метода требуется выполнить некоторую обработку. Она может включать трассировку имени метода и значений параметров, измерение времени выполнения или даже предоставление альтернативной реализации. Предположим, вы разрабатываете графический редактор, в котором основные фигуры представлены интерфейсами Line, Circle, Rectangle и Curve. Добавить трассировку всех методов этих интерфейсов можно несколькими способами. Можно пройти по каждой функции и тщательно вставить вызовы трассировки. Либо можно написать класс-заместитель, реализующий каждый интерфейс, выводящий трассировку и делегирующий работу исходной реализации. Это более чистый подход, поскольку отладочный код отделён от реализации, но он требует большого объёма однообразного программирования. Интересная и не слишком известная альтернатива - динамический заместитель, использующий отражение для перехвата вызовов методов. Пакет java.lang.reflection предлагает интерфейс InvocationHandler и класс Proxy, которые вместе позволяют динамически создавать экземпляр, реализующий несколько интерфейсов, заданных во время выполнения. Такой подход не требует определять при компиляции интерфейсы, реализуемые заместителем. После создания заместитель можно привести к любому из интерфейсов, указанных при его создании, а любой вызов метода этих интерфейсов передаётся единственному методу заместителя, invoke. Единственное требование к классу динамического заместителя - реализация интерфейса InvocationHandler, который определяет метод invoke.

Разработаем для Chat динамический заместитель, который трассирует вызовы слушателя сообщений. Напомним, что Chat связывает главное окно с сервером RMI посредством интерфейса MessageListener. Хотя у MessageListener только один метод, этого достаточно для иллюстрации. Поместим динамический заместитель между экземплярами MainFrame и ChatServer, чтобы добавить трассировку вызовов методов. Создадим в пакете covertjava.intercept класс TracingProxy, реализующий интерфейс InvocationHandler. Заместитель будет делегировать вызовы методов настоящему объекту, поэтому конструктор примет целевой объект как параметр. Объявление класса TracingProxy и его конструктор показаны в листинге 16.5.

Листинг 16.5. Объявление TracingProxy

Обратите внимание, что трассирующий заместитель принимает цель как тип java.lang.Object. Это ключевой момент: класс заместителя не связан с MessageListener, поэтому может использоваться с любым интерфейсом.

Теперь необходимо написать метод invoke() из интерфейса InvocationTarget. Он принимает три параметра: сам объект заместителя, метод и массив параметров метода. Наша реализация выводит имя метода, а затем делегирует вызов цели, переданной конструктору заместителя. Этот код показан в листинге 16.6.

Листинг 16.6. Реализация метода invoke()

Теперь заместитель готов к испытанию. Чтобы увидеть его в действии, создадим экземпляр TracingProxy, инициализированный экземпляром MainFrame приложения Chat как целью. Затем создадим объект java.lang.reflect.Proxy, который динамически реализует интерфейс MessageListener и делегирует вызовы экземпляру трассирующего заместителя. Наконец, передадим заместитель отражения серверу Chat, приведя его к интерфейсу MessageListener. Соответствующий код Java показан в листинге 16.7.

Листинг 16.7. Использование динамического заместителя

Выполнение метода main() класса TracingProxy даёт следующий вывод:

Таким образом, мы смогли перехватить вызов метода messageReceived, не реализуя интерфейс MessageInfo. Динамические заместители также полезны при разработке каркасов и инструментов, когда требуется взаимодействовать с классами, типы которых неизвестны во время компиляции. Вместо генерации и компиляции статических классов-заместителей каркасы могут использовать динамические заместители как связующий слой между компонентами.

Многообещающим нововведением стал интерфейс профилировщика виртуальной машины Java (JVMPI), стандартизующий взаимодействие профилировщика с JVM. Впервые он был открыт в JDK 1.2.2, а затем расширен в JDK 1.4. Этот API представляет собой двусторонний интерфейс, определяющий, как виртуальная машина должна уведомлять агент профилировщика о происходящих внутри неё событиях, например запуске потоков, вызовах методов и выделении памяти. Он также определяет средства, с помощью которых профилировщик получает сведения о состоянии JVM и задаёт интересующие его события. Агент профилировщика работает внутри JVM, а все методы API являются функциями в стиле C, вызываемыми через JNI. Для доступа к API JVM необходимо запустить с параметром -XrunProfilerLibrary, где ProfilerLibrary - имя загружаемой машинной библиотеки. Несколько жаль, что интерфейса JVMPI на основе Java нет, а подробности реализаций на C и JNI выходят за рамки книги. Тем не менее ниже перечислены самые интересные события, которые можно перехватывать:

• JVMPI_EVENT_CLASS_LOAD - отправляется при загрузке класса.

• JVMPI_EVENT_CLASS_LOAD_HOOK - отправляется после загрузки данных класса загрузчиком, но до создания внутреннего представления класса. Это даёт профилировщику возможность декорировать или инструментировать байт-код.

• JVMPI_EVENT_METHOD_ENTRY - отправляется при входе в метод.

• JVMPI_EVENT_METHOD_EXIT - отправляется при выходе из метода.

• JVMPI_EVENT_THREAD_START - отправляется при запуске потока.

• JVMPI_EVENT_THREAD_END - отправляется после завершения потока.

Полное справочное описание JVMPI доступно по адресу java.sun.com.

1. Почему и где в приложении важно использовать java.lang.Throwable?

2. Как перенаправить вывод системного потока ошибок в базу данных?

3. Как перехватить вызов System.exit()?

4. Как приложение Java, работающее как служба, может закрыть все соединения с базой данных при завершении работы компьютера?

5. Какие события можно получать через JVMPI?

• Хорошего способа перехватить поток управления в Java нет. JVMPI предоставляет самые широкие возможности вмешательства в выполнение, но требует программирования JNI.

• Системные ошибки сообщаются как необъявленные и могут быть перехвачены в виде экземпляров java.lang.Throwable.

• Стандартные системные потоки вывода и ошибок можно программно перенаправить в собственный PrintStream.

• Вызов System.exit() можно перехватить, установив собственный SecurityManager, запрещающий завершение, пока оно не разрешено явно.

• Приложения могут выполнять код при завершении JVM с помощью перехватчиков завершения. Эти перехватчики являются потоками, которые JVM запускает после получения сигнала завершения.

• JVMPI предоставляет огромные возможности управления средой выполнения, загрузкой классов и выполнением методов.

• Основы байт-кода

• Просмотр файлов классов с помощью обозревателя байт-кода jClassLib

• Набор инструкций JVM

• Формат файла класса

• Инструментирование и генерация байт-кода

• Сравнение модификации байт-кода с AOP и динамическими заместителями

• Короткий тест

• Краткие итоги

В главе 2, «Декомпиляция классов», был дан краткий обзор байт-кода и его назначения в Java. Как вам, несомненно, известно, байт-код является промежуточной ступенью между исходным и машинным кодом, обеспечивающей межплатформенное выполнение программ Java. Байт-код определён спецификацией виртуальной машины Java (java.sun.com), где также описаны понятия языка, формат файла класса, требования к виртуальной машине Java (JVM) и другие важные стороны языка программирования Java. Строгое соблюдение спецификации обеспечивает переносимость и повсеместное выполнение приложений, скомпилированных в байт-код. JVM, работающая поверх операционной системы, отвечает за предоставление среды выполнения и преобразование инструкций байт-кода Java в машинные инструкции.

Большинство представленных ранее в книге приёмов взлома требовало получить исходный код и манипулировать им для изменения поведения приложения. В этой главе мы будем работать на уровне байт-кода, а не исходного кода. Мы узнаем, как просматривать структуры данных файла класса, инструментировать (расширять) существующий байт-код и программно создавать новые классы. Изменение на уровне байт-кода даёт следующие преимущества:

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

• Байт-код можно создавать или инструментировать загрузчиком классов на лету, по мере загрузки классов в JVM.

• Автоматизировать генерацию байт-кода проще и быстрее, чем генерацию исходного кода, поскольку требуется меньше этапов и не нужно запускать компилятор. Например, Hibernate создаёт код хранения данных для классов Java во время выполнения.

• Инструменты могут применять инструментирование байт-кода для добавления логики, которой не требуется присутствовать в исходных файлах. Например, некоторые реализации аспектно-ориентированного программирования (AOP) вставляют в байт-код собственные атрибуты и инструментируют методы для поддержки AOP.

Следующие два раздела дают краткое введение в те части спецификации JVM, которые относятся к байт-коду. Хотя полезно ознакомиться с работой JVM и форматом файла класса, для реализации представленных в этой главе приёмов это не строго обязательно. Если терпение не относится к вашим известным добродетелям, а чтение материала, похожего на спецификацию, сравнимо для вас с написанием пользовательской документации к своему коду, можете пропустить следующие два раздела и сразу перейти к разделу «Инструментирование и генерация байт-кода».

Обозреватель байт-кода, поставляемый с бесплатной библиотекой jClassLib, - превосходная графическая утилита для просмотра содержимого файла класса. На левой панели она показывает иерархическое представление структуры файла, а на правой - содержимое выбранного элемента. На рисунке 17.1 jClassLib отображает содержимое SimpleClass из пакета covertjava.bytecode.

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

Рисунок 17.1. Обозреватель байт-кода jClassLib

Исходные файлы Java компилируются в двоичные файлы классов определённого формата. Логика каждого метода Java представлена набором примитивных инструкций JVM, определённых её спецификацией. Инструкции JVM - базовые команды, подобные машинному коду. Каждая инструкция JVM состоит из кода операции (opcode), за которым следуют ноль или более операндов, представляющих параметры операции. В файле класса инструкции хранятся как двоичный поток, представляющий атрибут Code метода. Код операции занимает 1 байт, после которого могут следовать байты с данными операндов. Например, исходный код из листинга 17.1 представлен набором инструкций из листинга 17.2.

Листинг 17.1. Пример исходного кода Java

Листинг 17.2. Представление примера исходного кода в байт-коде

Большинство инструкций очень просты, и сопоставить их с представленным ими исходным кодом легко. Например, iconst_0 задаёт целочисленную константу со значением 0, а istore_1 сохраняет значение с вершины стека (в нашем случае 0) в локальную переменную, заданную индексом (в нашем случае i). Более интересный сценарий - вызов метода. Как видно из листингов, до вызова метода println имя статического поля класса (System.out) и значение параметра (i) помещаются в стек операндов. Подробные сведения об инструкциях можно получить из спецификации JVM, но это выходит за рамки книги. Полезно познакомиться с инструкциями и их операндами, хотя мы и будем применять каркас, предоставляющий уровень абстракции над байт-кодом. Для инструментирования и генерации байт-кода необходимо программно строить наборы инструкций, поэтому хотя бы базовое понимание набора инструкций и его соответствия Java обязательно.

Теперь, когда вы научились модифицировать байт-код, можно сравнить этот приём с другими подходами к расширению возможностей во время выполнения. В главе 16, «Перехват потока управления», были представлены динамические заместители, позволяющие перехватывать методы любого интерфейса без статической реализации этого интерфейса. Хотя динамические заместители просто писать и легко использовать, их главный недостаток в том, что они работают только с интерфейсами, а не с классами, и требуют явного создания в вызывающем коде. Так, чтобы использовать динамический заместитель с Chat, нам пришлось вызвать метод setMessageListener() класса ChatServer и установить заместитель. Если бы исходного кода Chat не было, сделать это без декомпиляции не удалось бы. Изменять код приложения допустимо во время разработки, но это не подходит для стороннего кода или интеграции во время выполнения. В отличие от динамического заместителя, модификация байт-кода не требует менять модифицируемый код при компиляции.

AOP - развивающаяся технология добавления сквозных свойств объектам и методам - является чистым и хорошо структурированным дополнением к традиционному программированию. С помощью аспектов легко добавить такие возможности, как трассировка вызовов методов либо предварительная и последующая обработка. AOP чётко отделяет реализацию логики программы от инфраструктурных задач, например трассировки, профилирования, безопасности и прочих. Аспекты определяются в отдельных файлах, компилируемых и обрабатываемых вместе с кодом приложения. Реализации AOP используют инструментирование байт-кода для вставки дополнительного поведения. В этом они больше похожи на рассмотренную в главе модификацию байт-кода, чем на динамические заместители. AOP - высокоуровневый подход, которому недостаёт гибкости непосредственной инженерии байт-кода. Когда это уместно, аспекты могут быть самым простым способом добавить скрытую логику в существующее приложение.

1. По каким причинам манипулируют байт-кодом?

2. Что такое код операции и как операнды передаются инструкции байт-кода?

3. Как выглядел бы дескриптор метода Java с именем getCount(), объявленного как public Object[] getObjects(String name, char type)?

4. Из каких структур состоит файл класса?

5. Какие основные классы BCEL используются для инструментирования или генерации класса?

6. Какой атрибут метода необходимо изменить для инструментирования его байт-кода?

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

• Формат файла класса Java и допустимые инструкции определены спецификацией JVM.

• Логика каждого метода Java представлена набором примитивных инструкций JVM, являющихся базовыми командами и весьма похожих на машинный код.

• Двоичный формат файла класса представлен псевдоструктурами, определёнными в спецификации JVM и включающими данные о классе, полях, методах, атрибутах и других свойствах.

• Apache Byte Code Engineering Library (BCEL) предоставляет объектно-ориентированный API для работы со структурами и полями, из которых состоит класс.

• Инструментирование - это вставка нового байт-кода или дополнение существующего байт-кода класса.

• Зачем и когда исправлять машинный код

• Использование машинного кода в виртуальной машине Java

• Общие подходы к исправлению машинных методов

• Исправление машинного кода на платформе Windows

• Исправление машинного кода на платформах Unix

• Короткий тест

• Краткие итоги

Мы рассмотрели различные приёмы замены, исправления и обратной разработки классов Java. Все эти приёмы требуют работы на уровне исходного или байт-кода, поэтому ограничивают наши возможности высокоуровневым миром Java. Виртуальная машина Java (JVM) взаимодействует с операционной системой (ОС) посредством машинных библиотек, а значит, все низкоуровневые операции написаны не на Java и ими нельзя манипулировать представленными приёмами. Например, System.currentTimeMillis() является машинным методом, а все методы ClassLoader делегируют настоящее определение класса машинному методу defineClass0. Хотя исправить класс Java обычно проще и чище, в некоторых случаях остаётся только исправлять машинный код. В этой главе представлены несколько низкоуровневых приёмов исправления машинного кода, которые вместе с предыдущими приёмами дают полный контроль над JVM.

Прежде чем пачкать руки машинными исправлениями, я хотел бы отметить два важных момента. Первый касается законности предстоящей работы. Как уже говорилось в книге, вы сами обязаны проверить, не запрещены ли обратная разработка и исправление лицензионным соглашением продукта, с которым вы работаете. Кража чужой интеллектуальной собственности не только незаконна, но и неэтична, поэтому я настоятельно рекомендую применять представленные приёмы только с добрыми намерениями. Второй момент: работа с машинным кодом требует уверенного знания языка C, базового понимания машинных инструкций и знакомства с форматами двоичных файлов. На разных платформах двоичные файлы имеют разные форматы, и даже два разных компилятора могут создавать разные исполняемые файлы для одной платформы. Например, объектные файлы компилятора Microsoft C отличаются от файлов компилятора Borland C. Исправление двоичного кода требует вставлять машинные инструкции в существующий машинный код и манипулировать двоичным файлом. Это похоже на путешествие по неизведанным водам: будьте готовы к трудностям и не ожидайте, что всё заработает с первого раза. Отсутствие общего, чётко определённого формата и сложность работы с необработанными машинными инструкциями приводят к нехватке хороших инструментов, так сильно помогавших нам прежде. Например, ни один декомпилятор не способен получить код C из двоичного исполняемого файла.

Для этой главы требуются:

• понимание языка C;

• умение писать и компилировать машинные библиотеки для целевой платформы;

• базовое знание машинных инструкций и языка ассемблера;

• некоторое знакомство с машинным интерфейсом Java (JNI).

Исправлять двоичные файлы в мире Unix гораздо труднее, чем в Windows. Unix - разнообразная платформа с множеством аппаратных архитектур и программных стандартов, поэтому такие низкоуровневые задачи, как дизассемблирование исполняемого файла и редактирование машинного кода, требуют разных реализаций для разных архитектур. Например, к распространённым архитектурам процессоров Unix относятся SPARC в Sun Solaris, PA-RISC или Itanium в HP UX, RS/6000 или PPC в IBM AIX и Intel в Linux. У каждого процессора свой набор инструкций, поэтому двоичные файлы непереносимы между архитектурами. Это означает, что общего дизассемблера, преобразующего машинный код в ассемблер на всех платформах, нет. Для каждой платформы существуют бесплатные и коммерческие дизассемблеры, но их качество и удобство сильно различаются. Одна из лучших утилит - IDA Pro (datarescue.com), поддерживающая множество типов процессоров. Она работает только в Windows, но заявляет способность дизассемблировать двоичные файлы большинства распространённых аппаратных архитектур.

С программными стандартами положение ненамного лучше. Существует множество стандартов форматов исполняемых файлов, среди которых сегодня наиболее заметны Common Object File Format (COFF) и Executable and Linking Format (ELF). COFF традиционно использовался в системах Unix. У него есть ограничения и ему недостаёт гибкости, поэтому более современный ELF постепенно его заменяет. И COFF, и ELF подобны формату PE компании Microsoft. В таблице 18.2 показана высокоуровневая структура формата ELF с точки зрения связывания.

Таблица 18.2. Структура файла ELF

Исправление двоичных файлов требует чтения и записи. Работу с файлами ELF можно упростить библиотекой libelf. Она предоставляет набор высокоуровневых функций C для манипуляций с исполняемыми файлами, разделяемыми библиотеками, объектными и другими файлами формата ELF.

libelf доступна для Solaris, HP-UX, AIX и Linux; вероятнее всего, её можно найти и для других разновидностей Unix. Поскольку libelf является библиотекой общего назначения, она не предоставляет функций исправления, найденных нами в Microsoft Detours. libelf даёт удобный способ найти исправляемый код и обновить исполняемый файл изменениями, но вставлять ассемблерные инструкции и, возможно, реализовывать трамплин приходится вручную.

Подход к исправлению разделяемых библиотек Unix с машинным кодом совпадает с применённым в Windows. Необходимо найти и дизассемблировать машинный код целевой функции. Затем его можно перезаписать новым кодом или инструкцией JMP к новому коду. Новую логику можно также реализовать в разделяемой библиотеке, динамически загружаемой исправлением. Если сигнатура функции и соглашение о вызовах совпадают, параметры передаются и возврат происходит правильно. Для проектирования конкретного ассемблерного кода обратитесь к документации целевого процессора.

1. Какую роль JNI играет в архитектуре Java?

2. Какие этапы необходимо выполнить, чтобы реализовать и выполнить машинный метод?

3. Для каждого из трёх подходов к исправлению машинных методов перечислите достоинства и недостатки.

4. К какому разделу файла PE нужно обратиться, чтобы получить машинный код?

5. Почему Function Replacer не работает с машинными функциями, состоящими всего из нескольких машинных инструкций?

6. Можно ли при реализации отвода в ассемблерном коде передать управление исправлению инструкцией CALL вместо JMP? Объясните почему.

7. Какие преимущества предлагает библиотека Detours по сравнению с Function Replacer?

8. Какие форматы исполняемых файлов преобладают в Unix?

9. Как исправить машинную функцию в Unix?

• Исправление машинного кода даёт предельный контроль над JVM, поскольку позволяет изменять поведение на самом низком уровне. Оно основано на изучении двоичного формата библиотеки, поиске изменяемого машинного кода и его исправлении новой логикой.

• JNI - спецификация, описывающая определение машинных методов в Java и предоставление их реализации в машинных библиотеках.

• Машинные методы Java требуют разработать на языке C динамическую (разделяемую) библиотеку, загружаемую JVM во время выполнения.

• Самый простой подход к машинному исправлению - исправить объявляющий метод класс Java, удалить ключевое слово native и предоставить новую реализацию метода на Java.

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

• В Windows экспортируемую функцию одной DLL можно исправить экспортируемой функцией другой DLL с помощью такой утилиты, как Function Replacer. Она проста в использовании, но имеет ограничения и проблемы с надёжностью.

• Microsoft Detours - библиотека для работы с файлами PE на двоичном уровне и перехвата функций во время выполнения. Это надёжный и хорошо написанный каркас для ручного исправления в программах C.

• Исполняемые файлы Unix обычно соответствуют формату COFF или ELF. Общий подход к исправлению библиотек Unix подобен подходу Windows.

• libelf - широко используемая библиотека манипуляций исполняемыми файлами формата ELF в Unix.

• Постановка целей защиты приложения

• Защита данных с помощью архитектуры криптографии Java

• Защита дистрибутива приложения от взлома

• Реализация лицензирования для открытия функций приложения

• Короткий тест

• Краткие итоги

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

Обычное приложение Java поставляется как комплект (чаще всего в виде файла JAR или Zip, но иногда как исполняемая программа установки), содержащий библиотеки Java и машинные библиотеки, файлы конфигурации, документацию и различные файлы ресурсов. Сегодня принято бесплатно предлагать общественности версию программы без излишеств, а полный набор функций предоставлять только в лицензированных версиях. Другая стратегия привлечения потенциальных покупателей - ограниченный ознакомительный период с доступом ко всем функциям. После его окончания коммерческие функции приложения отключаются до покупки лицензии. Эту стратегию применяет Borland при распространении JBuilder X. Сначала он работает как 30-дневная ознакомительная версия Enterprise Edition, а затем превращается в JBuilder X Foundation с ограниченными возможностями. Многие поставщики корпоративного программного обеспечения бесплатно предлагают продукты для разработки или полагаются на честность пользователей и страх судебного преследования, побуждающий приобрести правильную лицензию. Какую бы модель лицензирования и распространения ни выбрал поставщик, он жизненно заинтересован собирать лицензионные платежи и получать выручку. Простые приёмы этой главы достаточно хорошо страхуют соблюдение модели лицензирования.

Важно понимать: добиться абсолютной защиты от хакеров практически невозможно, особенно если приложение можно загрузить из Интернета. Даже если самые сильные алгоритмы безопасности применяются для создания и шифрования конфиденциальных данных, например серийного номера, хороший хакер с доступом к приложению может исправить код проверки и полностью её обойти. В предыдущих главах показано, насколько легко находить и взламывать классы Java; если ставки высоки, можно вскрыть даже машинный код. Поэтому ключ успешного механизма защиты - сделать взлом слишком трудным для 95% обычных пользователей и заставить оставшиеся 5% опытных хакеров потратить на него значительное время. Иными словами, цель состоит в том, чтобы купить лицензию было дешевле, чем тратить время на взлом защиты. Ещё один жизненно важный аспект - предотвратить лёгкое распространение взломанных версий в Сети и не позволить хакерам выпускать собственные лицензии на продукт.

Начнём с основных сторон безопасности и криптографии. На примерах с API криптографии Java вы научитесь шифровать и расшифровывать сведения шифрами, защищать целостность данных свёрткой сообщения и реализовывать надёжный механизм лицензирования асимметричными парами ключей. Кроме этих мер мы рассмотрим несколько приёмов защиты основных файлов приложения от взлома и исправления.

1. Чем различаются алгоритмы свёртки сообщения, шифрования и подписания?

2. В чём разница между симметричными и асимметричными алгоритмами?

3. Как защитить содержимое электронного письма, отправляемого через Интернет? Какие классы JCE потребуются?

4. Какие меры можно принять для защиты содержимого приложения от взлома?

5. Мы использовали алгоритм свёртки для вычисления контрольной суммы файлов дистрибутива Chat. Стала бы контрольная сумма безопаснее при использовании симметричного или асимметричного алгоритма? Почему?

6. Какие логические шаги нужны для получения цифровой подписи симметричным алгоритмом?

7. Какие логические шаги нужны для получения цифровой подписи асимметричным алгоритмом?

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

• Шифрование - процесс кодирования читаемых сведений, а расшифрование - извлечение читаемых сведений из кода.

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

• Алгоритмы шифрования и расшифрования скрывают конфиденциальные сведения, которые может перехватить третья сторона. Содержимое изменяется секретным ключом, образуя результат, который без ключа практически невозможно вернуть в исходную форму.

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

• Архитектура криптографии Java (JCA) предоставляет полную и надёжную реализацию криптографических служб и алгоритмов.

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

• Большинство алгоритмов безопасности требует параметров, например пароля или ключей. Обычно они работают с двоичными данными.

• После обфускации байт-кода проверка целостности файлов дистрибутива - важнейшая мера защиты приложения от взлома.

• Самый эффективный способ реализовать лицензирование, открывающее коммерческие функции, - предоставить текстовый файл лицензии с цифровой подписью, созданной асимметричным алгоритмом.