Flash + Delphi + C++ =>???

[BrainSmasher]

Господа разработчики, хоть я и не злоумышленник, но все-же рискну высказаться посуществу вопроса:

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

Фигня полная, ибо использование стандартного (подчеркиваю) компонента ocx для проигрывания флеша подразумевает необходимость распаковки закриптованного потока самим же приложением. А учитывая то, что Весь дельфишный vcl на раз дизассемблируется, то отловить точку где вы будете "скармливать" уже расшифрованный код flash.ocx не составит большого труда (у меня я думаю это займет минут 10-15 чистого времени) После чего вместо flash.ocx мы весь поток заливаем в файлик и вуаля и не важно чем будет покриптован сам ресурсов банальным ксором или RSA и иже с ними.

Я бы оценил написание кода с фичами, что я только что описал, в 200 часов - отловить все баги, протестить на всех версиях виндов, флеша (5-7). Экономия (не по времени, только по деньгам) наступит, если ваш рабочий час стоит меньше $35 / 200 = чуть больше пяти рублей. Afaik, дизайнеры получают на порядок больше, даже на периферии (не говоря уже о Москве-Питере).

Согласен, 200 часов - это нормальная оценка, но опять же зачем тестировать под 5 флеш? Достаточно протестить под 7, ибо насколько мне известно седьмой хавает флешки пятой версии без каких-либо проблем.
И не надо в своих расчетах перекладывать все денежное бремя на плечи одного покупателя (и никто так, кстати, не делает ибо это методологически неправильно), я лично сильно сомневаюсь, что покупателей у этой штучки будет меньше 10-20, так вот эти самые 35$ можно спокойно разделить на 5-10 в зависимости от степени жадности )

PS Если кто-то решился купить, в приват кидайте сообщение - думаю, договоримся.

А вот это правильно, одобрям ))

[Softanics Group]

Оригинал написал(а) BrainSmasher
Фигня полная, ибо использование стандартного (подчеркиваю) компонента ocx для проигрывания флеша подразумевает необходимость распаковки закриптованного потока самим же приложением. А учитывая то, что Весь дельфишный vcl на раз дизассемблируется, то отловить точку где вы будете "скармливать" уже расшифрованный код flash.ocx не составит большого труда (у меня я думаю это займет минут 10-15 чистого времени) После чего вместо flash.ocx мы весь поток заливаем в файлик и вуаля и не важно чем будет покриптован сам ресурсов банальным ксором или RSA и иже с ними.

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

Оригинал написал(а) BrainSmasher
Согласен, 200 часов - это нормальная оценка, но опять же зачем тестировать под 5 флеш? Достаточно протестить под 7, ибо насколько мне известно седьмой хавает флешки пятой версии без каких-либо проблем.

Тестирование касалось фичи загрузки кода swflash.ocx/flash.ocx из потока - с помощью такого механизма
можно зашить весь код swflash.ocx/flash.ocx в ресурсы. Иногда есть смысл зашить именно 5-ку, т.к. swflash.ocx меньше весит.

[BrainSmasher]

Эпиграф: "О сколько раз твердили миру..."

Что означает, что мувик можно защищать с помощью тех же методов, что и прочие ресурсы приложения. ExeCryptor, etc.

Против лома нет приема, друг мой, любой exe-криптор ломается без проблем, а большинство так вообще ломаются автоломалками даже такие "монстры" как Армадилла и аспротект, для этого даже специальных знаний не требуется А для случая ресурсов вообще геморроиться не придется: легко и непринужденно дампим уже запущенный процесс показывающий нам "флеш-фильму" например процдампом и вперед, все ресурсы как на ладони!
Единственный более-менее серьезный метод защиты - это написание собственного flash.ocx, который будет сам в своих _запутанных_ недрах распаковывать и показывать твой мувик, но трудозатраты на его создание опять же будут несопоставимы ни с ценностью мува, ни со временем взлома

Удачи!

[Softanics Group]

Оригинал написал(а) BrainSmasher
Против лома нет приема, друг мой, любой exe-криптор ломается без проблем, а большинство так вообще ломаются автоломалками даже такие "монстры" как Армадилла и аспротект, для этого даже специальных знаний не требуется А для случая ресурсов вообще геморроиться не придется: легко и непринужденно дампим уже запущенный процесс показывающий нам "флеш-фильму" например процдампом и вперед, все ресурсы как на ладони!

Да, согласен по дампу процесса несложно получить ресурс. Но я же говорил, что он будет криптован.
Что касается ExeCryptor'а, то это не "какой-то", а вообще-то вполне определнный продукт (не наш ). И, между прочим, многие умудряются защищать им исполняемый код таким образом, что его _не ломают_. По крайней мере, кряков нет.

[BrainSmasher]

Только что написал пост на эту тему в другом треде
http://www.flasher.ru/forum/showthre...&postid=394117

Но специально для Вас повторюсь.
Ваяем собственный пустой flash.ocx с использованием интерфейса оригинального flash.ocx и реализуем в нем только одну функцию сохранения входных данных на диск.

Берем Вашу прогу, и подменяем в ней стандартный flash.ocx на собственную заготовку, и даже если прога будет закриптована, этот факт не сильно усложнит задачу, ибо Вам без flash.ocx никуда по-любому не деться, рано или поздно вы его дерните, а там уж наш троянский конь сыграет свою роль )

Короче, если напишете прототип своей защиты и что-либо им защитите, я готов протестировать его взломостойкость

[Softanics Group]

Оригинал написал(а) BrainSmasher
Только что написал пост на эту тему в другом треде
Ваяем собственный пустой flash.ocx с использованием интерфейса оригинального flash.ocx и реализуем в нем только одну функцию сохранения входных данных на диск.

Берем Вашу прогу, и подменяем в ней стандартный flash.ocx на собственную заготовку, и даже если прога будет закриптована, этот факт не сильно усложнит задачу, ибо Вам без flash.ocx никуда по-любому не деться, рано или поздно вы его дерните, а там уж наш троянский конь сыграет свою роль )

Одна из основных фич - более того, именно та фича, ради которой затевался в свое время проект FlashControl - эта фича, позволяющая зашить код flash.ocx внутрь приложения. т.е. с помощью TFlashControl можно писать приложения, которые не загружают внешний файл flash.ocx. TFlashControl умеет делать фактически тоже, что и виндовый загрузчик dll-ек - но, в отличие от LoadLibrary, умеет работать с dll-ками, код которых берется из пачки байтов, а не из внешнего файла. Итак, еще раз: flash.ocx извне не загружается. Поэтому подход с подсовыванием своего собственного flash.ocx не пройдет в этом случае - ну не будет вызываться LoadLibrary("flash.ocx"), не будет, и все тут )) Так что ломать придется монолитное приложение - а там можно покриптовать и код flash.ocx'а и сами ресурсы.

[BrainSmasher]

А я и не говорил про то что приложению обязательно должен подсовываться flash.ocx именно как _внешний_файл_.
Если Вы зашьете и покриптуете flash.oсх, то рано или поздно Вам все равно придется его раскриптовать и передать ему управление, а найти в адресном пространстве вашего приложения раскриптованный код flash.ocx и пропатчить его содержимым моего flash.ocx неcложно.
Кроме того, если мне не изменяет память, зашивать драйвера и библиотеки в ресурсы стало возможным только с 2000 версии виндов, но Вы же не хотите обделить бедных старых пользователей вынь98, которых имхо до сих пор довольно много?
И если Вы не вызываете loadlibrary, то вызываете другую API функцию (где-то у Руссиновича я встречал ее упоминание), которая по сути своей выполняет теже действия, что и первая
Да и вообще что говорить, flash.ocx как и любой com-компонент нуждается в инициализации, которая делается всякими ole.dll и т.п., и никуда от этого не деться, а это добро к счастью достаточно хорошо документировано.

[Softanics Group]

Оригинал написал(а) BrainSmasher
Кроме того, если мне не изменяет память, зашивать драйвера и библиотеки в ресурсы стало возможным только с 2000 версии виндов,

Изменяет. Не стало это возможным.

Оригинал написал(а) BrainSmasher
но Вы же не хотите обделить бедных старых пользователей вынь98, которых имхо до сих пор довольно много?

Все ОК. FlashControl работает под всеми виндами, начиная с 98-х.

Оригинал написал(а) BrainSmasher
И если Вы не вызываете loadlibrary, то вызываете другую API функцию (где-то у Руссиновича я встречал ее упоминание), которая по сути своей выполняет теже действия, что и первая

Нет, FlashControl сам размещает секции в памяти и делает прочие настройки - ровно так, как это делает виндовый загрузчик. Функций, непосредственно связанных с загрузкой dll-ек FlashControl не использует. Единственные функции, которые дергаются при загрузке swflash.ocx/flash.ocx - это функции работы с памятью (выделение, освобождение, обнуление, копирование, установка прав и т.д.).

Оригинал написал(а) BrainSmasher
Да и вообще что говорить, flash.ocx как и любой com-компонент нуждается в инициализации, которая делается всякими ole.dll и т.п., и никуда от этого не деться, а это добро к счастью достаточно хорошо документировано.

Но я бы все равно не стал ломать, мониторя именно вызовы ole.dll

[BrainSmasher]

Ну, во-первых, память мне все-таки не изменяет, и это возможно. Рекомендую открыть в редакторе ресурсов regmon.exe для вынь 2000 ( http://www.sysinternals.com/ntw2k/source/regmon.shtml ) и посмотреть на директорию ресурсов BINRES.
Эта утилитка как раз и использует эту технику, т.е. используемый драйвер вшит в ресурсы экзешника и загружается прямо из него, а не скидывается предварительно в темповушку.
Во-вторых, какая разница будете ли вы вызывать непосредственно loadlibrary или нет? Без вызовов API вы все равно ничего не сможете сделать. Взять хотя бы тот же getprocaddress без него вам не восстановить таблицу импорта flash.ocx, а без нее он не запустится. Да и память себе Вам тоже не выделить собственными силами

Повторяю еще раз: как бы вы ни загружали его, и как бы не шифровали, перед запуском вы его все равно распакуете и вызовете через стандартную точку входа (а хоть бы и ее вы даже измените, это ни на что не повлияет), в момент инициализации flash.ocx (а определить этот момент можно десятком разных способов, да хоть бы и через бряк на функции в ole.dll) я подменю его код своим (в памяти ли на диске ли - не важно) и получу то, что вы хотели предложить ему показать, а затем сохраню это на диск.

[masquerade]

Без вызовов API вы все равно ничего не сможете сделать. Взять хотя бы тот же getprocaddress без него вам не восстановить таблицу импорта flash.ocx

Да ну? Буду знать, а то по-старинке РЕ-хедер парсим и так до таблицы импорта добираемся.

Повторяю еще раз: как бы вы ни загружали его, и как бы не шифровали, перед запуском вы его все равно распакуете и вызовете через стандартную точку входа (а хоть бы и ее вы даже измените, это ни на что не повлияет), в момент инициализации flash.ocx (а определить этот момент можно десятком разных способов, да хоть бы и через бряк на функции в ole.dll) я подменю его код своим (в памяти ли на диске ли - не важно) и получу то, что вы хотели предложить ему показать, а затем сохраню это на диск.

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