for flooders
:: Главная :: Решения :: Статьи :: Сайт М. Дроздова :: Файловый архив :: Книга по VFP 9 :: Русский Help Online :: OFF-LINE Форум
   Лисоводы   всех   стран,  объединяйтесь !!!  

Список Форумов  :: Обсуждаем проекты
  

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 17.12.06 14:01:51
Hi Igor!

Igor Korolyov
1) Проверка рантайма не сработает если он загрузится не по стандартному адресу - я так подозреваю, что у Piva как раз этот случай.
Что-то я думал-думал, и никак не могу придумать ситуацию, при которой при запуске экзешника фоксовский рантайм может загрузиться не по стандартному адресу. Ну разве что вирус какой экзотический опередит его и займет его место. Но в это как-то не верится. Или Win2k SP4 так странно работает? По-моему это даже документировано, что если дллка может загрузиться на стандартное место, то она это делает. Мне кажется все-таки более вероятным битый рантайм. Это можно проверить, запустив на девятке или восьмерке команду
?SYS(2007,FILETOSTR("vfp6r.dll"),-1,1)
Должно получиться
1546457895

Цитата:
Я не совсем понял зачем тебе потребовалось менять RelocationTable - учитывая что она используется системой только в момент загрузки dll-ки (я честно говоря не очень представляю как можно влезть внутрь системного кода и успеть что-то исправить в секции .reloc до того как она будет использована по назначению). Может быть ты имел в виду не изменение а использование этой секции? Или речь идёт про .xdata секцию в защищённом exe/dll? Но разве там где-то требовался relocation...
Нет, мне RelocationTable нужно менять в защищаемой дллке - СОМ сервере. Там у меня в .text вставляется одна команда - прыжок на .xdata. Так вот она и портилась, когда СОМ сервер загружался не по стандартному адресу, поскольку я вставлял ее на место команды, которую надо было менять.

Цитата:
2) Откровенно говоря, при неудачной дешифрации очередного блока кода декодера может произойти что угодно - вплоть до вызова произвольной апишной функции, скажем DeleteFile
Ну это же надо еще чтобы и путь к файлу был загнан куда надо, а это уж совсем маловероятно. Скорее уж наверно может перезагрузка Windows произойти.
Цитата:
Однако я подозреваю что можно прицепить свой SEH (второй, не тот что сейчас в защите используется) и соответсвенно перехватывать все Exception-ы, отделять те из них что возникли внутри декодера и соотвественно выдавать своё сообщение - ну а если "не наше" - то передавать ошибку дальше - рантайму и т.п.
Пожалуй так можно сделать, но не шибко просто. Наверное я к этому еще не готов. А кроме того "свое сообщение" информативно врядли будет сильно отличаться от стандартного. Ну разве что кнопочку Send... приделать. Но ее все равно никто нажимать не будет. Мне как-то больше хочется сделать, чтобы при нормальном использовании программы Exception-ы не вылетали, а вылетали бы только при попытке взлома.

Цитата:
Кстати ты намеренно сделал так, чтобы 2 раза возникал Exception - один на INT3 и второй на попытку чтения по адресу 90909090, или же просто ошибся в подсчётах (сдвигаешь IP на 6 байт а не на 7 чтобы IP попадал на NOP-ы)?
А вот ответить на это не так просто. Дело тут еще в том, что эта конструкция по-разному работает на ХР и на Win98. Я сначала сделал на ХР с одним Exception, но на 98 это не работало. Я переделал так, что это работало на 98, но оно перестало работать на ХР. Тогда я стал эксперементировать, и когда наконец ето заработало, я заметил, что на ХР срабатывают два Exception (а на 98 все-таки один). Тогда я подумал, и решил, что может это и не так плохо.

Цитата:
Кстати вместо XOR в данном случае более правильно использовать OR
OR тоже имеет свои недостатки: он не все изменет. Я этот кусок вообще переделал, а вместо XOR там теперь XOR+ROR

Цитата:
4) Насчёт защиты fxp - что то поспешил я тебя похвалить Там же штатный алогритм работает, и защита состоит только в аккуратной "порче" объектного кода и структуры fxp... Я думал что ты как-то смог и там новую декодировочную таблицу задействовать... Впрочем надо же что-то и на будущее оставить - чтоб было куда улучшать
Алгоритм все-таки не совсем штатный, а так я ведь предупреждал:
Цитата:
Насчет fxp я тоже подумал и в конце концов решил пойти по компромисному варианту. Защиту для fxp приделал, но она не такая надежная, как для экзешников. Т.е. самую секретную информацию лучше в fxp не хранить. А так, ни Рефокс, ни Corso их не берут.

Цитата:
Возможно что для этого случая наиболее правильным будет "внешнее" задание ключа (индивидуального на каждый fxp файл или одного на их все) - из главной программы через какое-нить хитрое своё АПИ (ну от банальной передачи "наружу" адреса куда следует поместить ключ, до более интересного - фоксовой функции-обёртки, вызывающей через тот-же "оконный механизм" ассемблерную функцию добавления/установки ключа). В принципе конечно можно использовать для этих целей Cryptor - ему по барабану какие файлы шифровать - но боюсь что это заметно снизит надёжность защиты, да и надо проверять как будут совместно жить оба компонента...
Все это реализовать весьма трудно не меняя кардинально всю систему. Ведь я подключаюсь не в ReadFile, а в момент расшифровки. Там практически невозможно определить, какой файл в данный момент расшифровывается, хотя бы узнать его хендл. По крайней мере я не нашел способа это сделать. А без этого непонятно что откуда брать.

Цитата:
5) Я так понимаю ты встраиваешь непосредственно в объектный код защитный блок IF .F. лабуда ENDIF? Нельзя ли его встраивать не в конец, а в начало процедуры? Есть ли информация о том что нужно для этого поменять в самом объектнике (я пока не в курсе - там просто относительные смещения применяются, или всё пляшет от базового адреса - от начала соответствующего объектного блока?)
Этот кусок мне менять уже не хочется, поскольку от Рефокса он совсем не защищает. Независимо от того, в начале или в конце. Я его делал давно, сейчас уже всего не помню, но кажется приделать его в начало все-таки значительно труднее. Этот кусок помогал от восьмого Рефокса, а от 11 - нет.



Исправлено: leonid, 18.12.06 15:03
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 17.12.06 14:07:54
lowfreq
попробовал defoxII чтобы защитить приложение West-Wind Connection. При старте приложение валится с ошибкой Не найдено свойство GetappStatpath. Хотя метод такой описан. Компилится все VFP9SP1
Что делать?
Может быть самое простое - дать мне ссылочку на это приложение (но только конкретно, чтобы я тот же самый файл скачал), я попробую, если у меня такая же ошибка вылетит, то что-нибудь придумаю.

P.S. Если приложение использует арр файлы, то посмотрите в хелп, что по этому поводу написано.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
Igor Korolyov

Сообщений: 34123
Дата: 18.12.06 17:34:45
Hi leonid!

Отчего же это рантайм не может загрузится по другому адресу? AppInit_DLLs видать не пуст вот и грузится что-то, что мешает рантайму сесть на штатный адрес. У меня например грузится HookDLL.dll - это компонента Wise-а - но слава богу не в такую область памяти где будет рантайм
А может быть в его винде одна из штатных dll (ну там user32, kernell32) нестандартная - хотя это гораздо менее вероятно.
Насчёт релокации - а разве там не относительный переход стоит? Я думал что в этом случае не требуется никаких релокаций... Ну только при модификации exe/dll учесть разницу между RVA соответствующих секций. AFAIK загрузчик не может поменять RVA у секций и соответственно не может расположить их относительно друг друга как-то по иному нежели описано в PE заголовке. Т.е. знать абсолютный адрес тут кажись не нужно
Насчёт DeleteFile - я и написал, что это событие маловероятно, а то что в стеке будет информация которая удовлетворит соответствующую функцию - т.е. что она реально отработает - так это ещё в несколько раз менее вероятно - в момент перехода на новый блок декодера в стеке обычно нет указателей на какие либо строки, а то что там есть, вряд ли может трактоваться как имя/путь к файлу
Перезагрузка винды - это тоже не очень вероятно - для этого процесс (как правило пользователи работают не под административным аккаунтом - по крайней мере это хорошее ПРАВИЛО) должен обладать соответствующими привилегиями, а предположить что в бессмысленном наборе байт вдруг образуется несколько осмысленных вызовов... Это уж совсем на гране фантастики
Насчёт "своего сообщения" - всё-же программисты люди грешные и часто ошибаются, так что отделять ошибки в собственно программе от ошибок вызванных срабатывванием защиты всё-же стоит... Конечно желание избежать таковые при "нормальном ходе событий" похвально, но IMHO не всегда осуществимо. Впрочем по тому логу что создаёт более-менее свежий фокс и так видно откуда у ошибки ноги растут
Насчтё двойного Exception - видать разные версии винды по разному сохраняют IP - увы сейчас не имею под руками 98 так что посмотреть проблематично - но мне кажется что +7 должно помочь - там же довольно большой блок NOP-ов чтобы в него попасть... Не думаю что расхождение между сохранённым IP в 98 и NT настолько уж велико.
Настчёт OR - я имел в виду не ВСЕ XOR заменить, а только те что вынимают DR* из контекста - тот XOR что "портит" CRC не надо менять. Впрочем это не существенно - тот кто дошёл до этого блока кода в любом случае пройдёт дальше - это для неопытного взломщика непонятка будет - куда точки останова исчезают
Насчёт отлова информации "что за файл потрошится" надо подумать и посмотреть - мне кажется что эта информация где-то всё-же должна быть... В стеке наверняка есть - надо лишь посмотреть насколько по разному под разными версиями рантайма это хранится. Ну или как совсем уж тупой вариант - таки подключится к ReadFile и отслеживать какой же fxp/exe/app файл читался последним (не проводя никаких изменений в этой части ессно)...
Насчёт порчи/модификации объектного кода - а ты пробовал с достаточно длинной командой состоящей из одних нулей (кроме поля размера)? У меня и 10 и 11 отваливаются как положено Вот UnFoxAll прожёвывает - зато он клинически не понимает @ при вызовах функций и не разбирает main файл


------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 19.12.06 10:06:17
Hi Igor!
Igor Korolyov
AppInit_DLLs видать не пуст
Не знал про эту штуку, хотя сам Microsoft про это пишет
Цитата:
We do not recommend that applications use this feature or rely on this feature. There are other techniques that can be used to achieve similar results
Не хотелось бы из-за этого отключать один из существенных элементов защиты. А как проверять контрольную сумму на перемещенных дллках я тоже не придумал.
Цитата:
А может быть в его винде одна из штатных dll (ну там user32, kernell32) нестандартная - хотя это гораздо менее вероятно.
Вот в это совсем не верится. Они же грузятся совем в другую (7ххххххх) область памяти, и насколько я знаю они вообще зашарены.

Цитата:
Насчёт релокации - а разве там не относительный переход стоит? Я думал что в этом случае не требуется никаких релокаций...
Там так получилось, что у того, что я ставлю, переход относительный, т.е. его менять не надо, а у того, что было, адрес абсолютный, и relocation его меняло (пока я не исправил).

Цитата:
Насчёт "своего сообщения" - всё-же программисты люди грешные и часто ошибаются, так что отделять ошибки в собственно программе от ошибок вызванных срабатывванием защиты всё-же стоит...
Наверное я подумаю на эту тему, но обещать что-либо боюсь.

Цитата:
Конечно желание избежать таковые при "нормальном ходе событий" похвально, но IMHO не всегда осуществимо.
Вот с этим, к сожалению, трудно не согласиться.

Цитата:
Насчтё двойного Exception - видать разные версии винды по разному сохраняют IP - увы сейчас не имею под руками 98 так что посмотреть проблематично - но мне кажется что +7 должно помочь - там же довольно большой блок NOP-ов чтобы в него попасть... Не думаю что расхождение между сохранённым IP в 98 и NT настолько уж велико.
Я сейчас этот кусок довольно существенно переделал. Мне кажется, теперь его пройти еще труднее будет. Новый вариант уже выложил. Мне кажется, он теперь одинаково работает на ХР и на 98, хотя как это все работает на 98 я так до конца и не понял.

Цитата:
Насчёт отлова информации "что за файл потрошится" надо подумать и посмотреть - мне кажется что эта информация где-то всё-же должна быть... В стеке наверняка есть
Я весь стек облазил, надежного варианта не нашел. Отличия не только по версиям, но и в одной версии туда приходит то так, то так, то получается найти, то нет.
Цитата:
Ну или как совсем уж тупой вариант - таки подключится к ReadFile и отслеживать какой же fxp/exe/app файл читался последним
Это конечно вариант, но он существенно сложней в реализации, и к тому же, где гарантия того, что файл, который последним проходил через ReadFile как раз и расшифровывается.

Цитата:
Насчёт порчи/модификации объектного кода - а ты пробовал с достаточно длинной командой состоящей из одних нулей (кроме поля размера)? У меня и 10 и 11 отваливаются как положено
Нет, именно так не пробовал. Надо будет попробовать на досуге
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
lowfreq

Сообщений: 9
Дата: 19.12.06 21:42:51
могу прислать по емейлу. Скажите мыло и какой файл присылать - шифрованный или исходный?
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 20.12.06 09:09:52
lowfreq
могу прислать по емейлу.
defox@grada.lv
Цитата:
шифрованный или исходный?
Если не очень большие, то лучше оба. Если большие - то сначала исходный.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
Igor Korolyov

Сообщений: 34123
Дата: 20.12.06 18:04:15
Hi leonid!
Цитата:
А как проверять контрольную сумму на перемещенных дллках я тоже не придумал.
Я уже писал - это будет очень сложно, и скорее всего не очень надёжно. Другое дело, что возможно стоит добавить проверку, и если базовый адрес модуля рантайма не тот что надо то сразу и отлуп давать... Кстати для тестирования можно нарисовать пару "пустых" dll-ек и прописать в реестре - чтоб "штатные" адреса рантайма и основного exe/dll сместились.
Про релокацию понял, обратная ситуация оказывается
Цитата:
Я сейчас этот кусок довольно существенно переделал. Мне кажется, теперь его пройти еще труднее будет. Новый вариант уже выложил. Мне кажется, он теперь одинаково работает на ХР и на 98, хотя как это все работает на 98 я так до конца и не понял.
Посмотрю - я как раз собирался на виртуалку ставить 98SE :puke:
Проблема правда со скачиванием возникает - прокся бывает старый файлик подсовывает
Цитата:
Цитата:
Ну или как совсем уж тупой вариант - таки подключится к ReadFile и отслеживать какой же fxp/exe/app файл читался последним
Это конечно вариант, но он существенно сложней в реализации, и к тому же, где гарантия того, что файл, который последним проходил через ReadFile как раз и расшифровывается
Ну 100% гарантии конечно нет, но я так понимаю, что рантайм не делает никаких задержек между скачиванием блока и его декодированием, а всякие "левые" обращения (без декодирования) - так они не помеха - перед декодированием будет "то самое" обращение.


------------------
WBR, Igor




Исправлено: Igor Korolyov, 20.12.06 18:05
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 21.12.06 11:03:31
Hi Igor!
Igor Korolyov
Другое дело, что возможно стоит добавить проверку, и если базовый адрес модуля рантайма не тот что надо то сразу и отлуп давать...
Конечно так можно, но мне контрольная сумма все равно нужна, чтобы следующий кусок кода расшифровать, если я ее не могу посчитать, то мне ее где-то надо хранить, а это сразу снижает надежность защиты.
Цитата:
Кстати для тестирования можно нарисовать пару "пустых" dll-ек и прописать в реестре - чтоб "штатные" адреса рантайма и основного exe/dll сместились.
Я вчера попробовал так сделать, странные результаты получаются. Я пробовал на экзешнике, скомпилированном на шестерке, а в качестве "пустой" dll-ки взял vfp9t.dll. Не думаю, что шестерка может ее как-то признать за родную, но она ее выгружала, перед тем, как загрузить свой рантайм, и рантайм все равно загружался по стандартному адресу. Надо будет еще поэкспериментировать.
Цитата:
перед декодированием будет "то самое" обращение.
По идее это конечно так, но я уже много раз натыкался на то, что фоксовский рантайм не всегда работает "по идее". В частности и здесь у меня есть сомнения. Фокс не всегда читает в точности то, что его просят - иногда больше, любит блоками по 512 байт. Если какой-нибудь маленький файл будет прочитан вместе с предыдущим "за компанию", то по-моему фокс его второй раз читать не будет, а возьмет из своего кэша и сразу отдаст на расшифровку. Не хотелось бы на такие грабли наступить. Совсем непонятно, как их можно обойти.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
lowfreq

Сообщений: 9
Дата: 21.12.06 11:08:43
так что там с ошибкой то, нашли что нибудь?
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 21.12.06 11:10:49
lowfreq
могу прислать по емейлу
Спасибо за файлы. Действительно там нашлась ошибочка. Я ее уже исправил и сегодня вечером выложу новую версию. Характерный признак ошибки: сообщение "Свойство ... не найдено" для классов, которе задаются с помощью Define class. Кстати, в присланном Вами файле есть классы, определенные как Olepublic, т.е. это СОМ сервер. В таком случае его нужно защищать, как СОМ сервер, а то как ехе он работать будет, а как СОМ сервер - нет.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
lowfreq

Сообщений: 9
Дата: 21.12.06 11:29:10
я пока не использую его как комсервер. поэтому в общем проблемы пока нет ну, ддайте знать пожалста когда новая версия будет.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
Igor Korolyov

Сообщений: 34123
Дата: 21.12.06 15:35:46
Hi leonid!

1) Насчёт перемещённого рантайма ты меня не понял... Не надо нигде CRC хранить - надо просто проверить что базовый адрес # 0с000000 и вывалится с соответствующим сообщением - т.е. просто сделать более корректный аварийный выход - не по попытке исполнить "мусор", а ДО того, и более-менее штатно (хотя убиение процесса в данном случае не есть абсолютно корректный выход, но всё-же)...

2) Я думаю что нужно специальную dll сооружать для забивания места - очевидно имеет большое значение как инициализируется эта самая dll - видать фоксовая так (не)инициализируется, что её выкидывает.

3) Насчёт кэша я не уверен - мне кажется что рантайм не поддерживает кэш "нерасшифрованных блоков", вот расшифрованный объектный код он в каком-то виде хранит, но это ничему не мешает.

4) Всё-же я попробую найти способ поиметь filehandle в пределах этой части декодера - это решило бы сразу массу проблем.


------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 21.12.06 19:03:26
lowfreq
ддайте знать пожалста когда новая версия будет.
Даю знать.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 21.12.06 19:16:03
Hi Igor!
Igor Korolyov
1) Насчёт перемещённого рантайма ты меня не понял... Не надо нигде CRC хранить - надо просто проверить что базовый адрес # 0с000000 и вывалится с соответствующим сообщением - т.е. просто сделать более корректный аварийный выход - не по попытке исполнить "мусор", а ДО того, и более-менее штатно (хотя убиение процесса в данном случае не есть абсолютно корректный выход, но всё-же)...
А, ну так конечно можно, даже прямо в фоксе с нормальным выходом.

Цитата:
2) Я думаю что нужно специальную dll сооружать для забивания места - очевидно имеет большое значение как инициализируется эта самая dll - видать фоксовая так (не)инициализируется, что её выкидывает.
Не знаю, может быть, я когда пробовал посмотреть с помощью Olly, он у меня как-то неадекватно работал, вылетал по эксепшену, и я не смог засечь момент, когда dll-ка выгружается.

Цитата:
3) Насчёт кэша я не уверен - мне кажется что рантайм не поддерживает кэш "нерасшифрованных блоков", вот расшифрованный объектный код он в каком-то виде хранит, но это ничему не мешает.
Я не очень хорошо помню, но у меня какое-то смутное ощущение, что я видел следующее: фокс в самом начале читает две области - список файлов и таблицу их размещения, так вот если он, прочитав одну из них (не помню, какую он читает первой) захватит ненароком и вторую, то он потом второй раз в ReadFile не лезет, а если не захватит, то конечно лезет.

Цитата:
4) Всё-же я попробую найти способ поиметь filehandle в пределах этой части декодера - это решило бы сразу массу проблем.
Да, но только это надо найти в 14 поддерживаемых рантаймах. Хотя если найти в одном, то в остальных будет легче.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
lowfreq

Сообщений: 9
Дата: 21.12.06 19:40:21
скачал. в заголовке написано v.1.005.129 - это новая версия? если да, то ошибка осталась. Если нет, тогда откуда точно качать новую версию?
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 22.12.06 09:29:59
Да, действительно, недоглядел. Теперь, вроде, исправлено. Кстати, номер версии, которая сидит в интернете, можно посмотреть до скачивания
Текущая версия DeFoxII
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
lowfreq

Сообщений: 9
Дата: 22.12.06 10:20:12
значится так... на XP - работает на ура. скопировал файл на WinServer2003 - валится по C0000005 и написано типа вызвано из q3216547.fxp строка там не помню уже какая. В общем, на Winserver 2003 - не работает. Для экспериментов v;tim использовать тот файл что я посылал- я использовал для теста именно его. Защита производилась для EXE варианта.
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 31.12.06 12:00:35
Вот, наконец-то сделал некое подобие сайта:
DeFoxII
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
Igor Korolyov

Сообщений: 34123
Дата: 08.01.07 19:52:23
Hi leonid!
Цитата:
Вот, наконец-то сделал некое подобие сайта
Это хорошо, но буковки что то великоваты...

Тут ещё одна идея появилась - для усложнения жизни взломщику стоит перед выделением основной памяти под компоненты защиты выделить блок памяти RAND() размера - как я понимаю это приведёт к тому, что при последовательных запусках программы адреса размещения блоков декодера будут плавать - т.е. придётся либо заново проходить всё с самого начала, либо "вычислять" новые адреса для точек останова.

Удачи!


------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Защита от декомпиляции
leonid
Автор

Сообщений: 2983
Откуда: Рига
Дата: 09.01.07 15:05:13
Hi Igor!
Igor Korolyov
Это хорошо, но буковки что то великоваты...
Я бы и сделал поменьше, но этот чертов IIS не поддерживает Extended SSI, а без этого как-то уже трудно. Но кому надо могут ведь у себя поменять.

Цитата:
Тут ещё одна идея появилась - для усложнения жизни взломщику стоит перед выделением основной памяти под компоненты защиты выделить блок памяти RAND() размера - как я понимаю это приведёт к тому, что при последовательных запусках программы адреса размещения блоков декодера будут плавать
Идея интересная, и легкоосуществимая, думаю, порпробую. Хотя они и без этого иногда плавали, но так, конечно, будут плавать чаще.

Цитата:
- т.е. придётся либо заново проходить всё с самого начала, либо "вычислять" новые адреса для точек останова.
А вот это как раз не так трудно автоматизировать.

Кстати, идею вставить SEH для отлова собственных эксепшенов я осуществил.
И еще одно. Я тут получил несколько писем, и в одном из них был поднят вопрос о фоксовском обфускаторе. Я порылся и интернете и реально ничего такого не нашел. Немного подумав, пришел к выводу, что ничего хорошего сделать не получится (ну там, type, eval, макроподстановки), а вот некоторую ограниченную модель - можно. Нечто я уже написал, и последняя версия DeFoxII им уже обработана. Вообще, если такая вещь представляет интерес, я могу слегка доделать и выставить на всеобщее пользование.
Ratings: 0 negative/0 positive



Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 1 (Гостей: 1)

© 2000-2021 Fox Club 
Яндекс.Метрика