Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Поведение при большом количестве записей в hosts #231

Open
de-served opened this issue Jan 5, 2024 · 9 comments

Comments

@de-served
Copy link

  1. При превышении некоторого количества записей хостов в System32\drivers\etc\hosts после каждого сканирования, даже начального, показывается лишь мизерная часть хостов.

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

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

  4. Вероятно следовало бы показывать все найденные изменения, а не порционно по 40 строк за раз.

  5. Однако в случае огромного числа записей это будет абсолютным трешем, соответственно лучше всего добавить некую функцию по добавлению всех имеющихся записей хостов в список игнорирования разом (допустим, пользователь уверен в текущем своём hosts и хочет просто добавить всё в игнор и следить только за изменениями с текущего момента) - может кнопку "добавить все хосты в игнор", может вопрос при сканировании при обнаружении большого числа записей (необязательно если сканирование впервые, хосты можно массово прописать после первого использования hijackthis - на просторах есть утилиты, добавляющие массово опасные хосты в hosts)

  6. Вероятно в таком случае разумнее всего список игнора как и настройки хранить в отдельном файле нежели в реестре - что-то вроде "портабельной" версии, в том же %AppData%. Так и переносимость будет проще в случае краха/поломки/переустановки системы (за много лет не сталкивался, но в последнее время много экспериментов творю на живой системе, и увалил несколько раз за полгода... ищу так сказать "золотую середину" - и каждый раз ставил всё с нуля, и самое худшее при переносе данных - возня с реестром, поиск зависимостей, какая программа в какой/каких ветках складывает свои данные + ещё нередко встречается и в реестре и в файлах...). Импорт старых настроек из реестра предыдущих версий сходу не прошёл - оказалось, что в текущей версии путь записей в реестре отличается от каких-то прошлых - раньше было в TrendMicro\HiJackThisFork (и всегда создавалась пустая ветка TrendMicro\HiJackThis), а теперь просто в корне HiJackThis+...

Соответственно, если будет добавлена возможность хранения в .ini в %AppData%, то при выборе такого варианта переносить настройки из реестра в .ini, если они хранились в реестре.

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

@de-served de-served added the bug label Jan 5, 2024
@dragokas
Copy link
Owner

dragokas commented Jan 5, 2024

Приветствую!

При превышении некоторого количества записей хостов в System32\drivers\etc\hosts после каждого сканирования, даже начального, показывается лишь мизерная часть хостов.

Для управления большим числом хостов служит инструмент Hosts File Manager, однако именно с огромным числом (к примеру > 1k) хостов он не тестировался. Интересно, как себя поведёт. Интеграции с игнор-листом там конечно нет, но вполне можно добавить.

Вероятно следовало бы показывать все найденные изменения, а не порционно по 40 строк за раз.

это сделано как раз потому что:

Однако в случае огромного числа записей это будет абсолютным трешем

также, у списка результатов есть свой лимит; и на прошлой версии интерфейса (v2) это вызывало значительные подвисания программы, надо взглянуть как сейчас обстоят дела

соответственно лучше всего добавить некую функцию по добавлению всех имеющихся записей хостов в список игнорирования разом

да, это пожалуй разумная идея, в списке результатов уже есть похожий по назначению пункт:

O1 - Hosts: Reset contents to default

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

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

Делать подобное ради экономии на реестре не вижу смысла, т.к. реестр по своей архитектуре является базой данных, которая как раз и предназначена для хранения большого числа записей с максимальной скоростью доступа к ним. Hosts с примерно 10к записей (пусть по ~ 40 символов на каждую) должен увеличить общий объем реестра на не более чем 1 MiB. Это вообще ни о чем.

На счёт собственно портативной версии, она пока в проекте, в низком приоритете. Однако, в плане переносимости игнор-листа, он специально зашифрован и не может быть перенесён на другой ПК простым экспортом/импортом. Так было сделано ради защиты от вредоносов, которые таким же способом обходят сканер HiJackThis. Тем не менее, после ваших слов я сейчас подумываю, что можно реализовать иначе и тратить время на шифрование вообще не понадобится. В окне сканирования можно добавить предупреждение, чтобы было явно видно, что игнор-лист не пуст, а при проверке из-под AutoLogger там в любом случае применяется ключ для отключения обработки игнор-листа. При этом в меню программы как вариант, можно добавить удобный пункт "Импорт/Экспорт настроек". Подумаем над этим.

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

Это уже есть.

@dragokas dragokas added enhancement and removed bug labels Jan 5, 2024
@de-served
Copy link
Author

de-served commented Jan 6, 2024

Делать подобное ради экономии на реестре не вижу смысла, т.к. реестр по своей архитектуре является базой данных, которая как раз и предназначена для хранения большого числа записей с максимальной скоростью доступа к ним. Hosts с примерно 10к записей (пусть по ~ 40 символов на каждую) должен увеличить общий объем реестра на не более чем 1 MiB. Это вообще ни о чем.

Тут скорее не об экономии места речь, а о выделении конкретных данных в отдельную запись. Скорость обращения к реестру фактически такая же, как и скорость обращения к файлу, ничем не отличается. Только хранение/перенос осложняются.
Да и при изменении данных в реестре фактических записей на диск происходит несколько больше, чем если бы это было просто редактирование файла.
Касательно вопроса шифрования данных - если они шифруются в реестре, то точно так же могут шифроваться и в файле %))) Разницы никакой :))

PS: о Hosts File Manager не знаю, у меня три других редактора hosts. (а, наверное понял - речь о встроенном в HJT редакторе)
Размер hosts ужатый по 8-10 записей в строку у меня около 800 килобайт.

@dragokas
Copy link
Owner

dragokas commented Jan 6, 2024

Да и при изменении данных в реестре фактических записей на диск происходит несколько больше, чем если бы это было просто редактирование файла.

Если речь о простом не-индексированном списке, то нет. Когда файл с записями не фиксированной длины, то для изменения одного элемента требуется перезаписать весь файл, с чтением аналогично - чтобы прочитать одну запись, требуется ее поиск. Не хочу усложнять утилиту. Когда появится портативная версия, то в ней и будут все настройки (не только hosts) в отдельном файле. А пока можно ограничится простым импортом/экспортом. Простой батник с

reg export "HKEY_LOCAL_MACHINE\SOFTWARE\HijackThis+" HJT-Settings.reg

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

Касательно вопроса шифрования данных - если они шифруются в реестре, то точно так же могут шифроваться и в файле %))) Разницы никакой :))

Речь не в том, есть шифрование или нет, а в том, что в данный момент оно залочено под конкретную машину. Если перенести игнор-лист на другую машину, то ключ не совпадёт и список там расшифруется неправильно.

P.S. Еще раз, обращу внимание, что реестр от такого увеличения в размерах не станет работать медленнее. Там все реализовано на хешировании и указателях. Вот если часто перезаписывать данные, то происходит эффект фрагментации. Но это не как с диском, скорость все равно не падает, по той же причине - это база данных. От фрагментации будет страдать размер реестра. Но и это решаемо, например, с помощью вспомогательной утилиты defrag, которая распространяется с ABR, используемой внутри HJT. В комплекте HJT ее нет (вырезана), но можно скачать с сайта автора: http://dsrt.dyndns.org:8888/files/abr.zip

@de-served
Copy link
Author

Я 30+ лет с компами, живу с ними, необязательно расписывать всё :)
У меня скрипт(ы) на установку всего, в т.ч. этой программки, и там есть экспорт-импорт.
Возня вся когда впервые выясняешь все детали, где/что/как хранит, как это всё выдергивать и как это всё потом обратно "засовывать".
Проблема не только с переносом на другую машину. Проблема даже в самой переустановке системы - если идёт переустановка без обновления поверх, а полная, то пересоздаются все криптоключи, и потом летит много чего.
Например перенести хром и ему подобный софт становится практически нерешаемой задачей. И если у меня на прошлой многолетнеработающей установке было в хроме 20 аккаунтов активных, то за несколько переустановок за последние 6 месяцев со всеми этими экспериментами-ломаниями-воскрешениями... с хромом по сути больше всего головняка такого мощнейшего. Учитывая, что аккаунты разбросаны по разным телефонам и людям. Но это уже другая история.

Реестр если и дефрагментировал когда, то Registry Workshop. Мощнейшая штука, если не знаком - рекомендую всячески.

@dragokas
Copy link
Owner

dragokas commented Jan 6, 2024

Привычка, расписывать подробно. Тогда меньше недосказанности и предположений.

Реестр если и дефрагментировал когда, то Registry Workshop. Мощнейшая штука, если не знаком - рекомендую всячески.

хорошо :)

@de-served
Copy link
Author

de-served commented Jan 6, 2024

Реестр если и дефрагментировал когда, то Registry Workshop

Ага, похоже память подвела. Инструмент что надо, однако сейчас полазил по менюхам и не нашёл дефрагментации реестра. Либо выпилили (что врядли), либо в какой-то другой софтине, но сходу не вспомню какой. А ведь точно перед глазами всплывает окно с информацией о дефрагментации - сколько сейчас, сколько после дефрагментации, уведомление о необходимости перезагрузки... 👀

Не подвела, всё же. Надыбал скриншот в инете - была такая функция в Registry Workshop
image

@dragokas
Copy link
Owner

dragokas commented Jan 7, 2024

Попробовал. Даже скрытые ключи показывает*, правда не все. А вот поиск очень быстрый и результат списком, что очень удобно. Спасибо, что посоветовали.
*PS. При том, видеть видит, а удалять не умеет, gg, ну да ладно основное назначение инструмента не для этого...

@de-served
Copy link
Author

de-served commented Jan 7, 2024

А ПКМ да управление правами доступа, разве не помогает?
Я пока не натыкался на то, что с этим инструментом чего-то нельзя сделать. Хотя может и не всё пробовал, конечно.
Дефрагментацию и бекап реестра удалили из последней версии с комментарием "для избежания проблем в Windows 10". Очень странный whatsnew.

@dragokas
Copy link
Owner

dragokas commented Jan 7, 2024

Там не в правах дело. Разработчик либо не знает, либо не стал заморачиваться, либо не захотел предоставлять такую возможность всем подряд (что собственно и правильно сделал :)) И это не так легко реализуется. Вообщем, ушли в оффтоп...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants