Я предпочитаю для таких целей использовать С/С++ с минимальными вставками (а то и без них) ассемблера. Дело в том, что очень часто можно реверснуть структуры данных игры и использовать их в Сишном проекте. В результате немного увеличивается эффективность труда.
В свое время я сел переписывать Master of Orion 2, но дело заглохло — он был слишком криво написан и его проще было бы переписать с нуля, чем отреверсить целиком.
Кстати, из таких вот интересных проектов могу упомянуть TTDPatch, ScummVM, OpenTTD. Последние два реверснуты ludde (Ludvig Strigeus), он же автор µTorrent.
Вобщем, тема интересная. Только времени много забирает.
Плохо и не будет работать по нескольким причинам.
1. Поддерживать сразу кучу платформ надо (пыхпых работает почти везде)
2. "Нормальный" админ не разрешит чего-то там скачивать и запускать в автоматическом режиме. Разве что он безгранично доверяет разработчику.
3. Какой кусок функциональности должен быть реализован в .so/.dll файле, что бы его нельзя было дописать в самом PHP?
Смысла в такой защите нет вообще.
Место где делается проверка найдется достаточно быстро. Даже если оно спрятанно досаточно "глубоко" с кучей промежуточных вызовов. Примеры - nulled релизы всяких форумов.
В защите софта криптография с открытым ключем поможет, но не сильно, так как:
1. Можно просто выключить нафиг проверку (всегда 'ok') возвращать
2. Можно создать свою ключевую пару и зашить ее в скрипт/программу (так, кстати с The Bat! делают)
Я когда-то интересный способ защиты видел. Какой-то форумный движок, а вот какой - не помню. Идея в том, что без лицензии он работает, но вставляет в страничку некое уникальное слово которое не видно (спрятано стилем). Автор время от времени, тем же гуглом, ищет такие вот сайты. Если находит - пишет телегу хостеру.
Лично мне Git не нравится. Собственно - git это куча скриптов, бинарников и тому подобного которое работает как одна большая scm. Плюс, не нравится что базу время от времени нужно пересобирать что бы оно не тормозило и не жрало много места.
Из личных предпочтений - Mercurial. Во первых нормально работает на разных платформах (да да, знаю, Git уже тоже доточили напильником для винды). Во вторых - быстро работает. В третьих - command-line интерфейс не сильно отличается от SVN. В четвертых - написан на питоне, достаточно компактен, кода относительно не много (меньше чем в Git, Bazaar и SVN раза в два при той же функциональности). Работает чуть медленнее Git, но быстрее Bazaar. Есть виндовый гуй а-ля TortoiseSVN. Trac умеет работать с репозиторием.
P.S. У Mercurial и Git общие корни - все выросло из обсуждения в linux-kernel mailing list. Просто ребята не договорились как делать scm и пошли своими дорогами.
1. Время работы функции получения строки по ошибки никого абсолютно не волнует.
2. В приложении, которое может сгенерить 10000 ошибок - лишние 40 килобайт не важны.
3. Про шифрование - не совсем вау-фактор. Я видел реализацию SHA-256 на MMX. Она в несколько раз быстрее чем обычная, оптимизированная, на C.
В целом, о чем я хочу сказать: субьект для оптимизации выбран неудачно.
Если код определения ошибки вызывается слишком часто, значит что то не то с программой. Т.е. в жизни, та же запись в log существенно будет больше по времени чем рассматриваемый пример, так что время потраченое на поиск строки никого уже не интересует.
Лучше бы показали, как пример, разницу между каким нибудь криптографическим преобразованием, которое на C/C++ написано и в реализации на ассемблере. Вот тут и будет видна разница.
Нет, спасибо.
В свое время я сел переписывать Master of Orion 2, но дело заглохло — он был слишком криво написан и его проще было бы переписать с нуля, чем отреверсить целиком.
Кстати, из таких вот интересных проектов могу упомянуть TTDPatch, ScummVM, OpenTTD. Последние два реверснуты ludde (Ludvig Strigeus), он же автор µTorrent.
Вобщем, тема интересная. Только времени много забирает.
1. Поддерживать сразу кучу платформ надо (пыхпых работает почти везде)
2. "Нормальный" админ не разрешит чего-то там скачивать и запускать в автоматическом режиме. Разве что он безгранично доверяет разработчику.
3. Какой кусок функциональности должен быть реализован в .so/.dll файле, что бы его нельзя было дописать в самом PHP?
Место где делается проверка найдется достаточно быстро. Даже если оно спрятанно досаточно "глубоко" с кучей промежуточных вызовов. Примеры - nulled релизы всяких форумов.
В защите софта криптография с открытым ключем поможет, но не сильно, так как:
1. Можно просто выключить нафиг проверку (всегда 'ok') возвращать
2. Можно создать свою ключевую пару и зашить ее в скрипт/программу (так, кстати с The Bat! делают)
Я когда-то интересный способ защиты видел. Какой-то форумный движок, а вот какой - не помню. Идея в том, что без лицензии он работает, но вставляет в страничку некое уникальное слово которое не видно (спрятано стилем). Автор время от времени, тем же гуглом, ищет такие вот сайты. Если находит - пишет телегу хостеру.
Из личных предпочтений - Mercurial. Во первых нормально работает на разных платформах (да да, знаю, Git уже тоже доточили напильником для винды). Во вторых - быстро работает. В третьих - command-line интерфейс не сильно отличается от SVN. В четвертых - написан на питоне, достаточно компактен, кода относительно не много (меньше чем в Git, Bazaar и SVN раза в два при той же функциональности). Работает чуть медленнее Git, но быстрее Bazaar. Есть виндовый гуй а-ля TortoiseSVN. Trac умеет работать с репозиторием.
P.S. У Mercurial и Git общие корни - все выросло из обсуждения в linux-kernel mailing list. Просто ребята не договорились как делать scm и пошли своими дорогами.
1. Время работы функции получения строки по ошибки никого абсолютно не волнует.
2. В приложении, которое может сгенерить 10000 ошибок - лишние 40 килобайт не важны.
3. Про шифрование - не совсем вау-фактор. Я видел реализацию SHA-256 на MMX. Она в несколько раз быстрее чем обычная, оптимизированная, на C.
В целом, о чем я хочу сказать: субьект для оптимизации выбран неудачно.
Лучше бы показали, как пример, разницу между каким нибудь криптографическим преобразованием, которое на C/C++ написано и в реализации на ассемблере. Вот тут и будет видна разница.