|
Реферат: Неполадки при загрузке Windows и их устранение. Загрузочная дискета (Программирование)
Министерство образования Российской Федерации
Магнитогорский Государственный Технический Университет им. Г.И. Носова
Кафедра вычислительной техники и прикладной математики
Индивидуальная работа
по теме «Неисправности при загрузке Windows. Загрузочная дискета»
Выполнил: студент группы АМ–01–2 Фасхутдинов Д.Д.
Проверил: старший преподаватель Ильина Е.А.
Магнитогорск
2003
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 2
ОСНОВНАЯ ЧАСТЬ 3
Диагностика проблем, возникающих на этапе загрузки 3
Проблемы, возникающие до появления экрана загрузчика 3
Предупреждение 4
Примечание 4
Устранение проблем с системным разделом 5
Примечание 5
Устранение проблем с главной загрузочной записью 5
Устранение проблем с загрузочным сектором раздела 6
Проблемы CMOS 7
Аппаратные проблемы 8
Проблемы, возникающие после запуска загрузчика 9
Использование отладочной версии Ntdetect 9
Загрузка ОС Windows 10
ЗАКЛЮЧЕНИЕ 14
ВВЕДЕНИЕ
Существует целый ряд причин, по которым компьютер не может успешно
выполнить загрузку. Первый шаг в их выявлении – определение времени
возникновения проблемы. Например, если на компьютерах х86 проблема
возникает до появления экрана загрузчика, то причиной ее возникновения
может быть как аппаратный сбой, так и повреждение главной загрузочной
записи, таблицы разделов или загрузочного сектора раздела.
К таким повреждениям может привести ряд факторов. Например, на
компьютерах х86 прерывание BIOS INT 13 часто используется вирусами для
самоинсталляции. Windows перехватывает прерывания INT 13, но только в том
случае, когда она уже загрузилась. Если компьютер загрузить с помощью
системной дискеты MS-DOS, а также в том случае, когда система с двойной
загрузкой загружается под управлением MS-DOS, Windows NT/2000 не может
защитить себя от такой угрозы. В Microsoft Knowledge Base есть ряд статей с
рекомендациями по защите компьютера от вирусов и описанием методов
восстановления системы, поврежденной вирусами.
ОСНОВНАЯ ЧАСТЬ
Диагностика проблем, возникающих на этапе загрузки
Здесь обсуждаются действия, которые можно предпринять для выяснения
причин, не препятствующих загрузке системы Windows. Далее будут кратко
рассмотрены ситуации, когда компьютер «зависает» или отображает сообщение
об ошибке прежде, чем пользователь получает возможность зайти в систему.
Помимо этого будут перечислены возможные причины возникновения проблем с
диском и пути устранения этих неполадок.
Если проблема возникает уже после появления меню загрузчика и выбора в
нем Windows 2000, то причина может быть в том, что файлы, необходимые для
загрузки операционной системы, отсутствуют или повреждены.
В случае инсталляции новых физических устройств или новых драйверов
причиной проблем с загрузкой системы могут быть изменение конфигурации
системы и ее несовместимость с этими устройствами или драйверами!
Проблемы, возникающие до появления экрана загрузчика
Здесь описаны проблемы, которые могут возникнуть на этапе между включением
компьютера и появлением экрана загрузчика. Их симптомы:
. Сразу после завершения фазы самотестирования (POST) компьютер
«зависает»
. Экран загрузчика не появляется
. На экране появляются сообщения об ошибках следующего типа:
. Missing operating system (Отсутствует операционная система)
. A disk read error occurred (Ошибка чтения диска)
. Insert a system diskette and restart the system (Вставьте системную
дискету и перезагрузите систему)
. invalid partition table (Неверная таблица разделов)
. Hard Disk Error (Ошибка жесткого диска)
. Hard Disk Absent/Failed (Жесткий диск отсутствует/отказал)
Вполне возможно, что в этой ситуации запустить компьютер вообще не
удастся. Если все основные разделы отформатированы для использования
файловой системы NTFS, то применение утилит MS-DOS не поможет. Если у вас
под рукой есть загрузочная дискета Windows, попробуйте воспользоваться этой
дискетой. Если вы не можете запустить компьютер с помощью загрузочной
дискеты Windows, и восстановление системы с помощью диска аварийного
восстановления не помогло решить проблему, попробуй снять жесткий диск и
установить его вторым диском на другом компьютере. После этого вы сможете
работать с этим диском, использовать утилиты Windows.
Предупреждение
Перемещать диски с компьютера на компьютер не рекомендуется, поскольку
при этом могут возникнуть проблемы с различием аппаратных конфигураций.
Однако если два компьютера идентичны, то вы сможете обнаружить и, возможно,
решить проблему.
Описанные выше проблемы могут возникнуть по одной из следующих причин:
. Отсутствие системного раздела на первом жестком диске
. Повреждена главная загрузочная запись
. Поврежден загрузочный сектор раздела
. Испортилась микросхема CMOS (или разрядилась ее батарея)
. Аппаратный сбой
Примечание
Если по каким-то причинам на диске отсутствует файл Boot.ini, но какая-то
система (при наличии нескольких систем) инсталлирована в каталог по
умолчанию, т. е. C:Winnt, загрузка этой системы все-таки произойдет.
Устранение проблем с системным разделом
Когда на компьютерах х86 выполняется загрузка с жесткого диска,
системный код BIOS определяет загрузочный диск (обычно, диск 0) и считывает
главную загрузочную запись. Код, содержащийся в главной загрузочной записи,
ищет системный раздел на жестком диске. Если он не может найти системный
раздел или Windows не может стартовать из этого раздела, процесс запуска
останавливается. Появление сообщения об ошибке типа "Error loading
operating system" указывает, что код главной загрузочной записи нашел
системный раздел, но не может запустить операционную систему.
Возможно, что на жестком диске, с которого вы пытаетесь загрузить
операционную систему, вообще нет системного раздела. Кроме того, не
исключена ситуация, когда в качестве системного указан другой раздел.
Примечание
Системный раздел — это основной раздел на загрузочном диске (как
правило, диск 0), индикатор загрузки которого (Boot Indicator) установлен в
значение 0x80. Этот раздел содержит файлы, необходимые для загрузки Windows
(такие, как NTLDR, Ntdetect.com и Boot.ini).
Утилита Fdisk показывает системный раздел как активный (active
partition).
В качестве системного раздела может использоваться только основной
раздел. Логический диск в дополнительном разделе для этой цели использовать
нельзя. Установить новый системный раздел можно с помощью оснастки
Управление дисками (Disk Management) в Windows 2000, программы Windows 4.0
Disk Administrator или с помощью программы MS-DOS Fdisk. Все эти программы
устанавливают поле Boot Indicator для раздела, который устанавливается как
системный, и сбрасывают это поле для раздела, который был системным ранее.
Устранение проблем с главной загрузочной записью
Здесь описаны проблемы с главной загрузочной записью. Функции кода
главной загрузочной записи:
. Считывание таблицы разделов, расположенной в том же секторе
. Определение местоположения загрузочного сектора раздела
. Загрузка и выполнение кода, расположенного в загрузочном секторе
раздела
Если код главной загрузочной записи оказывается не в состоянии выполнить
эти задачи, отображается одно из следующих сообщений об ошибках:
. Missing operating system (Отсутствует операционная система)
. invalid partition table (Неверная таблица разделов)
Для восстановления поврежденной главной загрузочной записи можно
воспользоваться командной консолью восстановления Windows 2000 (Recovery
Console), которая позволяет выполнять многие административные задачи и
восстановительные операции. Запускать консоль восстановления можно из
программы установки Windows 2000 или включить ее в качестве одной из опций
в меню загрузки.
Устранение проблем с загрузочным сектором раздела
Существует несколько известных вирусов, способных вызывать проблемы с
загрузочным сектором раздела даже тогда, когда том отформатирован для
использования файловой системы NTFS. Заражение может произойти при запуске
программы MS-DOS с дискеты или при запуске MS-DOS на компьютере с двойной
загрузкой. Windows 2000 не может защититься от заражения, если она не
запущена.
В ряде случаев повреждение загрузочного сектора раздела может привести
к генерации следующей ошибки типа "синий экран": STOP ОхООООООУВ
INACCESSIBLE_BOOT_DEVICE. Еще одним симптомом проблем с загрузочным
сектором раздела является "зависание" компьютера в процессе загрузки без
отображения каких-либо сообщений, при этом экран остается черным.
Даже при условии отсутствия очевидных грубых повреждений загрузочный
сектор раздела может работать неправильно. Убедиться в этом можно следующим
образом. Попробуйте переименовать файл NTLDR и запустить Windows с этого
жесткого диска (это можно сделать, загрузив систему с дискеты Windows).
Если загрузочный сектор раздела в норме, а причина неудачи —
поврежденный файл загрузчика NTLDR, то в основном разделе NTFS вы увидите
следующее сообщение об ошибке:
Couldn't find NTLDR
В основном разделе FAT вы увидите сообщение об ошибке:
A kernel file is missing from the disk
Если, заменив имя NTLDR, вы таких сообщений об ошибках не получите,
это будет говорить о том, что причина кроется в повреждении загрузочного
сектора раздела. Не забудьте переименовать файл загрузчика обратно в NTLDR,
чтобы загрузочный сектор раздела мог его найти.
Как правило, файл NTLDR по умолчанию имеет атрибуты скрытый, системный
и только чтение. Поскольку запустить Windows при испорченном загрузочном
секторе в загрузочном разделе невозможно, можно запустить MS-DOS с
загрузочной дискеты MS-DOS. Загрузив MS-DOS, можно изменить атрибуты файла
(только на диске с FAT!). Для этой цели необходимо в командной строке MS-
DOS ввести следующую команду:
Attrib –s –h –r ntldr
Проблемы CMOS
Как правило, CMOS хранит следующую информацию:
. Дата и время
. Тип дисковода для гибких дискет
. Тип видеоадаптера
. Тип жесткого диска (дисков)
. Объем установленной памяти
Каждый производитель BIOS принимает решение о стандартных
конфигурациях, а также задает параметры, которые пользователь может
устанавливать самостоятельно. Доступ к программе конфигурирования CMOS
можно получить через специальную утилиту или путем нажатия
последовательности клавиш в процессе загрузки компьютера (эти опции зависят
от поставщика). Информацию, содержащуюся в CMOS, необходимо записывать (или
распечатать, если программа Setup позволяет это делать).
Компьютер использует контрольные суммы CMOS, чтобы определить, не
изменялись ли значения CMOS иначе, чем через программу Setup. Если
контрольная сумма окажется неверной, компьютер не загрузится.
Если информация CMOS корректно сконфигурирована, то возможные проблемы
CMOS могут быть вызваны следующими причинами:
. Слабая батарея (это бывает, если компьютер долго не включали)
. CMOS и батарея не соединены, соединены некачественно или неправильно
. Микросхема CMOS повреждена разрядом статического электричества
Все эти проблемы могут вызвать обнуление CMOS или иное повреждение
информации, что может не позволить загрузить компьютер.
Аппаратные проблемы
Если устройство не инициализируется во время самотестирования при
загрузке (POST), то возможны проблемы с доступом к этому устройству. Если
устройство было добавлено или модифицировано при предыдущем запуске
системы, то проблема может быть вызвана новой конфигурацией системы.
Если вы вносили изменения в конфигурацию дисковой подсистемы,
необходимо обратить внимание на следующее:
. Правильность установки терминаторов на SCSI-шлейфах
. BIOS активизирована только на первом контроллере SCSI (если вообще
активизирована)
. Отсутствие конфликтов по IRQ
Если вы не вносили никаких изменений, проверьте следующее:
. Правильность установки карт контроллеров
. Правильность подключения всех кабелей
. Питание подается на все диски
Проблемы, возникающие после запуска загрузчика
Здесь описаны проблемы, возникающие после запуска загрузчика
операционной системы, но до регистрации в системе пользователя. Эта фаза
процесса запуска начинается, когда на черном экране появляется строка
точек.
Использование отладочной версии Ntdetect
На компьютерах х86 Ntdetect осуществляет распознавание установленных
аппаратных компонентов.
Windows 2000 Resource Kit содержит отладочную (checked) версию
Ntdetect.coiJ
которая называется Ntdetect.chk. Если Ntdetect.com не может обнаружить
все аппаратные устройства, которые он, по вашему мнению, должен находить,
вы можете использовать отладочную версию, которая поможет локализовать
проблему.
Отладочная версия устанавливается с помощью файла Installd.cmd,
которая выполняет следующие действия:
. переименовывает стандартный Ntdetect.com
. копирует Ntdetect.chk в Ntdetect.com
После выполнения этих операций нужно перезагрузить компьютер.
При запуске системы с отладочной версией Ntdetect на экране будет
появляться информация обо всех обнаруживаемых аппаратных средствах. Ни
приведен типичный пример этого вывода на экран:
Detecting System Component ...
Reading BIOS Date ...
Done Reading BIOS Date (1/20/94) Detecting Bus/Adapter Component ...
Collecting Disk Geometry ... Detecting Keyboard Component . . .
Когда Ntdetect завершит вывод информации на экран, нажмите клавишу
для продолжения. Ntdetect отобразит информацию об узлах дерева
аппаратных устройств. Для завершения вывода каждого информационного экрана
необходимо нажимать клавишу .
Когда необходимость в использовании отладочной версии Ntdetect
отпадает, выполните команду installd /not.
Загрузка ОС Windows
Для загрузки ОС Windows необходимы следующие файлы: io.sys;
command.com, system.ini; win.ini; файлы реестра system.dat; user.dat. Файлы
msdos.sys, config.sys и autoexec.bat требуются только для специфического
конфигурирования ОС, и Windows может обходиться и без них. Все эти файлы
грамотный необходимо регулярно сохранять в специально отведенной для
резервного копирования папке (только в этом случае можно практически без
усилий, воспользовавшись системной дискетой, восстановить сбившиеся
настройки).
Далее будут считаны некоторые параметры из системного реестра,
проанализированы аппаратные средства компьютера.
Затем последует исполнение инструкций файла config.sys, расположенного
в корневой директории системного диска. Этот файл предназначен для задания
некоторых ключевых системных параметров и загрузки драйверов реального
режима. Он также является обычным текстовым файлом, поэтому для его
редактирования достаточно обычного текстового редактора, хотя в Windows 98
появилась и гораздо более удобная и безопасная утилита для редактирования
основных конфигурационных файлов – «Программа настройки системы»
(msconfig.exe).
Главное преимущество этой утилиты в том, что в ней предусмотрена
возможность отмены ошибочно введенных изменений. Необрабатываемые
комментарии в config.sys также начинаются с точки с запятой либо со слова
«rem». Но, по большому счету, файл этот операционной системе не очень-то и
нужен, так как все необходимые Windows параметры задаются автоматически еще
на этапе загрузки файла io.sys. В нем содержатся все нужные системе
параметры, используемые в том случае, если в config.sys явно не прописаны
альтернативные установки. Получается, что ОС Windows сама загружает по
умолчанию следующий набор параметров (табл. 1).
Таблица 1
Команды файла config.sys, загружаемые по умолчанию
|Параметр |Выполнение |
|device=c:windowshimem.sys |Драйвер обеспечивает доступ к |
| |расширенной и верхней памяти |
|device=c:windowsifshlp.sys |Драйвер поддержки файловых систем, |
| |без него Windows обычно не может |
| |загрузиться |
|Device=c:windowssetver.exe |Драйвер нужен для того, чтобы |
| |устаревшие приложения не |
| |отказывались работать с современными|
| |реализациями MS-DOS - на запрос |
| |старой программы он отвечает, что |
| |установлена именно та версия MS-DOS,|
| |которая ей нужна |
|fileshigh=30 |Максимальное количество одновременно|
| |открытых файлов, для многих |
| |DOS-программ требуется увеличить это|
| |значение до 100 |
|lastdrivehich=z |Последняя буква, которую можно |
| |использовать для обозначения дисков |
|buffershigh=30 |Количество буферов дискового |
| |ввода-вывода |
|Stackshigh=9,256 |Количество и размер стеков, |
| |предназначенных для временного |
| |хранения различной системной |
| |информации |
|shell=command.com /p |Путь и параметры используемого |
| |командного интерпретатора |
|fcbshigh=4 |Количество блоков управления |
| |файлами, необходимых старым |
| |DOS-программам |
Все эти параметры и драйвера загружаются, даже если config.sys их не
содержит. Значения, задаваемые командами files, lastdrive, buffers, stacks,
fcbs, и драйвер setver.exe нужны только приложениям MS-DOS. Хотя
параметров, команд и драйверов, задаваемых через config.sys, очень много,
чаще всего этот файл используется для загрузки каких-либо специфичных DOS-
драйверов.
В Windows 98 файл config.sys позволяет создавать меню
мультиконфигурации (при каждой загрузке можно выбирать нужные в данный
конкретный момент параметры), а также соответствующую этим параметрам ветвь
в файле autoexec.bat, что просто незаменимо для тех, кто часто использует
MS-DOS - получается очень гибкая и удобная система.
После обработки config.sys в Windows 98 загружается командный
интерпретатор command.com - программа, отвечающая, например, за такие
задачи, как прием и выполнение команд; выполнение пакетных файлов (с
расширением .bat); загрузка в память DOS-программ. По умолчанию
используется command.com, находящийся в корневой директории системного
диска, хотя с помощью команды shell в config.sys можно задать любой путь к
этому файлу. Файл этот тоже легко восстанавливается командой sys С: после
загрузки ПК с дискеты.
С помощью только что загруженного command.com обрабатывается файл
autoexec.bat, предназначенный для запуска резидентных DOS-программ, для
выполнения каких-либо команд или установки некоторых системных параметров.
Как и config.sys, файл autoexec.bat не является жизненно необходимым для
Windows, поскольку все, что нужно операционной системе, задается в
встроенном в файле io.sys (см. табл.2).
Таблица 2
Команды файла autoexec.bat, загружаемые по умолчанию
|Параметр |Выполнение |
|@echo off |Отключение вывода информации на |
| |экран при выполнении команд из |
| |autoexec.bat |
|net start |Загрузка сетевых компонентов |
| |реального режима, если они |
| |установлены |
|set tmp=C:WindowsTemp |Установка значения переменной ТМР |
| |путь к папке временных файлов |
|set temp=C:WindowsTemp |Установка значения переменной TEMP –|
| |путь к папке временных файлов |
|set comspec=C:command.com |Задается значение переменной COMSPEC|
| |– путь к командному интерпретатору |
|prompt $p$g |Настройка вида курсора командной |
| |строки MS-DOS |
|path C:Windows; |Пути поиска исполняемых файлов |
|C:WindowsCommand | |
Если по какой-то причине необходимо отменить выполнение каких-либо
параметров необходимо в config.sys добавить строку dos=noauto или записать
в один из конфигурационных файлов явную команду, изменяющую требуемый
параметр.
На этом фаза загрузки компонентов реального режима завершается.
Посмотреть, что в результате загрузилось, можно, введя в строке Выполнить
меню Пуск команду mem /р/с или mem /d/p - будет показана картина занятости
памяти с перечнем всех загруженных DOS-драйверов и резидентных программ.
Присутствие каких-либо DOS-драйверов без необходимости не рекомендуется.
Windows не всегда способна их отключить, подменяя своими драйверами, а это
серьезно снижает и быстродействие системы, и ее устойчивость.
ЗАКЛЮЧЕНИЕ
Для того, чтобы устранить неисправности при запуске Windows,
необходимо:
. Следить за сообщениями с первого момента запуска
. Проверить файлы Config.sys, Autoexec.bat
. Создать файл отчёта по загрузке Windows
. Попасть в стартовое меню Windows (F8)
. Выбрать режим – создавать отчёт (C:BOOTLOG.TXT)
. После загрузки посмотреть BOOTLOG.TXT. В файлах отчёта загрузка
фиксируется двумя строчками. Сообщение об ошибках надо смотреть во
второй строке.
Реферат на тему: Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX. На примере octopus.stu.lipetsk.ru
Министерство образования российской федерации
ЛИПЕЦКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИчЕСКИЙ УНИВЕРСИТЕТ
Кафедра АСОИУ
Индивидуальное домашнее задание по дисциплине «Операционные системы»
«Несанкционированный доступ к терминалам серверов с операционными системами
семейства UNIX. На примере octopus.stu.lipetsk.ru »
Выполнил: Архипов Н.А.
Группа: АС-99-2
Принял: Журавлева М.Г.
Липецк 2001
Предисловие
План, что и говорить, был превосходный:
простой и ясный, лучше не придумаешь. Недостаток
у него был только один: было совершенно
неизвестно, как привести его в исполнение.
Л. Кэрролл. Алиса в стране чудес
В данном отчете мы попытаемся выявить «дыры» и «изъяны» локальной
компьютерной сети ЛГТУ (LSTU) в целом и в частности сервера для изучения
операционных систем UNIX – octopus.lstu. Для этого мы расскажем о
возможных попытках получения доступа к терминалам серверов, в том числе и с
правами root’a, а так же попытка перегрузить сервер. Здесь не
рассматривается такой вид атаки как «Социальная инженерия», поскольку наша
задача – изучение операционных систем, а не психологии. Сразу предупреждаю,
что на практике не использовалось ни каких деструктивных действий (в том
числе перегрузки сервера), кроме тех действий которые использовались только
для изучения сети. Поэтому, мы ни какой ответственности за использование
этого документа не несем.
Особенности безопасности компьютерных сетей
Основной особенностью любой сетевой системы является то, что ее
компоненты распределены в пространстве, а связь между ними осуществляется
физически, при помощи сетевых соединений (коаксиальный кабель, витая пара,
оптоволокно и т. п.), и программно, при помощи механизма сообщений. При
этом все управляющие сообщения и данные, пересылаемые между объектами
распределенной вычислительной системы, передаются по сетевым соединениям в
виде пакетов обмена.
К сетевым системам, наряду с обычными (локальными) атаками,
осуществляемыми в пределах одной компьютерной системы, применим
специфический вид атак, обусловленный распределенностью ресурсов и
информации в пространстве так называемые сетевые (или удаленные) атаки
(remote или network attacks). Они характеризуются, во-первых, тем, что
злоумышленник может находиться за тысячи километров от атакуемого объекта,
и, во-вторых, тем, что нападению может подвергаться не конкретный
компьютер, а информация, передающаяся по сетевым соединениям. С развитием
локальных и глобальных сетей именно удаленные атаки становятся лидирующими
как по количеству попыток, так и по успешности их применения, и,
соответственно, обеспечение безопасности ВС с точки зрения противостояния
сетевым атакам приобретает первостепенное значение.
удаленные атаКИ НА ХОСТЫ iNterNet
Многое наша Земля повидала, Но не видала Такого скандала!
Б. Заходер. География всмятку
Анализ сетевого трафика Internet
В Internet базовыми протоколами удаленного доступа являются TELNET и FTP
(File Transfer Protocol). TELNET - это протокол виртуального терминала
(ВТ), позволяющий с удаленных хостов подключаться к серверам Internet в
режиме ВТ. FTP - протокол, предназначенный для передачи файлов между
удаленными хостами. Для получения доступа к серверу по данным протоколам
пользователю необходимо пройти процедуры идентификации и аутентификации. В
качестве информации, идентифицирующей пользователя, выступает его имя, а
для аутентификации используется пароль. Особенностью протоколов FTP и
TELNET является то, что пароли и идентификаторы пользователей передаются по
сети в открытом, незашифрованном виде. Таким образом, необходимым и
достаточным условием для получения удаленного доступа к хостам по
протоколам FTP и TELNET являются имя и пароль пользователя.
Одним из способов получения таких паролей и идентификаторов в Internet
является анализ сетевого трафика. Этот анализ осуществляется с помощью
специальной программы-анализатора пакетов (sniffer), перехватывающей все
пакеты, передаваемые по сегменту сети, и выделяющей среди них те, в которых
передаются идентификатор пользователя и его пароль. Сетевой анализ
протоколов FTP и TELNET показывает, что TELNET разбивает пароль на символы
и пересылает их по одному, помещая каждый символ пароля в соответствующий
пакет, a FTP, напротив, пересылает пароль целиком в одном пакете.
Возникает вопрос: а почему бы не сделать передачу имени пользователя и
пароля в зашифрованном виде? Видимо, проблема в том, что базовые прикладные
протоколы семейства TCP/IP разрабатывались очень давно, в период с конца 60-
х до начала 80-х годов, и с тех пор абсолютно не изменились. При этом точка
зрения на построение глобальных сетей стала иной. Инфраструктура Сети и ее
протоколы разрабатывались исходя, в основном, из соображений надежности
связи, но не из соображений безопасности.
Таким образом возможно отследить сетевой поток и выявить пакеты
содержащие необходимые данные (Имя, пароль, и т.д.). Так как в данном
документе рассматривается только сервер ЛГТУ octopus.lstu, то я
проанализировав сеть, пришел к выводу, что сервер не всегда находится в
активном состоянии. Таким образом, данный вариант атаки отпадает, да и еще
чтобы постоянно отслеживать трафик, необходимо, чтобы все это время в сети
находился хотя бы один компьютер, что невозможно из-за финансовых
трудностей.
Перебор паролей в файле /etc/passwd
В ранних версиях операционных системах семейства UNIX зашифрованные
пароли (точнее их хэш-копии) хранились в файле /etc/passwd. В современных
UNIX’ах пароли хранятся в /etc/shadow. Хранение зашифрованных паролей в
/etc/passwd делает систему сервера octopus.lstu уязвимой. Здесь
используется хэш-функция Data Encryption Standard (DES 48/64 4K). Поскольку
данная шифровка работает только «в одну сторону», а проверка подлинности
пароля заключается в том, что при вводе пароля пользователя, операционная
система шифрует введенную последовательность и сравнивает ее со строкой в
файле /etc/passwd. Вот пример записи паролей и имен пользователей в
/etc/passwd:
root:LyavHDdahFcwU:0:1:Superuser:/:
…
malysh:7DnDkTMD9/wG2:1007:25:Olga A. Bocharnikova, AS-98-
1:/user/students/as98/malysh:
Для перебора паролей мы используем тот же метод, что и операционная
система: перебираю все возможные комбинации букв латинского алфавита
(причем имеет значение прописная буква или строчная), цифр и специальных
знаков. Здесь можно использовать как функции самой операционной системы,
так и написать свою функцию шифровки. Но нужно быть точно уверенным что за
алгоритм используется в данном случае, иначе перебор не приведет ни к каким
результатам. На компьютере octopus используется алгоритм шифрования DES
[48/64 4K]. Так как на octopus’e столь неважные, по сегодняшним меркам,
аппаратные средства (см. следующий пункт), то ни о каком переборе пароля не
может идти и речи. Тем более, даже на более быстрых машинах (Pentium III –
650MHz) расшифровка заняла примерно 30 суток (!!!). Да и сервер не все
время находится в рабочем состоянии, как уже было замечено выше. В отчете
прилагается часть программы, для расшифровки паролей файла /etc/passwd.
Deny of Service (DoS) атака.
Дословно Deny of Service переводится как «отказ в обслуживании». Это
означает например, что операционная система не может обслужить запрос
пользователя или другой системы.
Рассмотрим нарушение работоспособности хоста в сети при использовании
направленного шторма ложных TCP-запросов на создание соединения либо при
переполнении очереди запросов. Из рассмотренной в предыдущем пункте схемы
создания TCP-соединения следует, что на каждый полученный TCP-запрос (TCP
SYN) операционная система должна сгенерировать начальное значение
идентификатора ISN и отослать его на запросивший хост. Но так как в
Internet (стандарта IPv4) не предусмотрен контроль за IP-адресом
отправителя сообщения, то проследить истинный маршрут, пройденный IP-
пакетом, невозможно и, следовательно, у конечных абонентов сети нет способа
ограничить число запросов, принимаемых в единицу времени от одного хоста.
Поэтому возможно осуществление типовой удаленной атаки «отказ в
обслуживании», которая будет заключаться в передаче на объект атаки как
можно большего числа ложных TCP-запросов на создание соединения от имени
любого хоста в сети (направленный шторм запросов TCP SYN, схема которого
приведена на рисунке).
При этом атакуемая сетевая ОС в зависимости от вычислительной мощности
компьютера либо перестает реагировать на легальные запросы на подключение
(отказ в обслуживании), либо, в худшем случае, практически зависает. Это
происходит потому, что система должна, во-первых, сохранить в памяти
полученную в ложных сообщениях информацию и, во-вторых, выработать и
отослать ответ на каждый запрос. Таким образом, «съедаются» все ресурсы
системы: переполняется очередь запросов, и ОС вынуждена заниматься только
их обработкой. Эффективность данного воздействия тем выше, чем больше
пропускная способность канала между атакующим и его целью, и тем ниже, чем
больше вычислительная мощность атакуемого компьютера (число и
быстродействие процессоров, объем ОЗУ и т.п.).
Такую атаку можно было предсказать еще лет двадцать назад, когда появилось
семейство протоколов TCP/IP: ее корни находятся в самой инфраструктуре сети
Internet, в ее базовых протоколах - IP и TCP. Но каково же было наше
удивление, когда выяснилось, что на информационном . WWW-сервере CERT
(Computer Emergency Respone Team) первое упоминание об удаленном
воздействии такого рода датировано только 19 сентября 1996 года! Там эта
атака носила название «TCP SYN Flooding and IP Spoofing Attacks»
(«наводнение» TCP-запросами с ложных IP-адресов). Другая разновидность
атаки «отказ в обслуживании» состоит в передаче на атакуемый хост
нескольких десятков (сотен) запросов TCP SYN в секунду (направленный мини-
шторм TCP-запросов) на подключение к серверу, что может привести к
временному (до 10 минут) переполнению очереди запросов на сервере (см.
атаку К. Митника). Это происходит из-за того, что некоторые сетевые ОС
обрабатывают только первые несколько запросов на подключение, а остальные
игнорируют, Таким образом, получив N запросов на подключение, ОС сервера
ставит их в очередь и генерирует соответственно N ответов. Затем в течение
определенного промежутка времени (тайм-аут < 10 минут) сервер будет
дожидаться сообщения от предполагаемого клиента, чтобы завершить handshake
и подтвердить создание виртуального канала с сервером. Если атакующий
пришлет такое количество запросов на подключение, которое равно
максимальному числу одновременно обрабатываемых сервером сообщений, то в
течение тайм-аута остальные запросы будут игнорироваться и установить связь
с сервером не удастся.
Мы провели ряд экспериментов с направленным штормом и направленным
миништормом запросов на различных по вычислительным мощностям компьютерах с
разными операционными системами.
Тестирование направленным штормом запросов TCP SYN, проводимое на
различных сетевых ОС в экспериментальных 10-мегабитных сегментах сети, дало
следующие результаты: все описанные далее атаки осуществлялись по
определенной методике. Подготавливался TCP-запрос, который при помощи
специально разработанной собственной программы в цикле передавался в сеть с
соответствующими задержками (вплоть до нулевой) между запросами. При этом
циклически изменялись такие параметры запроса, как порт отправителя и
значение 32-битного идентификатора SYN. IP-адрес отправителя запроса был
выбран так, чтобы, во-первых, этот хост в настоящий момент не был активен в
сети и, во-вторых, чтобы соответствующий маршрутизатор, в чьей зоне
ответственности находится данный хост, не присылал сообщения Host
Unreachable (Хост недоступен). В противном случае хост, от имени (с IP-
адреса) которого посылался запрос TCP SYN, получив «неожиданный» ответ TCP
АСК от атакуемого сервера, перешлет на него пакет TCP RST, закрывая таким
образом соединение.
При передаче по каналу связи максимально возможного числа TCP-запросов и
при нахождении кракера в одном сегменте с объектом атаки атакуемые системы
вели себя следующим образом: ОС Windows 95, установленная на 486DX2-66 с 8
Мб ОЗУ, «замирала» и переставала реагировать на любые внешние воздействия
(в частности, нажатия на клавиатуру); ОС Linux 2.0.0 на 486DX4-133 с 8 Мб
ОЗУ также практически не функционировала, обрабатывая одно нажатие на
клавиатуре примерно 30 секунд. В результате к этим хостам невозможно было
получить не только удаленный, но и локальный доступ.
Не менее интересным было поведение атакуемых систем после снятия
воздействия: ОС Windows 95 практически сразу же после прекращения атаки
начала нормально функционировать; в ОС Linux 2.0.0 с 8 Мб ОЗУ, по-видимому,
переполнился буфер, и более получаса система не функционировала ни для
удаленных, ни для локальных пользователей, а занималась только передачей
ответов на полученные ранее запросы. CyberGuard сразу же после снятия
воздействия стал доступным для удаленного доступа.
Если кракер находился в смежных сегментах с объектом, то во время атаки ОС
Windows 95 на Pentium 100 с 16 Мб ОЗУ обрабатывала каждое нажатие с
клавиатуры примерно секунду, ОС Linux 2.0.0 на Pentium 100 с 16 Мб ОЗУ
практически «повисала» - одно нажатие за 30 секунд, зато после снятия
воздействия нормальная работа возобновлялась.
Не нужно обманываться, считая, что ОС Windows 95 показала себя с лучшей
стороны. Такой результат объясняется следующим: Windows 95 - операционная
система, не имеющая FTP-сервера, а следовательно, ей не нужно было
сохранять в памяти параметры передаваемого TCP-запроса на подключение к
этому серверу и дожидаться окончания handshake.
Таким образом, учитывая аппаратные средства сервера octopus.lstu
(Olivetti 80286) можно без труда осуществить на него DoS атаку. Даже если
локальная сеть будет загружена. Можно предположить, что и остальные сервера
университета могут быть «обездвижены» таким способом. Например сервер
кафедры прикладной математики: IBM 486DX66 16RAM. По аппаратной части
серверы кафедры АСУ (здесь не имеется ввиду octopus.lstu) более устойчивы к
DoS атаке.
Превышение максимально возможного размера IP-пакета, или Ping Death
В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка
и длина ноля данных в IP-пакете. Так как минимальный размер IP-заголовка -
20 байт (максимальный - 60), то соответственно размер данных, передаваемых
в одном IP-пакете, не может превышать 65 535- 20 = 65 515 байт. А что
будет, если превысить это число? Тестировать свои программы на предельных
критических значениях -стандартный для любого программиста ход. Подобные
тесты позволяют выявить такие неприятные ошибки, как всевозможные
переполнения (буфера, стека, переменной и т. д.). Но вернемся к IP. В
принципе ничто не мешает атакующему сформировать набор фрагментов, которые
после сборки превысят максимально возможный размер IP-пакета. Собственно в
этой фразе и сформулирована основная идея данной атаки.
Итак, 18 декабря 2000 года на информационном сервере СЕКТ появились
сообщения о том, что большинство сетевых операционных систем,
поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при
передаче на них IP-пакета длиной, превышающей максимально допустимое
значение, в этих ОС переполняется буфер или переменная, в результате
система «зависает» или перезагружается, то есть налицо отказ в
обслуживании. Был приведен и список потенциально опасных платформ:
• Berkeley Software Design, Inc. (BSD);
• Computer Associates, Intl. (products for NCR);
• Cray Research;
• Digital Equipment Corporation;
• FreeBSD, Inc.; ' Hewlett-Packard Company;
• IBM Corporation;
• Linux Systems;
• NEC Corporation;
• Open Software Foundation (OSF);
• The Santa Cruz Operation, Inc. (SCO);
• Sun Microsystems, Inc.
Мы с удивлением прочитали этот перечень операционных систем на различных
платформах, а потом принялись за эксперименты. Наше глубочайшее изумление
вызвал тот факт, что элементарную ошибку переполнения буфера в модуле IP
ядра ОС за почти 20 лет активного функционирования протокола IP
разработчики сегодняшних систем до сих пор не замечали. Поэтому мы
позволили себе не поверить столь уважаемой организации, как CERT. Но прежде
чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке
(http://www.sophist.demon.co.uk/ping) на WWW-сервер, где экспертами
проводились подобные исследования на различных ОС. На WWW-сервере
предлагалось реализовать такое воздействие следующим образом: необходимо
выполнить на рабочей станции с ОС Windows 95 или Windows NT следующую
команду: ping -l 65527 victim.destination.IP.address (по этой команде атака
и получила свое название - Ping Death).
Так как обычный размер IP-заголовка составляет 20 байт, а размер 1СМР-
заголовка - 8 байт, то подобный ICMP-пакет будет превышать максимально
возможный размер IP-пакета на 20 байт: 65 527 +20+8-65 535 = 20.
Основываясь на приведенном расчете, эти «эксперты» декларировали, что
обычной командой ping можно нарушить работоспособность практически любой
сетевой ОС. В завершение предлагалась следующая таблица тестирования
различных операционных систем
|Операционная система |Версия ПО |Симптомы |
|Solaris (x86) |2.4, 2.5, 2.5.1 |Перезагрузка |
|Minix |1.7.4, v2.0 и другие |Сбой |
|HP3000 MPE/iX |4.0, 5.0, 5.5 |Сброс системы |
|Convex SPP-UX |Все версии |Сбой |
|Apple Mac |MacOs 7.x.x |Сбой |
|Windows 3.11 with |? |Смешанные отчеты |
|Trumpet winsock | | |
|Novell Netware |3.x |Смешанные отчеты |
|Windows 95 |Все версии |Сбой |
|AIX |3 и 4 |Сброс системы |
|Linux |2.0.23 |Спонтанная перезагрузка|
| | |или зависание (kernel |
| | |panic) |
|DEC UNIX / OSF1 |2.0 и выше |зависание (kernel |
| | |panic) |
|Open VMS for AXP |Различные |Смешанные отчеты |
|HP-UX |9.0 по 10.20 |Сбой, перезагрузка, |
| | |зависание. |
|Windows NT |3.5.1 |Смешанные результаты |
|Irix |5.3 |зависание (kernel |
| | |panic) |
|Windows NT |4 |Сбой |
|SCO Openserver |4.2, 5.0.x |Уязвима |
|DEC TOPS-20, TOPS-10 |Все |Ошибки |
|Digital Firewall |? |Уязвима |
|AltaVista Firewall for |? |Уязвима |
|UNIX | | |
(здесь она приводится в сокращении), на которые данная удаленная атака
якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно
говоря, абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS,
SunOs, FreeBSD, Linux, Windows NT 4.0, даже Windows 95 и Windows for
WorkGroups 3.11- абсолютно не реагировали на подобный некорректный запрос,
продолжая нормально функционировать. Тогда были предприняты специальные
поиски операционной системы, которую бы действительно вывела из строя
данная атака. Ей оказалась Windows 3.11 с WinQVT - эта ОС действительно
«зависла».
Этим «экспертам», которым столь доверяют CERT и С1АС, мы послали запрос,
где попросили прояснить возникшую ситуацию, а также уточнить сведения из
вышеприведенной таблицы. В полученном нами ответе говорилось, что успех
данной атаки зависит от многих факторов, а именно: программного и
аппаратного обеспечения, установленного на компьютере, и, самое главное, от
фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели
бы привести описание exploit, созданного для Windows NT 4.0, задача
которого, используя ping, «завесить» собственный компьютер (!). Сначала
предлагалось запустить Web Browser, затем-taskmgr (Task Manager): так Ping
Death якобы лучше работает (еще не хватает шаманского бубна!). И наконец,
требовалось запустить 18 ping-процессов (почему не 100?). Если вы думаете,
что после всего этого ваша ОС немедленно «повиснет», то ошибаетесь! В
комментариях к exploit до получения эффекта предлагалось ждать примерно 10
минут, а может быть, несколько больше или несколько меньше.
Можно сделать вывод, что опасения по поводу данного воздействия ни на чем
не основаны, и нам остается только назвать эту атаку очередной
программистской байкой и причислить ее к разряду практически
неосуществимых.
причины усПЕХА УДАЛЕННЫХ АТАК
«То, что изобретено одним человеком,
может быть понято другим», - сказал Холме.
А. Конан Доил. Пляшущие человечки
( Использование нестойких алгоритмов идентификации
К сожалению, взаимодействие объектов по виртуальному каналу в
распределенной ВС не является панацеей от всех проблем, связанных с
идентификацией объектов РВС. ВК - необходимое, но не достаточное условие
безопасного взаимодействия. Чрезвычайно важным в данном случае становится
выбор алгоритма идентификации при создании виртуального канала. Основное
требование, предъявляемое к этим алгоритмам, состоит в следующем: перехват
ключевой информации, которой обмениваются объекты РВС при создании ВК, не
должен позволить атакующему получить итоговые идентификаторы канала и
объектов. Однако в базовых алгоритмах идентификации, используемых при
создании ВК в большинстве существующих сетевых ОС, это требование
практически не учитывается.
( Отсутствие контроля за виртуальными каналами связи
Объекты распределенной ВС, взаимодействующие по виртуальным каналам,
могут подвергаться типовой атаке «отказ в обслуживании». Особенность этого
воздействия состоит в том, что, действуя абсолютно легальными средствами
системы, можно удаленно добиться нарушения ее работоспособности. В чем
причина успеха данной атаки? В отсутствии необходимого контроля над
соединением. При этом задача контроля распадается на две подзадачи:
• контроль за созданием соединения;
• контроль за использованием соединения.
Если пути решения второй задачи понятны - обычно соединение разрывается
по тайм-ауту, определенному системой, - так сделано во всех известных
сетевых ОС (однако тут возникает серьезная проблема выбора конкретного
значения тайм-аута), то контроль за созданием ВК достаточно сложен: в
системе, где отсутствует статическая ключевая информация обо всех ее
объектах, невозможно отделить ложные запросы на создание соединения от
настоящих. Очевидно также, что если один субъект сетевого взаимодействия
будет иметь возможность анонимно занимать неограниченное число каналов
связи с удаленным объектом, то подобная система может быть полностью
парализована данным субъектом. Таким образом, если любой объект в
распределенной системе способен анонимно послать сообщение от имени другого
объекта (например, в Internet маршрутизаторы не проверяют IP-адрес
отправителя), то в подобной распределенной ВС практически невозможен
контроль за созданием виртуальных соединений. Поэтому основная причина
типовой угрозы «отказ в обслуживании» - это отсутствие приемлемого решения
задачи контроля за маршрутом сообщений.
( Отсутствие возможности контролировать маршрут сообщений
Если в РВС не предусмотреть контроля за маршрутом сообщения, то адрес
отправителя сообщения оказывается ничем не подтвержденным. Таким образом, в
системе будет существовать возможность работы от имени любого объекта путем
указания в заголовке сообщения чужого адреса отправителя (IP Spoofing). В
подобной РВС затруднительно определить, откуда на самом деле пришло
сообщение, а следовательно - вычислить координаты атакующего (в Internet
невозможно найти инициатора однонаправленной удаленной атаки).
( Отсутствие полной информации об объектах РВС
В распределенной системе с разветвленной структурой, состоящей из
большого числа объектов, может возникнуть ситуация, когда для доступа к
определенному хосту у субъекта взаимодействия не окажется необходимой
информации, то есть адреса данного объекта. Очевидно, что в системе
подобного типа существует потенциальная опасность внесения ложного объекта
и выдачи одного объекта за другой путем передачи ложного ответа на
поисковый запрос.
( Отсутствие криптозащиты сообщений
В распределенных ВС связь между объектами системы осуществляется по
виртуальным каналам связи, а следовательно, хакер имеет принципиальную
возможность прослушать канал, получив несанкционированный доступ к
информации, которой обмениваются по сети се абоненты. Если эта информация
не зашифрована, то возникает угроза атаки типа «анализ сетевого трафика».
( Отсутствие выделенного канала связи между объектами сети Internet
Глобальная сеть не может быть построена по принципу прямой связи между
объектами, поскольку для каждого объекта невозможно обеспечить вы деленный
канал связи с любым другим объектом. Поэтому в Internet связь
осуществляется через цепочку маршрутизаторов, а следовательно, сообщение,
проходя через большое количество промежуточных подсетей, может быть
перехвачено. Также к Internet подключено большое число локальных Ethernet-
сетей, использующих топологию «общая шина»; в сетях с такой
топологией несложно программно осуществлять перехват сообщений.
( Недостаточные идентификация и аутентификация
В базовых протоколах обмена идентификация и аутентификация объектов
практически отсутствуют. Так, например, в прикладных протоколах . FTP,
TELNET, РОРЗ имена и пароли пользователей передаются по сети в виде
открытых незашифрованных сообщений.
( Использование нестойких алгоритмов идентификации объектов при создании
виртуального TCP-соединения
Как уже подчеркивалось, протокол TCP является единственным базовым
протоколом транспортного уровня, в функции которого заложена защита
соединения. Однако использование простейшего алгоритма идентификации
объектов при создании виртуального TCP-канала, особенно при условии
применения в сетевых ОС простейших времязависимых законов генерации TCP-
идентификаторов (ISN), сводит на нет все попытки обеспечения идентификации
канала и объектов при их взаимодействии по протоколу TCP.
( Отсутствие криптозащиты сообщений
В существующих базовых протоколах семейства TCP/IP, обеспечивающих
взаимодействие на сетевом и транспортном уровнях, не предусмотрена
возможность шифрования сообщений, хотя очевидно, что добавить ее в протокол
TCP не составляло труда. Разработчики решили переложить задачу криптозащиты
на протоколы более высоких уровней, например прикладного уровня. При этом
базовые протоколы прикладного уровня (FTP, TELNET, HTTP и др.) также не
предусматривали никакого шифрования сообщений. Только не так давно появился
общедоступный прикладной протокол SSL, встроенный в Netscape Navigator,
позволяющий как надежно зашифровать сообщение, так и подтвердить его
подлинность. В заключение хотелось бы заметить, что все описанные выше
причины, по которым возможна успешная реализация угроз безопасности РВС,
делают сеть Internet небезопасной. А следовательно, все пользователи сети
могут быть атакованы в любой момент.
Подведем итоги.
Учитывая все вышесказанное, я думаю, что студентам кафедры АСОИУ уже
сейчас не представляется никакой сложности для несанкционированного доступа
к терминалам серверов с правами администраторов (причем это не
необоснованное высказывание). Другой вопрос – целесообразности всего этого.
Я думаю что не стоит проверять все вышесказанное на практике в целях своей
же безопасности.
В целом, вычислительная сеть университета администрируется весьма
неплохо, нужно отдать должное системным администраторам. На серверах стоят
последние версии операционных систем. Однако на chuck.stu.lipetsk.ru почему-
то у обычных пользователей нет прав на компилирование Си программ. Почему?
Может это и есть слабое звено в администрировании, или это еще одна
предосторожность администратора? Хотя на tomcat.am.lstu обычным смертным
разрешено…
Вообще-то взлом octopus.stu.lipetsk.ru был бы неуважением своей же
кафедры. Ведь та защита которая там присутствует направлена не для того,
чтобы предотвратить проникновение злоумышленника, а для элементарной защиты
от неопытных пользователей.
ПРИЛОЖЕНИЕ.
В целях безопасности, приводим только фрагменты программы. Файл john.c
#include
#include
#include
#include
#include "arch.h"
#include "misc.h"
#include "params.h"
#include "path.h"
#include "memory.h"
#include "list.h"
#include "tty.h"
#include "signals.h"
#include "idle.h"
#include "common.h"
#include "formats.h"
#include "loader.h"
#include "logger.h"
#include "status.h"
#include "options.h"
#include "config.h"
#include "bench.h"
#include "charset.h"
#include "single.h"
#include "wordlist.h"
#include "inc.h"
#include "external.h"
#include "batch.h"
#if CPU_DETECT
extern int CPU_detect();
#endif
extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;
extern struct fmt_main fmt_AFS, fmt_LM;
extern int unshadow(int argc, char **argv);
extern int unafs(int argc, char **argv);
extern int unique(int argc, char **argv);
static struct db_main database;
static struct fmt_main dummy_format;
static void john_register_one(struct fmt_main *format)
{
if (options.format)
if (strcmp(options.format, format->params.label)) return;
fmt_register(format);
}
static void john_register_all()
{
if (options.format) strlwr(options.format);
john_register_one(&fmt_DES);
john_register_one(&fmt_BSDI);
john_register_one(&fmt_MD5);
john_register_one(&fmt_BF);
john_register_one(&fmt_AFS);
john_register_one(&fmt_LM);
if (!fmt_list) {
fprintf(stderr, "Unknown ciphertext format name requestedn");
error();
}
}
static void john_load()
{
struct list_entry *current;
umask(077);
if (options.flags & FLG_EXTERNAL_CHK)
ext_init(options.external);
if (options.flags & FLG_MAKECHARS_CHK) {
options.loader.flags |= DB_CRACKED;
ldr_init_database(&database, &options.loader);
if (options.flags & FLG_PASSWD) {
ldr_show_pot_file(&database, LOG_NAME);
database.options->flags |= DB_PLAINTEXTS;
if ((current = options.passwd->head))
do {
ldr_show_pw_file(&database, current->data);
} while ((current = current->next));
} else {
database.options->flags |= DB_PLAINTEXTS;
ldr_show_pot_file(&database, LOG_NAME);
}
return;
}
if (options.flags & FLG_STDOUT) {
ldr_init_database(&database, &options.loader);
database.format = &dummy_format;
memset(&dummy_format, 0, sizeof(dummy_format));
dummy_format.params.plaintext_length = options.length;
dummy_format.params.flags = FMT_CASE | FMT_8_BIT;
}
if (options.flags & FLG_PASSWD) {
if (options.flags & FLG_SHOW_CHK) {
options.loader.flags |= DB_CRACKED;
ldr_init_database(&database, &options.loader);
ldr_show_pot_file(&database, LOG_NAME);
if ((current = options.passwd->head))
do {
ldr_show_pw_file(&database, current->data);
} while ((current = current->next));
printf("%s%d password%s cracked, %d leftn",
database.guess_count ? "n" : "",
database.guess_count,
database.guess_count != 1 ? "s" : "",
database.password_count -
database.guess_count);
return;
}
if (options.flags & (FLG_SINGLE_CHK | FLG_BATCH_CHK))
options.loader.flags |= DB_WORDS;
else
if (mem_saving_level)
options.loader.flags &= ~DB_LOGIN;
ldr_init_database(&database, &options.loader);
if ((current = options.passwd->head))
do {
ldr_load_pw_file(&database, current->data);
} while ((current = current->next));
ldr_load_pot_file(&database, LOG_NAME);
ldr_fix_database(&database);
printf("Loaded %d password%s%s",
database.password_count,
database.password_count != 1 ? "s" : "",
database.password_count ? "" : ", exiting...");
if (database.password_count > 1) {
printf(" with ");
printf(database.salt_count != 1 ? "%d" : "no",
database.salt_count);
printf(" different salts");
}
if (database.password_count)
printf(" (%s [%s])n",
database.format->params.format_name,
database.format->params.algorithm_name);
else
putchar('n');
if ((options.flags & FLG_PWD_REQ) && !database.salts) exit(0);
}
}
static void john_init(int argc, char **argv)
{
#if CPU_DETECT
if (!CPU_detect()) {
#if CPU_REQ
fprintf(stderr, "Sorry, %s is requiredn", CPU_NAME);
error();
#endif
}
#endif
path_init(argv);
cfg_init(CFG_NAME);
status_init(NULL, 1);
opt_init(argc, argv);
john_register_all();
common_init();
sig_init(idle_yield);
john_load();
}
static void john_run()
{
if (options.flags & FLG_TEST_CHK)
benchmark_all();
else
if (options.flags & FLG_MAKECHARS_CHK)
do_makechars(&database, options.charset);
else
if (options.flags & FLG_CRACKING_CHK) {
if (!(options.flags & FLG_STDOUT)) log_init(LOG_NAME);
tty_init();
if (options.flags & FLG_SINGLE_CHK)
do_single_crack(&database);
else
if (options.flags & FLG_WORDLIST_CHK)
do_wordlist_crack(&database, options.wordlist,
(options.flags & FLG_RULES) != 0);
else
if (options.flags & FLG_INC_CHK)
do_incremental_crack(&database, options.charset);
else
if (options.flags & FLG_EXTERNAL_CHK)
do_external_crack(&database);
else
if (options.flags & FLG_BATCH_CHK)
do_batch_crack(&database);
status_print();
tty_done();
if (!(options.flags & FLG_STDOUT)) log_done();
}
}
static void john_done()
{
path_done();
check_abort();
}
int main(int argc, char **argv)
{
char *name;
#ifdef __DJGPP__
if (--argc 4)
if (!strcmp(strlwr(name) + strlen(name) - 4, ".exe"))
name[strlen(name) - 4] = 0;
#endif
if (!strcmp(name, "john")) {
john_init(argc, argv);
john_run();
john_done();
return 0;
}
if (!strcmp(name, "unshadow"))
return unshadow(argc, argv);
if (!strcmp(name, "unafs"))
return unafs(argc, argv);
if (!strcmp(name, "unique"))
return unique(argc, argv);
fprintf(stderr, "Sorry, I can't find myselfn");
return 1;
}
Файл des_bs.c
#include
#include "arch.h"
#include "DES_std.h"
#include "DES_bs.h"
DES_bs_combined DES_bs_all;
int DES_bs_mem_saving = 0;
extern void DES_bs_body();
void DES_bs_init()
{
| |
