Как идентифицировать иконку?

[ger_kar]

В последнее время задолбали вирусы, которые маскируются под простые папки и благодаря глупым юзерам просто массово распространяются на флешь носителях. И в организациях где мне приходится обслуживать компьютеры, уж в который раз, снова и снова, приходится чистить эту заразу, поэтому возникла мыслишка, сканировать флешки и загодя удалять эту заразу, но сразу же возник вопрос, а как идентифицировать иконку файла на предмет является ли она рисунком папки, либо нет? Саму иконку найти в ресурсах не проблема, но вот определить, что рисунок является рисунком папки, что-то нет даже приблизительной идеи. Хотя конечно она идейка есть, но она мне, что-то совсем не нравится. Т.е. найти рисунок папки в ресурсах Shell32.dll и выполнять побитовое сравнение, но это во первых будут тормоза, а во вторых, иконка в идентифицируемом файле может несколько отличаться от иконки в Shell32.dll и тогда при сравнении получится пшик!
Вообщем мой мыслительный процесс встал колом и дальше никаких идей не генерирует, поэтому и решил обратиться к коллективному разуму.
Поделитесь идеями

[Qwertiy]

Нейронная сеть приходит в голову...

А вообще, попиксельный анализ не такой уж и долгий. Только лучше искать сходство, а не полное совпадение. Наверняка можно какую-нибудь эвристику придумать, типа изменения цвета, совпадения области прозрачности и ещё чего-нибудь такого.

PS: А антивирус поставить не вариант?

[ger_kar]

Наверняка можно какую-нибудь эвристику придумать, типа изменения цвета, совпадения области прозрачности и ещё чего-нибудь такого.

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

PS: А антивирус поставить не вариант?

Так он стоит, только толку от него никакого, точнее толк есть, но в борьбе с вирусами, которые действительно суть вирусы, но то с чем мне приходится сталкиваться, по сути - то и вирусами назвать сложно, ибо они как правило настолько банально и топорно написаны, что только диву даешься. Основная масса написана на AutoIt Script, который наверное является самым простейшим языком программирования, но тем не менее сыскал себе славу у вирусописателей в нашем регионе. Причем эти горе вирусописатели плодят их в неимоверном количестве и разнообразии. А эвристический анализатор антивирусов их никак не идентифицирует. Пока эта херня не расплодится, пока не попадет в антивирусные базы, антивири на неё никак не реагируют, но а потом, а потом уже поздно. Конечно в силу свой топорности чистка этой заразы особого труда не составляет, но делать раз за разом одно и тоже уже никакой мочи нет.

Кстати, а как найти иконку в файле ресурсов например Shell32.dll ? По каким критериям вообще ее искать? В смысле не программно (это я знаю), а вручную в Hex редакторе, что бы визуально представить не картинку иконки, а байты, байты, байты (как в матрице ) и созерцать их, причем из разных версий Shell32.dll и злополучных вирей, выискивая закономерности. Может тогда, меня озарит, какая либо идея.

[dormouse]

Я сначала по названию темы не понял даже, о чём в ней речь и подумал, что это что-то про OCR или вроде того. Потом увидел активность и заглянул. Истинная тема меня развеселила
1. для отключения автозагрузки есть сотни твикалок. Есть просто рекомендации по правке реестра. Надо только погуглить на эту тему.
2. основной механизм всей это флешовой заразы (при попадании на неоттвиканный комп) - "заражение" её поддельным автораном. Файл autorun.inf, в котором написано, что надо запускать. Этим зараза распространяется дальше. Чтоб этот файл не возникал, можно обмануть винду. Создать папку с таким же именем. Но т.к. вирусня способна стирать своего предшественника, надо сделать эту папку неудаляемой. А вот для этого есть монструозный по своей деятельности батник:

Код: Выделить всё

attrib -s -h -r autorun.*
del autorun.*
mkdir %~d0\AUTORUN.INF
mkdir "\\?\%~d0\AUTORUN.INF\.."
attrib +s +h %~d0\AUTORUN.INF

Создаёте такой bat-файл (или cmd), закидываете его на флешку и запускаете там. Будьте осторожны. Прочитайте дальнейшее объяснение до конца прежде, чем запускать. В корне будет создана папка AUTORUN.INF, а внутри неё папка "..". Да. Две точки. Файловая система такое имя в навигации понимает, как выход из папки. В проводнике винды вы её даже не увидите. В тотал-командире сможете. На попытку её удаления файловая система попытается выйти из неё И не сможет ничего с ней сделать. Таким образом будет создана неудаляемая папка, которую вирус не сомжет заменить на свой авторан и на этой флэшке его путь остановится

[ger_kar]

Все это уже давно пройденный этап, ибо нынче эта дыра давно заткнута и нынче все совсем по другому и механизм распространения не имеет ничего общего с AUTORUN.INF. А происходит примерно следующее: Чистая флешка вставляется в зараженный компьютер. И после того, как она там побывала, на ней вместо папок появляются файлы *.lnk и *.exe с одноименным названием, а сами папки в лучшем случае становятся системными и невидимыми, а иногда переносятся в созданный в корне каталог \.., а в худшем удаляются или шифруются файлы.
Причем внешне все выглядит благопристойно, и не чего не подозревающий юзер, вставляя флешку в компьютер и открывая, как ему кажется любимую папку, тем самым запускает хрень на своем компе, и все антивири на это смотрят сквозь пальцы, а ежели и есть реакция, то она явно запаздывает.
И все пипец. приехали у юзера начинаются проблемы, даже если антивирусник с большим опозданием эту хрень почистит, то у юзера появляются сообщения о невозможности запустить файл при загрузке, вирь успевает ушатать настройки отображения скрытых файлов и папок, и таким образом юзер никак не может отыскать на флешке свои папки, ну т.д. А если произошло реальное удаления или шифровка файла, то и вообще ж...
Есть и другие варианты заражения с подменой, например если есть File.exe то он скрывается, а вместо него появляется File .exe или даже так
File.exe .exe, правда последний способ мне встретился только один раз.
Что касается меня, то у меня на моем компе, такие приколы не прокатят, ибо моя квалификация позволяет мне не попадаться на такие банальные уловки, но поди научи глупых юзеров. Это просто не реально, ибо борьба с их невежеством напоминает борьбу с ветряными мельницами, вобщем полная безнадега.

[Qwertiy]

А почему бы тогда тупо не искать совпадающие (т. е. похожие) имена в большом количестве?

[ger_kar]

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

[dormouse]

Может быть, тогда реагировать на любые exe и lnk? Как бы им не место на флэшке. Если это дистрибутив проги, то должен быть в архиве, а не в открытом виде.

[ger_kar]

Если это дистрибутив проги, то должен быть в архиве, а не в открытом виде.

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

[Qwertiy]

А можешь выложить набор иконок папок?
Если будет время, я бы с ними поэксперементировал

[VBTerminator]

А нельзя ли политиками просто запретить Windows запускать исполняемые файлы со съёмных носителей? А пользователям объяснить, что если они хотят запустить какую-то программу с флешки, то пусть сначала скопируют её к себе на жёсткий диск.

[Proxy]

А нельзя ли политиками просто запретить Windows запускать исполняемые файлы со съёмных носителей?

Они не всегда работают почему-то.

[ger_kar]

А нельзя ли политиками просто запретить Windows запускать исполняемые файлы со съёмных носителей?

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

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

В некоторых случаях это будет не очень удобно.

А можешь выложить набор иконок папок?

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

Злобный_замаскированный_вирь .rar

(552.22 Кб) Скачиваний: 370

[Qwertiy]

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

Моментально при распаковке :)

Злобный_замаскированный_вирь - Outpost.png (21.18 Кб) Просмотров: 16167

[iGrok]

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

Злобный_замаскированный_вирь - Outpost.png

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

[Qwertiy]

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

В принципе, возможно.
Кстати, почти все антивирусы вирус видят.

Я просто обратил внимание на фразы

Так он стоит, только толку от него никакого ... А эвристический анализатор антивирусов их никак не идентифицирует. Пока эта херня не расплодится, пока не попадет в антивирусные базы, антивири на неё никак не реагируют

и все антивири на это смотрят сквозь пальцы, а ежели и есть реакция, то она явно запаздывает.

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

[Qwertiy]

По поводу иконки. С помощью XN Resource Editor'а извлёк иконку (экспорт) из вируса и из shell32.dll. Полученные ico-файлы полностью совпадают. Так что, скорее всего тупое попиксельное сравнение в самый раз.

[ger_kar]

Вообще слово недавно я наверное употребил не очень корректно, хотя и само слово само по себе уж очень неконкретное
В действительности же это "недавно" случилось еще до нового года. На настоящее время сей экземпляр уже давно попал в вирусные базы и можно сказать исчерпал себя, но дело в том, что как заметил iGrok, "на завтра выпустят новую версию"... Вот уж поистине неутомимые люди эти вирусописатели, плодят неутомимо всякую заразу и не устают
А антивирусы реагируют как правило, в самом лучшем случае дня через три -четыре, а бывает и гораздо позже (статистика Nod32). Бывает и такая ситуация, когда эвристический анализатор выказывает свои подозрения, но при этом он тревогу не поднимает, а просто отправляет файл на анализ, в этом случае, при следующем обновлении антивирь уже на заразу реагирует, но пакость уже успевает натворить делов...

Полученные ico-файлы полностью совпадают. Так что, скорее всего тупое попиксельное сравнение в самый раз.

А может как нибудь оптимизировать этот алгоритм, например провести сравнение через пиксель, в этом случае, как мне кажется, результат будет тем же, но скорость сканирования возрастет в 2 раза. Может и другие оптимизации можно привнести в этот алгоритм, а может на оптимизацию и заморачиватся не стоит?

[ger_kar]

Кстати про ресурс на который дал ссылку Qwertiy я до этого ничего не знал. Ресурс мне понравился. Спасибо, теперь обязательно им буду пользоваться. Кстати там указано, что Eset ничего не обнаружил. Интересно, какой конкретно продукт использовался, потому как мой Eset Nod32 3 версии этот вирь вполне определяет.

[Qwertiy]

А может как нибудь оптимизировать этот алгоритм

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

Кстати про ресурс на который дал ссылку Qwertiy я до этого ничего не знал.

Я на него ссылку недавно на другом форуме увидел. Вообще, таких ресурсов достаточно много, кажется.

[ger_kar]

Алгоритм простой: для каждого формата иконки попиксельно сравниваем её с образцом такого же формата.

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

Я на него ссылку недавно на другом форуме увидел. Вообще, таких ресурсов достаточно много, кажется.

Может ресурсов много, но все когда нибудь открываешь для себя в первый раз

[Qwertiy]

Ну вообще я имел введу не простоту алгоритма, а его производительность.

Учитывая размер иконки, не вижу причин считать этот алгоритм непроизводительным, конечно, если не угораздит написать его через GetPixel (это про .NET). Для кажной иконки надо сравнить всего лишь (16*16*4 +16*16*8 + 16*16*32 + 24*24*8 + 24*24*32 + 32*32*4 +32*32*8 + 32*32*32 + 48*48*4 + 48*48*8 + 48*48*32 + 96*96*8 + 96*96*32) / 8 = 68672 байт (кстати, размер экспортированного файла 78942), т. е. на хорошей машине реально за секунду выполнить более 1000 сравнений. Конечно, с учётом того, что иконки ещё надо извлекать, это число будет намного меньше, но ведь извлекать их придётся в любом случае.

[ger_kar]

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

[ger_kar]

PrivateExtractIcons - Создает массив дескрипторов значков, которые извлечены из указанного файла.
Возвращает количество извлеченных иконок, в параметре phicon [out] возвращается указатель на возвращаемый массив дескрипторов значков.
А что дальше то с этим массивом делать. И какую природу имеет этот массив, т.е. каким образом он организован в памяти, где мне брать сами дескрипторы, подряд начиная с адреса по указателю? Или как то по другому. И потом дескриптор это же идентификатор, а не указатель на область памяти, куда загружен значок. Как мне найти этот значок в памяти, что-бы провести идентификацию, со значком папки, сравнив побайтно области памяти. Или я вообще иду не тем путем?

[iGrok]

Эмм.. Массив - он и есть массив. Подряд, начиная с полученного адреса.
Далее, например, можно вызвать для каждой GetIconInfo, которая заполнит ICONINFO для данной иконки.
А там уже и два hBitmap есть - маски и самой иконки. Дальше можно вызвать GetDIBits, и получить массив пикселей и прочую инфу об изображении.

[ger_kar]

Эмм.. Массив - он и есть массив.

Ну, оно то конечно так, но не все так однозначно, в мире массивов. Есть например SafeArray массивы. Они конечно в плане организации самих данных, если речь идет о дескрипторах ( фактически DWord 'ах), тоже будут идти подряд, но вот сама ссылка на массив будет ведь в этом случае указывать не на сами данные, а на структуру SafeArray, что потребовало бы совсем других методов обработки.

[ger_kar]

Вобщем пошел другим путем:
ExtractIcon - получаю количество иконок и еще раз для каждой иконки в цикле
получаю через тот же ExtractIcon хендл, а затем уже посредством LockResource получаю указатель на область памяти. Но эта область содержит группу иконок, а не одну единственную. В группе всего 15 иконок. Как теперь получить конец области памяти, где группа заканчивается?
И как как мне проводить сравнение, для отождествления с иконкой папки, сравнивать группу с другой группой или как то можно выделить и сравнить одну иконку. Так конечно было бы быстрее, но вот вопрос как это сделать?

[iGrok]

1) Чем тебе не понравился первый вариант?
2) Найти описание структуры группы. Ключевое слово, например, GroupIconDir, по нему выяснить айдишники иконок, входящих в группу, и получать уже их.

[ger_kar]

1) Чем тебе не понравился первый вариант?

Тем, что работает не всегда корректно, я вчера промучался с ним полдня, но так и не понял причины, по которой это происходит. Дело в том, что он почему-то иногда не срабатывает, причем на одном и том же файле. Например на 10 запусков 3-4 обязательно получались некорректными. Второй вариант до получения указателя на область с иконками работает стабильно, глюков замечено не было.

2) Найти описание структуры группы. Ключевое слово, например, GroupIconDir, по нему выяснить айдишники иконок, входящих в группу, и получать уже их.

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

[iGrok]

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

EnumResourceNames по RT_ICON -> EnumResourceLanguages по найденным -> FindResourceEx -> LoadResource.
Далее LockResource выдаст тебе указатель на данные, а SizeOfResource - размер даных.

Вот эти-то данные тебе и нужны.

З.Ы. Да, hModule для них получается при помощи LoadLibraryEx с флагом LOAD_LIBRARY_AS_DATAFILE (всё-таки потенциальную вирусню грузишь, нефиг её коду выполняться). Ну и FreeLibrary не забудь.