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

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

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

Сообщений: 42
Дата: 01.12.06 17:09:18
Здравствуйте Леонид.
DLL multi-threaded. Фокс 9SP1. Фокс ругается на якобы отсутствие переменной. Если мне не изменяет память (сейчас нет под рукой проекта). Попробую еще раз и подробнее напишу. На APP ругается, что скомпилирована в другой версии Фокса (это вроде у меня класс ToolBar). На другую ругается вроде аналогично, она вызывается Do .... With ...
Ratings: 0 negative/0 positive

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

Сообщений: 2983
Откуда: Рига
Дата: 01.12.06 17:12:04
piva
Антивирусник бы сругался
Ну не всегда. И антивирусник можно удушить, особенно если он натыкается на то, чего не знает.

Цитата:
функция выдает 1172493194
Я проверю это дома

Цитата:
Попробовал под сервером Win2K3 при пером запуске
defoxii a fm.exe
выдао ошибку "опция TO используется только для модальных форм"
Потом после лиц. соглашения, которого я так и не прочитал отработало нормально, мой экзешник "опух" на 20 кил.
Странно, почему на 2003 выдает фоксовскую ошибку, которую не выдает на других. Я поищу, почему такое может быть, но к сожалению, доступа к Win 2003 server у меня нет никакого.

Цитата:
И еще, я помню что c SP4 у многих были проблемы, так что это скорее проблема именно в SP4 !
Но ведь igor86 написал, что у него на W2kSP4 работает.

2 All
Я вчера написал приложение, позволяющее тестировать различные варианты использования защиты. Когда я его запустил, то обнаружил, что действительно имеются проблемы с АРР файлами и СОМ серверами. С первого раза они запускаются нормально, а при последующих вызовах могут вывалиться на ошибку. Я попробую выяснить, в чем дело, но боюсь, что это может занять немало времени. На данный момент программой можно пользоваться только для отдельно работающих экзешников (на таких мне не удалось завалить ее ни разу).
А пока всем спасибо.
Ratings: 0 negative/0 positive

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

Сообщений: 34123
Дата: 07.12.06 18:44:22
Hi Leonid!

Начнём пожалуй с исправления ошибок
Чёрт его знает - может из-за этого не работает у некоторых на Win2K (я сам не проверял).
В стартовой prg-ке имеется
LOCAL M.PRHP , M.PRHP2  
   M.PRHP = GETPROCESSHEAP()  
   IF M.PRHP = 0  
      IF _SCREEN.Q3216549 = -1  
          MESSAGEBOX("Program can't start. Error in GetProcessHeap",16,'Error')  
         RETURN   
      ELSE   
         _SCREEN.Q3216549 = 3  
         RETURN   
      ENDIF   
   ENDIF   
   M.PRHP2 = HEAPCREATE(262144,65536,0)  
   IF M.PRHP = 0  
      IF _SCREEN.Q3216549 = -1  
          MESSAGEBOX("Program can't start. Error in HeapCreate",16,'Error')  
         RETURN   
      ELSE   
         _SCREEN.Q3216549 = 3  
         RETURN   
      ENDIF   
   ENDIF
PRHP и всё что с ней связано более не используется - поэтому можно удалить. А вот во втором IF надо как раз PRHP2 проверять.
Чуть ниже
M.HEAP2 = HEAPALLOC(M.PRHP2,262144,LEN(M.ST22) + 16)
Тут флаг HEAP_CREATE_ENABLE_EXECUTE не нужен - точнее он не работает при выделении памяти из кучи (только при создании самой кучи) не знаю может ли это как-то влиять, но стоит всё-же убрать его.
Ещё ниже многократно (через строчку) повторяется
DECLARE RtlMoveMemory IN Win32API INTEGER , STRING , INTEGER
Это тоже несколько лишнее.

Что касается общего впечатления. На простом тестовом примере у меня всё работает Но есть и предложения.

1) Стоит продумать интерфейсный механизм для защиты сразу большой кучи файлов (особенно это касается fxp) - это можно сделать как в рамках самой программы, так и внешним модулем - который будет вызывать defoxii.exe требуемое число раз с нужными параметрами.
2) Очень важное для меня - защита отдельно стоящих vcx/scx файлов - не полная конечно, а имеющегося у них внутри объектного кода (одновременно с очисткой поля Methods). Я пока не знаю какой механизм использует фокс при обработке объектного кода из поля Objcode - но надеюсь что он таки вызывает штатный декодер, и принципиальная возможность защиты тут имеется. Я пробовал запихать в это поле "защищённый" fxp файл с описанной процедурой Click - но без успеха - ошибки не возникает, но видимо "лишняя инфа" в fxp относительно того что он на самом деле есть "файл" (в частности имя файла и путь к папке где он компилировался) а не содержимое поля Objcode мешает...

P.S. Может быть стоит перекомпилировать/заново защитить urf.exe - чтоб и он нормально работал на машинах с DEP.

P.P.S. Пока не смотрел "внутренности" новой защиты - с наскока не выходит, т.к. видимо теперь более чётко детектируется отладчик.


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

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

Сообщений: 34123
Дата: 08.12.06 13:01:15
В дополнение...
Посмотрел чуток на то как рантайм обрабатывает Objcode из "табличных" файлов - похоже он пропускает стадию дешифрования Т.е. заголовок то дешифрует как положено, а вот всё прочее содержимое видимо нет По крайней мере он обращается к нерасшифрованной таблице размещения модулей и конечно получает абсолютно недостоверную информацию оттуда


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

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

Сообщений: 2983
Откуда: Рига
Дата: 08.12.06 15:38:36
Hi Igor!

Igor Korolyov
Начнём пожалуй с исправления ошибок Чёрт его знает - может из-за этого не работает у некоторых на Win2K (я сам не проверял).
В стартовой prg-ке имеется
LOCAL M.PRHP , M.PRHP2  
   M.PRHP = GETPROCESSHEAP()  
   IF M.PRHP = 0  
      IF _SCREEN.Q3216549 = -1  
          MESSAGEBOX("Program can't start. Error in GetProcessHeap",16,'Error')  
         RETURN   
      ELSE   
         _SCREEN.Q3216549 = 3  
         RETURN   
      ENDIF   
   ENDIF   
   M.PRHP2 = HEAPCREATE(262144,65536,0)  
   IF M.PRHP = 0  
      IF _SCREEN.Q3216549 = -1  
          MESSAGEBOX("Program can't start. Error in HeapCreate",16,'Error')  
         RETURN   
      ELSE   
         _SCREEN.Q3216549 = 3  
         RETURN   
      ENDIF   
   ENDIF
PRHP и всё что с ней связано более не используется - поэтому можно удалить. А вот во втором IF надо как раз PRHP2 проверять.
Я на днях тут копался, переделывал, теперь уже PRHP опять используется. У меня тут был недостаток, что при запуске одного и того же арр несколько раз PRHP2 создавался каждый раз и сжирал немного памяти. Сейчас я это искоренил. А насчет вторго IF, да, конечно, исправлю.

Цитата:
Чуть ниже
M.HEAP2 = HEAPALLOC(M.PRHP2,262144,LEN(M.ST22) + 16)
Тут флаг HEAP_CREATE_ENABLE_EXECUTE не нужен - точнее он не работает при выделении памяти из кучи (только при создании самой кучи) не знаю может ли это как-то влиять, но стоит всё-же убрать его.
Я тоже не знаю, может ли это как-то влиять, но именно исходя из этого я и решил, что его лучше оставить таким, вреда вроде бы от этого быть не должно.

Цитата:
Ещё ниже многократно (через строчку) повторяется
DECLARE RtlMoveMemory IN Win32API INTEGER , STRING , INTEGER
Это тоже несколько лишнее.
Да, наверное стоит почистить, хотя врядли это влияет на работу.

Цитата:
1) Стоит продумать интерфейсный механизм для защиты сразу большой кучи файлов (особенно это касается fxp) - это можно сделать как в рамках самой программы, так и внешним модулем - который будет вызывать defoxii.exe требуемое число раз с нужными параметрами.
Я для себя написал фоксовский скрипт, который все это делает. Мне кажется это для многих будет вполне удобным решением. Я постараюсь в воскресенье выложить новый вариант, и тогда все это тоже выложу.

Цитата:
2) Очень важное для меня - защита отдельно стоящих vcx/scx файлов - не полная конечно, а имеющегося у них внутри объектного кода (одновременно с очисткой поля Methods). Я пока не знаю какой механизм использует фокс при обработке объектного кода из поля Objcode - но надеюсь что он таки вызывает штатный декодер, и принципиальная возможность защиты тут имеется. Я пробовал запихать в это поле "защищённый" fxp файл с описанной процедурой Click - но без успеха - ошибки не возникает, но видимо "лишняя инфа" в fxp относительно того что он на самом деле есть "файл" (в частности имя файла и путь к папке где он компилировался) а не содержимое поля Objcode мешает...
Я это тоже пробовал и - без результата. Даже без "лишней инфы" не работает. Мне кажется, обработку scx и vcx писали другие люди, в другое время и написали совсем по-другому. Они считали, что если можно сделать encrypted экзешнику, то для scx и vcx этого делать уже не нужно.

Цитата:
P.S. Может быть стоит перекомпилировать/заново защитить urf.exe - чтоб и он нормально работал на машинах с DEP.
Уже выложил

Цитата:
P.P.S. Пока не смотрел "внутренности" новой защиты - с наскока не выходит, т.к. видимо теперь более чётко детектируется отладчик.
А я там еще поменял. Еще лучше сделал
Ratings: 0 negative/0 positive

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

Сообщений: 34123
Дата: 08.12.06 21:59:30
Hi leonid!

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

Под "внешним модулем" я как раз и понимал нечто типа скриптика Это конечно тривиальная задача, но всё же...

C scx/vcx пока глухо. Да я понимаю их мотивы, но неприятно как-то... Ладно бы ещё сделали использование "включенных" в другие app/exe библиотек простым и приятным занятием - так нет же столько геморроя, что приходится отказываться от этого варианта А помещать "всё всё всё" в один exe тоже никак не получается - особенно для большого и "живого" проекта - не тянуть же каждый раз в виде обновления многомегабайтный exe... Да и "на месте" иногда приходится править - пересборка тут не катит... В общем жаль

Да, я пока не нашёл в новой системе где же ты ловишь за руку OllyDbg Видать знаешь какой-то хитрый способ получения значений отладочных регистров минуя GetThreadContext...


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

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

Сообщений: 2983
Откуда: Рига
Дата: 10.12.06 14:40:16
Hi, Igor

Igor Korolyov
Hi leonid!
Насчёт "множественности" кучи - не знаю как ты сделал, но у тебя же есть возможность использовать глобальные переменные для хранения инфы - я бы в них и хранил (т.е. первый запуск модуля защиты создаёт, остальные только пользуют) - я имею в виду _SCREEN.что_то_там_этакое - флаги есть, можно и для адреса кучи держать.
Сейчас у меня там вроде все в порядке: при повторном вызове ничего нового не соэдается, а флаг собственно и говорит, что вызов повторный.

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

Цитата:
C scx/vcx пока глухо. Да я понимаю их мотивы, но неприятно как-то... Ладно бы ещё сделали использование "включенных" в другие app/exe библиотек простым и приятным занятием - так нет же столько геморроя, что приходится отказываться от этого варианта А помещать "всё всё всё" в один exe тоже никак не получается - особенно для большого и "живого" проекта - не тянуть же каждый раз в виде обновления многомегабайтный exe... Да и "на месте" иногда приходится править - пересборка тут не катит... В общем жаль
Я тут вчера нашкрябал для защиты scx и vcx
www.grada.lv
Не ахти что, но по крайней мере от Рефокса защитит. А хорошо сделать, мне тоже показалось - глухо.

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

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

Сообщений: 2983
Откуда: Рига
Дата: 10.12.06 15:22:42
Hi, All
Посвятил неделю (в смысле вечера и weekend) поиску и справлению ошибок. Вот что выяснилось:
По поводу ошибки
Предложение ТО можно испльзовать только с модальными объектами Form или Formset
Оказывается она никакого отношения к Windows 2003 не имеет. Ее можно было получить в любом Windows. Глупая ошибка, просто когда приделывал работу с командной строкой, забыл, что screen=off, и написал вызов модальной формы с возвращением параметра.
По поводу APP
Нашлись две ошибки. Первая несущественная, от нее ничего не валилось, толь при неоднократном вызове одной и той же аррки незначительно возрастало количество используемой приложением памяти. Если поместить в длинный цикл, могло сказаться. Вторая ошибка была хуже. Я неправильно предполагал, как фоксовский рантайм позволяет идентифицировать используемый файл. То, что я считал идентификатором файла, оказывается в некоторых случаях меняется. В результате - вылет. Пришлось искать другой идентификатор. К счастью, нашелся.
По поводу COM
Тоже нашлись две ошибки. Одна глупая. При резервировании памяти неправильно указывалось требуемое количество. Грубо говоря бралось с потолка. В результате после двух - трех вызовов Windows становилось плохо. Найти было трудно, зато исправить легко. Вторая была хуже. Она проявлялась в случае, если СОМ сервер (дллка) загружалась не по стандартному адресу. Это случается достаточно редко, и поэтому ее трудно было найти. Чтобы ее исправить мне пришлось узнать, что такое relocation table, где она хранится и как ее можно изменять. Надеюсь, что у меня получилось.
Что касается вылетов на W2k SP4, то тут ничего нового сказать не могу. Может статься, что исправленные ошибки помогут, а может и нет. У меня такого Windows нет, чтобы попробовать.
Результат работы - новая версия
www.grada.lv
Кроме того, я выложил небольшой тестовый пример, который показывает использование защиты с различными модулями. Его можно откомпилировать в любой версии фокса 6-9. Для упрощения этого там есть скрипт (build_scritp.prg). Он предполагает, что defoxii.exe находится в директории верхнего уровня (можно заменить на любой другой путь). Он создет директории Рх и РхР (х - номер версии фокса) для откомпилированных незащищенных и защищенных файлов. Этот скрипт, немного подправив можно использовать для компиляции и защиты любых проектов. В нем используется программа rpw, которую не знаю кто написал, но если кто признает за свою, то ему - благодарность.
Жду новых отзывов.

P.S. Дико извиняюсь. Забыл привести ссылку на тестовый пример.
www.grada.lv



Исправлено: leonid, 12.12.06 09:49
Ratings: 0 negative/0 positive

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

Сообщений: 18600
Откуда: Курган
Дата: 13.12.06 09:45:37
Все равно падает под Win2K SP4

[attachment 3444 1.jpg]


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive

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

Сообщений: 18600
Откуда: Курган
Дата: 13.12.06 09:53:53
Та же при выполнении build_script вылезает unable to find Applicaion и втоге получам файл ошибок
Form c:\my\defoxii\test\test.scx has the following errors:
    Application TESTAPP - Undefined
    Application TESTAPPC - Undefined
    Application TESTEXE - Undefined


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive

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

Сообщений: 2983
Откуда: Рига
Дата: 13.12.06 15:37:57
piva
Все равно падает под Win2K SP4
А не может статься, что vfp6r.dll битая. Нельзя ее CRC32 глянуть (от восьмерки я посмотрел, там все правильно)? Вроде, есть места, где на Win2k SP4 работает.
Цитата:
Та же при выполнении build_script вылезает unable to find Applicaion и втоге получам файл ошибок
А, действительно. Надо было компиляцию main.exe в конец поставить. А так надо несколько раз Ignore нажать. Но после этого компилится правильно.
Ratings: 0 negative/0 positive

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

Сообщений: 18600
Откуда: Курган
Дата: 14.12.06 07:01:44
Да получил я конечно все только все равно падает.
А по повроду vfp6r - дык тот же твой urf с этим рантаймом работает


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive

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

Сообщений: 2983
Откуда: Рига
Дата: 14.12.06 14:13:35
Так urf совсем по-другому защищен. Та защита почти ничего и не проверяет.
Ratings: 0 negative/0 positive

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

Сообщений: 18600
Откуда: Курган
Дата: 14.12.06 14:15:41
Да я к тому что рантайм живой все-таки


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive

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

Сообщений: 2983
Откуда: Рига
Дата: 14.12.06 15:01:19
Живой-то живой, но защита его контрольную сумму проверяет, и если не совпадает, то дохнет. Это чтобы левые рантаймы не подсовывали, которые вместо того, чтобы запускать приложение дампят его на диск в распакованном виде.
Ratings: 0 negative/0 positive

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

Сообщений: 18600
Откуда: Курган
Дата: 14.12.06 15:03:19
Ах вон оно что - черт а других у меня нету, ладно, поишу может дома еще остались живые. А другое сообщение а не Exception прицепить никак нельзя было


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive

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

Сообщений: 2983
Откуда: Рига
Дата: 14.12.06 15:39:50
А Exception это вовсе не мое сообщение. Если я буду выдавать сообщения, то нужно делать развилку типа if ... then. А такие вещи ломаются на раз. Простой заменой одного байта. У меня контрольная сумма рантайма используется как ключ для расшифровки следующей порции кода. Если ключ неправильный - вылетает Exception. Причем могут быть самые разные. Не только C0000005.
Ratings: 0 negative/0 positive

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

Сообщений: 18600
Откуда: Курган
Дата: 14.12.06 20:22:25
Сурово сделано Тока рантайма дама я не нашел, за сим прощаюсь


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive

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

Сообщений: 34123
Дата: 15.12.06 17:55:05
Hi Piva & leonid!

1) Проверка рантайма не сработает если он загрузится не по стандартному адресу - я так подозреваю, что у Piva как раз этот случай. Это можно легко проверить - создать exe из простенькой prg-ки:
DECLARE INTEGER GetModuleHandle IN WIN32API STRING  
  MESSAGEBOX(TRANSFORM(GetModuleHandle("vfp9r.dll"),"@0"))
Ну конечно не забыв номер версии фокса поменять если что
Стандартный адрес для 9 фокса 0C000000.
Код подсчёта CRC рантайма не учитывает наличия там relocation-ов (по крайней мере код добавляемый версией DeFoxII 1.005.003). IMHO код который будет учитывать это при подсчёте CRC получится чересчур усложнённым. Учитывая к тому же что секция .reloc является DISCARDABLE и теоретически может быть выгружена в процессе работы приложения, сложность возрастает непропорционально получаемому результату.
Я не совсем понял зачем тебе потребовалось менять RelocationTable - учитывая что она используется системой только в момент загрузки dll-ки (я честно говоря не очень представляю как можно влезть внутрь системного кода и успеть что-то исправить в секции .reloc до того как она будет использована по назначению). Может быть ты имел в виду не изменение а использование этой секции? Или речь идёт про .xdata секцию в защищённом exe/dll? Но разве там где-то требовался relocation...

2) Откровенно говоря, при неудачной дешифрации очередного блока кода декодера может произойти что угодно - вплоть до вызова произвольной апишной функции, скажем DeleteFile Однако вероятность такого события IMHO весьма невелика - вероятнее всего в результате мы получим попытку исполнения "недопустимой инструкции" процессора или же то самое обращение к недопустимому адресу. Однако я подозреваю что можно прицепить свой SEH (второй, не тот что сейчас в защите используется) и соответсвенно перехватывать все Exception-ы, отделять те из них что возникли внутри декодера и соотвественно выдавать своё сообщение - ну а если "не наше" - то передавать ошибку дальше - рантайму и т.п.

3) Насчёт отлова содержимого DR* - сам затупил, ведь написано же в MSDN что в SEH передаётся указатель на эту структуру, да и до того ведь видел что ты IP именно там подменяешь для "пропихивания" через свой INT3... Кстати ты намеренно сделал так, чтобы 2 раза возникал Exception - один на INT3 и второй на попытку чтения по адресу 90909090, или же просто ошибся в подсчётах (сдвигаешь IP на 6 байт а не на 7 чтобы IP попадал на NOP-ы)?
Кстати вместо XOR в данном случае более правильно использовать OR - мы же по сути проверяем регистры на равенство нулю, а XOR приводит к тому, что можно поставить 2 точки останова на 1 адрес (скажем по Execute и на Read или Write) и "порчи ключа" не произойдёт - да, может произойти отключение этих самых точек останова, если взломщик не позаботится о "неисполнении" соответствующих инструкций и если его отладчик не предусматривает подобное поведение подопытного обработчика исключений.

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

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

6) Опять таки, как появится время, посмотрю новые версии и DeFoxII и DF_SVCX...

Как промежуточный итог - от более-менее ненастойчивых/неграмотных взломщиков эта защита уже должна помогать. И конечно она превосходит системы защиты Refox, Armadillo, Conxise... А если ещё посмотреть на ценники соответствующих продуктов


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

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

Сообщений: 9
Дата: 16.12.06 11:54:56
попробовал defoxII чтобы защитить приложение West-Wind Connection. При старте приложение валится с ошибкой Не найдено свойство GetappStatpath. Хотя метод такой описан. Компилится все VFP9SP1

Что делать?
Ratings: 0 negative/0 positive



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

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

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