Техника хакерских атак Фундаментальные основы хакерства




НазваниеТехника хакерских атак Фундаментальные основы хакерства
страница50/50
Дата публикации06.09.2013
Размер6.7 Mb.
ТипДокументы
shkolnie.ru > Информатика > Документы
1   ...   42   43   44   45   46   47   48   49   50
^

Неточности, недоговорки


1) "Почти все функции, создающие объекты ярда, принимают указатель на структуру SECURITY_ATTRIBUTES" как аргумент… Большинство приложений вместо этого аргумента передают NULL и создают объект с защитой по умолчанию. Такая защита подразумевает, что администратор и создатель объекта получают к нему полный доступ, а все прочие к объекту не допускаются" стр. 9.

Гм-гм, выходит, если к объекту необходимо допускать всех остальных, как часто и бывает, придется явно инициализировать SECURITY_ATTRIBUTES? Конечно же, нет! По умолчанию допускаются все пользователи со всеми полномочиями – будь то запись, чтение или еще что. Проверьте – создайте новый файл вызовом CreateFile, передав вместо атрибутов секретности NULL, и попытайтесь открыть его, войдя в систему под другим пользователем. Открывается? Вот и славненько!
2) "…если Вы создаете диалоговое окно, какой смысл формировать список одним потоком, а кнопку другим" стр. 53.

Смысл есть – пусть один (или несколько) потоков, занятых, скажем, поиском файлов на диске, создают один (или несколько) элементов списка для вывода результатов своей работы, а кнопка "Стоп" их всех "срубает".
3) "^ Как узнать, например, чьим объектом – User или ядра – является данный значок? ...проанализировать Win32 функцию, создающую объект. Практически у всех функций, создающих объекты ядра, есть параметр, позволяющий указать атрибуты защиты". стр. 9

Не очень-то надежный способ! Вот, у функции HINSTANCE LoadLibrary(LPCTSTR lpLibFileName) нет никаких атрибутов секретности, но описатель HINSTANCE принадлежит ядру. Почему? Да хотя бы уже потому, что ядро ее и экспортирует, о чем и рассказывается в SDK. Если под рукой нет SDK, на помощь приходит тот факт, что функция содержится в библиотеке kernel32.lib и, стало быть, – "ядреная".
4) "…по завершении процесса операционная система гарантированно освобождает все ресурсы, принадлежащие эту процессу" стр. 12.

…если только процесс не вызвал исключение, вызывающие его аварийное завершение. Именно поэтому приходится перегружать машину после очередного "зависания" того же Word-а, – иначе при попытке открытия последнего редактируемого файла, будет выдано сообщение – файл уже открыт другим процессом и работать с ним невозможно. Хороший программист должен предусмотреть такую ситуацию и принять адекватные меры по ее устранению.
5) "^ Имейте ввиду: описатели объектов наследуются, но сами объекты нет (курсив Рихтера)" там же

Ух, ты! килограмм не длиннее литра, да еще курсивом! Объекты ядра принадлежат ядру ОС, но не породившему их процессу, которому остается довольствоваться только описателями (дескрипторами) этих объектов. Поэтому о наследовании объектов ядра другими процессами говорить просто некорректно.
6) "^ Первый и третий параметр функции DuplicateHandle представляют собой описатели объектов ярда, специфичные для вызывающего процесса" стр. 18

Брр… ничего не понял! А вы, читатель? На самом деле, эти параметры описатели процессов – процесса-источника и процесса-приемника (точнее, выражаясь терминологией самого же Рихтера – псвевдоописатели)
7) "^ Граница между двумя типами приложений [консольных и графических –KK] весьма условна. Можно, например, создать консольное приложение, способное отображать диалоговые окна…" стр. 25

Тип приложения указывается в заголовке исполняемого фала и однозначно определяет механизм его загрузки и инициализации. Тот факт, что консольные приложения имеют доступ к GDI-функциям, а графические приложения могут создать консоли не позволяет делать вывод об "условности" границ между обоими типами приложений.
8) "^ Завершение потока" стр. 60.

К трем перечисленным Рихтером способам завершения потока (ExitThread; TerminateThread; завершение процесса, породившего поток) необходимо добавить и четвертый (кстати, самый популярный и простой из всех) – return. Т.е. возврат управления главной функции потока.
9) "^ В Windows 95 все четыре описанные функции не предусмотрены. В ней не удается даже загрузить программу, вызывающую любую из этих функций" стр. 72

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

Вообще же, в отношении функциональности Windows 95, Рихтер очень туманен и выражается то "приложение, использующее такие-то функции не будет работать в Windows 95", то "приложение, использующее такие-то функции вообще не удастся загрузить в Windows 95". Очень важно отличать отсутствие функций и отсутствие их реализаций. Первых – в Windows 95 вообще нет, вторые как будто-то есть, но при попытке вызова всегда возвращают ошибку. Рихтер, увы, различает эти два случая не всегда.
10) "^ Любой поток может вызвать эту функцию [SuspendThreadKK] и приостановить выполнение другого потока. Хоть об этом нигде и не говорится (но я все равно скажу!), приостановить свое выполнение поток способен сам, а возобновить без посторонней помощи – нет… Поток допустимо задерживать не более чем M " стр. 72

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

Второе – приостановка осуществляется не только SuspendThread, но и массой функций таких как: Sleep, WaitFor…

Третье – эти функции, в частности Sleep, позволяют потоку самостоятельно контролировать свое "засыпание" – "пробуждение". Ну, во всяком случае, без явного вызова ResumeThread другим потоком.
11) "^ Если система почему-либо не свяжет EXE-файл с необходимыми ему DLL-модулями, на экране появится соответствующее сообщение, а адресное пространство процесса и объект "процесс" освобождаются" стр. 164

Не могу удержаться, чтобы не заметить, что в Windows 2000 при запуске процесса из консольного приложения сообщение о неудачной загрузке DLL не появляется и процесс тихо "кончает", оставляя пользователя в недоумении – почему он не работает?!

Поэтому, теперь программисту недопустимо игнорировать результат успешности завершения CreateProcess и необходимо самостоятельно вызывать GetLastError для донесения до пользователя причины ошибки. Не стоит надеяться на операционную систему – отныне она это уже не делает.
12) "Семейство Interlocked функций" стр. 312

Описывая эти синхронизующие функции, Рихтер упустил одно немаловажное обстоятельство – большинство компиляторов в большинстве случав для приращения (уменьшения) значения переменной на единицу, используют ассемблерные команды inc [var] и dec[var] соответственно. Они не могут быть прерванными на середине операции и заботится об их синхронизации незачем.

Не прерываются и операции сложения (вычитания) 32-разрядной переменной с 32-разрядной константой, а так же все аналогичные битовые операции4.

Исключения:

а) 64-разрядные переменные;

б) известная "болезнь" ранних компиляторов от Borland – выполнение всех операций с переменными как минимум в три этапа: mov reg,[var]\ ops reg,const\ mov [var], reg;

в) сложные случаи адресации, разбиваемые компилятором на несколько стадий – вычисление эффективного адреса и приращение (уменьшение) переменной, расположенной по этому адресу.
13) "^ Если бы этот код выполнялся в Win32 приложении без блока try-finally и оно завершилось бы из-за неправильного доступа к памяти в Funcinator, семафор остался бы занят и не освободился – соответственно и ожидающие его потоки не получили бы процессорного времени" стр. 522

Постой, постой. Какие потоки? Если потоки самого процесса – так ведь они тихо скончались вместе с самим приложением, а если потоки других процессов – так ведь после завершения процесса семафор будет освобожден операционной системой. Так что принудительное освобождение семафора в этом случае – очевидное излишество.
14) "^ Это простейший способ внедрения DLL [добавления внедряемой DLL в ключ реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\ CurrentVersion\Windows\APPINIT_DLLSKK].. Однако здесь есть ряд недостатков… Ваша DLL будет спроецирована лишь тех процессов, на которые отображен и USER32. А последнее делается только в GUI-приложениях, т.е. данные способ не подходит для программ консольного типа, - например, компиляторов или компоновщиков." стр. 602

В документации от Microsoft и в технических статьях сторонних авторов, содержащихся в том же MSDN, утверждается, что этот способ срабатывает для всех процессов системы. Сейчас проверил на Windows 2000 – действительно, внедряемая DLL послушно проецируется даже на консольные приложения.

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

^

Досадные описки и ляпы


1) "Флаг HANDLE_FLAG_PROTECT_FROM_CLOSE [передаваемый функции SetHandleInformation – KK] сообщает системе, что данный описать закрывать нельзя… Если какой-нибудь поток попытается закрыть защищенный описатель, CloseHandle приведет к исключению" стр. 15

Какое – такое – исключение? CloseHandle всего лишь вернет NULL, сигнализируя об ошибке…
2) "DuplicateHandle(GetCurrentProcess, hObjProcessA, hObjProcessB, &hObjProcessB….)" стр. 21

Опечатка – третий аргумент должен быть hProcessB.
3) "^ Кроме адресного пространства, процессу принадлежат такие ресурсы как файлы…" стр. 23.

Файл – объект ядра и принадлежит ядру, но не процессу.
4) "В Windows 95 функции CreateFileMapping можно передать флаг PAGE_WRITECOPY" стр. 170

Пропущено слово "только", ибо других флагов Windows 95, увы, не поддерживает!
5) "^ PAGE + WRITECOPY" стр. 174

Досадная опечатка – конечно же должно быть PAGE_WRITECOPY.
6) "Обычно критические секции представляют собой набор глобальных переменных" стр. 220.

Критические секции – не переменные! Структуры CRITICAL_SECTION, передаваемые им, действительно часто хранятся в глобальных переменных, но это – дурной тон и гораздо лучше размещать их в куче или структуре данных, передаваемой синхронизуемым потокам через lpvThreadParam.
7) "имена файлов и каталогов могут включать буквы разного регистра, но при поиске файлов и каталогов регистр букв не учитывается. Если файл с именем ReadMe.txt уже существует, создание нового файла с именем README.TXT уже не допускается" стр. 416

Тут Рихтер противоречит сам себе – страницей назад от утверждал, что NTFS различает регистр символов, а главой вперед – чтобы заставить ее делать это, достаточно воспользоваться флагом FILE_FLAG_POSIX_SEMANTICS.
8) "…система создает для нового процесса виртуального адресное пространство размером 4 Гб и загружает в него код и данные как для исполняемого файла, так и для любых DLL" стр. 36

Не загружает, а проецирует. Разница принципиальна! Загрузка подразумевает считывание с диска и записи в память, но Windows поступает умнее – исполняемый файл и DLL трактуются как часть виртуальной памяти (о чем позднее сам же Рихтер и рассказывает в главе "Проецируемые в память файлы").

Заключение


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

Доверчивать читателей – вполне простительна, но для авторов это – тяжкий грех. Если уж взялся за перо (тьфу ты, за клавиатуру) будь любезен прежде чем печатать что-то тщательно проверить – правильно ли это или нет!


1 А может и чуточку раньше

2 Например, Microsoft Visual C всегда, независимо от прототипа функции main передает ей три аргумента – указатель на массив указателей переменных окружения, указатель на массив указателей аргументов командной строки и количество аргументов командной строки, а все остальные функции стартового кода принимают меньшее количество аргументов

3 Тип Turbo-Pascal

4 Зачастую сказанное остается верным и для 16- или 8- разрядных переменных, но некоторые компиляторы для увеличения быстродействия расширяют переменную до 32-разрядов, а потом обнуляют ее старшую часть. Естественно, содержимое переменной между этими операциями содержит мусор.
1   ...   42   43   44   45   46   47   48   49   50

Похожие:

Техника хакерских атак Фундаментальные основы хакерства iconXss новичкам. Предназначение xss-атак
Приветствую Вас, уважаемые посетители Портала! Зовут меня DrWeb. Я хочу рассказать Вам о предназначении xss-атак, поскольку xss-уязвимости...
Техника хакерских атак Фундаментальные основы хакерства iconЭлективный курс Фундаментальные эксперименты и фундаментальные константы...
В ходе изучения данного элективного курса учащимся создаются условия для решения следующих образовательных задач
Техника хакерских атак Фундаментальные основы хакерства iconУрока информатики и икт в 9 классе по теме «Кодирование графической и мультимедийной информации»
В нем рассматриваются как фундаментальные основы представления информации в электронном виде и общее понятие композиции, так и конкретные...
Техника хакерских атак Фундаментальные основы хакерства iconЭлективный курс Фундаментальные эксперименты и фундаментальные константы...
В ходе изучения данного элективного курса учащимся создаются условия для решения следующих образовательных задач
Техника хакерских атак Фундаментальные основы хакерства iconУчебное пособие Дунаев И. В. г™ Основы лечебного массажа (техника...
Основы лечебного массажа (техника и методики). Учебное пособие.— М.: Ивц «Маркетинг»; Новосибирск: ООО «Издатель­ство юкэа», 2000.—480...
Техника хакерских атак Фундаментальные основы хакерства iconУчебное пособие Дунаев И. В. г™ Основы лечебного массажа (техника...
Основы лечебного массажа (техника и методики). Учебное пособие.— М.: Ивц «Маркетинг»; Новосибирск: ООО «Издатель­ство юкэа», 2000.—480...
Техника хакерских атак Фундаментальные основы хакерства iconАннотационный отчет Номер и наименование конкурсной темы. Блок "Ориентированные...
Блок "Ориентированные фундаментальные исследования". Раздел «Информационные технологии и электроника». Подраздел " Электроника и...
Техника хакерских атак Фундаментальные основы хакерства iconПрограмма фундаментальные основы человеческого общения. Иллюзия понимания....
Все, кто заинтересован в улучшении своих коммуникативных навыков, умения влиять, убеждать
Техника хакерских атак Фундаментальные основы хакерства iconВыставки
Тематика: сельскохозяйственная техника, в частности, тракторы, уборочная техника, системы орошения и другое
Техника хакерских атак Фундаментальные основы хакерства icon«Детско-юношеская спортивная школа» Опыт работы
В основе игры в баскетбол, как в любой другой спортивной игры лежит техника. Чем совершенней техника игры, тем выше её уровень. Техника...
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2014
shkolnie.ru
Главная страница