Hi leonid!

Обфускатор это интересно - однако что-то мне кажется что это очень трудно осуществимо в реале - и даже без макроподстановок и EVAL-ов... Взять к примеру имена полей - как я понимаю они в объектнике никак от имён переменных не отличаются. С процедурами тоже будут проблемы - они и по имени файла могут опознаваться, и внутри его же по PROC/FUNC. Впрочем как альтернативный вариант - ручное задание фильтров (как Include так и Exclude) - например для переменных использование той же венгерской нотации уже даст неплохой фильтр

Теперь что касается старого вопроса про отлов хендла файла. Я посмотрел в VFP9SP1 - и прямо на входе в декодер вижу что EBP+ECX указывают на запись (структура размером 38h байт) в фоксовой таблице файлов, а там по +28h как раз и находится АПИшный хендл файла, блок из которого передан декодеру. Единственное замечание - эта фоксовая таблица динамическая, т.е. при одном вызове файл #3 будет указывать скажем на external1.fxp, а при другом уже на external2.fxp (т.е. сам по себе адрес начала структуры тут не поможет). Более того - фокс не держит fxp файлы открытыми дольше необходимого - и конечно проверять сам файловый хендл на предмет "а что же это за файл" тоже необходимо. Впрочем в этой структуре есть элемент +0Ch - это указатель на указатель на ASCIIZ строку с полным именем/путём к файлу.

P.S. Тут речь идёт именно про "физические" файлы.

Hi Igor!

Igor Korolyov
что-то мне кажется что это очень трудно осуществимо в реале

Сначала мне тоже так показалось, но потом я как раз и постарался вычленить ту часть, которая может быть реально осуществлена. Вот собственно, что получилось. Изменяться будут только локальные переменные, определенные командами lparameter и local. Здесь есть еще одно исключение. Если написать
то изменяться будут только переменные до первого массива включительно. В данном случае a, b и c. А d и f - нет. Это связано с тем, что выражение, определяющее количество элементов массива может быть как угодно сложным, и пройти его мне врядли по силам. Второе - имена локальных переменных, используемых в модуле (процедуре, функции, методе) не должны совпадать с именами других объектов (полей, таблиц, курсоров, свойств, методов, функций, процедур, и т.п.), используемых в этом же модуле. Мне кажется, для тех, кто пользуется венгерской нотацией это не сильное ограничение. И, наконец, локальные переменные не могут быть использованы в выражениях для передачи функциям type, eval и в макроподстановках. В принципе обфускатору можно указать, какие файлы обрабатывать, а какие нет. Т.е. те процедуры и функции, которые хочется защитить, можно специально написать так, чтобы они удовлетворяли вышеперечисленным условиям.

Цитата:

как Include так и Exclude

Этого у меня нет, но в принципе над этим тоже можно подумать.

Цитата:

Теперь что касается старого вопроса про отлов хендла файла.

Это я посмотрю. Сейчас не готов ответить.

Hi leonid!

Так ты что исходник обрабатываешь? Я думал ты прямо в объектном коде имена то портишь Исходник мне кажется немного сложнее потрошить...
И кстати если уж исходник ломать, то можно зайти с другой стороны - одна утилита из объектного кода вынимает все "имена" (возможно классифицируя их по тому в каких конструкциях они упоминались - это конечно требует частичной декомпиляции), и помещает их в специализированный коммент - а уже сам обфускатор читает этот коммент и использует как фильтр (причём по полному совпадению - тут уже не обязательны * да ?) - при этом руками всегда можно списочек то и подправить.
Ещё вариант "авто-расширения" списка (но не столь надёжный) - анализатор LOCAL+PUBLIC+{L}PARAMETERS и ловить отладочный вывод фокса при исполнении с включенным контролем _VFP.LanguageOptions = 1 (однако нет простой возможности прогнать через "исполнитель" все ветви программы - т.е. не все строки кода исполнятся при этом).

Hi Igor!

Igor Korolyov
Так ты что исходник обрабатываешь?

Нет, я как раз прямо в экзешнике. Изменение только локальных переменных объясняется тем, что нет необходимости синхронизировать изменения по разным процедурам, файлам, и т.п., а это сразу упрощает задачу на порядок. Нужно только, чтобы при изменении имен локальных переменных не изменились имена других объектов с теми же названиями. А поскольку локальные переменные, на мой взгляд, используются значительно интенсивнее, чем остальные, то после их изменения код становится читать очень трудно, по крайней мере, я собственный код разобрать уже не смог. Вот маленький примерчик
Кстати, его вполне можно запустить, насколько я помню, это функция, которая CRC16 от строки считает

А сдампить все это не проще? Уже после того, как прога запустилась. Адрес запуска проги известен. Затем замораживаешь саму виртуальную машину (VMWare) и ковыряйся на здоровье сколько хочешь - все ж открыто будет.

devilr
А сдампить все это не проще?

Проще чего?

Цитата:

Затем замораживаешь саму виртуальную машину (VMWare) и ковыряйся на здоровье сколько хочешь

А зачем VMWare? В памяти поковыряться и без этого можно.

Цитата:

все ж открыто будет.

Что все?

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

devilr
поковыряться в памяти не так уж и просто

Ну не так уж и трудно. Есть, например утилитка Winhex. Все как на ладони. Только выковырять из памяти что-нибудь полезное для декомпиляции совсем не просто. Там даже файлы целиком можно найти разве что, только очень маленькие.

Hi devilr!

В "служебных областях самой винды" - если под этим понимаются именно недоступные пользовательскому уровню Ring0 области (хотя большая часть винды это совсем не ядро) фоксового кода никак не будет
И вообще там мало чего интересного для нас.

Всё дело в том, что дамп памяти практически ничего не даёт для взлома... Нужно контролировать ход исполнения программы (в смысле самого vfpXr.dll - не подопытной фоксовой программы) - VM тут особо не помогут - тут тока родные Win32 отладчики годятся. А чтобы их без проблем использовать нужно сначала разобраться где и как код защиты проверяет наличие активного отладчика - вот в чём сложность состоит. Ну и конечно "плавающий" ключ дешифрации требует чтобы взломщик либо восстановил весь алгоритм шифрации (т.е. определил где хранятся ключи и как их использовать для раскодирования каждого кусочка закрытого файла) - и соответственно написал "универсальный дешифратор", ну или по тупому сидеть в отледчике и отлавливать все обращения к подопытному файлу - выкусывая по маленьким кусочкам расшифрованное содержимое - если для exe с 10-20 включенными файлами это ещё довольно просто решается, то для реально большого exe это по сути тупиковый путь - учитывая что фокс к каким-то частям программы может обращаться очень и очень редко...
Задача написания "универсального дешифратора" конечно решаема, но потребует довольно много времени и сил.

Igor Korolyov
недоступные пользовательскому уровню Ring0

В смысле Ring3, или я чего-то не понял?

Пару слов об обфускаторе. Обычное дело, пока что-то пишешь, в голову приходят идеи как все можно сделать значительно лучше. В результате сроки отодвигаются. Я уже отказался от того, что изменяться будут только локальные переменные, можно поработать и с некоторыми другими именами. Но поскольку в фоксе нельзя обфусцировать все подряд, то ответственность за то, что нужно обфусцировать, а что нет, перекладывается на пользователя обфускатором. А раз так, то хочется сделать его достаточно удобным, со всякими там запоминаниями в файл и т.п. Надеюсь, что к понедельнику я какую-нибудь бэту доделаю, только наверное хелп не успею написать.

Вот если кто хочет, может попробовать
Обфускатор
Хелпа пока нет, так что эксперементируйте.

P.S. Экзешник ничем не защищен, его легко можно открыть Рефоксом. Он только обработан сас собой. Так, для наглядности. Если кому-нибудь захочется перевести интерфейс на русский язык - ради бога.

И где, собственно, сам файл?

В смысле какой файл?

Все хорошо! Просто, некоторое время тому назад, с сайта возвращался пустой файл - длина =0
Сейчас все хорошо!

Выставил новую версию. Исправлены пара ошибок и добавлен русский хелп
Обфускатор

Выложил новую версию обфускатора Обфускатор
Реализовал одну новую идею (спасибо Вадиму Пирожкову за подсказку). Теперь, если обфусцированный файл декомпилировать Рефоксом, то результат получится достаточно странный, и ни работать в IDE environment, ни компилироваться не будет. Правда старый вариант тоже оставлен как опция, в первую очередь для того, чтобы можно было декомпилировать и с помощью дебагера выяснить в чем проблемы, если таковые возникли.

Написал новую версию DeFoxIII. Заметно усилена защита и добавлена возможность создавать приложения с возможностью регистрации через регистрационный код. Подробнее можно почитать в хелпе, а также посмотреть в прилагаемом примере.
DeFoxIII для VFP6SP5
DeFoxIII для VFP7SP1
DeFoxIII для VFP8SP1
DeFoxIII для VFP9SP1
Инструкция в формате Word
Проект с примером
Если нужны рантаймы, можно взять здесь
ftp.prolib.de

Hi leonid!

К сожалению в ближайшее время посмотреть никак не получится, сейчас в командировке, потом надо недельки 2 будет активно поработать, а то в отпуск в этом году не отпустят Но думаю что где-то к середине-концу осени может появиться свободное время...