Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Под вековыми пластами накопленных человечеством компьютерных знаний погребено множество ископаемых языков программирования и забытых технологий. Некоторые из них навсегда канули в Лету, другие еще используются в узких областях человеческой деятельности. Одна из таких технологий — FoxPro, популярная в девяностых система управления базами данных, которая использовалась когда‑то едва ли не в половине российских бухгалтерий. О принципах взлома FoxPro мы и поговорим в сегодняшней статье.
Язык программирования FoxPro применялся для разработки файл‑серверных реляционных баз данных и управления ими, хотя возможности языка позволяли найти ему значительно больше практических применений. Технология, появившаяся в 1989 году, базировалась на языке dBase, который использовался, в частности, в одноименных системах управления базами данных, из‑за чего между правообладателем, компанией Ashton-Tate, и Fox Software даже происходили судебные разбирательства. FoxPro быстро завоевал популярность на рынке СУБД и стал своеобразным стандартом разработки такого рода приложений. Были выпущены версии FoxPro для UNIX, MS-DOS и Macintosh.
В 1992 году, после долгих и мучительных переговоров, длившихся целых три года, компания Fox Software была приобретена корпорацией Microsoft, дальше технология FoxPro развивалась уже под крылом коммерсантов из Редмонда. Со временем была выпущена визуальная среда программирования Visual FoxPro, но технология понемногу утрачивала позиции в пользу более современных программных продуктов. Последняя версия FoxPro для Windows увидела свет в 1994 году, еще до официального релиза Windows 95. Однако с повсеместным переходом с 16- на 32-разрядную архитектуру основанные на FoxPro СУБД окончательно устарели и понемногу ушли в историю.
Сама Microsoft прекратила поддержку этой технологии больше пяти лет назад. Тем не менее, по слухам, где‑то в глубинах сибирской тайги еще встречаются написанные на FoxPro приложения, которые никто не собирается переписывать с нуля. Тем более исходники таких программ обычно утеряны, а последний программист, помнивший синтаксис FoxPro, давным‑давно умер от старости. Поэтому чисто теоретически может возникнуть необходимость реверсинга подобной программы с целью понять, как она вообще работает. Да и покопаться в такой древности — интересная задача сама по себе.
Казалось бы, ничего сложного в этом нет: среда представляет собой интерпретатор псевдокода, достаточно простой и примитивный, декомпиляторов для него было написано великое множество еще в девяностые годы прошлого века (автор одного из них — ваш покорный слуга ;)). С появлением VPF и ReFox вопрос совсем потерял актуальность — любой скомпилированный модуль можно реверсировать до состояния компилируемого проекта буквально в одно нажатие кнопки. Если бы не одно но.
Создатели ReFox не являются бескорыстными фанатами свободного программного обеспечения: они создали хороший коммерческий продукт, справедливо полагая, что для любой интеллектуальной собственности непременно отыщутся желающие ее спереть. И они выпустили свою собственную защиту компилируемых приложений, где можно выбрать аж целых пять типов протекции разной степени сложности. Разумеется, защищенную таким способом программу не декомпилировать ReFox’ом в один клик. Но на то мы и хакеры, дабы преодолевать подобные ограничения.
Не будем останавливаться на простых случаях, когда приложение представляет собой классический набор APP, FXP, FRM, FRX и прочего (хотя там тоже есть нюансы, но о них мы поговорим позже). Давай сразу перейдем к самому нехорошему варианту.
Итак, к нам попадает некий EXE-файл с хорошей компрессией. По косвенным признакам мы предполагаем, что он похож на защищенное VFP-приложение. Известные детекторы протекта нам не особо помогают, единственная зацепка — наличие оверлея с сигнатурой FEF2 (Overlay : FEF2EE... Nothing discovered
). Вообще‑то, это сигнатура любого FoxPro-шного файла. Развивая данную идею, отрезаем оверлей и пробуем скормить его специально обученным утилитам.
В качестве маленького лирического отступления расскажу пару слов о том, чем можно пользоваться для вивисекции VFP. При всем многообразии написанного на эту тему софта, в конкурентной борьбе выжило всего несколько инструментов, достойных упоминания. В первую очередь это, конечно, упомянутый ReFox, которому по большей части и посвящена данная статья. Несмотря ни на что, проект поддерживается (во всяком случае, так заявлено на сайте разработчиков). Актуальная версия на данный момент — XII 12.99/16 от ноября 2019 года. Существует еще французский проект DVFP, но он давно не развивается, и у меня не получилось достичь при использовании этой тулзы сколь‑либо значимых результатов.
В сети хвалили китайский Unfoxall, но из‑за специфики китайского сообщества найти хотя бы работающую дему для сравнения лично у меня не получилось. Правда, я особо и не старался. Отдельного упоминания достоин проект Corso: он хоть и не является декомпилятором в полном смысле этого слова (собственно, сама декомпиляция псевдокода в программный текст сделана обращением к внешнему серверу и по факту не работает), однако содержит много полезных фич для разборки проекта, о которых будет сказано ниже.
В общем, вытащили мы оверлей с сигнатурой наружу, скормили по очереди всем возможным утилитам и… ничего! Тулзы говорят: мол, да, сигнатура есть, да, использован неизвестный энкриптор и компрессия, но не более того. Но мы настойчивые и сдаваться в самом начале пути не собираемся.
Загружаем приложение в отладчик. Ну, допустим, под рукой у нас оказался OllyDbg. Для начала просто запускаем программу и, когда загрузится основное окно, прерываемся в произвольный момент, радуясь отсутствию защиты от отладчика и всплытия. Еще один приятный момент — успешный поиск по памяти процесса текстовых строк (которые мы до этого тщетно пытались найти в закодированном EXE-модуле). Более того, вокруг найденных строк явно раскодированный псевдокод FoxPro (строки со счетчиком, имена процедур и так далее).
Однако сдампить его, как нам хотелось бы, одним куском нельзя — фрагменты кода нарезаны в блоки буквально «по живому»: начало текстовой строки находится в одном блоке, конец в другом. В общем, собирать все это сложно и грустно, тем более объем весьма большой. Попробуем зайти с другой стороны: поскольку код явно компрессированный, вероятно, в какой‑то момент он был распакован и уж потом нашинкован в лапшу. В окне Memory Map упорядочиваем блоки по размеру — и действительно, в самом начале списка огромный блок, которого не было в момент старта программы. Правда, в нем содержится, на первый взгляд, полная каша с огромной энтропией, но пробуем добраться до ее источников.
REFOX не принимает сдампленный APP
Перезапускаем программу и ставим бряк на какую‑нибудь функцию Kernel32 (скажем, WriteFile
). При каждом останове проверяем карту памяти — oops! — перелет, в очередной раз блок уже присутствует, причем снова заполнен кашей. Не мудрствуя лукаво, просто ставим Hardware Breakpoint на первый байт этого блока и перезапускаем программу. Нам снова повезло — этот нечестный трюк оказался эффективным: аппаратная точка останова срабатывает именно на записи в свеженький, заполненный нулями блок FoxPro-шной сигнатуры FEF2
. Запускаем выполнение до конца процедуры (Execute till return
) и получаем на блюдечке блок, целиком заполненный расшифрованным и распакованным кодом, который можно дампить. Что мы и делаем.
Казалось бы, тут и сказке конец, а кто сдампил — молодец. Судя по сигнатуре и содержимому, мы получили чистый APP-модуль со снятой защитой, который можно смело исследовать. Но не тут‑то было. ReFox уже признает, что это VFP-приложение, даже версию видит, но декомпилировать и показывать структуру отказывается. Сам APP при запуске валит интерпретатор с какой‑то умопомрачительной ошибкой, другие декомпиляторы тоже на него ругаются, и только Corso видит список файлов, из которого собран данный APP. Выбор у нас небольшой, поэтому пробуем починить файл при помощи Corso.
Источник: xakep.ru