Флешбэки FoxPro. Ломаем приложения на VFX и познаем секреты защиты ReFox

Язык прог­рамми­рова­ния 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 упо­рядо­чива­ем бло­ки по раз­меру — и дей­стви­тель­но, в самом начале спис­ка огромный блок, которо­го не было в момент стар­та прог­раммы. Прав­да, в нем содер­жится, на пер­вый взгляд, пол­ная каша с огромной энтро­пией, но про­буем доб­рать­ся до ее источни­ков.

Пе­реза­пус­каем прог­рамму и ста­вим бряк на какую‑нибудь фун­кцию Kernel32 (ска­жем, WriteFile). При каж­дом оста­нове про­веря­ем кар­ту памяти — oops! — перелет, в оче­ред­ной раз блок уже при­сутс­тву­ет, при­чем сно­ва запол­нен кашей. Не мудрствуя лукаво, прос­то ста­вим Hardware Breakpoint на пер­вый байт это­го бло­ка и переза­пус­каем прог­рамму. Нам сно­ва повез­ло — этот нечес­тный трюк ока­зал­ся эффектив­ным: аппа­рат­ная точ­ка оста­нова сра­баты­вает имен­но на записи в све­жень­кий, запол­ненный нулями блок FoxPro-шной сиг­натуры FEF2. Запус­каем выпол­нение до кон­ца про­цеду­ры (Execute till return) и получа­ем на блю­деч­ке блок, целиком запол­ненный рас­шифро­ван­ным и рас­пакован­ным кодом, который мож­но дам­пить. Что мы и дела­ем.

Ка­залось бы, тут и сказ­ке конец, а кто сдам­пил — молодец. Судя по сиг­натуре и содер­жимому, мы получи­ли чис­тый APP-модуль со сня­той защитой, который мож­но сме­ло иссле­довать. Но не тут‑то было. ReFox уже приз­нает, что это VFP-при­ложе­ние, даже вер­сию видит, но деком­пилиро­вать и показы­вать струк­туру отка­зыва­ется. Сам APP при запус­ке валит интер­пре­татор с какой‑то умо­пом­рачитель­ной ошиб­кой, дру­гие деком­пилято­ры тоже на него руга­ются, и толь­ко Corso видит спи­сок фай­лов, из которо­го соб­ран дан­ный APP. Выбор у нас неболь­шой, поэто­му про­буем починить файл при помощи Corso.