книги хакеры / журнал хакер / 112_Optimized

Фабрика в Шеньжене

с большой долей скепсиса. Однако Edifier и здесь остается предельно честным и свои обещания выполняет. Откровенно дешевых решений вы здесь не найдете, даже системы младшей линейки 2.0 и 2.1 сработаны на совесть.

Спектр продукции Edifier достаточно богат, чтобы удовлетворить нужды всехпокупателей.Здесьудастсяподобратьипортативнуюсистемудляноут­ бука (чего стоит одна только MP300) и серьезное стационарное решение для домашнего кинотеатра или компьютера (например, хитовый Edifier S5.1, получивший широкое мировое признание). Но главное — Edifier ориентируется, пожалуй, на самую здравую аудиторию — на людей, которые ценят качество звука и в оном разбираются, но не желают при этом выкладывать сумасшедшие деньги за комплект акустики.

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

Производство корпусов из МДФ

Новая фабрика Edifier открывается летом этого года

Внутренний дворик главной фабрики Edifier

внешними усилителями, или линейка I-F, в которой представлены решения для плееров компании Apple — iPod, будь то мультимедийный док или забавный гаджет в форме будильника, исполняющий его непосредственные обязанности.

В заключение

Специалистам компании Edifier удается удерживать соотношения качества и цены на таком уровне, что покупатели в буквальном смысле голосуют рублем. Нет ничего удивительного в том, что на сегодня Edifier принадлежит львиная доля восточного рынка — порядка 50%. Что до нашей страны и соседних республик бывшего СССР, представительств Edifier у нас хватает. Одно то, что русскоязычных сайтов целых три — русский, белорусский и украинский, говорит само за себя. Доступность в сочетании с качеством уже завоевали компании прекрасную репутацию как на мировом, так и на нашем, отдельно взятом, рынке.z

Производство динамиков

Крис Касперски

indows намного надежнее, чем это принято считать в народе.

WМоя основная машина (на базе W2K) перезагружается не чаще двух раз в месяц, а файловый сервер (и по совместительству

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

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

Ипускай меня сочтут ненормальным… главное — методики реанимации системы, разработанные и обкатанные мной, могут принести пользу не только мне. Итак, что нам понадобится?

•  WindowsDriverKit(WDK) для всех систем по Vista включительно (www. microsoft.com/whdc/DevTools)

•  WindowsServer2003SP1DDK(www.microsoft.com/whdc/devtools/ddk/ default.mspx)

•  IA-32ArchitectureSoftwareDeveloper’sManualVol.3:System ProgrammingGuide(www.intel.com/products/processor/manuals)

•  Syser1.95.19000.0894(www.sysersoft.com/download/download.php)

По ту сторону BSOD’ов

Голубыеэкранывспыхиваютвсякийраз,когдаядросталкиваетсясситуацией,которуюнеможетразрулитьсамостоятельно.Еслинеостановитьнекорректноработающийкод,завершивработувсехмеханизмовосиваварийном режиме,ситуацияспособнапуститьсистемувразнос.Это,кстати,карди- нальноотличаетNT-подобныесистемыотмираUNIX,впадающеговBSOD

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

Конечно,еслиошибкавозникнетвдрайверефайловойсистемы,тодалекона такоймашиненеуедешь.Подавляющеебольшинствосбоевприходитсяна драйвера,установленныевирусами,антивирусами,брандмауэрами,звуковымиивидеокартами.Причем,какпоказываетпрактика,90%ошибокотнюдьне фатальны.Онивполнесовместимысжизнью,ноядронеспрашиваетнас,хотим лимыпродолжитьработуилипредпочитаемвнезапноумереть(втотсамый момент,когдаоткрытамассаприложенийстучейнесохраненныхфайлов). Прежде, чем бросаться в бой, нужно отделить программные ошибки от аппаратных отказов железа (как разогнанного, так и нет). Если голубые экраны вспыхивают в случайное время, каждый раз отображая разные данные (да кто эти данные читает?), то с большой вероятностью мы имеем дело с глюками железа. Пытаться реанимировать компьютер при этом чрезвычайно опасно. Если содержимое оперативной памяти разрушено из-за разгона или некачественного блока питания, то после выхода из BSOD’а операционная система попытается скинуть дисковые буфера. А там у нас что? Правильно, — мусор. И дисковый том отправится к праотцам, что намного хуже, чем потеря оперативных данных. Впрочем, дефекты программного обеспечения тоже могут приводить к генерации «рандомных» экранов голубой смерти. Следовательно, без полного анализа ситуации здесь не обойтись. Однако не будем падать духом! Рано или поздно мы «объездим» ядро и разберемся во всех тонкостях его организации, а пока ограничимся лишь общей схемой.

Как устроен BSOD

Роль палача в NT-системах играет функция KeBugCheckEx, экспортируемая ядром и вызываемая из сотен (если не тысяч!) мест с теми или

>>

Syser перехватил вызов KeBugCheckEx, предотвращая появление голубого экрана смерти

Вот она — машинная инструкция, вызвавшая исключение, обрушившее систему

иными параметрами. Что это за параметры? Обратившись к NTDDK, мы узнаем, что функция KeBugCheckEx принимает пять аргументов, первый из которых (BugCheckCode) содержит код ошибки, а четыре следующих параметра — места/время/обстоятельства ее возникновения. Перечень BugCheck-кодов можно найти в том же NTDDK. Там же содержится описание четырех аргументов, специфичных для каждого BugCheck-кода, количество которых чуть меньше сотни. Чтобы не дер­ жать в голове кучу ненужной информации, рекомендуется распечатать документацию и всегда хранить ее под рукой.

BugCheck-коды можно разделить на две большие категории. Первая содержит адрес инструкции, вызвавшей исключение (например, 1Eh:

KMODE_EXCEPTION_NOT_HANDLED, 0Ah: IRQL_NOT_LESS_OR_EQUAL,

24h: NTFS_FILE_SYSTEM). Это позволяет «заглянуть» отладчиком непосредственно на место аварии, исправить пробоину и, выйдя из отладчика, продолжить плавание (естественно, для этого нужно не только знать ассемблер, но и разбираться в тонкостях драйверостроения, но это — в идеале).

Другая категория BugCheck-кодов не содержит адреса дефективной инструкции, поскольку ядро диагностирует аварийную ситуацию на поздней стадии. Найти виновника в этих случаях затруднительно. Взять хотя бы такой BugCheck-код, как C2h: BAD_POOL_CALLER. Он вызывается из функции распределения памяти, обнаружившей, что память на конкретной измене, но кто ее разрушил и когда — этого система сказать не может.

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

Подготовка к работе

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

SoftICE, Syser и Microsoft Kernel Debugger, но SoftICE не работает на Висле и Server’е 2008, а Microsoft Kernel Debugger — это вообще не вариант. Оста-

ется Syser, который мы и будем использовать.

Установка обычно проходит гладко и без нареканий. Выбираем ручной ре-

жим загрузки (boot — manual) и, чтобы не грузить его вручную (это ж напряг какой!), перетягиваем иконку «Syser Loader», созданную инсталлятором в папку «Автозагрузка». В принципе, можно не извращаться и выбрать автоматический режим загрузки. Но в этом случае, если возникнет конфликт отладчика с операционной системой, его будет трудно выгрузить.

Окей, будем считать, что Syser загружен и готов работе, что подтверждается наличием соответствующей управляющей консоли на экране. Ее можно свернуть или совсем закрыть — отладчику от этого хуже не станет. Однако мы ничего закрывать не будем, поскольку чуть позже планируем немного поэкспериментировать с дефективным драйвером, запуск которого как раз и осуществляется через эту консоль. А сейчас нажимаем <CTRL-F12> и

вводим магическую команду «bpm KeBugCheckEx x<ENTER>x<ENTER>»,

заставляющую Syser перехватывать вызов функции KeBugCheckExдо возникновения голубого экрана смерти. Набирать ее придется вручную при каждом запуске Syser’а, поскольку текущие версии отладчика, увы, макросов автозапуска не поддерживают (в SoftICE делать вообще ничего не надо, так как он перехватывает KeBugCheckExпо умолчанию). На этом нашу миссию можно считать законченной. Теперь ни один голубой экран смерти не пробежит мимо нас незамеченным!

Уроки практической магии

Напишем простой драйвер, обращающийся к памяти по нулевому указателю (что категорически недопустимо) и, как следствие, вызывающий BSOD, с которым мы и будем сражаться.

Исходный ассемблерный текст простейшего драйвера-убийцы приведен ниже:

ПОДПИСЬ:CALL-the-BSOD.asm

.686

.model flat, stdcall

extern DbgPrint:PROC

.code

DriverEntry proc push offset to_die

; вывод предупредительного сообщения

CALL DbgPrint pop eax

XOR EAX, EAX

;обнуляем регистр EAX MOV EAX, [EAX]

;здесь выскакивает BSOD push offset happy

pc_zone

warning

Работа с операционкой в аварийном режиме может привести к краху системы и потере данных.

dvd

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

;если ты читаешь этот текст, CALL DbgPrint

;значит, ты еще жив :)

pop eax

mov eax, 0C0000182h

;STATUS_DEVICE_CONFIGURATION_ERROR

;RET

;Four-F says

RETN 8

; <- haron says DriverEntry endp

.data

to_die DB "*] prepare to die! [*",0Dh,0Ah,0 happy DB "*] welcome to life [*",0Dh,0Ah,0

end DriverEntry

Для его сборки нам понадобится NTDDK(который можно бесплатно скачать с серверов Microsoft), а также командный файл, в котором переменная окружения ntoskrnlсодержит полный путь к библиотеке ntoskrnl.lib(зависящий от того, куда инсталлятор установил NTDDK). Как видно, мыщъх использует путь, отличный от пути по умолчанию (C:\Program Files\) и потому нуждающийся в коррекции. В противном случае собрать драйвер не получится. На всякий случай, готовый драйвер CALL-the-BSOD.sysприлагается к статье.

ПОДПИСЬ:BAT-файлдлясборкидрайвера

@ECHO OFF

REM устанавливаем необходимые переменные окружения

SET FILE_NAME=CALL-the-BSOD

SET ntoskrnl=D:\NTDDK\libchk\i386\ntoskrnl. lib

REM удаляем результаты предыдущей сборки

IF EXIST %FILE_NAME%.obj DEL %FILE_NAME%.obj

REM транслируем ассемблерный листинг ml /nologo /c /coff %FILE_NAME%.asm IF NOT EXIST %FILE_NAME%.obj GOTO err

REM линкуем сгенерированный .obj файл

link /nologo /driver /base:0x10000 /align:32 /out:%FILE_NAME%.sys /subsystem:native %FILE_NAME%.obj %ntoskrnl%

GOTO end

Голубой экран смерти, вызванный нашим драйвером-убийцей

CALL-the-BSOD.sys

:err

ECHO -ERR!

:end

Первый бой — он трудный самый!

ВконсолиSyser’анаходим пункт «Tools», а в нем — «Quick Driver Loader». В появившемся диалоговом окне указыва-

ем путь к драйверу CALL-the-BSOD.sys(Driver File Name).

Имя сервиса (Service Name) загрузчик подставит самостоятельно. Нажимаем «Install» (установка) и «Start» (внимание: установку драйвера достаточно выполнить всего один раз и затем просто давить «Start», а когда надоест экспериментировать — сказать «Uninstall» для удаления сервиса из системы, но впрочем, можно и не говорить, это всего лишь запись в реестре, которая никому не мешает).

Номысильнозабегаемвперед.Посленажатиякнопки«Start» отладчикпоявляетсянаэкране,послушноостановившисьна функцииKeBugCheckEx.Еслитеперьнажать«x<ENTER>» длявыходаизотладчика,передаваяуправленияфункции KeBugCheckEx,системанемедленнорухнет,отображаяследующийBSOD(смотририсунок),тоестьсвершитсято,чтопроизошлобы,еслибыотладчикнебылустановленисконфигурирован. ОбратившиськNTDDK,мыузнаем,чтономер1Ehпринадлежит

BugCheck-кодуKMODE_EXCEPTION_NOT_HANDLED,сигна-

лизирующемуобошибкедоступакпамяти.Первыйаргумент функцииKeBugCheckExсодержиткодисключения,вданном случаеравныйC0000005h(STATUS_ACCESS_VIOLATION

—нарушениедоступа).Второйаргумент(равныйF75DF2AFh)

—адресдефективноймашиннойинструкции,докоторойможно «дотянуться»командой«u *(esp+(4*3))»—дизассембли- роватьсодержимоеуказателя,лежащеговтретьемдвойном словеотносительнорегистра-указателявершиныстека.

Если команда введена правильно, мы увидим код драй- вера-убийцы, который мы только что компилировали, линковали и загружали через «QuickDriverLoader». Все ясно! Машинная команда MOV EAX, [EAX] (где EAX, как мы помним, равен нулю) обращается к нулевой ячейке памяти. Процессор генерирует исключение, подхватываемое ядром и после непродолжительных мытарств попадающее под трибунал KeBugCheckEx.

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

изменен. А потому, возвращаться назад в драйвер нам нельзя. Точнее — можно, но для этого потребуется совершить слишком

>>

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

Универсальныеспособы реанимациисистемы

Начинаем мозговой штурм. Какие будут предложения?

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

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

Ладно, рискнем (а что нам еще остается делать?) и воспользуемся легальной функций возвращения на прикладной уровень (которая, между прочим, недокументированна и варьируется от системы к системе). А других вариантов нет? Почему же? Ядро работает с кодовым селектором 08h, прикладной уровень — 1Bh, следовательно, для нуль -транспортировки достаточно изменить регистр CS с 08h на 1Bh. Но Syser отказывается воспринимать команду «r CS 1B», ругаясь на ошибку синтаксиса, хотя с синтаксисом все нормально. Syser определенно еще не доделан и, чтобы из-

менить CS, приходится щелкать мышью по окну с регистрами и модифицировать CS вручную, посредством графического интерфейса (хвост бы его побрал). После можно со спокойной совестью выйти из отладчика по <CTRL-F12> и… тут же попасть под артобстрел голубых экранов смерти, падающих один за другим. Если не сдаваться и мужественно возвращаться каждый раз на прикладной режим путем модификации CS, то (при определенной степени везения) можно дождаться относительного затишья и продолжить работать на прикладном уровне, как ни в чем не бывало.

Авот другое решение. Вместо того, чтобы нуль-транспор- тироваться на прикладной режим, оставляя ядро в аварийном состоянии, попробуем модифицировать функцию KeBugCheckEx, воткнув в нее машинную команду «RETN 14h», соответствующую машинному коду: C2h 14h 00h. Находясь в начале KeBugCheckEx, просто дадим команду «d eip» (отобразить в дампе памяти содержимое по адресу, на

который указывает регистр EIP). Щелкнув мышью по верхнему окну, заменим три первых байта на «C2h 14h 00h». Поскольку Syser — сырой продукт, синхронизация дампа памяти с окном кода отсутствует. Чтобы увидеть проделанные изменения,

Крис Касперски

Рецепты

недетского

похудания

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

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

Авыкинуть можно многое! Рядовой дистрибутив ужимается в три и более раз, при этом практически не теряет в функциональности. Большинство утилит можно сделать портируемыми — и все это средствами самой ОС! Итак, начинаем операцию!

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

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

лицензионных соглашений и прочий упаковочный «пенопласт» можно даже и не говорить!

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

Нашей задачей будет избавление от всего лишнего, включая «мусор», оставленный кривыми деинсталляторами в каталогах Windows и System32. Опытные хакеры, вооруженные отладчиками, дизассемблерами, файловыми мониторами, API-шпионами и прочей амуницией подобного типа, после непродолжительного исследования могут с полной уверенностью определить, зачем (не)нужен тот или иной файл и когда он

(не)используется. А как быть тем, кто смотрит на ассемблерные листинги, как на священные тексты, и ни черта не понимает, за какой хвост дергать отладчик, чтобы он сказал «му»?!

Существует множество варварских методов облегчения дистрибутива, проводимых в кустарных условиях подручными инструментами без всякой анестезии. Одно неверное нажатие <DEL> может запросто угробить весь дистрибутив или, что хуже, искалечить его. Сохранив возможность запускаться, изуродованная программа подло рухнет в самый ответственный момент. Впрочем, риск не так уж и велик, особенно если не злоупотреблять. К тому же переустановить «убитый» дистрибутив — не проблема.

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

Тайна трех печатей

Начиная с Windows 95, каждый файл прокомпостирован тремя временными штампами. Первый — время модификации (или так называемое MS-DOS время, оставленное, главным образом, в целях обратной совместимости), второй — время создания файла на диске, третий — время последнего открытия файла на запись или чтение.

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

Дата создания файла автоматически проставляется операционной сис-

>>

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

А вот время последнего обращения к файлу — самая большая ценность, так как благодаря ему мы можем легко и быстро отделить мусор от полезного stuff’а. Что происходит при запуске программы? Правильно: она обращается к определенным файлам, и штамп времени их последнего открытия неизбежно изменяется, что позволяет нам мгновенно определить, какие файлы необходимы программе, а без каких она может и обойтись.

Естественно, в процессе запуска программы загружаются только базовые компоненты и вовсе не факт, что их окажется достаточно для нормальной работы. Скажем, печать довольно часто реализуется в виде отдельной библиотеки, загружаемой лишь при нажатии иконки, символизирующей принтер. Загрузка компонентов по потребности — весьма распространенный прием программирования. И прежде, чем приступать к расчистке мусора, следует поработать с программой некоторое время, например, неделю или даже месяц, гарантируя, что за это время мы «выбрали» весь необходимый нам функционал, но не взяли ничего лишнего. Например, если случайно нажать <F1> — загрузится раздел справки (и, возможно, динамические библиотеки, обеспечивающие его функционирование). Штамп времени последнего обращения ко всем этим файлам будет автоматически изменен, хотя они нам ни хвоста не нужны. Так что в процессе набора статистики следует вести себя предельно осторожно: не делать резких движений и не нажимать тех кнопок (пунктов меню), без которых можно обойтись.

Приступаем к операции

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

Жмем <CTRL-F9> для сортировки файлов по времени доступа и давим <Ctrl-5> (не <F5>, а просто <5>), заставляя FAR отображать время доступа, которое он по умолчанию (вот подлец!) не отображает.

Вот, например, результат исследования каталога C:\ Program Files\Microsoft Visual Studio\VC98\ Bin (смотри скриншот), в котором компилятор MS Visual Studio хранит свои исполняемые файлы. Как мы видим, его содержимое четко делится на три основные группы. В первую попадают постоянно используемые файлы, образующие ядро компилятора. Последний раз все они открывались в течение одного дня — 19.02.08, а точнее, в 23:43. Вторую группу образуют редко используемые файлы, открываемые в период с 15.02.08 по 16.01.08. Прожить без них можно, но… сложно. В третью группу попадают файлы, последний раз открытые несколько месяцев назад, причем в одно и то же время — 23.10.07/20:20, что, вероятно, произошло при антивирусной проверке или глобальном контекстном поиске. Вполне логично, если автор в течение полугода (а может, и больше) спокойно жил без этих файлов, то проживет и дальше, а потому их можно удалить или перенести на внешний носитель, например, на DVD. Просматривая содержимое папки Windows, мыщъх обнаружил, что 70% объема приходится на файлы, которые практически не используются. MS Office показал более скромную цифру, едва преодолев планку в 62% (притом, что он изначально был установлен в минимальном комплекте, в частности автор не инсталлировал Excel и прочую не нужную лично ему муть). Но все-таки 62% — немало! И это пространство занято реально невостребованными компонентами, которые могут быть беспрепятственно удалены или перемещены на DVD, FLASH или сетевой диск.

Главное достоинство предложенного метода — в его точности (ложные негативные и позитивные срабатывания, то есть пропуск нужных файлов, практически полностью исключены), высокой скорости (на поиск редко используемых файлов уходят считанные минуты) и «демократических» требованиях к квалификации пользователя. Главный же недостаток — в том, что из тех файлов, к которым

warning

Экспериментируя с файлами приложения, ты рискуешь сделать его неработоспособным. Будь осторожен, чтобы

приложение не рухнуло в самый последний момент.

dvd

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