Жанр: Учеба
Главы книги о взломе
Kris Kasperski 2:5063/61.8
Главы книги о взломе
Хаккеры
- Инструменты управления государством
всегда должны быть остро отточены и
готовы к употреблению. Власть держится
на страхе".
Ф. Херберт "Мессия Дюны"
За последние годы трактовка "хакер" сильно изменилась. Это в первую
очередь связано с появлением "хакерв-вандалов". Точнее совсем не хакеров,
в изначальном понимании этого слова, но называющими себя именно так.
Персонализация компьютера привела к тому, что доступ к последним получили
практически все желающие независимо от их возраста, наклонностей, уровня
знания и психологической уравновешенности.
Иными словами, если в высших учебных заведениях были (к сожалению
действительно, именно были) преимущественно люди культурные и образованные,
а на производствах по крайней мере по-просту серьезные, и любого вандала
легко было уволить, лишив его этим доступа к ЭВМ, то персональный компьютер
попадал в руки к самым разным людям.
Среди них были не только увлеченные фанаты, но и всевозможные маньяки.
К чему это привело мы как раз и наблюдаем сегодня. Компьютерный мир из
доброго сообщества быстро превратился в кальку нашего общества, где
незамкнутые ворота грозили грабежом, а за каждым темным углом мог стоять
человек с ножом.
Появились не только компьютерные воры, но и просто хулиганы, которым
приносило удовольствие доставлять пакость ближнему своему. Они уничтожали
информацию, блокировали компьютерные системы и писали так называемые
"троянские программы". Незащищенная персоналка оказалась питальной средой
для всех этих деяний. Но тогда еще никому и в голову не могла
придти мысль о разграничении доступа на однопользовательских маломощных
персональных компьютерах. Да и если бы она и пришла реализовать последнюю
без поддержки со стороны микропроцессора не предствалялось возможным.
Операнионная система просто не могла бы препятствовать обращению
прикладной задачи к портам ввода\вывода и своему коду. Из это следовало,
что злоумышленник мог как угодно модифицировать код операционной системы,
отключая все защитные механизмы или напрямую работать с оборудованием
уничтожая или модифицируя любые сектора на диске.
В то время компьютерный мир еще не знал ни вирусов, ни вандалов.
Сама Intel не верила, что ее процессоры будут использоваться в "серьезных"
машинах (уж слишком смехотворными казались их вычислительные способности).
Конечно, большой ошибкой со стороны IBM было продвигать ничем не защищенный
компьютер на рынок машин для среднего и малого бизнеса. Впрочем, в то время
никто не мог предствавить к чему в конечном счете приведет.
Парк IBM-совместимых машин стремительно рос и когда компьютерный мир
осознал какого он джина выпустил из бутылки, что-то менять стало уже
поздно. Ситуацию могла спасти только принципиально новая архитектура
оперционной системы и микропроцессора. Но в этом случае обесценилось все
существующие программное обеспение, а на такие жертры пойти никто не мог.
Впрочем со временем появились защищенные операционные системы типа
WINDOWS NT, но они не получили ожидаемой популярности именной по причинам
плохой совместимости с уже существующим программным обеспечением.
Большинство до сих пор работает на ничем не защищенной WINDOWS 95\WINDOWS
98. Впрочем, надо признать, что последняя хоть и с большим запозданием, но
все же имеет некоторые защитные механизмы, предотващающие некоторые
деструктивные действия. К сожалению последнее достигается ценой ухудшенной
совместимости. Многие программы могут не работать или работаь не правильно.
Действительно, в этом мире за все нужно платить.
Но оставим дискуссию о проблемме незащищенности "народной" операционной
системы WINDOWS 9x - словами горю не помощешь, и если вам требуется
безопасность, то переходите хотя бы на WINDOWS NT. Это не решит всех
проблемм, но по крайней мере позволит спать спокойно.
Рассмотрим причину всего этого - людей, умышленно пишущих деструктивные
программы и похищающих не принадлежащую им информацю. Какие же мотивы
толкают на это? Современная психология утверждает, что во всем виновата
жажда власти или превосходства над другими, что впрочем одно и то же.
Компьютерный вандал ну ничем ни отличается от уличного хулигана и причины
их поведения сходны - неудовлетворенность, агрессивность, озлобленность...
Таких людей можно только пожалеть. В какой-то мере именно общество
формирует последних. И именно оно же и пожинает плоды своих деяний. К
сожалению при этом страдают ни в чем невинные люди.
Компьютер позволяет ощутить превосходство над окружающими. Власть над
простыми пользователями, не спосбодными распозать и адекватно
прореагировать на зловредную программу кому-то доставляет изрядное
наслаждение.
К счастью подавляющие большинство последних обладают весьма смутными
познаниями в программировании и они бы не предстваляли никакой угрозы, не
будь пользователи так беспечны в отношении собственной безопасности. По
разным оценкам ущерб от вандалов составляет от 5 до 10 процентов от общего
числа случаев потери информации (при этом более 50% инцендентов происходит
по вине ошибок или неверных действий пользователя).
Последнее, кстати, служит отличным самооправданием для злоумышленников,
называющих себя "санитарами компьютерного леса". Они создают программы
наподобии "кракера интернета" (а на самом деле форматирующими жесткий
диск) и этим пытаются "лечить" так называемых "ламеров" (т.е.
низкоквалифицированных пользователей) от компьютерной глупости, а заодно и
жадности. Другими словами "компьтерный крестовый поход" во благо святого
дела.
Неграмотных пользователей конечно нужно учить, но не такими же приемами!
Бесполезность террора уже многократно доказана историей, но он с завидным
упорством вспыхивает не только в компьютерном, но к сожалению, и в реальном
мире. Очень маловероятно, что бы в течении ближайших ста лет хоть
что-нибудь изменилось. Проблемма вандалов (и не только компьютерных) не в
них самих, а в обществе, т.е. в нас всех.
Взломанные системы и отформатирование винчестеры это месть в никуда за
свою поломанную судьбу. Никакие законы, тюрьмы ничего не смогут изменить.
На место одно пойманного и наказанного вандала завтра придет десяток таких
же. Точнее не придет, а выпадет из оттолкнувшего их общества. Трудно судить
озлобленного и ожесточенного человека, садящегося после этого за
клавитатуру и пришущего злобного вируса, призваного наказать обидившее его
человечество.
Силой невозможно противостоять силе. И нетерпимсть окружающих к
вирусописателям и стремлениее "начистить последним функель" или
"разобраться" только подливает масла в огонь. Человек, отвечающий агрессией
на действя вирусописателя уже не может заслуживать жалости. Чем отличается
он, обиженный и готовый идти и избивать первого подозреваемого
вирусописателя не особо утруждая себя выяснением насколько тот виноват?
Фактически вандалов гораздо больше, и то что часть из них не пишет ни
вирусов, ни троянских программ - чистая случайность. Просто они еще не
дошли до этой грани, но может ли кто утвеждать, что этого не будет в
будущем? Очень сомнительно...
Нет, я не собираюсь здесь никого оправдывать, но всем своим авторитетом
призываю остановится и не вершить самосуд, а просто внимательнее относится
ко всем проходящим через ваши руки програмам. Альтруизм, конечно, не
наставит вирусописателя на путь истинный, но по крайней мере не породит
новой агрессии и новых злоумышленников. Вообще вандализм всега имеет
глубокие социально-писихологиские корни и прична озлобленности на общество
у каждого своя.
Невозможно повести ни какого обобщения. Каджый случай требует
отдельного рассмотрения. Человеком могут двигать разные мотивы а не только
месть. Быть может он одинок и хочет внимания, которому ему так не хватает?
Конечно, садится и писать вредоносные программы это не выход, но не
забывайте, что разговор идет о людях с тем или иными психическими
отклонениями, в которых они сами ни в чем ни виноваты.
Исправить вандалов невозможно. Можно перевосписать (или проще сломать
- чем и занимается Евгений Касперский с особо "доставшими" его
вирусописателями) одного человека, но ведь на его место завта придет
другой. Вандалы - это следствие болезни нашего общества и только исправляя
последнее можно добиться хоть каких-то результатов. Пока же мы боремся не с
причиной, а со следствем. На ум приходит извествных анекдот "бороться с
коммунистической партией под ее руководством".
В самом деле компьютерные преступники как это не парадоксально, но
принесли больше пользы, чем вреда и в экономическом и социальном плане. Они
обеспечили рабочие места специалистам по антивирусам и вообще компьютерной
безопасности. При этом оборот компьютерынх фирм неизмеримо превысл убытки
от вирусных атак. Вандалы стали приносить ошутимый доход и оказалсь в
самом деле весьма полезными. Забавно, но при этом на борьбу с ними ни у
кого до сих пор не находится денег.
К счастью человеку довльно скоро надоедает делать мелкие пакости
окружающим. При этом одни просто "уходят со сцены", но есть и такие,
которые отваживаются на глубокое изучение тонкостей операцинных систем,
компьютерного "железа", криптографии, математики с тем, что бы проникать в
действительно хорошо защищенные системы, писать сложно-шифруемые вирусы, т.
е. иными словами наносить уже значительный и крупномашстабнй вред. При этом
мы сталкиваемся с таки интересным явлением как "воспитание образоанием".
Образование неразрывно связано с культурой и духовым
воспитанием. При этом человек заметно добреет и мстить никому уже не
хочется. К сожалению, он все еще остается духовно искалечен и от объявления
войны обществу его отделяет очень тонкая грань, которую он может в любую
секнуду перешагнуть.
Могу с полной отвественностью заявить, что просто чудо, что до сих пор
такого инцедента еще не произошло. Впрочем, оно и понятно, знания дают
чувство уверенности в себе и стремление что-то кому-то доказывать пропадает
само собой.
Все сказанное выше навряд ли относится к хакерам - по определению
профессионалам. Среди последних за редкими исключениями практически не
встречается вандалов или злых шутников. Однако, профессионалами не
рождаются ими становятся. При этом немногим удается избежать "вирусной
болезни" в смысле увлечения написанием вирусов. Впрочем, написание еще не
подразумевает распространения.
Ну а мелким кракерстом занимаются почти все. Действительно, на
некотором этапе изучаения ассемблера и системного программирования трудно
найти более достойное применение своим знаниям. Для серьезных вещей еще не
хватает мастрерства, а текстовой редактор большинству писать все же скучно.
Впрочем, вреда от таких экспериментов было немного, если он вообще и был. В
вирусах оказалось действительно что-то притягательное. Конечно,
спекулятивно считать их хоть каким-то подобием живого огранизма, но зато
писать очень и очень интересно.
То же самое можно сказать и о взломе программ. И в том и другом случае
многих сознательно или подсознательно привлекает власть. Вряд ли последнее
утверждение нуждается в поясннении.
Kris Kasperski 2:5063/61.8 13 Mar 99 15:16:00
Очередной фрагмент из книги
Отречение: за неимением времени я предоставляю неотредактированный
вариант главы "Логическая защита\ограничение возможностей". Прошу извинить,
если допушенные ошибки кого-то раздражают. Все претензии высказывать на
KPNC@Null.ru конструктивые предложения KPNC@Usa.net
ОГРАНИЧЕНИЕ ВОЗМОЖНОСТЕЙ
Многие незарегестрированные версии отличаются тем, что часть
возможностей последних заблокирована. Если программа предусматривает
регистрацию, то обычно больших проблемм при взломе не возникает. Совсем
другое дело, когда регистация не предусмотрена и в наше распоряжения дана
DEMO-версия с ограниченными возможносями. Иначе говоря есть две программы,
никак не связанные между собой - полная и демонстационная версия. Строго
говоря, очень верятно, что взлом последней окажется невозможным, поскольку
код, выполняющий некоторые функции, в программе физически отсутствует.
Часто это оказывается безнадежным, но не всегда. Если нет никаких
других путей для получения легальной копии (например, ее автор
имигрировал в Штаты или запросил такое колличество денег, за которые лучшее
ее самому написатть), то можно решиться на такой отваждый шаг, как
воссоздать самостоятельно недостающий код. Это сложный и трудоемкий
процесс, требующий тщательного изучения алгоритма взаимодействия остального
кода с остутствующим.
Однако, чаще всего код все же физически присутствует, но просто не
получает управления. Например, просто заблокированы некоторые пункты меню,
как в file://CD/SRC/CRACK0D/Crack0D.exe Такое действительно встречается
очень часто и легко программируется. Все что нужно сделать программисту это
в редакторе ресурсов пометить некоторые элементы управления или меню как
'Disabled'. Но все что просто делается, так же просто и ломается.
Необходимо воспользоваться любым редактором ресурсорв. Я предпочитаю
пользоваться 'Symantex ResourceStudio 1.0', однако неплохо подойдет и любой
другой. Загрузим в него наш файл. Дальнейшие действия зависият от
интерфейса выбранной программы, и не должны вызвать затруднений, за
исключением тех ситуаций, когда выбранный редактор не поддерживает
используемого формата ресурсов или некоректно работает с ними. Например, с
помощью Borland Resource WorkShop мне так и не удалось выполнить эту
операцию. Он необратимо портил ресурс диалога, хотя с разблокированем меню
справился отлично.
Что бы разблокировать элементы управления или меню, необходимо вызвать
свойства объекта и снять пометку 'Disabled' или 'Grayed', после чего
сохранить изменения. Запустим программу, что бы проверить нашу работу.
Получилось! Не исправив ни одного байта кода и даже не прибегая к помощи
дизассемблера и отладчика мы вломали это!
Удивительно, что такие защиты до сих пор существуют и не так уж и
редко встречаются. Психология разработчиков это воистину великая тайна.
Очень трудно понять на что они расчитывают. Однако, некоторые уже, видимо,
начинают догадываться, что нет ничего проще и приятнее, чем редактировать
ресурсы в исполняемом файле, поэтому прибегают к явным вызовам API типа
EnableWindow(false). Т.е. блокируют элементы управления непосредственно во
время работы. Разумеется, можно перехватить этот вызов отладчикам и удалить
защитный код. Именно так и поступит любой хакер и даже кракер. Рядовой же
пользователь остановит свой выбор на программе, подобной Customizer,
которая позволяет "налету" менять свойства любого окна, а в последствии
делать это и автоматически.
Таким образом необходимо усилить реализацию защиты, так что бы ее
вскрытие не было доступно широкому кругу пользователей. Достаточно ввести
некоторую перемнную типа 'Registered' и проверять при нажатии на кнопку ее
значение. Если Registered равна нулю, а пользователь каким-то загадочным
образом все же ухитрился нажать заблокированную кнопку, то повторно
блокируем кнопку или завершаем работу, мотивируя это несанкционированныи
действиями пользовтеля.
Например, именно так и реализована защита в crack0E. Откроем файл
редактором ресурсов и убедимся, что все элементы разблокиpованы.
Выключаются они позже, на стадии иницилизации диалога, функциями API.
Поробуем разблокировать их инструментом типа customizer-а. С первого
взгляда кажется, что это сработало. Но попробуем нажать кнопку "hello".
Защита сообщает о незарегистрированной версии и вновь блокирует кнопку.
Для простого пользователя такой барьер можно уже считать непреодалимым.
Однако, для знакомых с ассемблером и отладчиком, нет ничего трудного
нейтрализовать подобную защиту.
Обратимся к MSDN и введем в строке поиска "Disable Window". Среди
полученных функций будет только одна, непосредственно относящиеся к win32
API - EnableWindow. Можно загрузить отладчик и установить на последнюю
точку останова или поискать перекресные ссылки на нее же в дизассемблере.
Но этому я, надеюсь, уже научил читателя. Давайте усложним себе задачу и
попробует обойтись без этих чудес прогресса. В конечном счете гораздо
интереснее работать головой, чем техникой.
Очевидно, что сообщение "Это незарегистрировнная копия" выдает защитный
механизм. Для этого он должен передать поцедуре AfxMessageBox смещение этой
строки. Разумеется речь идет о смещении в памяти, а не в файле. Однако для
PE файлов его легко узнать, например, с помощью HIEW. Эта утилита
единственная из всех мне известных шестнадцатиричных редкторов, позволяющая
просматривать локальные смещения для PE файлов.
Находим строку "Это незарегестрированная копия", не забыв сменить
кодировку, и переключаем Hiew в режим отображения локальных смещений. В
нашем случаи это будет 0х00403030. Не забывая про обратный порядок
байтов в слове, ищем последовательность '30 30 40 00'. Если все сделать
правильно, то получии только одно вхождение. Дизассемблируем прямо в hiew-е
найденный код:
.00401547: 8B4660 mov eax,[esi][00060]
.0040154A: 85C0 test eax,eax
.0040154C: 7516 jne .000401564 -------- (1)
.0040154E: 6830304000 push 000403030 ;" @00"
^^^^^^^^^
.00401553: E8C2020000 call .00040181A -------- (2)
.00401558: 6A00 push 000
.0040155A: 8D4E64 lea ecx,[esi][00064]
.0040155D: E8B2020000 call .000401814 -------- (3)
.00401562: 5E pop esi
.00401563: C3 retn
Обратим внимание на условный переход. Несомненно, он ведет к нужной нам
ветке программы. Однако, не будем спешить его изменять. Это нам ничего не
даст. Все элементы останутся по-прежнему заблокированными, и нажать на них
мышкой не будет никакой возможности. Можно, конечно, найти соответствующие
вызовы WindowEnable, но это утимительно и не гарантирует того, что хотя бы
один мы не пропустим.
Найдем перемнную, которая управляет выполнением программы. Очевидно,
что [esi+0x060] это она и есть. Необходимо найти код, который управляет ее
значением. Если его изменить на противоположное, то программа автоматически
зарегистрируется.
Давайте сделаем смелый шаг, предположим, что esi указывает на экземпляр
класса и переменная иницилизируется в этом же классе. Тогда любой код,
манипулирующий с ней, будет адресоваться аналогичным образом. На самом деле
это действительно смелый шаг, потому что никто нам не гарантирует, что не
будет иначе, особенно для оптимизирующих компиляторов. Однако, это
настольно часто срабатывает, что нет нужды искать другие пути, пока не
попробывать этот. В худшем случае мы ничего не найдем или получим ложные
срабатывания.
На этот раз, нам везет и hiew выдает следующий любопытный фрагмент:
.004013D3: 8B4C240C mov ecx,[esp][0000C]
.004013D7: C7466000000000 mov d,[esi][00060],00000
.004013DE: 5F pop edi
Это есть ни что иное, что самое сердце защиты. Обратите внимание, что
приложение не предусматирает явной регистрации. Переменная иницилизируется
одним и темже значением, ни от чего не зависящим. Т.е. демонстационная и
коммерческая версии это по сути дела разные программы. Но, отличающиеся
всего одним байтом. Попродуем присвоить этой переменной ненудевое значение-
.004013D7: C7466000000000 mov d,[esi][00060],00001
И перезапустим программу. Это сработало! Нам не пришлось даже
анализировать алгоритм защиты. Изменив только один байт (перемнную-флаг)
остальное мы возложили на плечи самой защиты. Ни в коем случае нельзя
сказать, что мы нейтрализовали или модифицировали ее. Разумеется нет.
Защита все еще жива и коректно функционирует.
Однако, изменив флаг, мы ввели ее в заблуждение и заставили нас
признать зарегистрированными пользователями. Это довольно универсальный
и широко распростаненный способ. Гораздо легче передать защите поддельные
вхдные данные, чем анализировать много килобайт кода в поисках ее
фрагментов, разбросанных по всей программе.
Впрочем, разработчики далеко не всегда ограничиваются одним флагом.
Таких перемнных может быть несколько, и одна не обязательно будет связана с
другой. Это усложнит задачу взломщика, особенно если защита проверяет, что
бы все флаги были идентичны. Тогда не остается ничего, кроме тщательного
анализа. В худщих реализациях бывает, что несоответствие флагов регистрации
не приводит к вызову сообщений об ошибках, а искажению алгоритма работы
таким образом, что программа внешне работает, но работает неправильно.
Это может выглядеть так.
return SomeResult*(!FlagReg1 ^ FlagReg2);
Если два флага не равны друг другу, то в реультате получится ноль!
Функция вернет неверный результат. Если такое, например, случится в
программе расчета зарплаты, то последствия не заставят себя ждать. Самое
печальное, что флаги регистрации могут одновременно являтся и рабочими
переменными программы. Обычно при этом флагу выделяют младший бит, а все
остальное под нужды какой-нибудь функции. Тогда без тщательного анализа
всего кода невозможно быть уверенным, приложение функционирует коректно.
К счастью, программисты часто оказыаются слишком ленивы, что бы
детально проработать эту архитектуру. И рождат перлы типа Crack0F.
Рассмотрим этот защитный механизм. Перед нами две заблокированных кнопки.
Очевидно, для локализации защиты, нужно найти вызовы EnableWindow.
j_?EnableWindow@CWnd@@QAEHH@Z proc near ; CODE XREF: sub_0_401360+D4.p
; .text:004015CF.p
jmp ds:?EnableWindow@CWnd@@QAEHH@Z
j_?EnableWindow@CWnd@@QAEHH@Z endp
Их всего два. Как раз по числу элементов упавления. Пока защита не
предвещает ничего необычного и ее код выглядит вполне типично:
.text:0040142A mov eax, [esi+68h]
.text:0040142D lea ecx, [esi+0ACh]
.text:00401433 push eax
.text:00401434 call j_?EnableWindow@CWnd@@QAEHH@Z ;
и аналогично другой фрагмент:
.text:004015C8 mov eax, [esi+60h]
.text:004015CB lea ecx, [esi+6Ch]
.text:004015CE push eax
.text:004015CF call j_?EnableWindow@CWnd@@QAEHH@Z ;
Попробуем найти, как уже было показано выше, '46 60', т.е. [esi+60] и '46
68'- [esi+68]. Полученный результат должен выглядеть следующим образом -
.00401385: C7466001000000 mov d,[esi][00060],000000000
и
.004012CC: C7466801000000 mov d,[esi][00068],000000000
Кажется, что защита использует два независимых флага. С первого взгяда
их нетрудно и изменить на ненулевое значение. Ожидается, что это заставит
защиту работать. ну чтож, попытаемся это сделать.
Как будто-бы все работает, не правда-ли? Но попробует нажать на левую
кнопку:
--------------------¬
+ ¦
¦ ¦
¦ ¦
¦ ¦
¦ ¦
¦ ¦
¦ ¦
¦ рисунок pe ¦
L--------------------
Пустой диалог выглядит странно, не так ли? Похоже, что защита взломана
некоректно и приложение работает неверно. И дело не только в том, что
сложно найти то место, где код ведет себя неправильно (это не так уж и
проблематично по большому счету). Главная сложность убедится в
работоспособности (неработоспособности программы). В данном примере это
тривиальная задача, но она не будет такой в банковских, научных, инженерных
приложениях. Если неправильно работает только одна редко вызываемая ветка,
то тестирование поломанного приложения дело безнадежное.
Однако, разработчики защит часто упускают из виду, что компилятор мог
расположить все флаги близко от друг друга, значительно упрощая кракеру
поиск. В самом деле, в нашем примере фигурируют две перемнные типа DWORD -
[esi+60] и [esi+68]. Нетрудно заметить, что между ними образовалась "дырка"
ровно в двойное слово. Может быть эта переменная - еще один флаг защиты?
Попробуем найти '46 64':
.004015B3: C7466400000000 mov d,[esi][00064],000000000
Что будет если ноль заменить на единицу? Попробуем, и... сработало!
Ранее пустой диалог теперь приветствует нас "Hell0, Sailor!". Защита пала!
Очевидно, что разработчик использовал по крайней мере три флага и
конструкц
...Поділитися у соцмережах
