FoxClub Forums > Не фоксом единым > Дайте ссылочку рефокса ::

• Войти

Страницы: 1 2 3 4

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 14.11.06 15:40:07 Hi, Igor Сейчас у меня мало времени, поподробнее потом отвечу. Китайский файл оказался "всего" 9 Mb. Но это - полный инсталлят на семерке. Если я правильно понял китайский, то это демо версия. www.grada.lv Мой файлик существенно поменьше - 46 Kb, но к сожалению он именно на шестерке. На девятке я смогу его сделать только через денек-другой. www.grada.lv Если нужны рантаймы от шестерки, то www.grada.lv

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

14.11.06 15:40:07

Hi, Igor
Сейчас у меня мало времени, поподробнее потом отвечу.
Китайский файл оказался "всего" 9 Mb. Но это - полный инсталлят на семерке. Если я правильно понял китайский, то это демо версия.
www.grada.lv
Мой файлик существенно поменьше - 46 Kb, но к сожалению он именно на шестерке. На девятке я смогу его сделать только через денек-другой.
www.grada.lv
Если нужны рантаймы от шестерки, то
www.grada.lv

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 14.11.06 19:25:18 Hi, Igor Igor Korolyov Цитата: В фоксовском рантайме чтение экзешника осуществляется из одного места, реально она переадресует в рантайме два вызова - ReadFile и SetFilePointer. А как же собственно создание/клонирование хендлов? Ведь нужно отделять хендл к exe от хендлов к прочим файлам - иначе он ничего кроме exe не сможет прочитать А где-то это отделяется. Когда туда доходит дело хендл уже сидит в каком-то регистре. Но именно через один и тот же вызов читается и сам экзешник, и, например, foxuser. Цитата: Не, если ты будешь "искать по самому рантайму", то как сможешь проверить что этот рантайм специально не модифицирован с целью создать дамп Ну, скажем, контрольную сумму проверять. Цитата: Цитата: Отладчиком в нее залесть можно (туда, куда идет переадресация), но понять там что-нибудь практически невозможно. Я например споткнулся на том, что там идет куча команд математического ко-процессора, которых я не знаю. Но там и других хитростей навалом. Сложно и неправильно Абсолютно согласен. Я и недолго пробовал. Цитата: Не надо лезть в код защиты - надо просто изменить параметры вызова (в стеке! Это IMHO НИКАК нельзя отследить и предотвратить, т.е. в итоге мы получаем абсолютно легальный вызов - неотличимый от тех что делает рантайм в "нормальном" режиме) и поставить останов ПОСЛЕ этого самого переадресованного вызова После этого слить буфер, куда защита считала данные - и это уже будет расшифрованный объектный код - ну конечно возможно закрытый встроенным фоксовым шифрованием, но это совершенно не проблема Я бы сказал, почти неотличимый, но на самом деле и от этого защитьться можно. Например, один фоксовский модуль загоняет в памать некое число и вызывает другой модуль. Расшифровщик (собственный, который вызывается вместо фоксовского) по какому-то признаку определяет этот файл и проверяет наличие данного числа в памяти. Если его нет, значит нас взламывают. Цитата: Цитата: Нет, она меняет не таблицы, а непосредственно вызов в рантайме. Странно, зачем так сложно? Чтобы отладчиком не найти где был ReadFile? Так оно находится на "нормальном" рантайме и всего делов Мне кажется они это сделали потому, что им так легче следить, откуда приходят вызовы. А, впрочем, не знаю. Цитата: Цитата: Цитата: От последнего наверняка поможет один из альтернативных декомпиляторов Не поможет. Лучшее, что на сегодня есть - Corso 6. Он находит подпорченные места, но не знает, как их исправить. А он уже стал сам декомпилировать? 5.2 только дешифровал и мог рефоксовые гнилые защитные понты удалить Нет, не декомпилирует, но он может много всего исправить до такого состояния, что потом Рефоксом можно. В данном случае он исправить не мог, но повреждения нашел. Цитата: У тебя от UnFoxAll есть защита? Он с этой стороны более простой - по крайней мере я пока не нашёл способа его повалить - правда у меня довольна старая версия (3) Насколько я знаю, она же и последняя, хотя может быть следующие версии как-то по другому называются. Но у меня всегда было ощущение, что он не очень сильный, по-моему даже Рефокс II - III не может сломать. И по-моему он берет только до шестого фокса. Цитата: Странно, в рантайме наприме есть проверка на целостность объектного кода - он "пробегает" по всем командам модуля (берёт он конечно только поля размера) Может быть я и ошибаюсь, но мне показалось, что он "пробегает" не по всем командам модуля, а по всем командам вызываемой процедуры. Да и то весьма поверхностно. А Рефокс пробегает по всем процедурам, даже по тем, которые из фокса никогда вызываться не будут и по которым фокс никогда не будет пробегать. Цитата: - т.е. нельзя безнаказанно удалить команду целиком Ну это наверное потому, что там сразу куча пойнтеров поплывет. Цитата: и на этом почему-то ИНОГДА ReFox и падает... Боюсь что это не дыры а специально так сделано Ну, я как раз это дырами и называл. Цитата: Цитата: загрузчик, рантайм и изнутри фокса Ну я не знаю как можно защитить рантайм Это привилегия MS... Я имел в виду, хотя бы тривиальную проверку контрольной суммы в некоторых критических местах. Цитата: Цитата: Программы, у которых хорошо защищен загрузчик, а нет других защит очень легко ломаются элементарной подменой рантайма, который вместо того, чтобы запускать приложение просто выгрузит его на диск в незащищенном виде. Ха, а если и сам рантайм "встроен" внутрь? Системы типа Molebox или ThInstall ;) Но у них другие проблемы имеются... Честно говоря, таких не встречал, но ведь рантайм можно подменить непосредственно в памяти уже после загрузки

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

14.11.06 19:25:18

Hi, Igor

Igor Korolyov
Цитата:
В фоксовском рантайме чтение экзешника осуществляется из одного места, реально она переадресует в рантайме два вызова - ReadFile и SetFilePointer.
А как же собственно создание/клонирование хендлов? Ведь нужно отделять хендл к exe от хендлов к прочим файлам - иначе он ничего кроме exe не сможет прочитать

А где-то это отделяется. Когда туда доходит дело хендл уже сидит в каком-то регистре. Но именно через один и тот же вызов читается и сам экзешник, и, например, foxuser.

Цитата:
Не, если ты будешь "искать по самому рантайму", то как сможешь проверить что этот рантайм специально не модифицирован с целью создать дамп

Ну, скажем, контрольную сумму проверять.

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

Абсолютно согласен. Я и недолго пробовал.

Цитата:
Не надо лезть в код защиты - надо просто изменить параметры вызова (в стеке! Это IMHO НИКАК нельзя отследить и предотвратить, т.е. в итоге мы получаем абсолютно легальный вызов - неотличимый от тех что делает рантайм в "нормальном" режиме) и поставить останов ПОСЛЕ этого самого переадресованного вызова После этого слить буфер, куда защита считала данные - и это уже будет расшифрованный объектный код - ну конечно возможно закрытый встроенным фоксовым шифрованием, но это совершенно не проблема

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

Цитата:
Цитата:
Нет, она меняет не таблицы, а непосредственно вызов в рантайме.
Странно, зачем так сложно? Чтобы отладчиком не найти где был ReadFile? Так оно находится на "нормальном" рантайме и всего делов

Мне кажется они это сделали потому, что им так легче следить, откуда приходят вызовы. А, впрочем, не знаю.

Цитата:
Цитата:
Цитата:
От последнего наверняка поможет один из альтернативных декомпиляторов
Не поможет. Лучшее, что на сегодня есть - Corso 6. Он находит подпорченные места, но не знает, как их исправить.
А он уже стал сам декомпилировать? 5.2 только дешифровал и мог рефоксовые гнилые защитные понты удалить

Нет, не декомпилирует, но он может много всего исправить до такого состояния, что потом Рефоксом можно. В данном случае он исправить не мог, но повреждения нашел.

Цитата:
У тебя от UnFoxAll есть защита? Он с этой стороны более простой - по крайней мере я пока не нашёл способа его повалить - правда у меня довольна старая версия (3)

Насколько я знаю, она же и последняя, хотя может быть следующие версии как-то по другому называются. Но у меня всегда было ощущение, что он не очень сильный, по-моему даже Рефокс II - III не может сломать. И по-моему он берет только до шестого фокса.

Цитата:
Странно, в рантайме наприме есть проверка на целостность объектного кода - он "пробегает" по всем командам модуля (берёт он конечно только поля размера)

Может быть я и ошибаюсь, но мне показалось, что он "пробегает" не по всем командам модуля, а по всем командам вызываемой процедуры. Да и то весьма поверхностно. А Рефокс пробегает по всем процедурам, даже по тем, которые из фокса никогда вызываться не будут и по которым фокс никогда не будет пробегать.

Цитата:
- т.е. нельзя безнаказанно удалить команду целиком

Ну это наверное потому, что там сразу куча пойнтеров поплывет.

Цитата:
и на этом почему-то ИНОГДА ReFox и падает...
Боюсь что это не дыры а специально так сделано

Ну, я как раз это дырами и называл.

Цитата:
Цитата:
загрузчик, рантайм и изнутри фокса
Ну я не знаю как можно защитить рантайм Это привилегия MS...

Я имел в виду, хотя бы тривиальную проверку контрольной суммы в некоторых критических местах.

Цитата:
Цитата:
Программы, у которых хорошо защищен загрузчик, а нет других защит очень легко ломаются элементарной подменой рантайма, который вместо того, чтобы запускать приложение просто выгрузит его на диск в незащищенном виде.
Ха, а если и сам рантайм "встроен" внутрь? Системы типа Molebox или ThInstall ;) Но у них другие проблемы имеются...

Честно говоря, таких не встречал, но ведь рантайм можно подменить непосредственно в памяти уже после загрузки

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 15.11.06 09:44:31 leonid Мой файлик существенно поменьше - 46 Kb, но к сожалению он именно на шестерке. На девятке я смогу его сделать только через денек-другой. Вот теперь здесь файлик на девятке www.grada.lv

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 16.11.06 16:24:21 leonid А где-то это отделяется. Где-то в самом рантайме?Т.е. защита ориентируется на внутренние структуры данных рантайма? Круто однако leonid Когда туда доходит дело хендл уже сидит в каком-то регистре. Но именно через один и тот же вызов читается и сам экзешник, и, например, foxuser. Именно потому и есть необходимость разделять обращения - насколько я помню, и в Armadillo и в KonXise и в ещё какой-то системе это делалось на основе специальной "отметки" хендлов - т.е. по сути защита отдавала рантайму не настоящий хендл к файлу, а "свой" - ну там добавляла к значению большое число и т.п. А уже внутри себя на основе анализа параметра hFile и решала надо ли обрабатывать вызов или просто пропустить его дальше - настоящей АПИ функции. leonid Цитата: Не надо лезть в код защиты ... Я бы сказал, почти неотличимый, но на самом деле и от этого защитьться можно. Например, один фоксовский модуль загоняет в памать некое число и вызывает другой модуль. Расшифровщик (собственный, который вызывается вместо фоксовского) по какому-то признаку определяет этот файл и проверяет наличие данного числа в памяти. Если его нет, значит нас взламывают. Не понял как это поможет... Мы же на данном этапе не вмешиваемся в функционирование системы - т.е. она работает так как и должна - просто в некоторый момент вместо штатного считывания кусочка объектного кода мы заставляем декодер считать весь файл и всё... leonid Нет, не декомпилирует Да я уже его нашёл, посмотрел. IMHO автор пошёл совсем не в том направлении что нужно - вместо хорошего расширения функциональности занялся рисованием попсового интерфейса leonid но он может много всего исправить до такого состояния, что потом Рефоксом можно. Да исправить большинство повреждений я и сам могу руками - другое дело быстро найти их... leonid В данном случае он исправить не мог, но повреждения нашел. Ну значит путь к взлому открыт leonid Цитата: У тебя от UnFoxAll есть защита? Насколько я знаю, она же и последняя, хотя может быть следующие версии как-то по другому называются. Но у меня всегда было ощущение, что он не очень сильный, по-моему даже Рефокс II - III не может сломать. И по-моему он берет только до шестого фокса. Да именно так - есть там и ошибки. А Level III равно как и другие "паковщики" "автоматизированно" сломать ой как не просто - т.е. оно конечно можно, но подкаждый тип упаковки нужен декодер, при этом теоретически можно паковать вместе с нормальным шифрованием (не той пародией что встроена в рантайм) - а значит всё ещё более усложняется. А вот "руками" ломать - практически любую защиту можно по одному и тому-же алгоритму leonid Цитата: Странно, в рантайме наприме есть проверка на целостность объектного кода - он "пробегает" по всем командам модуля (берёт он конечно только поля размера) Может быть я и ошибаюсь, но мне показалось, что он "пробегает" не по всем командам модуля, а по всем командам вызываемой процедуры. Да и то весьма поверхностно. Ну под модулем я и понимал это дело - не fxp целиком. Кстати описание класса БЕЗ методов имеет примерно такую-же внутреннюю структуру - хотя все "команды" там это банальные присвоения свойствам некоторых выражений. leonid А Рефокс пробегает по всем процедурам, даже по тем, которые из фокса никогда вызываться не будут и по которым фокс никогда не будет пробегать. А, тут ещё и такой момент... Не задумывался никогда насчёт этого! Я в "исполняемом" коде ставил ловушки leonid Цитата: - т.е. нельзя безнаказанно удалить команду целиком Ну это наверное потому, что там сразу куча пойнтеров поплывет. Нет, там мало что плывёт - по крайней мере если бы этой проверки не было, то фокс мог бы исполнить код - т.к. в IF есть ссылка на то "куда идти если условие не выполнилось" - и потому даже если блок после IF но до ELSE/ENDIF полностью разрушен то это не фатально - при условии конечно что мы внутрь никогда не попадём Но рантайм тут проверяет поля размеров команд - т.е. по сути "проходит" через каждую команду - не разбирая её саму конечно. И если что не так то получаем not an object file... leonid Цитата: Ха, а если и сам рантайм "встроен" внутрь? Системы типа Molebox или ThInstall ;) Но у них другие проблемы имеются... Честно говоря, таких не встречал, но ведь рантайм можно подменить непосредственно в памяти уже после загрузки Можно наверное, но это уже гораздо сложнее - они же кстати и от "ручного" взлома неплохо защищают - т.к. в этих системах изначально стоят защиты от разного рода отладчиков. Они приближаются по сути к виртуальным машинам - только неплохо защищённым от отладки. Существеннейший минус в том, что система может быть сломана всего 1 раз - одно дело не сильно распространённый фокс - его то и ломает/защищает пяток энтузиастов, а те системы ориентированы в общем то на любые приложения - и сишные и даже нетовские - а значит армия взломщиков несравненно больше - и защита потому быстрее падает... P.S. Твой exe-ник я скачал, а вот китайский не успел видимо, т.к. сейчас его сервер не отдаёт - нету говорит... Посмотрим что там к чему - может на выходных, если ничего срочного не случится ------------------ WBR, Igor

Re: Дайте ссылочку рефокса

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

16.11.06 16:24:21

leonid
А где-то это отделяется.

Где-то в самом рантайме?Т.е. защита ориентируется на внутренние структуры данных рантайма? Круто однако

leonid
Когда туда доходит дело хендл уже сидит в каком-то регистре. Но именно через один и тот же вызов читается и сам экзешник, и, например, foxuser.

Именно потому и есть необходимость разделять обращения - насколько я помню, и в Armadillo и в KonXise и в ещё какой-то системе это делалось на основе специальной "отметки" хендлов - т.е. по сути защита отдавала рантайму не настоящий хендл к файлу, а "свой" - ну там добавляла к значению большое число и т.п. А уже внутри себя на основе анализа параметра hFile и решала надо ли обрабатывать вызов или просто пропустить его дальше - настоящей АПИ функции.

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

Не понял как это поможет... Мы же на данном этапе не вмешиваемся в функционирование системы - т.е. она работает так как и должна - просто в некоторый момент вместо штатного считывания кусочка объектного кода мы заставляем декодер считать весь файл и всё...

leonid
Нет, не декомпилирует

Да я уже его нашёл, посмотрел. IMHO автор пошёл совсем не в том направлении что нужно - вместо хорошего расширения функциональности занялся рисованием попсового интерфейса

leonid
но он может много всего исправить до такого состояния, что потом Рефоксом можно.

Да исправить большинство повреждений я и сам могу руками - другое дело быстро найти их...

leonid
В данном случае он исправить не мог, но повреждения нашел.

Ну значит путь к взлому открыт

leonid
Цитата:
У тебя от UnFoxAll есть защита?
Насколько я знаю, она же и последняя, хотя может быть следующие версии как-то по другому называются. Но у меня всегда было ощущение, что он не очень сильный, по-моему даже Рефокс II - III не может сломать. И по-моему он берет только до шестого фокса.

Да именно так - есть там и ошибки. А Level III равно как и другие "паковщики" "автоматизированно" сломать ой как не просто - т.е. оно конечно можно, но подкаждый тип упаковки нужен декодер, при этом теоретически можно паковать вместе с нормальным шифрованием (не той пародией что встроена в рантайм) - а значит всё ещё более усложняется. А вот "руками" ломать - практически любую защиту можно по одному и тому-же алгоритму

leonid
Цитата:
Странно, в рантайме наприме есть проверка на целостность объектного кода - он "пробегает" по всем командам модуля (берёт он конечно только поля размера)
Может быть я и ошибаюсь, но мне показалось, что он "пробегает" не по всем командам модуля, а по всем командам вызываемой процедуры. Да и то весьма поверхностно.

Ну под модулем я и понимал это дело - не fxp целиком. Кстати описание класса БЕЗ методов имеет примерно такую-же внутреннюю структуру - хотя все "команды" там это банальные присвоения свойствам некоторых выражений.

leonid
А Рефокс пробегает по всем процедурам, даже по тем, которые из фокса никогда вызываться не будут и по которым фокс никогда не будет пробегать.

А, тут ещё и такой момент... Не задумывался никогда насчёт этого! Я в "исполняемом" коде ставил ловушки

leonid
Цитата:
- т.е. нельзя безнаказанно удалить команду целиком
Ну это наверное потому, что там сразу куча пойнтеров поплывет.

Нет, там мало что плывёт - по крайней мере если бы этой проверки не было, то фокс мог бы исполнить код - т.к. в IF есть ссылка на то "куда идти если условие не выполнилось" - и потому даже если блок после IF но до ELSE/ENDIF полностью разрушен то это не фатально - при условии конечно что мы внутрь никогда не попадём

Но рантайм тут проверяет поля размеров команд - т.е. по сути "проходит" через каждую команду - не разбирая её саму конечно. И если что не так то получаем not an object file...

leonid
Цитата:
Ха, а если и сам рантайм "встроен" внутрь? Системы типа Molebox или ThInstall ;) Но у них другие проблемы имеются...
Честно говоря, таких не встречал, но ведь рантайм можно подменить непосредственно в памяти уже после загрузки

Можно наверное, но это уже гораздо сложнее - они же кстати и от "ручного" взлома неплохо защищают - т.к. в этих системах изначально стоят защиты от разного рода отладчиков. Они приближаются по сути к виртуальным машинам - только неплохо защищённым от отладки. Существеннейший минус в том, что система может быть сломана всего 1 раз - одно дело не сильно распространённый фокс - его то и ломает/защищает пяток энтузиастов, а те системы ориентированы в общем то на любые приложения - и сишные и даже нетовские - а значит армия взломщиков несравненно больше - и защита потому быстрее падает...

P.S. Твой exe-ник я скачал, а вот китайский не успел видимо, т.к. сейчас его сервер не отдаёт - нету говорит... Посмотрим что там к чему - может на выходных, если ничего срочного не случится

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

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 17.11.06 11:22:30 Igor Korolyov leonid А где-то это отделяется. Где-то в самом рантайме?Т.е. защита ориентируется на внутренние структуры данных рантайма? Круто однако Мне кажется, что защита может по хендлу определить название файла и, если это сам экзешник, то обработать его по-своему. Цитата: Именно потому и есть необходимость разделять обращения - насколько я помню, и в Armadillo и в KonXise и в ещё какой-то системе это делалось на основе специальной "отметки" хендлов - т.е. по сути защита отдавала рантайму не настоящий хендл к файлу, а "свой" - ну там добавляла к значению большое число и т.п. А уже внутри себя на основе анализа параметра hFile и решала надо ли обрабатывать вызов или просто пропустить его дальше - настоящей АПИ функции. Ну да, Рефокс III вроде тоже что-то подобное делает. Цитата: leonid Цитата: Не надо лезть в код защиты ... Я бы сказал, почти неотличимый, но на самом деле и от этого защитьться можно. Например, один фоксовский модуль загоняет в памать некое число и вызывает другой модуль. Расшифровщик (собственный, который вызывается вместо фоксовского) по какому-то признаку определяет этот файл и проверяет наличие данного числа в памяти. Если его нет, значит нас взламывают. Не понял как это поможет... Мы же на данном этапе не вмешиваемся в функционирование системы - т.е. она работает так как и должна - просто в некоторый момент вместо штатного считывания кусочка объектного кода мы заставляем декодер считать весь файл и всё... Идея такая. Сам декодер может раскодировать определенный файл только если ему подсунуть некую информацию, например ключ. Ключ подсовывает другой фоксовский модуль непосредственно перед тем, как вызвать данный файл. После употребления ключ, естественно, сразу стирается. Раскодировать такой файл не запуская саму фоксовскую программу не получится. Получается, что раскодировать можно только те файлы, которые реально загружаются при работе программы. Если в программе есть файлы, которые загружаюся далеко не при каждом запуске (например, у меня в программах второй уровень проверки защиты от копирования срабатывает только на второй год функционирования программы), то раскрыть эти файлы будет крайне проблематично. Цитата: А Level III равно как и другие "паковщики" "автоматизированно" сломать ой как не просто Для Level II, II+ и III я когда-то написал распаковщик www.grada.lv на шестом фоксе (рантайм нужен). И другие еще в сети есть. Цитата: - т.е. оно конечно можно, но подкаждый тип упаковки нужен декодер, при этом теоретически можно паковать вместе с нормальным шифрованием (не той пародией что встроена в рантайм) - а значит всё ещё более усложняется. Мой распаковщик действительно сделан чисто под Рефокс, а один еще, который я видел, включает его в числе прочих. Цитата: А вот "руками" ломать - практически любую защиту можно по одному и тому-же алгоритму Руками действительно возможности существенно шире. Цитата: leonid Цитата: Ха, а если и сам рантайм "встроен" внутрь? Системы типа Molebox или ThInstall ;) Но у них другие проблемы имеются... Честно говоря, таких не встречал, но ведь рантайм можно подменить непосредственно в памяти уже после загрузки Можно наверное, но это уже гораздо сложнее С помощью WinHex это совсем не трудно, тем более, что менять надо не весь рантайм, а только небольшой кусочек. Те защиты, которые я видел на WinHex реагируют совершенно спокойно, не принимая его за отладчик (которым он собственно и не является). А вот после внесения в рантайм каких-либо изменений китайская программа быстро валилась на эксепшн. Цитата: P.S. Твой exe-ник я скачал, а вот китайский не успел видимо, т.к. сейчас его сервер не отдаёт - нету говорит... Посмотрим что там к чему - может на выходных, если ничего срочного не случится Я глянул логи, и мне показалось, что он уже скачан, поэтому я его убрал. Сейчас назад выставил.

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

17.11.06 11:22:30

Igor Korolyov
leonid
А где-то это отделяется.
Где-то в самом рантайме?Т.е. защита ориентируется на внутренние структуры данных рантайма? Круто однако

Мне кажется, что защита может по хендлу определить название файла и, если это сам экзешник, то обработать его по-своему.

Цитата:
Именно потому и есть необходимость разделять обращения - насколько я помню, и в Armadillo и в KonXise и в ещё какой-то системе это делалось на основе специальной "отметки" хендлов - т.е. по сути защита отдавала рантайму не настоящий хендл к файлу, а "свой" - ну там добавляла к значению большое число и т.п. А уже внутри себя на основе анализа параметра hFile и решала надо ли обрабатывать вызов или просто пропустить его дальше - настоящей АПИ функции.

Ну да, Рефокс III вроде тоже что-то подобное делает.

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

Идея такая. Сам декодер может раскодировать определенный файл только если ему подсунуть некую информацию, например ключ. Ключ подсовывает другой фоксовский модуль непосредственно перед тем, как вызвать данный файл. После употребления ключ, естественно, сразу стирается. Раскодировать такой файл не запуская саму фоксовскую программу не получится. Получается, что раскодировать можно только те файлы, которые реально загружаются при работе программы. Если в программе есть файлы, которые загружаюся далеко не при каждом запуске (например, у меня в программах второй уровень проверки защиты от копирования срабатывает только на второй год функционирования программы), то раскрыть эти файлы будет крайне проблематично.

Цитата:
А Level III равно как и другие "паковщики" "автоматизированно" сломать ой как не просто

Для Level II, II+ и III я когда-то написал распаковщик
www.grada.lv
на шестом фоксе (рантайм нужен). И другие еще в сети есть.

Цитата:
- т.е. оно конечно можно, но подкаждый тип упаковки нужен декодер, при этом теоретически можно паковать вместе с нормальным шифрованием (не той пародией что встроена в рантайм) - а значит всё ещё более усложняется.

Мой распаковщик действительно сделан чисто под Рефокс, а один еще, который я видел, включает его в числе прочих.

Цитата:
А вот "руками" ломать - практически любую защиту можно по одному и тому-же алгоритму

Руками действительно возможности существенно шире.

Цитата:
leonid
Цитата:
Ха, а если и сам рантайм "встроен" внутрь? Системы типа Molebox или ThInstall ;) Но у них другие проблемы имеются...
Честно говоря, таких не встречал, но ведь рантайм можно подменить непосредственно в памяти уже после загрузки
Можно наверное, но это уже гораздо сложнее

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

Цитата:
P.S. Твой exe-ник я скачал, а вот китайский не успел видимо, т.к. сейчас его сервер не отдаёт - нету говорит... Посмотрим что там к чему - может на выходных, если ничего срочного не случится

Я глянул логи, и мне показалось, что он уже скачан, поэтому я его убрал. Сейчас назад выставил.

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 20.11.06 16:57:24 Hi leonid! Цитата: Мне кажется, что защита может по хендлу определить название файла и, если это сам экзешник, то обработать его по-своему. Да возможно, правда я не знаю не нужны ли какие-то повышенные (в частности админовские) права для исполнения такого кода... msdn2.microsoft.com А по хорошему надо бы и "внешние" fxp/app/ets... файлы иногда защищать - тут всё-же без полного перехвата всего IO никак не обойтись. Впрочем возможно что это больше работа для FoxCryptor и ему подобных программ... Цитата: Идея такая. Сам декодер может раскодировать определенный файл только если ему подсунуть некую информацию, например ключ. Ключ подсовывает другой фоксовский модуль непосредственно перед тем, как вызвать данный файл А, теперь понял - ну да, подобное переплетение защиты с "обычным" кодом действительно затруднит взлом. Цитата: Раскодировать такой файл не запуская саму фоксовскую программу не получится. Получается, что раскодировать можно только те файлы, которые реально загружаются при работе программы. Да, это создаёт сложности, однако скорее всего не непреодолимые. Например штатный алгоритм шифрования фокса (Который кстати и ты сам используешь - хотя я не очень понимаю зачем тебе это понадобилось - уж если ты перехватил декодер, то почему бы не переписать полностью алгоритм шифрования, а не только подменять декодировочную таблицу ) он IMHO довольно слабый - т.е. зная даже очень небольшие PlainText части соответствующих файлов (а для FXP, таблично-базированных файлов, BMP, JPG и многих других это именно так и есть) можно очень быстро подобрать декодировочную таблицу. По моим прикидкам, потребуется проверить не более чем 65536*N вариантов, где 65536 это период повторения генератора псевдослучайной последовательности (т.е. по сути размер массива из которого выбираются подблоки декодирования) а N это число пар "размеры подблоков декодирования" - коих тоже очень немного - в штатном рантайме VFP7 и старше их всего 23. Я наверное опробую этот вариант на твоей тестовой проге, т.к. пока не понял по какому принципу считается задающее число (которое определяет в частности используемую часть этого массива псевдослучайных чисел). Цитата: Если в программе есть файлы, которые загружаюся далеко не при каждом запуске (например, у меня в программах второй уровень проверки защиты от копирования срабатывает только на второй год функционирования программы), то раскрыть эти файлы будет крайне проблематично. Возможно что, "прямым" способом да, но вот если просто "побдирать пароли перебором" - то всё упирается в надёжность алгоритма шифрования, а в фоксе он увы чересчур примитивен Цитата: Для Level II, II+ и III я когда-то написал распаковщик Ну что-ж посмотрим. Правда я не понимаю почему это для "нового" формата Level III и вдруг старый рантайм Впрочем рантайм то я найду где-нить... Цитата: И другие еще в сети есть. Да, я тоже видел на WASM ананс декодера для Armadillo... Но как я понимаю тут всё очень чётко упирается в использованную версию кодировщика - т.е. надо либо научится вызывать соответствующие функции из exe loader-а, либо понять используемый формат сжатия/кодирования и написать свой раскодировщик. Первое думаю будет проще, но менее универсально (например в очередной версии поменяют структуру загрузчика, или начнут его шифровать и всё пропало ) Цитата: Мой распаковщик действительно сделан чисто под Рефокс, а один еще, который я видел, включает его в числе прочих. Ну раскодировать Level I/II не представляет труда (особенно имея задающую таблицу - т.е. собственно модифицированный рантайм - Level II+ тут не имеет преимуществ, так как "снять" изменённую таблицу можно и из памяти). Цитата: Цитата: А вот "руками" ломать - практически любую защиту можно по одному и тому-же алгоритму Руками действительно возможности существенно шире. Я имел в виду, что все упомянутые защиты ломались по одной схеме - т.е. по сути эти защиты были "одинаково" уязвимы. Это их большой минус. Цитата: Цитата: Можно наверное, но это уже гораздо сложнее С помощью WinHex это совсем не трудно, тем более, что менять надо не весь рантайм, а только небольшой кусочек. Те защиты, которые я видел на WinHex реагируют совершенно спокойно, не принимая его за отладчик (которым он собственно и не является). Не понял, как можно поменять рантайм (не запуская прогу), который включен внутрь exe, зашифрован и, видимо, дополнительно проверяется оболочкой-загрузчиком? Или мы про разное говорим? Цитата: А вот после внесения в рантайм каких-либо изменений китайская программа быстро валилась на эксепшн. Видимо надо её ломать НЕ меняя собственно рантайма P.S. Забрал китайскую прогу и декодер. Если не пропадёт охота, то на выходных посмотрю P.P.S. M.A = 8049 M.B = 304 M.C = 7030 Твою прогу не до конца разломал - те модули к которым был доступ снял, а редко запускаемая test2 пока недоступна Вот попробую её (и прочие fxp) ломать методом "подбора пароля" - т.к. не хватает терпения разобраться с алгоритмом получения "задающего числа" - это надо пошагово пройти весь блок "проверок и анализа" В общем и целом защита порадовала - нетривиальные моменты, комплексность подхода... Пришлось повозится не один час. Из отмеченных мной моментов (как минусов так и плюсов): - падает на машине с DEP (Athlon 64 X2) - надо бы те "кучи" куда ты "мелкий" код помещаешь создавать с флагом разрешающим "исполнение", ну и на ту часть основной "кучи" куда основной код помещён тоже видимо надо распространить это разрешение... - большая часть защиты от отладчика малоэффективна - во-первых всегда можно поставть INT3 не на первый байт АПИшной функции во-вторых IsDebuggerPresent() чересчур проста - достаточно поменять 1 байт в памяти и она "забудет" про отладчик - так что её копирование в свой код вылгядит стрельбой из пушки по воробьям - свой SEH и "контролируемое исключение" - это сильная вещь - пришлось с этим повозится - но возможно тут сыграла свою роль моя безграмотность в Win32 и слабое знание особенностей работы используемого мной отладчика То точки останова переставали работать, то исключение "зацикливалось" (видимо отладчик пропускал твой SEH а без его отработки "выхода нет"). - особенно долго я ругал свою тупость, когда понял как задёшево купился на "левый" ключевой файл создаваемый в TEMP ;) Совсем упустил что изнутри фоксового exe файлы часто видятся совсем не тем что они есть на самом деле. - "мелкие пакости" в уже раскодированном объектном коде тоже радуют. Правда ReFox не падает ни на левой "сверхдлинной" процедуре, (т.е. её он конечно не декодирует - но её и рантайм не прожуёт если вдруг она будет вызвана, но вот следующие за этим процедуры берёт нормально) ни на IF .F. ... (надо бы внутрь более поломанную команду поместить ) - кстати я не понимаю почему этот блок стоит у тебя в конце процедуры? По идее он должен стоять первой или второй (если есть [L]PARAMETERS) командами - тогда сбой декомпилятора как раз и скроет оставшуюся часть процедуры. Вот зануление одного смещения в заголовке объектного блока оказалось более эффективно - пока не прописал там 0x25 Рефокс отказывался признавать наличие в блоке фоксового кода Кстати почему это использовано лишь в методах формы? Для простого fxp рантайм не принимает этой шутки? - сама идея "плавающего" ключа дешифрации очень интересна и видимо очень эффективна для проекта где включено много файлов. - самошифрующийся код тоже любопытен, хотя он и не создал больших сложностей (по крайней мере при использовании Hardware Breakpoints - я не уверен что вставка INT3 прошла бы безболезненно - хотя отладчик возможно и отслеживает все попытки "чтения/записи" тех адресов куда он забил INT3)... - пожалуй главное: Повторю высказанную выше мысль - если уж ты перехватил декодер, то почему бы не перехватить его полностью - т.е. не заменить сам алоритм шифрования. По крайней мере тогда видимо придётся выдирать не только декодировочную таблицу, но и сам код дешифрации - а заодно и повысить уровень защиты от взлома путём "перебора" - т.е. тогда уж точно придётся полностью анализировать твой код Чтобы понять как формируется "задающее число" для каждого файла... ------------------ WBR, Igor

Re: Дайте ссылочку рефокса

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

20.11.06 16:57:24

Hi leonid!

Цитата:
Мне кажется, что защита может по хендлу определить название файла и, если это сам экзешник, то обработать его по-своему.

Да возможно, правда я не знаю не нужны ли какие-то повышенные (в частности админовские) права для исполнения такого кода...
msdn2.microsoft.com
А по хорошему надо бы и "внешние" fxp/app/ets... файлы иногда защищать - тут всё-же без полного перехвата всего IO никак не обойтись. Впрочем возможно что это больше работа для FoxCryptor и ему подобных программ...

Цитата:
Идея такая. Сам декодер может раскодировать определенный файл только если ему подсунуть некую информацию, например ключ. Ключ подсовывает другой фоксовский модуль непосредственно перед тем, как вызвать данный файл

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

Цитата:
Раскодировать такой файл не запуская саму фоксовскую программу не получится. Получается, что раскодировать можно только те файлы, которые реально загружаются при работе программы.

Да, это создаёт сложности, однако скорее всего не непреодолимые. Например штатный алгоритм шифрования фокса (Который кстати и ты сам используешь - хотя я не очень понимаю зачем тебе это понадобилось - уж если ты перехватил декодер, то почему бы не переписать полностью алгоритм шифрования, а не только подменять декодировочную таблицу

) он IMHO довольно слабый - т.е. зная даже очень небольшие PlainText части соответствующих файлов (а для FXP, таблично-базированных файлов, BMP, JPG и многих других это именно так и есть) можно очень быстро подобрать декодировочную таблицу. По моим прикидкам, потребуется проверить не более чем 65536*N вариантов, где 65536 это период повторения генератора псевдослучайной последовательности (т.е. по сути размер массива из которого выбираются подблоки декодирования) а N это число пар "размеры подблоков декодирования" - коих тоже очень немного - в штатном рантайме VFP7 и старше их всего 23.
Я наверное опробую этот вариант на твоей тестовой проге, т.к. пока не понял по какому принципу считается задающее число (которое определяет в частности используемую часть этого массива псевдослучайных чисел).

Цитата:
Если в программе есть файлы, которые загружаюся далеко не при каждом запуске (например, у меня в программах второй уровень проверки защиты от копирования срабатывает только на второй год функционирования программы), то раскрыть эти файлы будет крайне проблематично.

Возможно что, "прямым" способом да, но вот если просто "побдирать пароли перебором" - то всё упирается в надёжность алгоритма шифрования, а в фоксе он увы чересчур примитивен

Цитата:
Для Level II, II+ и III я когда-то написал распаковщик

Ну что-ж посмотрим. Правда я не понимаю почему это для "нового" формата Level III и вдруг старый рантайм

Впрочем рантайм то я найду где-нить...

Цитата:
И другие еще в сети есть.

Да, я тоже видел на WASM ананс декодера для Armadillo... Но как я понимаю тут всё очень чётко упирается в использованную версию кодировщика - т.е. надо либо научится вызывать соответствующие функции из exe loader-а, либо понять используемый формат сжатия/кодирования и написать свой раскодировщик. Первое думаю будет проще, но менее универсально (например в очередной версии поменяют структуру загрузчика, или начнут его шифровать и всё пропало

)

Цитата:
Мой распаковщик действительно сделан чисто под Рефокс, а один еще, который я видел, включает его в числе прочих.

Ну раскодировать Level I/II не представляет труда (особенно имея задающую таблицу - т.е. собственно модифицированный рантайм - Level II+ тут не имеет преимуществ, так как "снять" изменённую таблицу можно и из памяти).

Цитата:
Цитата:
А вот "руками" ломать - практически любую защиту можно по одному и тому-же алгоритму
Руками действительно возможности существенно шире.

Я имел в виду, что все упомянутые защиты ломались по одной схеме - т.е. по сути эти защиты были "одинаково" уязвимы. Это их большой минус.

Цитата:
Цитата:
Можно наверное, но это уже гораздо сложнее
С помощью WinHex это совсем не трудно, тем более, что менять надо не весь рантайм, а только небольшой кусочек. Те защиты, которые я видел на WinHex реагируют совершенно спокойно, не принимая его за отладчик (которым он собственно и не является).

Не понял, как можно поменять рантайм (не запуская прогу), который включен внутрь exe, зашифрован и, видимо, дополнительно проверяется оболочкой-загрузчиком? Или мы про разное говорим?

Цитата:
А вот после внесения в рантайм каких-либо изменений китайская программа быстро валилась на эксепшн.

Видимо надо её ломать НЕ меняя собственно рантайма

P.S. Забрал китайскую прогу и декодер. Если не пропадёт охота, то на выходных посмотрю

P.P.S. M.A = 8049
M.B = 304
M.C = 7030
Твою прогу не до конца разломал - те модули к которым был доступ снял, а редко запускаемая test2 пока недоступна

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

В общем и целом защита порадовала - нетривиальные моменты, комплексность подхода... Пришлось повозится не один час. Из отмеченных мной моментов (как минусов так и плюсов):
- падает на машине с DEP (Athlon 64 X2) - надо бы те "кучи" куда ты "мелкий" код помещаешь создавать с флагом разрешающим "исполнение", ну и на ту часть основной "кучи" куда основной код помещён тоже видимо надо распространить это разрешение...
- большая часть защиты от отладчика малоэффективна - во-первых всегда можно поставть INT3 не на первый байт АПИшной функции

во-вторых IsDebuggerPresent() чересчур проста - достаточно поменять 1 байт в памяти и она "забудет" про отладчик - так что её копирование в свой код вылгядит стрельбой из пушки по воробьям

- свой SEH и "контролируемое исключение" - это сильная вещь - пришлось с этим повозится - но возможно тут сыграла свою роль моя безграмотность в Win32 и слабое знание особенностей работы используемого мной отладчика

То точки останова переставали работать, то исключение "зацикливалось" (видимо отладчик пропускал твой SEH а без его отработки "выхода нет").
- особенно долго я ругал свою тупость, когда понял как задёшево купился на "левый" ключевой файл создаваемый в TEMP ;) Совсем упустил что изнутри фоксового exe файлы часто видятся совсем не тем что они есть на самом деле.
- "мелкие пакости" в уже раскодированном объектном коде тоже радуют. Правда ReFox не падает ни на левой "сверхдлинной" процедуре, (т.е. её он конечно не декодирует - но её и рантайм не прожуёт если вдруг она будет вызвана, но вот следующие за этим процедуры берёт нормально) ни на IF .F. ... (надо бы внутрь более поломанную команду поместить

) - кстати я не понимаю почему этот блок стоит у тебя в конце процедуры? По идее он должен стоять первой или второй (если есть [L]PARAMETERS) командами - тогда сбой декомпилятора как раз и скроет оставшуюся часть процедуры. Вот зануление одного смещения в заголовке объектного блока оказалось более эффективно - пока не прописал там 0x25 Рефокс отказывался признавать наличие в блоке фоксового кода

Кстати почему это использовано лишь в методах формы? Для простого fxp рантайм не принимает этой шутки?
- сама идея "плавающего" ключа дешифрации очень интересна и видимо очень эффективна для проекта где включено много файлов.
- самошифрующийся код тоже любопытен, хотя он и не создал больших сложностей (по крайней мере при использовании Hardware Breakpoints - я не уверен что вставка INT3 прошла бы безболезненно - хотя отладчик возможно и отслеживает все попытки "чтения/записи" тех адресов куда он забил INT3)...
- пожалуй главное: Повторю высказанную выше мысль - если уж ты перехватил декодер, то почему бы не перехватить его полностью - т.е. не заменить сам алоритм шифрования. По крайней мере тогда видимо придётся выдирать не только декодировочную таблицу, но и сам код дешифрации - а заодно и повысить уровень защиты от взлома путём "перебора" - т.е. тогда уж точно придётся полностью анализировать твой код

Чтобы понять как формируется "задающее число" для каждого файла...

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

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 20.11.06 18:36:50 Hi, Igor! Igor Korolyov Да возможно, правда я не знаю не нужны ли какие-то повышенные (в частности админовские) права для исполнения такого кода... Мне кажется, рантайм, когда открывает файл, просто записывает хендл и путь куда-то, где всегда может посмотреть. Цитата: А по хорошему надо бы и "внешние" fxp/app/ets... файлы иногда защищать А у меня эта защита app файлы тоже закрывает, fxp правда нет. Цитата: тут всё-же без полного перехвата всего IO никак не обойтись. У меня как раз без этого Цитата: Да, это создаёт сложности, однако скорее всего не непреодолимые. Например штатный алгоритм шифрования фокса (Который кстати и ты сам используешь - хотя я не очень понимаю зачем тебе это понадобилось - уж если ты перехватил декодер, то почему бы не переписать полностью алгоритм шифрования, а не только подменять декодировочную таблицу ) он IMHO довольно слабый - т.е. зная даже очень небольшие PlainText части соответствующих файлов (а для FXP, таблично-базированных файлов, BMP, JPG и многих других это именно так и есть) можно очень быстро подобрать декодировочную таблицу. По моим прикидкам, потребуется проверить не более чем 65536*N вариантов, где 65536 это период повторения генератора псевдослучайной последовательности (т.е. по сути размер массива из которого выбираются подблоки декодирования) а N это число пар "размеры подблоков декодирования" - коих тоже очень немного - в штатном рантайме VFP7 и старше их всего 23. Одно замечание. Я не использую весь штатный алгоритм шифрования, а только часть его, поэтому приведенные вычисления не очень корректны. В принципе я могу без проблем увеличить число вариантов до 2^64, а то и больше. Цитата: Возможно что, "прямым" способом да, но вот если просто "побдирать пароли перебором" - то всё упирается в надёжность алгоритма шифрования, а в фоксе он увы чересчур примитивен Да, я тоже думаю, что такой алгоритм возможен, но все-таки мне кажется там не все так просто. Цитата: Правда я не понимаю почему это для "нового" формата Level III и вдруг старый рантайм У меня шестой фокс лицензионный. Цитата: Цитата: Мой распаковщик действительно сделан чисто под Рефокс, а один еще, который я видел, включает его в числе прочих. Ну раскодировать Level I/II не представляет труда (особенно имея задающую таблицу - т.е. собственно модифицированный рантайм - Level II+ тут не имеет преимуществ, так как "снять" изменённую таблицу можно и из памяти). Мой распаковщик умет то, что не умеют другие - раскодировать Level II при отсутствии модифицированного рантайма. Цитата: Не понял, как можно поменять рантайм (не запуская прогу), который включен внутрь exe, зашифрован и, видимо, дополнительно проверяется оболочкой-загрузчиком? Или мы про разное говорим? Нет, я имел ввиду именно запустить программу, а когда она загрузится (скажем, покажет какое-нибудь окно) подменить рантайм, который к этому времени уже должен быть распакован и загружен на нужное место. Цитата: Цитата: А вот после внесения в рантайм каких-либо изменений китайская программа быстро валилась на эксепшн. Видимо надо её ломать НЕ меняя собственно рантайма Не знаю, не знаю. Я как раз менял, и она до того, как свалиться, успевала кое-что сделать. Цитата: Твою прогу ... разломал Ну чтож, честно скажу - класс! Пожалуй добавлю некоторые коментарии. Цитата: - падает на машине с DEP (Athlon 64 X2) - надо бы те "кучи" куда ты "мелкий" код помещаешь создавать с флагом разрешающим "исполнение", ну и на ту часть основной "кучи" куда основной код помещён тоже видимо надо распространить это разрешение... По-моему от DEP разрешения не помогут, мне кажется у меня все необходимые разрешения есть. Я процессоров с DEP не встречал, но с софтверным DEP можно побороться обычными настройками. Может с хардверным тоже можно? Цитата: - большая часть защиты от отладчика малоэффективна - во-первых всегда можно поставть INT3 не на первый байт АПИшной функции во-вторых IsDebuggerPresent() чересчур проста - достаточно поменять 1 байт в памяти и она "забудет" про отладчик - так что её копирование в свой код вылгядит стрельбой из пушки по воробьям У меня много кода - анахронизм. Просто пробовал разные варианты, а когда выяснялось, что они малоэффективны, все равно оставлял, потому как убирать - лишняя работа. Цитата: Правда ReFox не падает ни на левой "сверхдлинной" процедуре, (т.е. её он конечно не декодирует - но её и рантайм не прожуёт если вдруг она будет вызвана, но вот следующие за этим процедуры берёт нормально) Эта процедура создается случайным образом. В некоторых случаях Рефокс падает, в некоторых - нет. Если файлов много, то где-нибудь упадет. Цитата: ни на IF .F. ... (надо бы внутрь более поломанную команду поместить ) - кстати я не понимаю почему этот блок стоит у тебя в конце процедуры? По идее он должен стоять первой или второй (если есть [L]PARAMETERS) командами - тогда сбой декомпилятора как раз и скроет оставшуюся часть процедуры. Это анахронизм, 11 Рефокс это проглатывает, а 8 валился, даже если в конце. Цитата: Вот зануление одного смещения в заголовке объектного блока оказалось более эффективно - пока не прописал там 0x25 Рефокс отказывался признавать наличие в блоке фоксового кода Кстати почему это использовано лишь в методах формы? Для простого fxp рантайм не принимает этой шутки? Да, не принимает. Цитата: - сама идея "плавающего" ключа дешифрации очень интересна и видимо очень эффективна для проекта где включено много файлов. - самошифрующийся код тоже любопытен, хотя он и не создал больших сложностей (по крайней мере при использовании Hardware Breakpoints - я не уверен что вставка INT3 прошла бы безболезненно Не прошла бы. Цитата: пожалуй главное: Повторю высказанную выше мысль - если уж ты перехватил декодер, то почему бы не перехватить его полностью - т.е. не заменить сам алоритм шифрования. По крайней мере тогда видимо придётся выдирать не только декодировочную таблицу, но и сам код дешифрации - а заодно и повысить уровень защиты от взлома путём "перебора" - т.е. тогда уж точно придётся полностью анализировать твой код Чтобы понять как формируется "задающее число" для каждого файла... Ну, во-первых, так все-таки проще. А во вторых ... Ну да ладно, не буду выдавать оставшихся секретов.

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

20.11.06 18:36:50

Hi, Igor!

Igor Korolyov
Да возможно, правда я не знаю не нужны ли какие-то повышенные (в частности админовские) права для исполнения такого кода...

Мне кажется, рантайм, когда открывает файл, просто записывает хендл и путь куда-то, где всегда может посмотреть.

Цитата:
А по хорошему надо бы и "внешние" fxp/app/ets... файлы иногда защищать

А у меня эта защита app файлы тоже закрывает, fxp правда нет.

Цитата:
тут всё-же без полного перехвата всего IO никак не обойтись.

У меня как раз без этого

Цитата:
Да, это создаёт сложности, однако скорее всего не непреодолимые. Например штатный алгоритм шифрования фокса (Который кстати и ты сам используешь - хотя я не очень понимаю зачем тебе это понадобилось - уж если ты перехватил декодер, то почему бы не переписать полностью алгоритм шифрования, а не только подменять декодировочную таблицу ) он IMHO довольно слабый - т.е. зная даже очень небольшие PlainText части соответствующих файлов (а для FXP, таблично-базированных файлов, BMP, JPG и многих других это именно так и есть) можно очень быстро подобрать декодировочную таблицу. По моим прикидкам, потребуется проверить не более чем 65536*N вариантов, где 65536 это период повторения генератора псевдослучайной последовательности (т.е. по сути размер массива из которого выбираются подблоки декодирования) а N это число пар "размеры подблоков декодирования" - коих тоже очень немного - в штатном рантайме VFP7 и старше их всего 23.

Одно замечание. Я не использую весь штатный алгоритм шифрования, а только часть его, поэтому приведенные вычисления не очень корректны. В принципе я могу без проблем увеличить число вариантов до 2^64, а то и больше.

Цитата:
Возможно что, "прямым" способом да, но вот если просто "побдирать пароли перебором" - то всё упирается в надёжность алгоритма шифрования, а в фоксе он увы чересчур примитивен

Да, я тоже думаю, что такой алгоритм возможен, но все-таки мне кажется там не все так просто.

Цитата:
Правда я не понимаю почему это для "нового" формата Level III и вдруг старый рантайм

У меня шестой фокс лицензионный.

Цитата:
Цитата:
Мой распаковщик действительно сделан чисто под Рефокс, а один еще, который я видел, включает его в числе прочих.
Ну раскодировать Level I/II не представляет труда (особенно имея задающую таблицу - т.е. собственно модифицированный рантайм - Level II+ тут не имеет преимуществ, так как "снять" изменённую таблицу можно и из памяти).

Мой распаковщик умет то, что не умеют другие - раскодировать Level II при отсутствии модифицированного рантайма.

Цитата:
Не понял, как можно поменять рантайм (не запуская прогу), который включен внутрь exe, зашифрован и, видимо, дополнительно проверяется оболочкой-загрузчиком? Или мы про разное говорим?

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

Цитата:
Цитата:
А вот после внесения в рантайм каких-либо изменений китайская программа быстро валилась на эксепшн.
Видимо надо её ломать НЕ меняя собственно рантайма

Не знаю, не знаю. Я как раз менял, и она до того, как свалиться, успевала кое-что сделать.

Цитата:
Твою прогу ... разломал

Ну чтож, честно скажу - класс!
Пожалуй добавлю некоторые коментарии.

Цитата:
- падает на машине с DEP (Athlon 64 X2) - надо бы те "кучи" куда ты "мелкий" код помещаешь создавать с флагом разрешающим "исполнение", ну и на ту часть основной "кучи" куда основной код помещён тоже видимо надо распространить это разрешение...

По-моему от DEP разрешения не помогут, мне кажется у меня все необходимые разрешения есть. Я процессоров с DEP не встречал, но с софтверным DEP можно побороться обычными настройками. Может с хардверным тоже можно?

Цитата:
- большая часть защиты от отладчика малоэффективна - во-первых всегда можно поставть INT3 не на первый байт АПИшной функции во-вторых IsDebuggerPresent() чересчур проста - достаточно поменять 1 байт в памяти и она "забудет" про отладчик - так что её копирование в свой код вылгядит стрельбой из пушки по воробьям

У меня много кода - анахронизм. Просто пробовал разные варианты, а когда выяснялось, что они малоэффективны, все равно оставлял, потому как убирать - лишняя работа.

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

Эта процедура создается случайным образом. В некоторых случаях Рефокс падает, в некоторых - нет. Если файлов много, то где-нибудь упадет.

Цитата:
ни на IF .F. ... (надо бы внутрь более поломанную команду поместить ) - кстати я не понимаю почему этот блок стоит у тебя в конце процедуры? По идее он должен стоять первой или второй (если есть [L]PARAMETERS) командами - тогда сбой декомпилятора как раз и скроет оставшуюся часть процедуры.

Это анахронизм, 11 Рефокс это проглатывает, а 8 валился, даже если в конце.

Цитата:
Вот зануление одного смещения в заголовке объектного блока оказалось более эффективно - пока не прописал там 0x25 Рефокс отказывался признавать наличие в блоке фоксового кода Кстати почему это использовано лишь в методах формы? Для простого fxp рантайм не принимает этой шутки?

Да, не принимает.

Цитата:
- сама идея "плавающего" ключа дешифрации очень интересна и видимо очень эффективна для проекта где включено много файлов.
- самошифрующийся код тоже любопытен, хотя он и не создал больших сложностей (по крайней мере при использовании Hardware Breakpoints - я не уверен что вставка INT3 прошла бы безболезненно

Не прошла бы.

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

Ну, во-первых, так все-таки проще. А во вторых ... Ну да ладно, не буду выдавать оставшихся секретов.

Re: Дайте ссылочку рефокса
aga Сообщений: 290 Откуда: Могилев Дата регистрации: 09.10.2003	aga 20.11.06 19:15:16 to leonid и Igor Korolyov Молодцы парни!Так держать! Увлекательный матч, как на футболе!.. Как увлекательный сериал с продолжением!.. напряжение растет... ставки повышаются... Игорь, дааваааай!(я за тебя болею, земляк потому что. Извини, leonid). Право слово - очень интересная и поучительная беседа у вас вырисовывается! (по ней потом учебник защиты и кряка применительно к Fox'y писать можно будет Успехов вам в творчестве! С уважением, aga.

Re: Дайте ссылочку рефокса

aga

Сообщений: 290
Откуда: Могилев
Дата регистрации: 09.10.2003

aga

20.11.06 19:15:16

to leonid и Igor Korolyov
Молодцы парни!Так держать!
Увлекательный матч, как на футболе!..

Как увлекательный сериал с продолжением!..

напряжение растет... ставки повышаются...

Игорь, дааваааай!(я за тебя болею, земляк потому что. Извини, leonid).

Право слово - очень интересная и поучительная беседа у вас вырисовывается!
(по ней потом учебник защиты и кряка применительно к Fox'y писать можно будет

Успехов вам в творчестве!
С уважением, aga.

Re: Дайте ссылочку рефокса
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004	piva 21.11.06 07:07:17 АГа - а я за Леню болею, потому что сам в Риге учился - Леня ! Давай ! ------------------ Часто бывает так, что есть над чем задуматься, а нечем.

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 21.11.06 10:29:26 А мы по большому счету вовсе не соревнуемся. Цель одна - сделать более ли менее приличную защиту. А Игорь помогает мне найти в ней слабые места и дает ценные советы. Вот только не знаю, хватит ли мне сил все дотянуть.

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

21.11.06 10:29:26

А мы по большому счету вовсе не соревнуемся. Цель одна - сделать более ли менее приличную защиту. А Игорь помогает мне найти в ней слабые места и дает ценные советы. Вот только не знаю, хватит ли мне сил все дотянуть.

Re: Дайте ссылочку рефокса
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004	piva 21.11.06 10:35:34 Потому мы из группы поддержки ------------------ Часто бывает так, что есть над чем задуматься, а нечем.

Re: Дайте ссылочку рефокса
Snick Сообщений: 5949 Откуда: Москва Дата регистрации: 21.05.2001	Snick 21.11.06 10:52:12 Поддерживаю, интересно! Исправлено 1 раз(а). Последнее : Snick, 21.11.06 11:07

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 21.11.06 16:52:06 Hi leonid! Цитата: Мне кажется, рантайм, когда открывает файл, просто записывает хендл и путь куда-то, где всегда может посмотреть. Для "внешних" fxp/app/dbf наверное да, а вот для "главного" exe - не уверен. Надо бы попристальнее изучить внутреннюю таблицу "открытых файлов" фокса. Цитата: А у меня эта защита app файлы тоже закрывает, fxp правда нет. Ну ты же декодер перехватываешь - т.е. она по идее может защищать любой файл, который фокс решит передать на расшифровку декодеру - fxp в том числе. Кстати fxp по своей структуре это тот-же app, только содержит внутри всего 1 объектный модуль Цитата: У меня как раз без этого Ну да, т.к. ты уже "после" считывания блока встраиваешься, и как раз в то место, которое фокс вызывает лишь для зашифрованных файлов (как он полагает, самим собой зашифрованных ). Цитата: Одно замечание. Я не использую весь штатный алгоритм шифрования, а только часть его, поэтому приведенные вычисления не очень корректны. В принципе я могу без проблем увеличить число вариантов до 2^64, а то и больше. Теоретически да - если заменить алгоритм генерации PRAND со штатного полинома на что-то иное. Level II кстати помимо прочего меняет коэффициенты этого полинома - это AFAIK действительно затрудняет взлом путём прямого перебора. А вот если поменять не только коэффициенты но и сам алгоритм... Хотя-бы повысить степень полинома (но тут надо с математиками/криптологами посоветоваться) - тогда да, сложность может возрасти многократно и от метода прямого перебора придётся отказаться. Однако мне всё равно кажется что тут можно полностью заменить алгоритм - взяв какой либо из стандартных "блочных" алгоритмов шифрования. Вопрос генерации "ключа" тоже решаем - ты и сейчас каким-то образом получаешь для каждого "файла" в exe свой ключ - конечно 16 бит это маловато, но думаю несложно их "расширить" Главное - что ты отказываешься от вызова штатного и чересчур примитивного блока 2 проходного XOR-а А значит уже не так просто будет делать "внешнее" декодирование - и соответственно мы автоматически закрываем доступ к взлому тех "файлов" к которым не происходит обращения (или очень редко происходит). Цитата: У меня шестой фокс лицензионный. А, ну если исходить из этого Впрочем сегодня такую задачу можно решать на бесплатном .NET (благо с "математическими" задачами у него всё более менее нормально/красиво, в отличие от прикладных задач работы с СУБД). Либо используя бесплатную среду разработки VS Express (или как там оно называется), либо просто вызывая компилятор входящий в состав бесплатно же распространяемого SDK ;) Цитата: Мой распаковщик умет то, что не умеют другие - раскодировать Level II при отсутствии модифицированного рантайма Вот это круто - неужели полный перебор реализовал? Я правда не знаю по какому принципу Refox меняет коэффициенты полинома - возможно что он всегда ставит одни и те-же коэффициенты Но если коэффициенты могут быть любыми, тогда сложность подбора многократно возрастает. Да и с таблицей "размеров частей ключа" тоже не всё так гладко - найти размер первой половинки думаю не очень сложно, но вот определить размер второй... Для этого надо определить "период повторения" - а это значит что требуется иметь достаточно большой кусок PlainText данных - ну ладно для fpt подобных файлов - там практически всегда имеется около полукилобайта нулей - этого наверняка будет достаточно для атаки, но ведь далеко не всегда в программе имеются vct/sct или собственно fpt файлы! А в простом fxp модуле всего-то пару десятков байт (причём даже не подряд идущих) можно с большой долей уверенности "угадать" IMHO этого маловато для атаки методом перебора... Хотя надо ещё поразмыслить, может я чего и упускаю из вида. Цитата: Нет, я имел ввиду именно запустить программу, а когда она загрузится (скажем, покажет какое-нибудь окно) подменить рантайм, который к этому времени уже должен быть распакован и загружен на нужное место. А, ну это другое дело - но я же писал, что такие системы неплохо защищают адресное пространство "завёрнутой" программы - как от отладчика, так и от модификации. Т.е. сначала придётся сломать эту внешнюю защиту, и только потом ломать сам фокс - либо подменой рантайма, либо просто запуском его частей в "пошаговом" режиме... Цитата: Не знаю, не знаю. Я как раз менял, и она до того, как свалиться, успевала кое-что сделать Ну если там стоит нечто типа проверки на CRC блока кода рантайма, то "отладка" этого кода не повалит систему - если конечно использовать Hardware Breakpoints, или если найти и временно деактивировать этот самый код проверки целостности (ты вроде говорил что он в отдельном потоке исполняется). Цитата: По-моему от DEP разрешения не помогут, мне кажется у меня все необходимые разрешения есть. Я процессоров с DEP не встречал, но с софтверным DEP можно побороться обычными настройками. Может с хардверным тоже можно? Не знаю, в MSDN по CreateHeap описан флаг HEAP_CREATE_ENABLE_EXECUTE - как я понимаю это именно оно и есть. А для основной "кучи" должен помочь VirtualProtect... Но если не поможет то в можно отказаться от использования "кучи" для размещения кода, а использовать простой блок полученный по VirtualAlloc... Т.е. это IMHO не проблема. Цитата: У меня много кода - анахронизм. Просто пробовал разные варианты, а когда выяснялось, что они малоэффективны, все равно оставлял, потому как убирать - лишняя работа. А, понятно Цитата: Эта процедура создается случайным образом. В некоторых случаях Рефокс падает, в некоторых - нет. Если файлов много, то где-нибудь упадет. Возможно. Цитата: Это анахронизм, 11 Рефокс это проглатывает, а 8 валился, даже если в конце. Я пользовал команду состоящую из нулей - XI на такой останавливается - да не валится напрочь, но оставшийся в процедуре/методе код не берёт. Правда UnFoxAll 3 это не останавливает. Цитата: Цитата: я не уверен что вставка INT3 прошла бы безболезненно Не прошла бы. Не прошла бы если отладчик не отслеживает все обращения к памяти - иначе он бы либо остановился с сообщением про то что читается временно изменённый байт, либо эмулировал "читающую" команду так, чобы она считала не CC а "старое" содержимое. По крайней мере он способен "пошагово" выполнять REP* команды - уж не знаю (не помню) является ли это фишкой x86 или отладчик на самом деле "заменяет" REP* команду на соответствующую одиночную команду (для этого достаточно сместить IP на 1 байт ) Я просто не настолько хорошо знаю отладчик, чтобы полностью доверится ему в этом плане - хотя это можно легко проверить Цитата: Цитата: пожалуй главное: Повторю высказанную выше мысль - если уж ты перехватил декодер, то почему бы не перехватить его полностью Ну, во-первых, так все-таки проще. Проще? Вызывать из своего кода функцию рантайма? Не сказал бы я что это проще... Вот ломать его из-за этого действительно проще Цитата: А во вторых ... Ну да ладно, не буду выдавать оставшихся секретов. ------------------ WBR, Igor

Re: Дайте ссылочку рефокса

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

21.11.06 16:52:06

Hi leonid!

Цитата:
Мне кажется, рантайм, когда открывает файл, просто записывает хендл и путь куда-то, где всегда может посмотреть.

Для "внешних" fxp/app/dbf наверное да, а вот для "главного" exe - не уверен. Надо бы попристальнее изучить внутреннюю таблицу "открытых файлов" фокса.

Цитата:
А у меня эта защита app файлы тоже закрывает, fxp правда нет.

Ну ты же декодер перехватываешь - т.е. она по идее может защищать любой файл, который фокс решит передать на расшифровку декодеру - fxp в том числе. Кстати fxp по своей структуре это тот-же app, только содержит внутри всего 1 объектный модуль

Цитата:
У меня как раз без этого

Ну да, т.к. ты уже "после" считывания блока встраиваешься, и как раз в то место, которое фокс вызывает лишь для зашифрованных файлов (как он полагает, самим собой зашифрованных

Цитата:
Одно замечание. Я не использую весь штатный алгоритм шифрования, а только часть его, поэтому приведенные вычисления не очень корректны. В принципе я могу без проблем увеличить число вариантов до 2^64, а то и больше.

Теоретически да - если заменить алгоритм генерации PRAND со штатного полинома на что-то иное. Level II кстати помимо прочего меняет коэффициенты этого полинома - это AFAIK действительно затрудняет взлом путём прямого перебора. А вот если поменять не только коэффициенты но и сам алгоритм... Хотя-бы повысить степень полинома (но тут надо с математиками/криптологами посоветоваться) - тогда да, сложность может возрасти многократно и от метода прямого перебора придётся отказаться. Однако мне всё равно кажется что тут можно полностью заменить алгоритм - взяв какой либо из стандартных "блочных" алгоритмов шифрования. Вопрос генерации "ключа" тоже решаем - ты и сейчас каким-то образом получаешь для каждого "файла" в exe свой ключ - конечно 16 бит это маловато, но думаю несложно их "расширить"

Главное - что ты отказываешься от вызова штатного и чересчур примитивного блока 2 проходного XOR-а

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

Цитата:
У меня шестой фокс лицензионный.

А, ну если исходить из этого

Впрочем сегодня такую задачу можно решать на бесплатном .NET (благо с "математическими" задачами у него всё более менее нормально/красиво, в отличие от прикладных задач работы с СУБД). Либо используя бесплатную среду разработки VS Express (или как там оно называется), либо просто вызывая компилятор входящий в состав бесплатно же распространяемого SDK ;)

Цитата:
Мой распаковщик умет то, что не умеют другие - раскодировать Level II при отсутствии модифицированного рантайма

Вот это круто - неужели полный перебор реализовал? Я правда не знаю по какому принципу Refox меняет коэффициенты полинома - возможно что он всегда ставит одни и те-же коэффициенты

Но если коэффициенты могут быть любыми, тогда сложность подбора многократно возрастает. Да и с таблицей "размеров частей ключа" тоже не всё так гладко - найти размер первой половинки думаю не очень сложно, но вот определить размер второй... Для этого надо определить "период повторения" - а это значит что требуется иметь достаточно большой кусок PlainText данных - ну ладно для fpt подобных файлов - там практически всегда имеется около полукилобайта нулей - этого наверняка будет достаточно для атаки, но ведь далеко не всегда в программе имеются vct/sct или собственно fpt файлы! А в простом fxp модуле всего-то пару десятков байт (причём даже не подряд идущих) можно с большой долей уверенности "угадать" IMHO этого маловато для атаки методом перебора... Хотя надо ещё поразмыслить, может я чего и упускаю из вида.

Цитата:
Нет, я имел ввиду именно запустить программу, а когда она загрузится (скажем, покажет какое-нибудь окно) подменить рантайм, который к этому времени уже должен быть распакован и загружен на нужное место.

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

Цитата:
Не знаю, не знаю. Я как раз менял, и она до того, как свалиться, успевала кое-что сделать

Ну если там стоит нечто типа проверки на CRC блока кода рантайма, то "отладка" этого кода не повалит систему - если конечно использовать Hardware Breakpoints, или если найти и временно деактивировать этот самый код проверки целостности (ты вроде говорил что он в отдельном потоке исполняется).

Цитата:
По-моему от DEP разрешения не помогут, мне кажется у меня все необходимые разрешения есть. Я процессоров с DEP не встречал, но с софтверным DEP можно побороться обычными настройками. Может с хардверным тоже можно?

Не знаю, в MSDN по CreateHeap описан флаг HEAP_CREATE_ENABLE_EXECUTE - как я понимаю это именно оно и есть. А для основной "кучи" должен помочь VirtualProtect... Но если не поможет то в можно отказаться от использования "кучи" для размещения кода, а использовать простой блок полученный по VirtualAlloc... Т.е. это IMHO не проблема.

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

А, понятно

Цитата:
Эта процедура создается случайным образом. В некоторых случаях Рефокс падает, в некоторых - нет. Если файлов много, то где-нибудь упадет.

Возможно.

Цитата:
Это анахронизм, 11 Рефокс это проглатывает, а 8 валился, даже если в конце.

Я пользовал команду состоящую из нулей - XI на такой останавливается - да не валится напрочь, но оставшийся в процедуре/методе код не берёт. Правда UnFoxAll 3 это не останавливает.

Цитата:
Цитата:
я не уверен что вставка INT3 прошла бы безболезненно
Не прошла бы.

Не прошла бы если отладчик не отслеживает все обращения к памяти - иначе он бы либо остановился с сообщением про то что читается временно изменённый байт, либо эмулировал "читающую" команду так, чобы она считала не CC а "старое" содержимое. По крайней мере он способен "пошагово" выполнять REP* команды - уж не знаю (не помню) является ли это фишкой x86 или отладчик на самом деле "заменяет" REP* команду на соответствующую одиночную команду (для этого достаточно сместить IP на 1 байт

) Я просто не настолько хорошо знаю отладчик, чтобы полностью доверится ему в этом плане - хотя это можно легко проверить

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

Проще? Вызывать из своего кода функцию рантайма? Не сказал бы я что это проще... Вот ломать его из-за этого действительно проще

Цитата:
А во вторых ... Ну да ладно, не буду выдавать оставшихся секретов.

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

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 21.11.06 18:29:20 Hi Igor! Igor Korolyov Цитата: Мне кажется, рантайм, когда открывает файл, просто записывает хендл и путь куда-то, где всегда может посмотреть. Для "внешних" fxp/app/dbf наверное да, а вот для "главного" exe - не уверен. Надо бы попристальнее изучить внутреннюю таблицу "открытых файлов" фокса. Я так понял, что главный ехе у нее там же. Цитата: Цитата: А у меня эта защита app файлы тоже закрывает, fxp правда нет. Ну ты же декодер перехватываешь - т.е. она по идее может защищать любой файл, который фокс решит передать на расшифровку декодеру - fxp в том числе. У меня все не совсем так. Информация о защищенном арр файле хранится в нем самом и активизируется при запуске, с fxp так не поступишь, значит надо придумывать и реализовывать что-то новое. Цитата: Цитата: Одно замечание. Я не использую весь штатный алгоритм шифрования, а только часть его, поэтому приведенные вычисления не очень корректны. В принципе я могу без проблем увеличить число вариантов до 2^64, а то и больше. Теоретически да - если заменить алгоритм генерации PRAND со штатного полинома на что-то иное. Level II кстати помимо прочего меняет коэффициенты этого полинома - это AFAIK действительно затрудняет взлом путём прямого перебора. А вот если поменять не только коэффициенты но и сам алгоритм... Хотя-бы повысить степень полинома (но тут надо с математиками/криптологами посоветоваться) - тогда да, сложность может возрасти многократно и от метода прямого перебора придётся отказаться. Вот-вот, идея именно такая, только вот я уже что-то забыл, я это реализовал, или только собирался? Цитата: Однако мне всё равно кажется что тут можно полностью заменить алгоритм - взяв какой либо из стандартных "блочных" алгоритмов шифрования. Вопрос генерации "ключа" тоже решаем - ты и сейчас каким-то образом получаешь для каждого "файла" в exe свой ключ - конечно 16 бит это маловато, но думаю несложно их "расширить" Главное - что ты отказываешься от вызова штатного и чересчур примитивного блока 2 проходного XOR-а А значит уже не так просто будет делать "внешнее" декодирование - и соответственно мы автоматически закрываем доступ к взлому тех "файлов" к которым не происходит обращения (или очень редко происходит). Ну да, конечно. Если что, то может когда-нибудь... Цитата: Впрочем сегодня такую задачу можно решать на бесплатном .NET (благо с "математическими" задачами у него всё более менее нормально/красиво, в отличие от прикладных задач работы с СУБД). Либо используя бесплатную среду разработки VS Express (или как там оно называется), либо просто вызывая компилятор входящий в состав бесплатно же распространяемого SDK ;) Ну это все надо изучать, а фокс я уже знаю Цитата: Цитата: Мой распаковщик умет то, что не умеют другие - раскодировать Level II при отсутствии модифицированного рантайма Вот это круто - неужели полный перебор реализовал? В принципе, да. Но пришлось очень сильно пооптимизировать, чтоб по времени разумно было. Цитата: Я правда не знаю по какому принципу Refox меняет коэффициенты полинома - возможно что он всегда ставит одни и те-же коэффициенты Вот этого я тоже к сожалению не знаю, а то бы можно было еще ускорить. Цитата: Но если коэффициенты могут быть любыми, тогда сложность подбора многократно возрастает. Да и с таблицей "размеров частей ключа" тоже не всё так гладко - найти размер первой половинки думаю не очень сложно, но вот определить размер второй... Для этого надо определить "период повторения" - а это значит что требуется иметь достаточно большой кусок PlainText данных - ну ладно для fpt подобных файлов - там практически всегда имеется около полукилобайта нулей - этого наверняка будет достаточно для атаки, но ведь далеко не всегда в программе имеются vct/sct или собственно fpt файлы! А в простом fxp модуле всего-то пару десятков байт (причём даже не подряд идущих) можно с большой долей уверенности "угадать" IMHO этого маловато для атаки методом перебора... Хотя надо ещё поразмыслить, может я чего и упускаю из вида. Там в конце есть таблица размещения файлов, там нолики по восемь штук встречаются часто, а ее расположение можно вычислить. Цитата: я же писал, что такие системы неплохо защищают адресное пространство "завёрнутой" программы - как от отладчика, так и от модификации. Т.е. сначала придётся сломать эту внешнюю защиту, и только потом ломать сам фокс - либо подменой рантайма, либо просто запуском его частей в "пошаговом" режиме... Что-то я с такими системами еще не встречался, мне все попроще попадались. Цитата: Цитата: Не знаю, не знаю. Я как раз менял, и она до того, как свалиться, успевала кое-что сделать Ну если там стоит нечто типа проверки на CRC блока кода рантайма, то "отладка" этого кода не повалит систему - если конечно использовать Hardware Breakpoints, или если найти и временно деактивировать этот самый код проверки целостности (ты вроде говорил что он в отдельном потоке исполняется). Отладка даже через Int 3 эту систему не валит, а вот изменение рантайма валит, но не сразу, а где-то через полсекунды, похоже по таймеру. То, что это в отдельном потоке, я предполагаю, но вовсе не уверен. Вообще мне показалось, что эта программа защищена дважды - сначала фоксовской защитой, а затем еще AsProtect. Хотя может и ошибаюсь. Цитата: Цитата: По-моему от DEP разрешения не помогут, мне кажется у меня все необходимые разрешения есть. Я процессоров с DEP не встречал, но с софтверным DEP можно побороться обычными настройками. Может с хардверным тоже можно? Не знаю, в MSDN по CreateHeap описан флаг HEAP_CREATE_ENABLE_EXECUTE - как я понимаю это именно оно и есть. А для основной "кучи" должен помочь VirtualProtect... Но если не поможет то в можно отказаться от использования "кучи" для размещения кода, а использовать простой блок полученный по VirtualAlloc... Т.е. это IMHO не проблема. Да, я тоже подумал, наверное эту проблему так можно решить, только мне довольно много кода придется переписать, а что хуже всего - отлаживать. А отлаживать программу, в которой сделано все, чтобы отлаживать ее было как можно труднее - это кошмар. А программировать без ошибок я не умею. Цитата: Я пользовал команду состоящую из нулей - XI на такой останавливается - да не валится напрочь, но оставшийся в процедуре/методе код не берёт. Там у Рефокса есть какой-то переключатель, так Рефокс в двух положения переключателя то, что у меня написано, не брал, а в одном - брал. Цитата: Цитата: Цитата: я не уверен что вставка INT3 прошла бы безболезненно Не прошла бы. Не прошла бы если отладчик не отслеживает все обращения к памяти - иначе он бы либо остановился с сообщением про то что читается временно изменённый байт, либо эмулировал "читающую" команду так, чобы она считала не CC а "старое" содержимое. По крайней мере он способен "пошагово" выполнять REP* команды - уж не знаю (не помню) является ли это фишкой x86 или отладчик на самом деле "заменяет" REP* команду на соответствующую одиночную команду (для этого достаточно сместить IP на 1 байт ) Я просто не настолько хорошо знаю отладчик, чтобы полностью доверится ему в этом плане - хотя это можно легко проверить Я использовал Olly, он по-моему такое не умеет, а впрочем я его тоже не шибко хорошо знаю. Цитата: Цитата: Цитата: пожалуй главное: Повторю высказанную выше мысль - если уж ты перехватил декодер, то почему бы не перехватить его полностью Ну, во-первых, так все-таки проще. Проще? Вызывать из своего кода функцию рантайма? Не сказал бы я что это проще... Вот ломать его из-за этого действительно проще Ну а это, наверное, кому как.

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

21.11.06 18:29:20

Hi Igor!

Igor Korolyov
Цитата:
Мне кажется, рантайм, когда открывает файл, просто записывает хендл и путь куда-то, где всегда может посмотреть.
Для "внешних" fxp/app/dbf наверное да, а вот для "главного" exe - не уверен. Надо бы попристальнее изучить внутреннюю таблицу "открытых файлов" фокса.

Я так понял, что главный ехе у нее там же.

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

У меня все не совсем так. Информация о защищенном арр файле хранится в нем самом и активизируется при запуске, с fxp так не поступишь, значит надо придумывать и реализовывать что-то новое.

Цитата:
Цитата:
Одно замечание. Я не использую весь штатный алгоритм шифрования, а только часть его, поэтому приведенные вычисления не очень корректны. В принципе я могу без проблем увеличить число вариантов до 2^64, а то и больше.
Теоретически да - если заменить алгоритм генерации PRAND со штатного полинома на что-то иное. Level II кстати помимо прочего меняет коэффициенты этого полинома - это AFAIK действительно затрудняет взлом путём прямого перебора. А вот если поменять не только коэффициенты но и сам алгоритм... Хотя-бы повысить степень полинома (но тут надо с математиками/криптологами посоветоваться) - тогда да, сложность может возрасти многократно и от метода прямого перебора придётся отказаться.

Вот-вот, идея именно такая, только вот я уже что-то забыл, я это реализовал, или только собирался?

Цитата:
Однако мне всё равно кажется что тут можно полностью заменить алгоритм - взяв какой либо из стандартных "блочных" алгоритмов шифрования. Вопрос генерации "ключа" тоже решаем - ты и сейчас каким-то образом получаешь для каждого "файла" в exe свой ключ - конечно 16 бит это маловато, но думаю несложно их "расширить" Главное - что ты отказываешься от вызова штатного и чересчур примитивного блока 2 проходного XOR-а А значит уже не так просто будет делать "внешнее" декодирование - и соответственно мы автоматически закрываем доступ к взлому тех "файлов" к которым не происходит обращения (или очень редко происходит).

Ну да, конечно. Если что, то может когда-нибудь...

Цитата:
Впрочем сегодня такую задачу можно решать на бесплатном .NET (благо с "математическими" задачами у него всё более менее нормально/красиво, в отличие от прикладных задач работы с СУБД). Либо используя бесплатную среду разработки VS Express (или как там оно называется), либо просто вызывая компилятор входящий в состав бесплатно же распространяемого SDK ;)

Ну это все надо изучать, а фокс я уже знаю

Цитата:
Цитата:
Мой распаковщик умет то, что не умеют другие - раскодировать Level II при отсутствии модифицированного рантайма
Вот это круто - неужели полный перебор реализовал?

В принципе, да. Но пришлось очень сильно пооптимизировать, чтоб по времени разумно было.

Цитата:
Я правда не знаю по какому принципу Refox меняет коэффициенты полинома - возможно что он всегда ставит одни и те-же коэффициенты

Вот этого я тоже к сожалению не знаю, а то бы можно было еще ускорить.

Цитата:
Но если коэффициенты могут быть любыми, тогда сложность подбора многократно возрастает. Да и с таблицей "размеров частей ключа" тоже не всё так гладко - найти размер первой половинки думаю не очень сложно, но вот определить размер второй... Для этого надо определить "период повторения" - а это значит что требуется иметь достаточно большой кусок PlainText данных - ну ладно для fpt подобных файлов - там практически всегда имеется около полукилобайта нулей - этого наверняка будет достаточно для атаки, но ведь далеко не всегда в программе имеются vct/sct или собственно fpt файлы! А в простом fxp модуле всего-то пару десятков байт (причём даже не подряд идущих) можно с большой долей уверенности "угадать" IMHO этого маловато для атаки методом перебора... Хотя надо ещё поразмыслить, может я чего и упускаю из вида.

Там в конце есть таблица размещения файлов, там нолики по восемь штук встречаются часто, а ее расположение можно вычислить.

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

Что-то я с такими системами еще не встречался, мне все попроще попадались.

Цитата:
Цитата:
Не знаю, не знаю. Я как раз менял, и она до того, как свалиться, успевала кое-что сделать
Ну если там стоит нечто типа проверки на CRC блока кода рантайма, то "отладка" этого кода не повалит систему - если конечно использовать Hardware Breakpoints, или если найти и временно деактивировать этот самый код проверки целостности (ты вроде говорил что он в отдельном потоке исполняется).

Отладка даже через Int 3 эту систему не валит, а вот изменение рантайма валит, но не сразу, а где-то через полсекунды, похоже по таймеру. То, что это в отдельном потоке, я предполагаю, но вовсе не уверен. Вообще мне показалось, что эта программа защищена дважды - сначала фоксовской защитой, а затем еще AsProtect. Хотя может и ошибаюсь.

Цитата:
Цитата:
По-моему от DEP разрешения не помогут, мне кажется у меня все необходимые разрешения есть. Я процессоров с DEP не встречал, но с софтверным DEP можно побороться обычными настройками. Может с хардверным тоже можно?
Не знаю, в MSDN по CreateHeap описан флаг HEAP_CREATE_ENABLE_EXECUTE - как я понимаю это именно оно и есть. А для основной "кучи" должен помочь VirtualProtect... Но если не поможет то в можно отказаться от использования "кучи" для размещения кода, а использовать простой блок полученный по VirtualAlloc... Т.е. это IMHO не проблема.

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

Цитата:
Я пользовал команду состоящую из нулей - XI на такой останавливается - да не валится напрочь, но оставшийся в процедуре/методе код не берёт.

Там у Рефокса есть какой-то переключатель, так Рефокс в двух положения переключателя то, что у меня написано, не брал, а в одном - брал.

Цитата:
Цитата:
Цитата:
я не уверен что вставка INT3 прошла бы безболезненно
Не прошла бы.
Не прошла бы если отладчик не отслеживает все обращения к памяти - иначе он бы либо остановился с сообщением про то что читается временно изменённый байт, либо эмулировал "читающую" команду так, чобы она считала не CC а "старое" содержимое. По крайней мере он способен "пошагово" выполнять REP* команды - уж не знаю (не помню) является ли это фишкой x86 или отладчик на самом деле "заменяет" REP* команду на соответствующую одиночную команду (для этого достаточно сместить IP на 1 байт ) Я просто не настолько хорошо знаю отладчик, чтобы полностью доверится ему в этом плане - хотя это можно легко проверить

Я использовал Olly, он по-моему такое не умеет, а впрочем я его тоже не шибко хорошо знаю.

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

Ну а это, наверное, кому как.

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 22.11.06 20:40:39 Hi leonid! Цитата: У меня все не совсем так. Информация о защищенном арр файле хранится в нем самом и активизируется при запуске, с fxp так не поступишь, значит надо придумывать и реализовывать что-то новое. Почему? Если дело в ключе - то можно для данного конкретного случая найти место в заголовке fxp (там где и фокс хранит инфу о ключе), если о собственно "подключении" - то это сделает запускающий exe... Цитата: Цитата: ... заменить алгоритм генерации PRAND ... Вот-вот, идея именно такая, только вот я уже что-то забыл, я это реализовал, или только собирался? Я не увидел - в test точно такой-же алгоритм как и в самом рантайме. Кстати по некотором размышлении я понял в чём есть существенная проблема замены алгоритма (в случае перехвата только декодера, а не всего IO) - рантайм не читает файлы блоками достаточного размера - он может и 4 байта прочитать и даже видимо всего 1 (кажется я такой вызов видел) - а множество криптоалгоритмов смогут работать только если им дать целый блок... Так что видимо остаётся один путь - "укрепить" PRAND - взять более "мощный" полином и использовать хотя-бы 32 разрядную арифметику (а лучше действительно 64 разрядную - но я не уверен что при этом не придётся уже задействовать FPU). Цитата: Цитата: неужели полный перебор реализовал? В принципе, да. Но пришлось очень сильно пооптимизировать, чтоб по времени разумно было. Ну это понятно Цитата: Там в конце есть таблица размещения файлов, там нолики по восемь штук встречаются часто, а ее расположение можно вычислить. Да, действительно есть такое. Правда я видел одну защиту, которая "дописывала" к нормальному app ложный хвостовик - как раз с "ложной" таблицей размещения файлов - да и сами ложные файлы в этом хвосте были - типа декодер начнёт разбор с хвоста, а не с тех смещений что в заголовке app прописаны - но и она кажись была по виду вполне "стандартная"... Цитата: Что-то я с такими системами еще не встречался, мне все попроще попадались. THInstall и MoleBox - есть демки, но в одной из них кажись возможность "включать dll в exe" не реализована - впрочем, как я уже говорил, про способы взлома таких систем тоже писали... А взломав внешний слой уже можно ломать и внутренность - в частности фоксовую прогу. Цитата: Отладка даже через Int 3 эту систему не валит, а вот изменение рантайма валит, но не сразу, а где-то через полсекунды, похоже по таймеру. То, что это в отдельном потоке, я предполагаю, но вовсе не уверен. Вообще мне показалось, что эта программа защищена дважды - сначала фоксовской защитой, а затем еще AsProtect. Хотя может и ошибаюсь. Ну это было бы вполне логично - пока ASM код совсем уж беззащитен есть хороший плацдарм для его взлома Впрочем если защищён ТОЛЬКО ASM код то это тоже плохо - его просто "обходишь" и на выходе ловишь то что он там раскодировал Цитата: Да, я тоже подумал, наверное эту проблему так можно решить, только мне довольно много кода придется переписать, а что хуже всего - отлаживать. А отлаживать программу, в которой сделано все, чтобы отлаживать ее было как можно труднее - это кошмар. А программировать без ошибок я не умею. Ну для начала можно просто в фоксовых блоках это поправить Там же создаются эти мелкие "кучи"... Вот с основным кодом который в ProcessHeap падает уже сложнее - но он кажись уже не занимается выделением памяти - а значит можно опять таки в фоксовой части попытаться сменить режим доступа к этой памяти. Я думаю это не очень сложно - по крайней мере не надо переписывать весь твой линковщик/криптор... Кстати каким образом ты собираешь exe-ники? Потрошишь "незащищённый" app или сам его собираешь из простых fxp/vcx/vct? Цитата: Я использовал Olly, он по-моему такое не умеет, а впрочем я его тоже не шибко хорошо знаю Если не забуду, обязательно это проверю. У него же есть средства установки точки останова на доступ к данным (причём не Hardware Breakpoint!) Т.е. он очевидно умеет так хитро пошагово исполнять программу, что может отловить доступ к некоторому адресу - и, что особенно интересно, делает это ДО попытки этого самого доступа, в отличие от Hardware Breakpoint который останавливает прогу на инструкции ПОСЛЕ той которая читала/писала память (ну это то как раз понятно). К сожалению такая точка останова может быть всего одна (или я чего-то не понял) - однако может быть "внутри" он и держит подобные точки для тех байт куда сам же СС и запихал... ------------------ WBR, Igor

Re: Дайте ссылочку рефокса

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

22.11.06 20:40:39

Hi leonid!

Цитата:
У меня все не совсем так. Информация о защищенном арр файле хранится в нем самом и активизируется при запуске, с fxp так не поступишь, значит надо придумывать и реализовывать что-то новое.

Почему? Если дело в ключе - то можно для данного конкретного случая найти место в заголовке fxp (там где и фокс хранит инфу о ключе), если о собственно "подключении" - то это сделает запускающий exe...

Цитата:
Цитата:
... заменить алгоритм генерации PRAND ...
Вот-вот, идея именно такая, только вот я уже что-то забыл, я это реализовал, или только собирался?

Я не увидел - в test точно такой-же алгоритм как и в самом рантайме. Кстати по некотором размышлении я понял в чём есть существенная проблема замены алгоритма (в случае перехвата только декодера, а не всего IO) - рантайм не читает файлы блоками достаточного размера - он может и 4 байта прочитать и даже видимо всего 1 (кажется я такой вызов видел) - а множество криптоалгоритмов смогут работать только если им дать целый блок... Так что видимо остаётся один путь - "укрепить" PRAND - взять более "мощный" полином и использовать хотя-бы 32 разрядную арифметику (а лучше действительно 64 разрядную - но я не уверен что при этом не придётся уже задействовать FPU).

Цитата:
Цитата:
неужели полный перебор реализовал?
В принципе, да. Но пришлось очень сильно пооптимизировать, чтоб по времени разумно было.

Ну это понятно

Цитата:
Там в конце есть таблица размещения файлов, там нолики по восемь штук встречаются часто, а ее расположение можно вычислить.

Да, действительно есть такое. Правда я видел одну защиту, которая "дописывала" к нормальному app ложный хвостовик - как раз с "ложной" таблицей размещения файлов - да и сами ложные файлы в этом хвосте были - типа декодер начнёт разбор с хвоста, а не с тех смещений что в заголовке app прописаны - но и она кажись была по виду вполне "стандартная"...

Цитата:
Что-то я с такими системами еще не встречался, мне все попроще попадались.

THInstall и MoleBox - есть демки, но в одной из них кажись возможность "включать dll в exe" не реализована - впрочем, как я уже говорил, про способы взлома таких систем тоже писали... А взломав внешний слой уже можно ломать и внутренность - в частности фоксовую прогу.

Цитата:
Отладка даже через Int 3 эту систему не валит, а вот изменение рантайма валит, но не сразу, а где-то через полсекунды, похоже по таймеру. То, что это в отдельном потоке, я предполагаю, но вовсе не уверен. Вообще мне показалось, что эта программа защищена дважды - сначала фоксовской защитой, а затем еще AsProtect. Хотя может и ошибаюсь.

Ну это было бы вполне логично - пока ASM код совсем уж беззащитен есть хороший плацдарм для его взлома

Впрочем если защищён ТОЛЬКО ASM код то это тоже плохо - его просто "обходишь" и на выходе ловишь то что он там раскодировал

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

Ну для начала можно просто в фоксовых блоках это поправить

Там же создаются эти мелкие "кучи"... Вот с основным кодом который в ProcessHeap падает уже сложнее - но он кажись уже не занимается выделением памяти - а значит можно опять таки в фоксовой части попытаться сменить режим доступа к этой памяти.
Я думаю это не очень сложно - по крайней мере не надо переписывать весь твой линковщик/криптор...
Кстати каким образом ты собираешь exe-ники? Потрошишь "незащищённый" app или сам его собираешь из простых fxp/vcx/vct?

Цитата:
Я использовал Olly, он по-моему такое не умеет, а впрочем я его тоже не шибко хорошо знаю

Если не забуду, обязательно это проверю. У него же есть средства установки точки останова на доступ к данным (причём не Hardware Breakpoint!) Т.е. он очевидно умеет так хитро пошагово исполнять программу, что может отловить доступ к некоторому адресу - и, что особенно интересно, делает это ДО попытки этого самого доступа, в отличие от Hardware Breakpoint который останавливает прогу на инструкции ПОСЛЕ той которая читала/писала память (ну это то как раз понятно). К сожалению такая точка останова может быть всего одна (или я чего-то не понял) - однако может быть "внутри" он и держит подобные точки для тех байт куда сам же СС и запихал...

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

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 23.11.06 19:17:18 Hi Igor! Igor Korolyov Hi leonid! Цитата: У меня все не совсем так. Информация о защищенном арр файле хранится в нем самом и активизируется при запуске, с fxp так не поступишь, значит надо придумывать и реализовывать что-то новое. Почему? Если дело в ключе - то можно для данного конкретного случая найти место в заголовке fxp (там где и фокс хранит инфу о ключе), если о собственно "подключении" - то это сделает запускающий exe... Сдается мне, все не так просто. Если хранить в запускаемом экзешнике всю информацию о ключах самого экзешника и всех запускаемых из него файлов (app, fxp), то защищать все надо единым скопом, а тогда теряется весь смысл использования app или fxp, поскольку их нельзя будет просто так взять и заменить, не заменяя самого экзешника. Кроме того, одну app-ку можно будет использовать только с одним экзешником, а разные экзешники одну app-ку не смогут вызывать. Я пошел по другому пути: у меня информация о ключах app-ки хранится в самой app-ке и активизируется при ее запуске. Здесь тоже есть недостатки, например, если app-ка запускается командой DO, то ее можно использовать как обычно, ничего менять не надо, а если по-другому, например Set Classlib to, то нужно где-нибудь в начале программы написать DO MyApp.app with "NO_RUN" для того, чтобы активизировать декодировочную систему. Для этого я вставляю в нее парочку fxp и парочку бинарных файлов, а с fxp файлами такого сделать не получится. Зато преимущество, что арр-ку можно защищать независимо от экзешника, в котором она используется, и использовать в разных защищенных экзешниках. Цитата: Цитата: Цитата: ... заменить алгоритм генерации PRAND ... Вот-вот, идея именно такая, только вот я уже что-то забыл, я это реализовал, или только собирался? Я не увидел - в test точно такой-же алгоритм как и в самом рантайме. Да, я тоже посмотрел и тоже не увидел. Цитата: Кстати по некотором размышлении я понял в чём есть существенная проблема замены алгоритма (в случае перехвата только декодера, а не всего IO) - рантайм не читает файлы блоками достаточного размера - он может и 4 байта прочитать и даже видимо всего 1 (кажется я такой вызов видел) Этого легко добиться, если сделать fopen файлу, который включен в ехе, а потом fread один байт. Хотя я заметил, что рантайм не всегда читает столько, сколько его просят, а больше любит кратно 512. Цитата: - а множество криптоалгоритмов смогут работать только если им дать целый блок... Наверное это можно обойти, но довольно трудно, нужно когда идет запрос на 1 байт, определять из какого он блока, расшифровывать весь блок, а потом из него брать нужный байт. Цитата: Так что видимо остаётся один путь - "укрепить" PRAND - взять более "мощный" полином и использовать хотя-бы 32 разрядную арифметику (а лучше действительно 64 разрядную - но я не уверен что при этом не придётся уже задействовать FPU). Я наверное попробую укрепить алгоритм, а вот перейти на 32 двух разрядную арифметику... Что-то сейчас не хочется. Вообще, если алгоритм будет другой, то перебор все равно непонятно как делать. Чтобы понять, как получается ключ, надо в алгоритме копаться. Цитата: Правда я видел одну защиту, которая "дописывала" к нормальному app ложный хвостовик - как раз с "ложной" таблицей размещения файлов - да и сами ложные файлы в этом хвосте были - типа декодер начнёт разбор с хвоста, а не с тех смещений что в заголовке app прописаны - но и она кажись была по виду вполне "стандартная"... Ну я это чисто под Рефокс писал, так что такой проблемы не было. Цитата: Цитата: Да, я тоже подумал, наверное эту проблему так можно решить, только мне довольно много кода придется переписать, а что хуже всего - отлаживать. А отлаживать программу, в которой сделано все, чтобы отлаживать ее было как можно труднее - это кошмар. А программировать без ошибок я не умею. Ну для начала можно просто в фоксовых блоках это поправить Там же создаются эти мелкие "кучи"... Вот с основным кодом который в ProcessHeap падает уже сложнее - но он кажись уже не занимается выделением памяти - а значит можно опять таки в фоксовой части попытаться сменить режим доступа к этой памяти. Я думаю это не очень сложно - по крайней мере не надо переписывать весь твой линковщик/криптор... Да, да. Я это уже переделал. (Спасибо за совет.) Оказалось не так сложно. Там все можно класть не в ProcessHeap, а во вновь созданный с соответствующими ключами. И на самом деле оказалось, что многое надо менять именно в фоксе (что совсем просто). На софтверном DEP я уже проверил, а вот хардверного у меня нет. Если не трудно, я сюда выложил новую версию www.grada.lv Цитата: Кстати каким образом ты собираешь exe-ники? Потрошишь "незащищённый" app или сам его собираешь из простых fxp/vcx/vct? Потрошу, а потом собираю заново. Таким способом нетрудно добавить в экзешник что-нибудь свое. Кстати при желании можно и чисто фоксовский вирус написать. Цитата: Цитата: Я использовал Olly, он по-моему такое не умеет, а впрочем я его тоже не шибко хорошо знаю Если не забуду, обязательно это проверю. У него же есть средства установки точки останова на доступ к данным (причём не Hardware Breakpoint!) Т.е. он очевидно умеет так хитро пошагово исполнять программу, что может отловить доступ к некоторому адресу - и, что особенно интересно, делает это ДО попытки этого самого доступа Насколько я знаю он накладывает запрет на чтение с помощью VirtualProtect, а потом перехватывает эксепшн. Цитата: в отличие от Hardware Breakpoint который останавливает прогу на инструкции ПОСЛЕ той которая читала/писала память (ну это то как раз понятно). К сожалению такая точка останова может быть всего одна (или я чего-то не понял) Сдается мне на любую из четырех точек можно наложить условие, когда она срабатывает: на чтение, на запись, на выполнение или на их комбинацию.

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

23.11.06 19:17:18

Hi Igor!

Igor Korolyov
Hi leonid!
Цитата:
У меня все не совсем так. Информация о защищенном арр файле хранится в нем самом и активизируется при запуске, с fxp так не поступишь, значит надо придумывать и реализовывать что-то новое.
Почему? Если дело в ключе - то можно для данного конкретного случая найти место в заголовке fxp (там где и фокс хранит инфу о ключе), если о собственно "подключении" - то это сделает запускающий exe...

Сдается мне, все не так просто. Если хранить в запускаемом экзешнике всю информацию о ключах самого экзешника и всех запускаемых из него файлов (app, fxp), то защищать все надо единым скопом, а тогда теряется весь смысл использования app или fxp, поскольку их нельзя будет просто так взять и заменить, не заменяя самого экзешника. Кроме того, одну app-ку можно будет использовать только с одним экзешником, а разные экзешники одну app-ку не смогут вызывать. Я пошел по другому пути: у меня информация о ключах app-ки хранится в самой app-ке и активизируется при ее запуске. Здесь тоже есть недостатки, например, если app-ка запускается командой DO, то ее можно использовать как обычно, ничего менять не надо, а если по-другому, например Set Classlib to, то нужно где-нибудь в начале программы написать


DO MyApp.app with "NO_RUN"

для того, чтобы активизировать декодировочную систему. Для этого я вставляю в нее парочку fxp и парочку бинарных файлов, а с fxp файлами такого сделать не получится. Зато преимущество, что арр-ку можно защищать независимо от экзешника, в котором она используется, и использовать в разных защищенных экзешниках.

Цитата:
Цитата:
Цитата:
... заменить алгоритм генерации PRAND ...
Вот-вот, идея именно такая, только вот я уже что-то забыл, я это реализовал, или только собирался?
Я не увидел - в test точно такой-же алгоритм как и в самом рантайме.

Да, я тоже посмотрел и тоже не увидел.

Цитата:
Кстати по некотором размышлении я понял в чём есть существенная проблема замены алгоритма (в случае перехвата только декодера, а не всего IO) - рантайм не читает файлы блоками достаточного размера - он может и 4 байта прочитать и даже видимо всего 1 (кажется я такой вызов видел)

Этого легко добиться, если сделать fopen файлу, который включен в ехе, а потом fread один байт. Хотя я заметил, что рантайм не всегда читает столько, сколько его просят, а больше любит кратно 512.

Цитата:
- а множество криптоалгоритмов смогут работать только если им дать целый блок...

Наверное это можно обойти, но довольно трудно, нужно когда идет запрос на 1 байт, определять из какого он блока, расшифровывать весь блок, а потом из него брать нужный байт.

Цитата:
Так что видимо остаётся один путь - "укрепить" PRAND - взять более "мощный" полином и использовать хотя-бы 32 разрядную арифметику (а лучше действительно 64 разрядную - но я не уверен что при этом не придётся уже задействовать FPU).

Я наверное попробую укрепить алгоритм, а вот перейти на 32 двух разрядную арифметику... Что-то сейчас не хочется. Вообще, если алгоритм будет другой, то перебор все равно непонятно как делать. Чтобы понять, как получается ключ, надо в алгоритме копаться.

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

Ну я это чисто под Рефокс писал, так что такой проблемы не было.

Цитата:
Цитата:
Да, я тоже подумал, наверное эту проблему так можно решить, только мне довольно много кода придется переписать, а что хуже всего - отлаживать. А отлаживать программу, в которой сделано все, чтобы отлаживать ее было как можно труднее - это кошмар. А программировать без ошибок я не умею.
Ну для начала можно просто в фоксовых блоках это поправить Там же создаются эти мелкие "кучи"... Вот с основным кодом который в ProcessHeap падает уже сложнее - но он кажись уже не занимается выделением памяти - а значит можно опять таки в фоксовой части попытаться сменить режим доступа к этой памяти.
Я думаю это не очень сложно - по крайней мере не надо переписывать весь твой линковщик/криптор...

Да, да. Я это уже переделал. (Спасибо за совет.) Оказалось не так сложно. Там все можно класть не в ProcessHeap, а во вновь созданный с соответствующими ключами. И на самом деле оказалось, что многое надо менять именно в фоксе (что совсем просто). На софтверном DEP я уже проверил, а вот хардверного у меня нет. Если не трудно, я сюда выложил новую версию
www.grada.lv

Цитата:
Кстати каким образом ты собираешь exe-ники? Потрошишь "незащищённый" app или сам его собираешь из простых fxp/vcx/vct?

Потрошу, а потом собираю заново. Таким способом нетрудно добавить в экзешник что-нибудь свое. Кстати при желании можно и чисто фоксовский вирус написать.

Цитата:
Цитата:
Я использовал Olly, он по-моему такое не умеет, а впрочем я его тоже не шибко хорошо знаю
Если не забуду, обязательно это проверю. У него же есть средства установки точки останова на доступ к данным (причём не Hardware Breakpoint!) Т.е. он очевидно умеет так хитро пошагово исполнять программу, что может отловить доступ к некоторому адресу - и, что особенно интересно, делает это ДО попытки этого самого доступа

Насколько я знаю он накладывает запрет на чтение с помощью VirtualProtect, а потом перехватывает эксепшн.

Цитата:
в отличие от Hardware Breakpoint который останавливает прогу на инструкции ПОСЛЕ той которая читала/писала память (ну это то как раз понятно). К сожалению такая точка останова может быть всего одна (или я чего-то не понял)

Сдается мне на любую из четырех точек можно наложить условие, когда она срабатывает: на чтение, на запись, на выполнение или на их комбинацию.

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 23.11.06 21:15:14 Hi leonid! Цитата: Сдается мне, все не так просто. Если хранить в запускаемом экзешнике всю информацию о ключах самого экзешника и всех запускаемых из него файлов (app, fxp), то защищать все надо единым скопом, а тогда теряется весь смысл использования app или fxp, поскольку их нельзя будет просто так взять и заменить, не заменяя самого экзешника Нет не так - в "главном" exe стоит установщик перехватчика, а в остальных модулях хранятся ТОЛЬКО ключи нужные для расшифровки этих модулей. Естественно, что попытка запуска такого fxp/app НЕ из защищённого exe провалится, но вот из защищённого вполне себе пройдёт (алгоритм то один) - его защита просто возьмёт ключи для этого нового модуля из него же самого. Впрочем это так - мысли вслух Цитата: Этого легко добиться, если сделать fopen файлу, который включен в ехе, а потом fread один байт. Хотя я заметил, что рантайм не всегда читает столько, сколько его просят, а больше любит кратно 512. Я как раз и имел в виду не "пользовательское" чтение, а чтение объектных модулей (точнее их частей) исполняющей средой. Цитата: Наверное это можно обойти, но довольно трудно, нужно когда идет запрос на 1 байт, определять из какого он блока, расшифровывать весь блок, а потом из него брать нужный байт. Увы - для этого надо считать весь этот блок - а значит наиболее разумный выход тут - перехватывать не декодер а как раз само IO - а это уже заметно более сложная задача получается. Цитата: Я наверное попробую укрепить алгоритм, а вот перейти на 32 двух разрядную арифметику... Что-то сейчас не хочется Для генерации PRAND - не "вообще" Тем самым увеличивается "период повторения" в этой псевдослучайной последовательности, которая служит базой для декодировочной таблицы. При этом, как я понимаю, не нужно менять сам декодер (тот фоксовый модуль что ты вызываешь) - надо лишь поменять алгоритм подсчёт задающего числа (чтоб он давал не 16-разрядное а 32-разрядное значение), ну и полином взять другой. Цитата: Вообще, если алгоритм будет другой, то перебор все равно непонятно как делать. Чтобы понять, как получается ключ, надо в алгоритме копаться Да, конечно, но если он к тому же потребует для перебора не 64KX а 4096MX "проходов" - это думаю сильно отобъёт охоту к такому способу взлома А значит останется: либо понять как/откуда берётся задающее число для каждого "файла", либо "вылавливать" под отладчиком все обращения к этим файлам - а если к том же файлов много и обращения к некоторым из них чрезвычайно редки... Цитата: На софтверном DEP я уже проверил, а вот хардверного у меня нет. Если не трудно, я сюда выложил новую версию www.grada.lv Ок проверю. Цитата: Насколько я знаю он накладывает запрет на чтение с помощью VirtualProtect, а потом перехватывает эксепшн Хм, тогда он бы тормозил совсем уж неприлично - защитить то можно лишь страницу целиком - а значит надо отсеивать все "лишние" срабатывания - снимать защиту, перезапускть команду, снова ставить защиту - а АПИ это довольно медленное... Хотя может быть так оно и есть А вот точка останова на уровне блоков памяти - там это наверное так и будет. Цитата: Сдается мне на любую из четырех точек можно наложить условие, когда она срабатывает: на чтение, на запись, на выполнение или на их комбинацию Да, но всё равно команда уже "выполнится" к моменту останова... ------------------ WBR, Igor

Re: Дайте ссылочку рефокса

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

23.11.06 21:15:14

Hi leonid!

Цитата:
Сдается мне, все не так просто. Если хранить в запускаемом экзешнике всю информацию о ключах самого экзешника и всех запускаемых из него файлов (app, fxp), то защищать все надо единым скопом, а тогда теряется весь смысл использования app или fxp, поскольку их нельзя будет просто так взять и заменить, не заменяя самого экзешника

Нет не так - в "главном" exe стоит установщик перехватчика, а в остальных модулях хранятся ТОЛЬКО ключи нужные для расшифровки этих модулей. Естественно, что попытка запуска такого fxp/app НЕ из защищённого exe провалится, но вот из защищённого вполне себе пройдёт (алгоритм то один) - его защита просто возьмёт ключи для этого нового модуля из него же самого. Впрочем это так - мысли вслух

Цитата:
Этого легко добиться, если сделать fopen файлу, который включен в ехе, а потом fread один байт. Хотя я заметил, что рантайм не всегда читает столько, сколько его просят, а больше любит кратно 512.

Я как раз и имел в виду не "пользовательское" чтение, а чтение объектных модулей (точнее их частей) исполняющей средой.

Цитата:
Наверное это можно обойти, но довольно трудно, нужно когда идет запрос на 1 байт, определять из какого он блока, расшифровывать весь блок, а потом из него брать нужный байт.

Увы - для этого надо считать весь этот блок - а значит наиболее разумный выход тут - перехватывать не декодер а как раз само IO - а это уже заметно более сложная задача получается.

Цитата:
Я наверное попробую укрепить алгоритм, а вот перейти на 32 двух разрядную арифметику... Что-то сейчас не хочется

Для генерации PRAND - не "вообще"

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

Цитата:
Вообще, если алгоритм будет другой, то перебор все равно непонятно как делать. Чтобы понять, как получается ключ, надо в алгоритме копаться

Да, конечно, но если он к тому же потребует для перебора не 64K*X а 4096M*X "проходов" - это думаю сильно отобъёт охоту к такому способу взлома

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

Цитата:
На софтверном DEP я уже проверил, а вот хардверного у меня нет. Если не трудно, я сюда выложил новую версию
www.grada.lv

Ок проверю.

Цитата:
Насколько я знаю он накладывает запрет на чтение с помощью VirtualProtect, а потом перехватывает эксепшн

Хм, тогда он бы тормозил совсем уж неприлично - защитить то можно лишь страницу целиком - а значит надо отсеивать все "лишние" срабатывания - снимать защиту, перезапускть команду, снова ставить защиту - а АПИ это довольно медленное... Хотя может быть так оно и есть

А вот точка останова на уровне блоков памяти - там это наверное так и будет.

Цитата:
Сдается мне на любую из четырех точек можно наложить условие, когда она срабатывает: на чтение, на запись, на выполнение или на их комбинацию

Да, но всё равно команда уже "выполнится" к моменту останова...

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

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 23.11.06 21:36:52 Hi leonid! Можно взять алгоритм (дучше наверное самый нижний) отсюда vx.netlux.org ------------------ WBR, Igor

Re: Дайте ссылочку рефокса
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 24.11.06 18:18:34 Hi Igor! Igor Korolyov Hi leonid! Цитата: Сдается мне, все не так просто. Если хранить в запускаемом экзешнике всю информацию о ключах самого экзешника и всех запускаемых из него файлов (app, fxp), то защищать все надо единым скопом, а тогда теряется весь смысл использования app или fxp, поскольку их нельзя будет просто так взять и заменить, не заменяя самого экзешника Нет не так - в "главном" exe стоит установщик перехватчика, а в остальных модулях хранятся ТОЛЬКО ключи нужные для расшифровки этих модулей. Естественно, что попытка запуска такого fxp/app НЕ из защищённого exe провалится, но вот из защищённого вполне себе пройдёт (алгоритм то один) - его защита просто возьмёт ключи для этого нового модуля из него же самого. Не так просто из программы, которая предназначена только для расшифровки, определять хендл модуля, из которого пришел запрос на расшифровку, лезть в сам модуль за ключами, не сбивая при этом File pointer, и т.д. и т.п. У меня все сделано значительно проще: когда приходит запрос на расшифровку, вся необходимая информация уже сидит в известном месте памяти. Цитата: Цитата: Этого легко добиться, если сделать fopen файлу, который включен в ехе, а потом fread один байт. Хотя я заметил, что рантайм не всегда читает столько, сколько его просят, а больше любит кратно 512. Я как раз и имел в виду не "пользовательское" чтение, а чтение объектных модулей (точнее их частей) исполняющей средой. По крайней мере в такой ситуации из файла будет прочитан один байт и запрос на расшифровку придет именно на один байт (как мне помнится, впрочем не абсолютно уверен) Цитата: Цитата: Наверное это можно обойти, но довольно трудно, нужно когда идет запрос на 1 байт, определять из какого он блока, расшифровывать весь блок, а потом из него брать нужный байт. Увы - для этого надо считать весь этот блок - а значит наиболее разумный выход тут - перехватывать не декодер а как раз само IO - а это уже заметно более сложная задача получается. Вот-вот именно это я и хотел сказать. Цитата: Цитата: Сдается мне на любую из четырех точек можно наложить условие, когда она срабатывает: на чтение, на запись, на выполнение или на их комбинацию Да, но всё равно команда уже "выполнится" к моменту останова... Ну на выполнение она все-таки остановится до, или я что-то не так понимаю? Цитата: Можно взять алгоритм (дучше наверное самый нижний) отсюда vx.netlux.org Спасибо, уже списал это себе, обязательно посмотрю. Я уже посмотрел у себя этот кусок, вроде бы заменить алгоритм вполне реально. На выходных попробую. Слава богу (и спасибо НАТО) они у нас будут побольше обычного.

Re: Дайте ссылочку рефокса

leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006

leonid

24.11.06 18:18:34

Hi Igor!

Igor Korolyov
Hi leonid!
Цитата:
Сдается мне, все не так просто. Если хранить в запускаемом экзешнике всю информацию о ключах самого экзешника и всех запускаемых из него файлов (app, fxp), то защищать все надо единым скопом, а тогда теряется весь смысл использования app или fxp, поскольку их нельзя будет просто так взять и заменить, не заменяя самого экзешника
Нет не так - в "главном" exe стоит установщик перехватчика, а в остальных модулях хранятся ТОЛЬКО ключи нужные для расшифровки этих модулей. Естественно, что попытка запуска такого fxp/app НЕ из защищённого exe провалится, но вот из защищённого вполне себе пройдёт (алгоритм то один) - его защита просто возьмёт ключи для этого нового модуля из него же самого.

Не так просто из программы, которая предназначена только для расшифровки, определять хендл модуля, из которого пришел запрос на расшифровку, лезть в сам модуль за ключами, не сбивая при этом File pointer, и т.д. и т.п. У меня все сделано значительно проще: когда приходит запрос на расшифровку, вся необходимая информация уже сидит в известном месте памяти.

Цитата:
Цитата:
Этого легко добиться, если сделать fopen файлу, который включен в ехе, а потом fread один байт. Хотя я заметил, что рантайм не всегда читает столько, сколько его просят, а больше любит кратно 512.
Я как раз и имел в виду не "пользовательское" чтение, а чтение объектных модулей (точнее их частей) исполняющей средой.

По крайней мере в такой ситуации из файла будет прочитан один байт и запрос на расшифровку придет именно на один байт (как мне помнится, впрочем не абсолютно уверен)

Цитата:
Цитата:
Наверное это можно обойти, но довольно трудно, нужно когда идет запрос на 1 байт, определять из какого он блока, расшифровывать весь блок, а потом из него брать нужный байт.
Увы - для этого надо считать весь этот блок - а значит наиболее разумный выход тут - перехватывать не декодер а как раз само IO - а это уже заметно более сложная задача получается.

Вот-вот именно это я и хотел сказать.

Цитата:
Цитата:
Сдается мне на любую из четырех точек можно наложить условие, когда она срабатывает: на чтение, на запись, на выполнение или на их комбинацию
Да, но всё равно команда уже "выполнится" к моменту останова...

Ну на выполнение она все-таки остановится до, или я что-то не так понимаю?

Цитата:
Можно взять алгоритм (дучше наверное самый нижний) отсюда vx.netlux.org

Спасибо, уже списал это себе, обязательно посмотрю. Я уже посмотрел у себя этот кусок, вроде бы заменить алгоритм вполне реально. На выходных попробую. Слава богу (и спасибо НАТО) они у нас будут побольше обычного.

Re: Дайте ссылочку рефокса
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 24.11.06 20:29:45 Hi leonid! 1) Насчёт расшифровки - думаю что для fxp можно дополнительно перехватывать ту функцию, которая проводит в самом фоксе определение ключа дешифрации - и если в том-же месте файла (в заголовке) хранить в некотором хитром виде свой ключ, то задача решится сама собой. Но это наверное не очень годится для собственно app (если хотим сохранить "плавающий" код). Ещё идея - задействоват зарезервированные поля (те самые 8 байт нулей) в таблице описания включенных в app файлов - мне кажется что будет несложно найти связь между чтением этого самого описания файла и собственно чтением его содержимого... Впрочем это всё пока находится на уровне бредовых идей 2) В OllyDbg при использовании Hardware Breakpoint на чтение/запись памяти выполнение останавливается на "следующей" команде (исплючение видимо REP* команды - но они то по сути не совсем "команды" - скорее своеобразный цикл). А вот при "софтверном" брейкпоинте останов как раз на команде которая и читает/пишет этот байт - возможно конечно что реально то проц команду выполняет, а Olly её "откатывает" - но мне кажется что это слишком уж сложно было-бы (отслеживать постоянно все регистры...) 3) твой новый test у меня не проходит DEP. Ты какой флаг использовал в HeapCreate? Я поставил ради теста в bxx флаг 0x40000 и эта функция заработала - без неё как раз и происходит фоксовая ошибка - типа вызов dll вызвал исключение и всё такое ------------------ WBR, Igor

Re: Дайте ссылочку рефокса

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

24.11.06 20:29:45

Hi leonid!

1) Насчёт расшифровки - думаю что для fxp можно дополнительно перехватывать ту функцию, которая проводит в самом фоксе определение ключа дешифрации - и если в том-же месте файла (в заголовке) хранить в некотором хитром виде свой ключ, то задача решится сама собой. Но это наверное не очень годится для собственно app (если хотим сохранить "плавающий" код).
Ещё идея - задействоват зарезервированные поля (те самые 8 байт нулей) в таблице описания включенных в app файлов - мне кажется что будет несложно найти связь между чтением этого самого описания файла и собственно чтением его содержимого... Впрочем это всё пока находится на уровне бредовых идей

2) В OllyDbg при использовании Hardware Breakpoint на чтение/запись памяти выполнение останавливается на "следующей" команде (исплючение видимо REP* команды - но они то по сути не совсем "команды" - скорее своеобразный цикл). А вот при "софтверном" брейкпоинте останов как раз на команде которая и читает/пишет этот байт - возможно конечно что реально то проц команду выполняет, а Olly её "откатывает" - но мне кажется что это слишком уж сложно было-бы (отслеживать постоянно все регистры...)

3) твой новый test у меня не проходит DEP. Ты какой флаг использовал в HeapCreate? Я поставил ради теста в bxx флаг 0x40000 и эта функция заработала - без неё как раз и происходит фоксовая ошибка - типа вызов dll вызвал исключение и всё такое

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

Страницы: 1 2 3 4

:: Список Форумов•Список тем•Поиск•Войти

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

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