[reversing] Загадка о файле-невидимке

Dragokas

Angry & Scary Developer
Команда форума
Супер-Модератор
Разработчик
Клуб переводчиков
Сообщения
7,814
Реакции
6,593
aa148c35b21f619c41d20e4b48806d7d.png

Не так давно, закончив работу над очередной статьёй для Хабра, я решил оптравить её на ревью своему знакомому. Сохранив HTML-страницу со всем окружением (картинки, стили etc), я запаковал её в ZIP-архив и отправил адресату. Уже через пять минут я получил фидбек, который, вопреки моим ожиданиям, был связан вовсе не с самой статьёй, а с тем, что архив был абсолютно пустой. Почесав голову и решив, что я затупил с архивированием, я повторил процедуру, убедившись, что выделил все необходимые для запаковывания файлы. Спустя несколько минут знакомый снова разразился удивлённым «Ты что, шутишь?», в то время как я совсем не шутил.

Я начал собирать воедино все элементы паззла. Во-первых, я выяснил, чем он пытается открыть архив. Вдруг, в качестве viewer'а он использует какую-нибудь третьесортную фигню не пойми от какого разработчика? Однако им оказался дефолтный explorer.exe. Я же пользовался Total Commander'ом как для запаковки, так и для просмотра получившегося архива, и в моём случае он вовсе не был пустым:

8e3b87c8de14277f4bf4b77a8393579d.png

Что, неужели это сборочка xxxWindowsUltimateEditionxxx подкачала? Я попытался открыть тот же самый архив на моём компьютере при помощи explorer.exe и наконец поверил своему знакомому — архив действительно выглядел пустым:

359c2d8ec209e21b1bba35fcf17f59f8.png

Кто же виноват в таком поведении? Давайте разберёмся.

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов). Перед прочтением данной статьи также настоятельно рекомендую ознакомиться с предыдущими.
7-Zip в качестве архиватора содержимое получившегося архива спокойно отображается в explorer.exe. Проверка «проблемного» архива на ошибки встроенными средствами 7-Zip также ничего не выявила:

c5308a480ca1a9b9cd5e509ea953abcb.png

Кстати, Вы обратили внимание, что вместо символов '«' и '»' в оригинальном архиве Total Commander показывает underscore character ('_')? 7-Zip File Manager, в свою очередь, заменил '«' на символ '<':

eb101307d1134b7b8db654eea1fc17f9.png

Да что же такое? Давайте не будем гадать и посмотрим, чем между собой различаются ZIP-архивы в случае, когда один был запакован встроенным архиватором Total Commander'а, а второй — 7-Zip'ом.

Для начала создаём минимальный пример, воспроизводящий проблемную ситуацию — я остановился на пустом файле "«some_file.txt" (конечный архив будет называться "«some_file.zip"). Далее архивируем его обоими способами без сжатия и берём в руки XVI32, в котором открываем оба получившихся архива:

Проблемный архив
55d787580ff86178565881a7d20b7e5b.png

Нормальный архив
305b5ff228211ce95c68ba820472f37d.png

Уже невооружённым взглядом заметно, что их содержимое отличается друг от друга. Впрочем, это не должно пока что вызывать никаких конкретных эмоций, ведь архиваторы вполне могут писать информацию о себе любимых в какие-нибудь «дополнительные» поля. Чтобы убедиться, в чём именно заключается разница между этими файлами, давайте заглянем в спецификацию и на стороннее описание формата ZIP и «разобьём» наши байты на составные части:

Проблемный архив
Local file header

50 4B 03 04 -- signature
14 00 -- PKZip version needed to extract
02 00 -- General purpose bit flag
00 00 -- Compression
83 55 -- Mod. time
DC 46 -- Mod. date
00 00 00 00 -- CRC-32 checksum
00 00 00 00 -- Compressed size
00 00 00 00 -- Uncompressed size
0E 00 -- File name len
00 00 -- Extra field len
3C 73 6F 6D 65 5F 66 69 6C 65 2E 74 78 74 -- File name ("<some_file.txt")

Central directory file header

50 4B 01 02 -- Signature
14 00 -- Version
14 00 -- PRZip version needed to extract
02 00 -- Flags
00 00 -- Compression
83 55 -- Mod. time
DC 46 -- Mod. date
00 00 00 00 -- CRC-32 checksum
00 00 00 00 -- Compressed size
00 00 00 00 -- Uncompressed size
0E 00 -- File name len
00 00 -- Extra field len
00 00 -- File comm. len
00 00 -- Number of the disk on which this file exists
00 00 -- Internal attr.
20 00 00 00 -- External attr.
00 00 00 00 -- Offset of local header
3C 73 6F 6D 65 5F 66 69 6C 65 2E 74 78 74 -- File name ("<some_file.txt")

End of central directory record

50 4B 05 06 -- Signature
00 00 -- Number of this disk
00 00 -- Number of the disk on which the central directory starts
01 00 -- Number of central directory entries on this disk
01 00 -- Total number of entries in the central directory
3C 00 00 00 -- Central directory size
2C 00 00 00 -- Offset of cd wrt to starting disk
00 00 -- Comment len



Нормальный архив
Local file header

50 4B 03 04 -- signature
0A 00 -- PKZip version needed to extract
00 08 -- General purpose bit flag
00 00 -- Compression
84 55 -- Mod. time
DC 46 -- Mod. date
00 00 00 00 -- CRC-32 checksum
00 00 00 00 -- Compressed size
00 00 00 00 -- Uncompressed size
0F 00 -- File name len
00 00 -- Extra field len
C2 AB 73 6F 6D 65 5F 66 69 6C 65 2E 74 78 74 -- File name ("B«some_file.txt")

Central directory file header

50 4B 01 02 -- Signature
3F 00 -- Version
0A 00 -- PRZip version needed to extract
00 08 -- Flags
00 00 -- Compression
84 55 -- Mod. time
DC 46 -- Mod. date
00 00 00 00 -- CRC-32 checksum
00 00 00 00 -- Compressed size
00 00 00 00 -- Uncompressed size
0F 00 -- File name len
24 00 -- Extra field len
00 00 -- File comm. len
00 00 -- Number of the disk on which this file exists
00 00 -- Internal attr.
20 00 00 00 -- External attr.
00 00 00 00 -- Offset of local header
C2 AB 73 6F 6D 65 5F 66 69 6C 65 2E 74 78 74 -- File name ("B«some_file.txt")
0A 00 20 00 00 00 00 00 01 00 18 00 F0 88 3F D4 6D B1 D0 01 F0 88 3F D4 6D B1 D0 01 F0 88 3F D4 6D B1 D0 01 -- Extra field

End of central directory record

50 4B 05 06 -- Signature
00 00 -- Number of this disk
00 00 -- Number of the disk on which the central directory starts
01 00 -- Number of central directory entries on this disk
01 00 -- Total number of entries in the central directory
61 00 00 00 -- Central directory size
2D 00 00 00 -- Offset of cd wrt to starting disk
00 00 -- Comment len



Как видите, в случае проблемного архива символ '«' действительно по какой-то причине «превратился» в '<' (0x3C), в то время как в нормальном архиве он продолжает оставаться самим собой (0xC2 0xAB — именно так он представлен в UTF-8).

А что будет, если мы просто заменим '<' в проблемном архиве на '«', разумеется, попутно изменив значения остальных байт, на которые мы могли повлиять таким образом? Заменяем 0x3C на 0xC2 0xAB (обратите внимание, что сделать это необходимо сразу в двух местах), 0x0E 0x00 (File name len) на 0x0F 0x00 (это также необходимо сделать в двух местах), 0x3C 0x00 0x00 0x00 (Central directory size) на 0x3D 0x00 0x00 0x00 (т.к. мы предыдущими нашими действиями увеличили размер Central directory) и 0x2C 0x00 0x00 0x00 (Offset of cd wrt to strating disk) на 0x2D 0x00 0x00 0x00. В результате должно получиться следующее:

ea2e52e3213d49a2afada401eafd2015.png

Открываем получившийся архив в explorer.exe и видим:

073c6f4c4671acf5f42a88d0c8e4659f.png

Да, файл теперь виден, но с его названием явно что-то не так. Рыскаем по спецификации в поисках слова «unicode» и встречаем следующее:

APPENDIX D — Language Encoding (EFS)

D.1 The ZIP format has historically supported only the original IBM PC character
encoding set, commonly referred to as IBM Code Page 437. This limits storing
file name characters to only those within the original MS-DOS range of values
and does not properly support file names in other character encodings, or
languages. To address this limitation, this specification will support the
following change.

D.2 If general purpose bit 11 is unset, the file name and comment should conform
to the original ZIP character encoding. If general purpose bit 11 is set, the
filename and comment must support The Unicode Standard, Version 4.1.0 or
greater using the character encoding form defined by the UTF-8 storage
specification. The Unicode Standard is published by the The Unicode
Consortium (www.unicode.org). UTF-8 encoded data stored within ZIP files
is expected to not include a byte order mark (BOM)
Посмотрим, выставлен ли 11 бит поля флагов в наших случаях:

Проблемный архив
60053aae863d1a1aba1f127c76a904b8.png

Нормальный архив
404dac51e014b9a3ac9fbccb43923a91.png

Давайте выставим этот флаг в случае проблемного файла (Tools -> Bit manipulation)

1769fcb33fc713877b37de1419172a32.png

и попробуем ещё раз открыть наш архив в explorer.exe:

073c6f4c4671acf5f42a88d0c8e4659f.png

Точно, мы забыли, что поля флагов на самом деле два:

3a3e3b71659b15407baa4a194f438dd6.png

Выставляем необходимый бит и в этом поле и снова открываем наш архив:

5941a2e736e13d4a335feeff76a991b1.png

Здорово! Вот только почему Total Commander «превращает» символ '«' в '<'? Для того, чтобы понять это, возьмём в руки OllyDbg и запустим в нём исследуемый нами файловый менеджер. Хотя, подождите, давайте проверим, включена ли технология ASLR для totalcmd.exe. Загружаем его в PE Tools при помощи Alt-1, нажимаем на кнопку «Optional Header» и видим, что база меняться не будет (для более подробного описания данного процесса рекомендую посмотреть предыдущую статью):

093db2d47726c0663d40def10110139a.png

Очевидно, что для создания архива TC в начале должен воспользоваться WinAPI-функцией CreateFile, так что поставим бряки на её вызовах (вероятнее всего, в нашем случае он должен использовать юникодовую версию данной функции):

723928100728d207a7ca924f5ae1bd70.png

Убираем бряки, которые срабатывают на каждое ненужное нам действие (например, на событие получения окном TC фокуса — по адресу 0x00567264):

e8e2186dc54b76769bb9bb96126e8a95.png

Нажимаем Alt-F5 (комбинация клавиш для архивирования файлов в Total Commander'е), жмём на «OK» и оказываемся тут:

7326a05ddd6a11d4097db143f0653bdd.png

Давайте попробуем понять, выполнил ли уже TC преобразование символа '«' в '<'. Для этого откроем окно «Memory» при помощи Alt-M -> left-click по первой строке -> Ctrl-B -> вводим "<some_file.txt" в поле «ASCII»:

205e2bd89b69449895ffcc9cdf737d54.png

Нажимаем на кнопку «OK» и видим, что уже на данный момент приложение осуществило своё преобразование:

fd39e94a5216401bfc71fe5657014432.png

Нажимаем Alt-K, чтобы посмотреть на Call Stack:

a4a7ac61eed769dc419926bd1e7f2d1e.png

Ставим бряки на начало каждой из процедур в списке, нажимаем F9, удаляем получившийся архив и убеждаемся, что в памяти процесса больше нет строки "<some_file.txt". После этого снова запускаем процесс архивирования и останавливаемся в начале первой процедуры из показанного ранее Call Stack'а:

c98fc6d90d0a49d8987def9435ee60b3.png

Снова ищем ту же самую строку во всей памяти процесса и… Находим её:

a9200518cd70dec1f715edd40dff946a.png

Что ж, последний логичный на данный момент вариант — это поставить бряк на начало последней процедуры в Call Stack'е, из которой, собственно, нас сюда и позвали:

041c87567b389a29b0cbb1184b957d87.png

Прыгаем на вызов (right-click по строке с адресом текущей процедуры в окне Call Stack'а -> Show Call), бежим вверх до подсказанного OllyDbg начала процедуры и ставим на него бряк:

4ca5b26db4cf73b5a568123b1fe936e5.png

Проделываем те же действия, что и раньше (усиленно нажимаем F9, удаляем архив, проверяем память процесса на отсутствие строки "<some_file.txt", нажимаем Alt-F5 и кнопку «OK») и останавливаемся на только что поставленном бряке. Ищем ту же строку и… Снова находим её:

0aeaca94c2714a73834a1e06056a234b.png

Учитывая, что Call Stack на текущий момент пустой, можно предположить, что мы выполняемся в отличном от main thread'а потоке или же попали сюда в результате условного или безусловного перехода. Нажимаем Ctrl-R и видим:

0fef5fe1b6856f3c63742959629c5955.png

Прыгаем на единственную ссылку при помощи нажатия клавиши Enter:

d48217de9aee39c43172f3fc76019883.png

Смотрим, кто в свою очередь ссылается на эту строчку:

152176a7b37e8e7e5830ef49ca0604ff.png

Прыгаем туда:

4ab296677a6ba5b3b0ac5103988915c3.png

Заходим внутрь нескольких процедур и видим вызов WinAPI-функции CreateThread:

3562d6646cfeab05e11c6fb4e0b8959a.png

В принципе, убедиться в этом можно было бы и другим способом — для этого достаточно посмотреть на заголовок окна CPU, который в моём случае сообщал, что ID потока равен 0x000013B8:

4cc6e0a41fc30d2b1dd85c55235c4aca.png

При этом в окне «Log», открываемом по нажатию Alt-L, видно, что ID main thread'а равен 0x00001E30:

050d6b173e4c0a40da2233b58ccee3a0.png

Нажимаем Alt-F5, ставим бряки на вызовах CreateThread

5e8b5af4225a13014b80961c1a6b31da.png

, нажимаем на кнопку «OK» и останавливаемся на уже знакомом нам месте:

afd8c889b57018a0050fd89d63fe2379.png

Смотрим на Call Stack и методом «двоичного поиска» (делим кол-во входных параметров пополам и смотрим на результат) раскручиваем цепочку вызовов различных процедур до состояния, когда становится известно, после вызова какой именно из них в памяти процесса появляется строка "<some_file.txt" — ею является процедура, находящаяся по адресу 0x00491780. Посмотрев внимательно на то, что происходит внутри неё, мы можем обнаружить вызов WinAPI-функции CharToOem:

d0efb71b414de70036551a07116cc55a.png

Согласно официальной документации, данная функция переводит переданную строку в OEM-defined character set, причём, если используется ANSI-версия, мы можем выполнить т.н. «in place translation» (src и dest могут указывать на один и тот же адрес, что избавит от необходимости создавать отдельный буфер для конечной строки), что и происходит в случае TC:

lpszDst [out]
Type: LPSTR
The destination buffer, which receives the translated string. If the CharToOem function is being used as an ANSI function, the string can be translated in place by setting the lpszDst parameter to the same address as the lpszSrc parameter. This cannot be done if CharToOem is being used as a wide-character function
Да, после её вызова переданный ей буфер уже действительно содержит символ '<' вместо '«':

119cdd2b4f104777b8bf87b1585ffa5c.png

Что, будем патчить? А давайте сначала посмотрим на опции архивирования в TC:

a439fad4abe6460f9314ac9ab5ceb07a.png

По дефолту опция «Pack Unicode names» установлена в «Ask every time a Unicode name is encountered». Следовательно, TC не посчитал, что встреченное имя является юникодовым. А если попробовать заархивировать файл, например, с китайскими иероглифами?

1664a4f3753df4fa048f9da0989df3c6.png

Как видите, в таком случае TC отображает окно с сообщением о встреченном имени файла, который содержит символы, отличные от используемой кодовой страницы. В случае с символом '«' такого сообщения не было, вероятнее всего, потому, что многие code page'и (в моём случае, видимо, CP1251) содержат данный символ в отведённых им дополнительных «ячейках». А вот если выставить данную опцию в «All as UTF-8 if at least one contains characters>127», то мы увидим, что наш файл "«some_file.txt" корректно запаковывается и впоследствии отображается в explorer.exe.

Вы можете спросить «Почему, даже если имя файла сменилось с „«some_file.txt“ на „<some_file.txt“, explorer.exe не смог отобразить его хотя бы с изменившимся именем»? Дело в том, что '<' является одним из символов, которые запрещены для использования в названиях директорий и файлов в случае NTFS:

The following reserved characters:

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)
Более того, разархивировать такой архив встроенными средствами Windows также не получится. Во-первых, из-за символа '«' в названии самого архива:

e7c3ca9c297c4121212e4a145c9d02f0.png

Во-вторых, из-за его содержимого:

a3da7cf92aa5977e1d5565822dd3360c.png

Послесловие

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

Спасибо за внимание, и снова надеюсь, что статья оказалась кому-нибудь полезной.

Автор: @NikitaTrophimov
Источник
 
Назад
Сверху Снизу