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

Всем привет!!!

У меня такой вопрос: как можно при вставке *.swf ролика через компонент ShockwaveFlash в Delphi или C++Builder сделать так что бы ролик был доступен на компе на котором не установлен флешевсий ActiveX (или установлен да не той версии). То есть чтобы приложение было независимо – что то типа флешевского Projectora.

Как решить такую задачу :confused: ???
Заранее спасибо.

Вообще-то проще распространять AxtiveX вместе с прогой, но если ты хочешь сделать приложение единственным exeшником, то можно запаковать ActiveX Control в ресурсы, и если он не установлен - извлекать и устанавливать.

Мне вот что интересно... Вот когда из Flash публикуется EXE - он как это делает? Ведь едва ли этот EXE устанавливает ActiveX... Расковырял бы кто умный да другим рассказал...

Установить ActiveX можно с помощью regsvr32.exe. То есть нужно при компиляции приложения проверить установлен ActiveX или нет. Если не установлен то возникает исключение вот его и надо обработать и установить ActiveX, а потом продолжить компиляцию приложения.
И вот только проблема, как узнать, какая версия flash установлена? И как работает флешевский projector – что он засовывает внутрь EXE, что не надо регистрировать ActiveX?

Внутри projectora то же самое, что и внутри ActiveX - набор функций для работы со флэшем.

Дык! Вот только как бы это то же самое выковырять из прожектора и подгружать, без регистрации COM-класса в реестре? А то на инсталляцию ActiveX у пользователя прав может и не хватить...

добавить нужно ocx компонент
 

install new komponent из зарегестрированых потом выбираете flash Player ocx flash.ocx все в принципе как добавляется в проект виндовый медиаплейер, описание есть на сайте производителя и в форумах там весит только на ин язе

ну а после добавления компанента перетягиваете его в проект из панели актив Х компонентов

в дельфях, по крайней мере так...

я бы еще попробовалтак:

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

При перетягивании из Delphi компонента ShockwaveFlash всё равно для про-игрывания flash ролика нужен ActiveX.

А на счёт включения flash проигрывателя свой дистрибутив программы и ко-гда надо проиграть ролик, то в том то и дело что так можно проиграть только ролик или точнее файл SWF. А если он вставлен в моё приложение?

Кто-нибудь занает что за authplay.dll который лежит в …\First Run\authplay.dll. В описании этого dll написано что это Macromedia Flash Player, мо-жет его можно как-то использовать?

Проверить и проинсталить!
 

А как можно из программы проверить, установлет тот самый АctiveX? И как его программно инсталлировать?

При создании приложения проверить не возникло исключение EOleSysError если возникло то значит ActiveX не установлен. И тогда воспользоваться regsvr32.exe /s flash.ocx .

C authplay.dll вопрос интересный. Наверняка в этой библиотеке те же функции, что и во Flash ActiveX, но как они называются? Было бы неплохо найти документацию. Я сам очень мало работал с dll, может быть можно программно определить какие функции лежат в библиотеке и список передаваемых им параметров, но я не знаю как.

Насколько я знаю то узнать какие функции находятся в скомпилированной Dll не получиться. Но может я не прав? Кстати говоря эта DLL ещё находится, по крайней мере в XP, в C:\......\......\Application Data\Macromedia\Flash MX\Configuration\. И даже если её удалить, то при следующем запуски flash’a, он создаст её снова. Он пользует эту DLL для тестирования клипа внутри программы, так как даже если удалить все флешевские ActiveX, вместе с плеером то внутри программы всё равно можно просматривать клипы.
Может кто знает где можно найти документацию по этому поводу.

Узнать какие функции есть в DLL проще паренной репы, например с помощью tdump, или PEExplorer, не говоря уже о монстрах типа IDA с параметрами конечно сложнее, но тут все зависит от того на чем писалась DLL, опять же IDA поможет определелить кол-во переменных, но суть их он Вам конечно не покажет, придется разбираться самим. А еще лучше ставить бряки на экспортируемые функции и тестить тестить... хотя думаю это занятие не для флешарей, а для более дзенствующих васмеров ... Короче, читаем http://www.wasm.ru

все сделано до нас:
http://www.softanics.com/products/flashcontrol/
;)))

да, и авторы наши.

Контрол хороший да вот только в демо версии есть один недостаток это назойливое собщение – demo version. А где есть нормальный компоннт. Или как реализовано подключение к ActiveX без его регистрации? :confused:

а купить религия не позволяет? ;)
наверняка можно договориться :)

Да что-то они много хотят практически ни за что, у этого компонента есть только одно преимущество это возможность не устанавливать ActiveX, а остальное можно без проблем и самому догнать как сделать. :)

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

Итак, в ничто входит:
1. возможность создания полностью автономных приложений, использующих флешки - весь код swflash.ocx/flash.ocx можно запихнуть в ресурсы, и он будет загружен в рантайме прямо в память, минуя временные файлы;
2. возможность загрузки мувиков из стримов - например, можно запихнуть мувик в ресурсы, и его можно будет загружать оттуда - и опять-таки временные файлы не используются; можно, кстати, покриптовать мувик, а потом на лету его расшифровывать и скармливать компоненту - в этом случае извлечь мувик злоумышленнику (будем политкорректны ;) ) будет крайне сложно (можно закриптовать чем-нибудь типа RSA ;) ).

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

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

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


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

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

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

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

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

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

Удачи!

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

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

Но специально для Вас повторюсь.
Ваяем собственный пустой 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'а и сами ресурсы.

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

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

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

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

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

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

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

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

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

Мой многоуважаемый ироничный оппонент,можно мне ответить Вам в том же ключе?
Я очень рад, что границы Ваших познаний распростерлись на столь сложный для понимания и малодокументированный предмет как структура PE-файлов (а может быть даже дальше). Однако над четким формулированием своих мыслей Вам не мешало бы поработать, ибо сообщения на этом форуме читают не только такие профи как Вы, но и простые смертные, необремененные познаниями в области структур таблиц импорта/экспорта.
Я имею ввиду сказанную Вами фразу относительно парсинга и докапывания до таблицы импорта.
Подозреваю, что Вы имели ввиду докапывание не только и не столько до таблицы импорта сколько до таблиц экспорта системных библиотек с целью обхода вызова функции getprocaddress. Если я прав, то придется Вас огорчить, Вы не являтесь пионером данной методики, она уже давно и безуспешно применяется в том же аспре. Кстати об аспре, Ваше суждение об освоении мною стриппера является ошибочным, и хотя этот инструмент действительно где-то валяется у меня на винте, я его не использую, т.к. он по ряду причин не позволяет получить полностью работоспособный файл (я не буду здесь подробно останавливаться на этих причинах, т.к. думаю, что такой гуру как Вы должен быть в курсе)
Более того, распаковой аспра я занимался когда в природе еще не существовало ни стриппера, ни даже импрека. Так что моими инструментами были и остаются сосулька и процдамп, да еще парочка собсвенных утилит вспомогательного характера.
Поэтому финты ушами вроде переходников меня не пугают.
Что же касается любезно предложенного Вами crackme, я, к сожалению, не могу дать Вам однозначного ответа, поскольку мой способ зарабатывания на хлеб лежит в несколько иной плоскости нежели написание патчей, лоадеров и кейгенов ко всяким неро и фотошопам. Да, в свое время я увлекался реверсингом и нарешал множество крякмисов, но экспертом себя в этой области не считаю, и чтобы потешить Ваше самолюбие, готов безапелляционно признать пальму первенства в этом вопросе за Вами. Хотя позвольте мне, старому пердуну, выразить свое предвзятое и необъективное мнение по поводу столь горячолюбимого Вами execryptor'a. Я далеко не самый умный и не собираюсь лично Вам ничего доказывать,но Вы конечно можете льстить себе полагая, что с помощью этой тулзы создадите крякми, который никто не сможет раздраконить. Но сдается мне, Вам недолго придется почивать на лаврах.
Да и еще, если Вы внимательно прочли не только мое последнее сообщение, Вы наверное обратили внимание на то, что я предложил свои скромные услуги товарищу, который занимается разработкой флешконтрола, по оценке взломостойкости его компонента.
И я не отказываюсь от своих слов, поэтому, оставаясь в контексте обсуждаемого вопроса, хочу выступить со встречным предложением: если Вы готовы создать компонент аналогичный обсуждаемому или написать метаморфный flash.ocx, я уделю должное внимание его изучению.

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

Я на "ты" буду :)

Это был всего лишь ответ, т.ч. "ты первый начал" ;)

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