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

Реализованно это с использованием пула неблокирующих сокетов, за это отвечает класс CSocketPool (classes/class.CSocketPool.php) более подробно изучайте в нем.

Пример для ясности. Мы хотим скачать три страницы:

• страница 1 - обрабатывается веб сервером 1 секунду
• страница 2 - обрабатывается веб сервером 2 секунды
• страница 3 - обрабатывается веб сервером 10 секунд

При последовательном скачивании мы затратим 13 секнуд. При параллельном всего 10 секунд. То есть общее время работы равно времени получения самой долгой страницы.

При использовании keep-alive соединений мы не тратим время на подключения и отключения от сервера. Каждый открытый сокет возвращается в пул keep-alive соединений и следующее подключение берется уже из этого пула

Это ускоряет работу как минимум на время пинга до целевого сервера + на время установки соединения

Поиск системных файлов подразумевает собой поиск и точное определение нескольких групп файлов. Таких как вывод phpinfo, phpmyadmin, sypex dumper.

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

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

Как известно, белый свет состоит из семи основных цветов, которые изменяются по мере уменьшения длины световой волны: красного, оранжевого, желтого, зеленого, голубого, синего и фиолетового. И, к примеру, находящиеся на орбите космонавты видят ослепительно-белое Солнце на фоне черного неба. Так и должно быть: составные части белого света доходят до них в безвоздушном пространстве без искажений, в то время как до Земли они доходят через «фильтрЋ атмосферы.

Помните, почему запретительный сигнал светофора — красный? Потому что красный цвет плохо рассеивается в стороны (он почти всегда рассеивается вдоль луча). Значит, что будет, если мы посмотрим на белое Солнце сквозь рассеивающий слой воздуха? Правильно: из семи цветов спектра меньше всего рассеется красный, чуть сильнее — оранжевый, желтый и так далее. Именно таким, оранжево-красным, мы видим Солнце на рассвете и закате. Чем выше оно поднимется над головой и чем тоньше слой атмосферы между нами и светилом, тем меньше рассеяние света, значит, тем желтее и белее будет становиться Солнце.

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

Таким образом: небо синее, так как длина волны синего света самая короткая. Из-за этого он рассеивается сильнее других.

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

Так же бинг очень часто меняет свою верстку, поэтому, после таких изменений, сканер может не работать. Регулярки можно править в файле classes/class.CBingReverseIP.php

Дело в том что информация в выдаче Бинга бывает устаревает и сайты за это время меняют свой IP. Всвязи с этим в выдачу бывает попадают сайты которые в реальности имеют другие ипы. И если логично подумать то такие сайты нам скорее всего нужны не будут.

Эта настройка уберет сайты с левыми IP относительно целевого ресурса. Опять же за идею настройки благодарим Grey-я

Сканер содержит сигнатуры строк содержащихся в индексном файле. Если сигнатура совпадает то производится поиск специфических файлов для этого движка и при 100%-ном наличии всех этих файлов делается вывод о том что это искомый движек.

После определения движка производится дополнительное определение версии движка, если такие сигнатуры присутствуют в базе.

PS: спасибо eLwaux за большую часть имеющихся сигнатур в данной базе, спертых из его тулзы.

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

Все сигнатуры хранятся в папке engines/ Для каждого движка должен быть определен свой файл. Он не должен начинатся с точки и должен иметь расширение .txt.

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

Не забудьте поделится со мной вашей новой сигнатурой =)

В алгоритм заложенны два варианта.

• По коду ответа вебсервера
• По содержимому страницы

Для определения варианта, запрашивается заведомо несуществующая страница (по дефолту: "noneexistspage"). Если код ответа адекватен, то используется первый вариант. В противном случае каждая искомая страница сравнивается с заведомо несуществующей и при превышении порога схожести считается существующей.

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

При таком анализе необходимо учесть тот момент что каждая несуществующая страница может отличаться. Поэтому точное сравнение нормальных результатов не даст.

В данном сканере существует два способа:

• алгоритм Оливера (стандартная функция similar_text)
• мой алгоритм (анализ количества каждого символа)

Первый способ дает очень точный результат, но при размере каждой страницы более 5кб занимает очень много времени (у меня на ноуте - 2 секунды, при увеличении размеров время растет нелинейно).

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

В сканере используется первый способ если каждая страница меньше 2кб, если больше то используется мой алгоритм. Если страница по результатам вычислений совпадает с заведомо несуществующей на 92% и более, то она также считается несуществующей

При использовании этого метода веб сервер отсылает нам только заголовок HTTP пакета, без содержимого. Благодаря этому мы снижаем трафик в разы, что может дать прирост в скорости работы.

Имейте ввиду что этот метод невозможно использовать если используется анализ ответа вебсервера по содержимому (см.выше)

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

• Нет - будут найденны каталоги в корне сайта (Пример: http://site/dir/)
• 1 уровень - будут найденны каталоги и их подкаталоги (Пример: http://site/dir/dir1/)
• 2 уровня - будут найденны каталоги и их подкаталоги и "под-подкаталоги" (Пример: http://site/dir/dir1/dir2/)

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

В папке dict/ хранятся данные словари. Все они обязательно должны иметь префикс pathes_ и расширение .txt

Следующее после префикса слово определяет группу файла (Пример: pathes_admin). И последнее слово определяет "полноту" словаря (Пример: pathes_admin_full), его указывать не обязательно.

Таким образом вы можете добавить любой свой словарь всего лишь залив его в эту папку и соответствующим образом переименовав.

Примеры валидных имен:

• pathes_config.txt
• pathes_css_blabla.txt
• pathes_css_full.txt
• pathes_css_small.txt

Будет созданно две группы: config - с одним словарем ("Полный поиск"), и css - с тремя словарями (blabla, "Полный поиск" и "Быстро")

PS: имейте ввиду: некоторые имена в интерфейсе заменяются, остальные будут отображаться как есть.

Вся проблема в том что очень часто разные файлы обрабатываются по-разному. Допустим для php файлов есть свой обработчик, для html файлов второй, а картинки отдаются третьим. И каждый обработчик генерирует свой ответ 404 ошибки.

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

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

Файл classes/class.CSearchFiles.php содержит описание групп файлов. А более конкретно их описывает класс CSearchFiles_Library.

И этот же класс содержит пример описания группы файлов. По аналогии добавить свой будет не сложно.

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

• Быстро - используется треть от доступных варинтов
• Средне - используется две трети от доступных варинтов
• Полный поиск - используются все варианты

Вот такой вот банальный метод, убыстряющий поиск. Идея не моя, привет Grey-ю =)

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

Искать уже найденные файлы на остальных хостах - отвечает за повторный поиск каждой группы на остальных хостах

Допустим нам надо найти phpinfo и по возможности на всех хостах (какаято особенно-хитрая настройка сервера). Для этого мы устанавливаем:
Искать уже найденные файлы на остальных хостах - да (нам нужны phpinfo на каждом сайте из списка)
Искать до первого файла из группы - да (нам не надо дублей phpinfo на одном и том же сайте)