Помощь · Поиск · Пользователи · Календарь
Полная версия этой страницы: Декомпиляция игры Метро 2033 вконтакте
Flash Zone Forum > Macromedia Flash > ActionScript
gammaray
Всем привет!
Решил я написать бот для игры Метро 2033 вконтакте. Опыт написания до этого уже был. Обычно срабатывала связка Charles + .Net. Смотришь, что флешка шлет на сервак через Charles , анализируешь и кодишь, чтобы программа то же слала. Но с Метро 2033 так не вышло. Смутило большое количество непонятно откуда берущихся параметров в Post запросах, которые она шлет на свой сервер (hash, auth, session и т.д.)

Скачал swf исходник игры как описано тут. Раньше никогда особо флешем не занимался... Опыт небольшой. Но если что и декомпилировал, то использовал Sothink SWF Decompiler (но до этого я максимум звуки вытаскивал, а на actionscript файлы внимания не обращал). По старой памяти решил им воспользоваться и в этот раз. Он вроде бы как все показал. Декомпилировал его в Fla (про Flex сказал, что не подходит исходная swf, поэтому только fla). Поставил Adobe Flash Pro CS5. Начал с ним разбираться. Для начала просто открыл файл fla и попробовал запустить отладку - посыпались ошибки в cs файлах. Тут закрались сомнения по поводу корректности восстановления исходников через Сотник. Попробовал в качестве альтернативы Flash Decompiler Trillix. В местах, где были ошибки в скриптах он показывал исходный код, который почему-то не видел Сотник. НО! Триликс в свою очередь сказал, что это не fla, а flex! И конвертировать проект целиком только в него мог. При чем никакого flex файла он не выдавал и Flash Builder-ом открыть не смог. Но при этом смог вытащить все файлы cs из исходника, которые все до единого весили (а значит и содержали исходного кода) больше, чем аналогичные файлы, полученные через Сотник. + зачем-то еще Триликс добавлял к имени каждого файла класса слово "class", а к пакетам packages соответственно. Да еще и для каждой папки пакета он создал соответствующий cs файл вида "package имя пакета.cs". Поскольку этих файлов больше полутысячи, пришлось накатать еще и прикладную программку, чтобы эти все лишние слова убрать. Убил еще пару часов своего времени, но в итоге почистил имена файлов и папок (слева "было", справа "стало").

Да! И еще все эти скрипты запихнул в папку ActionScript 3.0 и в папке верхнего уровня создал файл ActionScript 3.0.cs.
Тут первый вопрос: почему они разные файлы выдают по количеству и размеру? Почему Сотник теряет строки исходного кода и зачем Триликс имена изменяет файлов и добавляет новые cs файлы?
Далее я все файлы, которые мне сотник выдал заменил на эти. Ошибки в исходниках, которые были до этого, пропали. Тут Триликс просто восстановил грамотно исходники в отличие от Сотника. После этого снова попробовал запустить отладку в CS5. Посыпались ошибки вида ActionScript Error #1093: Syntax error. во всех 500+ файлах в первой и последней строке) Нашел решение тут. И правда сработало. Достаточно было удалить первую строку из каждого файла ИмяКласса.cs вида 
Код
//class ИмяКласса
, сохранить файл, вставить строку обратно и снова сохранить))) Т.е. по сути ничего не поменялось, но Adobe Flash на эти файлы перестал ругаться. В итоге после 3 убийственного часов копипаста (файлов-то 500+) я избавился ото всех этих ошибок. Но теперь стали вылезать ошибки о некорректности добавления неймспейсов (сейчас, например, в файле Item.cs ошибка ActionScript Error #1004: Namespace was not found or is not a compile-time constant.). Даже если криво закомментарить использование этого неймспейса в этом конкретном файле, то сыпятся следующие из других файлов. Честно говоря не очень понимаю, как работают неймспейсы во Flash. Пакеты я так понял просто должны лежат в соответствующих папках и файлах с именами классов. А вот как организованы неймспейсы? Во всяком случае никаких похожих файлов/классов/имен я во всех этих исходниках не нашел.
Вопрос второй: кто-нибудь с подобным сталкивался? Что за глюк такой с этой ошибкой 1093, когда ты по сути ничего не меняешь, удаляешь, восстанавливаешь строку и ошибка пропадает. Что делать с ошибками про неймспейсы? И самое главное, как в итоге сделать из этого компилируемый проект?(
P.S. Ссылка на архив архив с иходником SWF игры, а так же полученные мной после долгих мучений и всяких извращений распакованные файлы и папки с исправленными именами и ошибками 1093.
chingachgoog
Улыбнуло )))

А зачем, собственно, пытаться скомпилить проект заново? Достаточно посмотреть, как строятся параметры hash, auth, session и т.д.
MustLive
gammaray

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

Цитата
кто-нибудь с подобным сталкивался?

С проблемами после декомпиляции в fla я сталкивался не раз, но не с теми, что у тебя возникли. Ни с ошибкой 1093, ни с ошибками с неймспейсами я не сталкивался. Но все подобные проблемы с флешками решались путём анализа получившихся исходников (т.е. без каких-либо перекомпиляций).

Поэтому тебе нужно лишь проанализировать исходники и найти код генерации нужных параметров. О чём тебе выше заметил chingachgoog. Так что воспользуйся этим советом.
gammaray
Цитата(chingachgoog @ 10.10.2012 - 18:15) *
Улыбнуло )))

А зачем, собственно, пытаться скомпилить проект заново? Достаточно посмотреть, как строятся параметры hash, auth, session и т.д.

Есть параметр sig для авторизации в API вконтакте. Он генерится как md5 от конкатенации строк, включающих в себя параметр запроса, id пользователя и секретный ключ приложения! Была идея этот секретный ключ достать в отладчике... Но он по ходу только когда флешка на серваке лежит работает верно... Так что теперь вообще тупик...
chingachgoog
Цитата(gammaray @ 11.10.2012 - 17:02) *
Но он по ходу только когда флешка на серваке лежит работает верно... Так что теперь вообще тупик...


Какая разница. Клиент-то работает на нашей стороне ))) Charles есть.
Как говорил MustLive, сервер никогда точно не сможет знать, где находится флешка )))

Этот этап защиты от лохов. Настоящая защита от ботов и читов гораздо сложнее и сводится к тому, что невозможно совершить невозможное в игре. Причем отлов невозможного идет только на стороне сервера.
gammaray
Цитата(chingachgoog @ 11.10.2012 - 20:53) *
Какая разница. Клиент-то работает на нашей стороне ))) Charles есть.
Как говорил MustLive, сервер никогда точно не сможет знать, где находится флешка )))

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

Возник такой вопрос. Везде пишут, что для авторизации десктоп приложений и доступа к Api надо вводить логин и пароль вконтакте. Но на это мало кто решится, учитывая сколько прог крадут пароли... Можно как-то это обойти? Например, чтобы пользователь авторизовался в браузере, разрешил моему созданному вконтакте десктоп-приложению доступ к его данным... А далее я без авторизации мог бы получить, например, список его друзей через мое десктоп-приложение...
MustLive
gammaray

Спокойно проанализируй трафик между клиентом (флешкой) и сервером. С помощью того же Charles.

Цитата
Можно как-то это обойти?

Только в виде плагина к браузеру. Делаешь плагин/расширение/тулбар к браузеру (а для кросс-браузерности тебе придётся создавать плагины ко всем основным браузерам) и можешь использовать авторизацию браузера. Иначе придётся в десктоп приложении вводить логин и пароль ВКонтакте.
gammaray
Цитата(MustLive @ 17.10.2012 - 00:57) *
gammaray

Спокойно проанализируй трафик между клиентом (флешкой) и сервером. С помощью того же Charles.
Только в виде плагина к браузеру. Делаешь плагин/расширение/тулбар к браузеру (а для кросс-браузерности тебе придётся создавать плагины ко всем основным браузерам) и можешь использовать авторизацию браузера. Иначе придётся в десктоп приложении вводить логин и пароль ВКонтакте.

В Charles даже если что-то и передается, то в уже зашифрованном виде (md5 в случае с контактом). Расширение писать для всех браузеров замучаешься... Да и его функционалом нужным трудно будет наполнить. Нашел выход. Компонент WebBrowser .net использует данные IE. Поэтому, если пользователь не доверяет приложению, то перед его запуском ему достаточно авторизоваться через ослика, тогда в программе уже не надо будет вводить логин-пароль
MustLive
Цитата
Расширение писать для всех браузеров замучаешься...

Естественно это требует усилий, но те, кому нужна кросс-браузерность (а также и кросс-платформенность - под разные ОС), то они идут данным путём. Что ты можешь увидеть в Интернете - разные компании и разработчики выпустили многочисленные расширения и тулбары для разных браузеров.

А компонент WebBrowser .net ты можешь использовать для этого, но сам понимаешь - он работает только с IE. И если у пользователя нет IE, или он не хочет его запускать (или у него на ПК это запрещено админом), то этот компонент не поможет. Вспомни тот же WebMoney Keeper Classic, который поддерживает различные браузеры - при желании всегда можно сделать кросс-браузерное решение. Тем не менее отчасти и этот компонент пригодится.
Русская версия IP.Board © 2001-2013 IPS, Inc.