Subj: Поле чудес_____________________________

Деятель из Арзамаса создал "Капитал-Шоу", которая теперь чуть ли не в любой конторе на любой машине стоит. И все бы хорошо, да вот досада — не наградила судьба утилитой для редактирования и добавления слов. Автору, видно, лень было клавиши нажимать, и ввел он всего-то 450 слов. Для заядлых поклонников, как говорится, на одну затяжку...

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

Пару слов о программе. Она написана на Turbo Pascal 6.0 с самопальными графическими библиотеками. Как и все программы, написанные на языке Pascal, в исполняемом коде выглядит ужасно. Мастдаевский стиль автора для "того" времени любопытен. В смысле оптимизации (ее отсутствия). Неупакованный словарь можно было бы объяснить параноидальной склонностью к оптимизации по скорости, однако на диске словарь занимает больше двух собственных размеров.

Словарь расположен в файле pole. ovi, но ни по структуре, ни по способу загрузки это совсем не ovi, а обычный типизированный паскалевский файл, в котором хранится массив строк stringl0xl4]. Первый элемент массива — число слов в строковом представлении.

Каждое слово представлено двумя элементами массива — первый элемент слово, второй — тема. Да-да, одна и та же строка с темой повторяется десятки раз! Словом, тут не все оптимально... Особенно если учесть, что лишь очень редкое слово занимает 0х14 байт, а место под него отводится.

Замечу по ходу дела, что в конце строк расположен "мусор", однако этот мусор "вытянут" с машины автора без его ведома и согласия. Что в стеке было, то и попало. В подобных системах (разве что резервирующих места на два порядка поболее этого) есть определенный риск "упустить" все что угодно — от фрагментов конфиденциального текста до интернетовских паролей. Так что систем без дыр не бывает.

Однако визуально слова имеют довольно плохую читабельность. Сразу в голову лезут кодировки разные там, циклические сдвиги и ксоренья. Увы. Это бывает часто, но здесь причина другая. Плохая читабельность — это не попытка сокрыть слова от пользовательского взгляда и HIEW-a, а еще одно проявление "трудолюбия" автора, которому, видимо, лень было строить таблицу для перевода строчных русских букв в заглавные. Проще добавлять/отнимать 0х20.

Но я никак не пойму: зачем? Зачем автор вводит с клавиатуры буквы в верхнем регистре, весьма коряво переводит их в нижний, который и сохраняет в словаре, а потом обратно переводит в верхний. Как я ни старался, но убедительных причин найти для объяснения необходимости таких махинаций я не нашел.

Таким образом, словарь нетрудно просмотреть/изменить hiew-om, а для ленивых использовать мою утилиту.

Формат:

str Все строки паскалевские, для незнающих Procedure Decode (s: string)

String [$14] выглядит так: var _N_WORD______________________________________ a: word;

word_l Length string мусор begin

team_i byte length for a:=1 to Length (s) do

word_2 0х15 asm

team_2 N_Word в строковом десятичном или les bx, [BP+4]

шестнадцатиричном представлении add bx+a

>SUB Byte ptr ES: [bx], 20h _//_ end

end;

Subj: SGWW password protection 'WhiteEagle'

Попался мне на CD электронный журнал SGWW. Но, попытавшись раскрыть arj-архив, я с удивлением наткнулся на пароль. Ну пароль и пароль. Но когда на другом диске (скорее всего, перепечатка) я наткнулся на тот же самый "закру­ченный" файл, то призадумался. К тому времени я собрал подборку журналов SGWW, которую с интересом пролистывал. Но "закрученного" номера в моей коллекции еще не было. Жаль. Но слабость алгоритма шифрования arj уже стала "притчей во языцех", и даже "лобовой" атаки на ключ методом перебора не требовалось. Впрочем, я ради эксперимента оставил на ночь "атакующую" программу, которая к утру так и ничего не нашла.

Известно, что используемая в arj схема шифрования при наличии открытого фрагмента шифротекста может быть легко раскрыта. Однако, в этом-то обычно и заключается проблема: далеко не всегда "злоумышленнику" доступен хотя бы фрагмент архива в нешифрованном виде. Но у меня такой фрагмент был! (Впрочем, это не было очевидно.) Им был файл pgpkey в каталоге INFO — он совпадал с имеющимся у меня из восьмого номера (что видно по длине и дате файла).

Таким образом, мне не составило труда расшифровать все остальные файлы и найти пароль "WhiteEagle". Десятисимвольный пароль можно было найти и лобовой атакой на ключ. Так что защита все же несерьезна, что бы об этом ни говорили. Атака по словарю также могла бы раскрыть это за доступное для анализа время.

Поэтому еще раз хотелось бы обратить внимание на то, что человек, заявля­ющий: "только не просите меня взломать пароль ARJ" вряд ли может называться хакером. Право, не стоит переоценивать возможности существующих широко распространенных защит, и тем более полагаться на них в серьезных случаях.