Привет всем!
Есть следующая задача: Существует файл с бинарными данными. Необходимо автоматически(!) определить, являются ли данные корректным исполняемым кодом, а не потоком мусора. Формат файла не содержит заголовков и начинается сразу с кода (типа COM формата в ДОС).
Понятно, что решения будут точными только с какой-либо степенью вероятности. Но вот какие бы найти пути к таким решениям?

Если не линкованный и передавать управление ему бессмысленно то только парсить. Так что придется тебе основательно засесть за книжки/исходники дизасмов.

Поправьте если не прав.


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

Valery

Если не линкованный и передавать управление ему бессмысленно
Заранее не известно, что в файле содержится... И передать управление то можно, но вот результат непредсказуемый :)

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

На счет SEH тоже ничего не получится, т.к. файл может быть 16-разрядным DOS приложением, да и если найти возможность отлавливать исключения при выполнении такого кода, это все равно ничего не даст. Например файл состоящий из последовательности 02010201.....0201... исключения (под NTVDM) не вызовет однако совсем не будет являться при этом осмыссленным.

Ну... тут ты не совсем прав по поводу дизасма.
посмотри хорошо в hiew результы дизассемблера - там могут появиться бредовые (в прямом смысле слова ) комманды. Т.е. расшифровать такой opcode используя intel manual не получается. Вот тебе и признак бердовости -)
Следующий момент - не забываем о распаковщиках и мутирующем коде - тут дизассемблер не поможет.

Можно задействовать БД с сигнатурами популярных форматов данных (BMP, GIF, PNG, RTF, MDB, ...) и сравнивать. Если ни один не совпадает, то парсим на предмет принадлежности к текстовому формату (поиск слов). Если и не TXT, можно поискать конкретные микроинструкции и т.д.

Да, для примера могу предложить посмотреть юниховую комманду file

Orb
Извини за 2 глупых вопроса:

Откуда эти файлы берутся.
Если точно знаешь откуда, то каково (возможное) их кол-во.

Если есть ответы, то можно попробовать статистический анализ.
Или это академическая задача заданная безумным профессором? :)

Если есть ответы, то можно попробовать статистический анализ

И это уже сделано. z0mbie собрал библиотечку по встречаемости опкодов в файле. Просто ты можешь подсчитать количество всех различных байт в твоем файле и сравнить его с эталонным. С некоторой степенью вероятности, понятное дело :)

volodya


О! Вот это первая здравая идея

:)

volodya
Это применительно только к большим (несколько Кб) файлам, но идея всё равно хороша.

S_T_A_S_

Задача, можно сказать, полуакадемическая :)
Файлы берутся абсолютно произвольным образом... Это может быть и текстовый файл, и картинка и исполняемяй com/exe, дамп памяти, база данных, либо вообще специально подсунутый мусор... Т.е. Ограничений на содержимое (как впрочем и на размер) нет!

Некоторое из предложенного уже частично реализовано. В начале анализа происходит именно то, что предложил Quantum, т.е. поиск по известным форматам. Таким образом распознается соержимое определенной части тестиремого набора. Затем происходит статистический анализ, но только на предмет выяснения категории файла (текстовый-бинарный) если кому интересно, то вот ссылка на статью с описанием методов. Я посмотрел рекомендованную volodya утилиту. Действительно, для PE-файлов можно проследить некоторую статистику наиболее встречающегся опкодов и сама идея подсчета статистики опкодов, а не байтов интересна. Но тут есть следующие минусы:
- Предположение, что опкод имеет длину только один байт может вносить погрешность (хотя это впрочем легко исправить);
- Идея полноценно применима только для PE(NE,LE) файлов, а это не очень актуально, т.к. они распознаются по формату еще в начальной стадии. Для простых бинарных файлов (com например) она дает сильную погрешность за счет хранения данных вместе с кодом;

Я попробовал реализовать то же, что предложил Zombie, но для набора com файлов. Вот что получилось (в каждой строке приводятся 16 самых часто встречающихся опкодов для каждого файла):

20; 72; 65; 41; 0A; 5A; 69; 2E; 42; 70; 53; 61; 6C; 6D; 49; 6E;
00; FF; 8E; 80; 02; 0E; 33; 05; 5E; 3D; 5A; 5B; 61; 39; 4D; 8B;
E8; 66; 68; 8E; B8; 8C; 6A; 2E; 03; 0F; BB; C1; CD; E2; FA; 50;
20; 61; 73; 45; 47; 63; 64; 79; 66; 4F; 72; 6E; 52; 0A; 53; 42;
75; 65; 69; 73; 20; 74; 6E; 6F; CD; 72; B4; 70; BB; B9; 6C; 61;
00; 2E; 0E; 1E; B4; E8; CD; 8E; 20; A0; 01; 02; 03; 50; A8; A5;
00; 20; CD; BA; 74; B8; E8; B4; B7; B9; 3C; 83; B0; B3; BB; 6E;
FA; 00; 73; 20; 2E; CD; 75; 74; 6F; 4E; B4; 61; B8; 65; 8E; 72;
00; E8; 74; 07; 8B; 70; 75; 3B; FF; C3; 44; 4F; 2E; 52; 6F; 64;
20; 69; 1F; 0E; 65; 74; AB; F3; 21; 87; 61; 6C; 75; 1E; 56; 07;
20; 69; 74; 65; 0E; 1F; 21; 61; 87; 8E; AB; F3; 09; 4B; 6F; 79;
EB; 8B; E8; 00; 74; 83; EE; C3; 26; B0; 2E; EC; 75; B8; 80; 07;
00; 20; 02; 0A; 01; 03; 05; 3F; 0F; FF; 2E; 2A; 75; 24; 15; 08;
8B; 74; E8; B4; C3; CD; F7; B8; 3C; 75; 8A; B2; B0; 80; 57; EB;
00; 20; FF; 01; 08; 45; 10; 6C; 39; 52; 73; 54; 41; 74; 0C; 0D;
E8; E9; 8B; 83; 74; 75; 72; 89; FF; C3; 73; C7; 33; B9; EB; F8;
00; FF; 6F; 74; 61; 73; 6E; 01; 63; 65; 04; 05; 53; 43; 42; 14;
00; 80; 26; 01; 75; 02; 04; EB; 03; 46; 33; E9; 06; 53; 17; 47;
00; 20; 01; 54; 64; 4D; 4C; 45; 4F; 07; 53; 3A; 2C; 41; E9; 08;
B4; CD; 73; 03; BA; 72; 80; 2D; 05; 74; 8B; 8C; B0; B1; B8; BB;
00; 4C; 53; 4E; 24; 55; 49; 50; 4B; E9; 02; 03; 04; 05; 06; 07;
B8; 50; 59; E8; 8B; 89; 83; CD; FF; 75; 2E; 74; EB; B4; 0B; 8C;
00; FF; B8; 8E; 36; 20; 3C; BA; CD; 2E; E7; 8C; 7E; B9; 42; 10;
66; 8B; C7; 89; C3; E9; 88; 83; 56; 5E; 25; E8; 57; 00; 5F; C8;
66; 20; 74; 2E; 3C; B4; E8; 72; BA; 80; 75; B0; EF; 65; C3; EB;
89; 8B; 80; 75; 26; 56; 2B; 83; B9; FF; E8; D3; BF; 73; 4D; 8C;
8B; E8; FF; 50; 89; B8; CD; EB; 75; 8C; 2E; 8E; B4; B9; 0E; 2B;
6C; 68; E5; DC; 35; AE; F3; 54; 0E; 61; 63; ED; DE; 5A; 0C; 39;
00; 20; E8; E9; 80; CD; C6; 74; 75; B4; 8B; 90; EB; C7; F6; 2B;
00; 45; 41; 54; FF; 01; 49; 03; 44; 42; 4C; 55; 05; 80; E9; 4E;
00; A1; 78; 6F; 70; 6D; 4D; 06; 43; E9; FA; 04; 05; 07; 08; 09;
00; FF; 03; 04; 0D; 02; 5E; 0F; 75; 80; 76; 25; 77; 0C; 82; 90;
00; C3; 83; 8B; E8; EB; F9; 2E; FF; B6; 75; F8; 04; 72; 74; 8E;
E8; 73; 99; B1; C3; EB; B2; 57; 2B; 42; 33; 41; 8B; BE; BF; C0;
3C; E6; 74; 2E; B0; EB; 00; 32; 75; 1F; 8A; AC; B1; 0B; 76; 0E;
4A; 1B; E9; 01; 02; 03; 04; 05; 06; 07; 08; 09; 0A; 0B; 0C; 0D;
8B; 89; 75; 83; 80; 26; BF; CD; D3; 2B; E8; 72; FF; 8C; 8E; B4;
78; 43; 41; 54; 4B; 1F; 1E; 20; 2E; CD; B8; 00; BA; 56; B4; 42;

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

Quantum
можно поискать конкретные микроинструкции

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

Orb
Если задача все таки полуакадемическая, самый простой способ ее решить - понять, что нужно академику :)

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

Самое кайфовое, если там окажется что-нибудь типа FORMAT <все подряд> !!! :))))

Orb
Если можно, расскажи поподробнее на эту тему...
Я имел в виду опкоды push, retn, mov, int и подобных инструкций, без которых не обходится ни одна программа.