Почти согласен, только два момента. Фидо перестало быть де-факто одноранговым после того как количество нод перевалило за сотни и полезло по континентам. И хотя причина была в стоимости телефонного звонка, всё равно ориентироваться на FTN при наличии уже зарекомендовавших себя в Интернете технологий P2P не стоит.
И второй момент — закрытость архитектуры и контроль за API у коммерческих социалок будут обязательно препятствовать внедрению такого приватного оверлея, так что имеет смысл именно разрабатывать изначально распределённую платформу.
1. Файлообменники я привёл не как параллель, а как пример того, что происходит, если на какую-то группу технологий и их реализацию начинает оказываться систематическое давление. То, что сейчас давление на соцсети только начинается, повод задуматься, к чему всё идёт.
2. Поскольку файлообменные сети являются частным случаем распределённых одноранговых, то параллель, если и есть, проходит именно на этом уровне — я имел в виду, что рано или поздно придётся отказаться от «клиент-серверного» и даже облачного наследия в этой области, а не то, что надо строить социалки на файлообменных принципах (хотя при таком подходе они там обязательно будут).
3. Относительно того, кто на чём зарабатывает. Steam, например, с вами не согласен категорически, да и другие менее известные P2P CDN тоже.
4. Предлагаемая концепция одноранговой социалки не противоречит в принципе возможности монетизации услуг в ней, зато закрывает возможность контроля за сетью в целом в интересах монетизатора, что есть несомненный плюс.
На самом деле ничего сложного там нет. Если предварительно снять образ уже загруженной обычным порядком DLL, то потом после внедрения этого образа в целевой процесс нужно только пройти таблицу relocations и расставить защиту памяти по атрибутам секций.
Для первого есть чудесная функция LdrProcessRelocationBlock() в NTDLL, для второго — несколько раз дёрнуть VirtualProtect(). Всё вместе около сотни строк со всеми проверками.
несколько неясен смысл сей статьи в таком состоянии
Оценка интереса сообщества к этой тематике;
Удовлетворение собственного тщеславия;
Закрепление приоритета (слишком уж часто в последнее время я обнаруживал анонсы реализаций того, до чего кто-то додумался тоже)
и т.п.
Ну вогнать dll-ку в чужой процесс не так уж и сложно
Я в курсе. Делал инжектор невидимой DLLки (т.е. без файла на диске) для win32/win64.
Но пока подход с дебагом работает, можно кодить основное направление.
Надёжность шифра и количество ресурсов тут совершенно ни при чём. Вот простая схема, которую можно за пару часов реализовать на штатном crypto winapi: алиса и боб каждый у себя генерят пару публичный-приватный ключ RSA; отправляют каждый другому свой публичный ключ; шифруют не своим ключом новый сгенеренный ключ, допустим, от RC5 или того же блоуфиша; передают его на ту сторону, там его расшифровывают приватным. Всё, теперь в обе стороны может ехать поток шифротекста, закрытый двумя независимыми ключами RC5/BF, которые любой MITM принципиально не сможет узнать за время актуальности данных даже при минимальном размере ключа RSA. Можно даже обойтись и одной стороной — пусть даже только один боб передаёт алисе свой потоковый ключ закрытый парой алисовых rsa. И всё тоже самое, только проще в два раза.
У меня такое делают студенты на лабораторках, я ж думаю, товарищи из КВГ как минимум не глупее. И даже если так не сделано, сделать это легко и просто и на нагрузке игровых серверов не отразится вообще никак, потому что сессию стартует сервер авторизации, а не игровой, а его нагрузка — около десятка юзеров в секунду.
Во-первых, при грамотно сделанном шифровании с обменом ключей сниффер не поможет в принципе.
А решать проблемы буду по мере их поступления. Кстати, по опыту — NMAPI более вменяемый, чем pcap.
А это уважаемый AN3O «забыл» сказать, что эти самые Pickle в реплеях таки шифруются именно blowfish'ем. Да вы всё-таки посмотрите внутрь реплея, там видно.
Посмотрите внутрь файла реплеев от 0.8.11 — там открытым текстом лежит JSON со статистикой боя (той, что показывается в клиенте после боя). В шифрованном виде только хронология событий.
Я не минусовал, но попробую пояснить. Дело в элементарном уважении к чужому труду. Вот в моей научной практике встречались два характерных явления:
1) Некто, обсуждая какую-то научно-техническую проблему, заявляет, что это очень сложно, требуется такое-то финансирование (большое), такой-то срок (большой) и такой-то штат (тоже большой) для её решения. Когда же ему через 10 минут показывают в соседнем помещении решающий эту проблему лабораторный макет, кое-как слепленный из чего попало 3-4 аспирантами, этот же человек не моргнув глазом, заявляет «а, ну так это же элементарно и тут вообще делать нечего!».
И обратный пример
2) Некто, обсуждая какую-то научно-техническую проблему, заявляет, что все возможные вопросы в этой области давно уже решены (как правило, в его собственных трудах и диссертациях), и что никакие дальнейшие разработки и исследования вопроса смысла не имеют. При этом он сам и его научный коллектив почему-то оказываются неспособны не то, что собрать действующий макет, а даже осознать принципиальную текущую нерешаемость задачи в рамках уже известных наработок.
Это, конечно, не прямая аналогия; пожалуйста, не воспринимайте это буквально и лично. Но примеры характерные и вызывают у собеседников оправданные негативные эмоции. Я поэтому воздержался от комментариев, а кто-то другой, видимо, не воздержался.
Вопрос сложный, об этом ветка комментариев выше. Как мне кажется по совокупности последних событий, КВГ не против этого проекта до тех пор, пока он не предназначен для продажи и пока он не светится на оф.форуме и не провоцирует настроения в духе «читы возможны а власти скрывают».
Исключительно из соображений трудоёмкости реализации.
Прокси-DLL это вообще какой-то костыль, который мне не нравится из эстетических соображений.
Я не так давно в рамках выполнения другого проекта писал внедрение невидимой DLL в процесс, и помню, что даже если не париться с невидимостью, мороки всё равно намного больше, чем от написания простого отладчика.
Нет, int3 не замедляет, я проверял. Даже с учётом всех танцев с откатом контекста и поиском именно того потока, который трапнулся на брейкпоинте, достаточно просто не заниматься в отладочном потоке ничем, кроме сброса вытащенных буферов памяти в очередь другого потока (который и занимается анализом — такая себе «двойная буферизация»), и тогда ни FPS ни пинг не проседает. Субъективно — по игре не заметно, идёт она под такой отладкой или нет.
Здесь тоже не передаются состояния вражеских юнитов, которые пропали из засвета. Однако, миникарту с отметками мест, где их последний раз видели, это сделать не помешало.
И второй момент — закрытость архитектуры и контроль за API у коммерческих социалок будут обязательно препятствовать внедрению такого приватного оверлея, так что имеет смысл именно разрабатывать изначально распределённую платформу.
2. Поскольку файлообменные сети являются частным случаем распределённых одноранговых, то параллель, если и есть, проходит именно на этом уровне — я имел в виду, что рано или поздно придётся отказаться от «клиент-серверного» и даже облачного наследия в этой области, а не то, что надо строить социалки на файлообменных принципах (хотя при таком подходе они там обязательно будут).
3. Относительно того, кто на чём зарабатывает. Steam, например, с вами не согласен категорически, да и другие менее известные P2P CDN тоже.
4. Предлагаемая концепция одноранговой социалки не противоречит в принципе возможности монетизации услуг в ней, зато закрывает возможность контроля за сетью в целом в интересах монетизатора, что есть несомненный плюс.
Для первого есть чудесная функция LdrProcessRelocationBlock() в NTDLL, для второго — несколько раз дёрнуть VirtualProtect(). Всё вместе около сотни строк со всеми проверками.
Оценка интереса сообщества к этой тематике;
Удовлетворение собственного тщеславия;
Закрепление приоритета (слишком уж часто в последнее время я обнаруживал анонсы реализаций того, до чего кто-то додумался тоже)
и т.п.
Я в курсе. Делал инжектор невидимой DLLки (т.е. без файла на диске) для win32/win64.
Но пока подход с дебагом работает, можно кодить основное направление.
У меня такое делают студенты на лабораторках, я ж думаю, товарищи из КВГ как минимум не глупее. И даже если так не сделано, сделать это легко и просто и на нагрузке игровых серверов не отразится вообще никак, потому что сессию стартует сервер авторизации, а не игровой, а его нагрузка — около десятка юзеров в секунду.
А решать проблемы буду по мере их поступления. Кстати, по опыту — NMAPI более вменяемый, чем pcap.
1) Некто, обсуждая какую-то научно-техническую проблему, заявляет, что это очень сложно, требуется такое-то финансирование (большое), такой-то срок (большой) и такой-то штат (тоже большой) для её решения. Когда же ему через 10 минут показывают в соседнем помещении решающий эту проблему лабораторный макет, кое-как слепленный из чего попало 3-4 аспирантами, этот же человек не моргнув глазом, заявляет «а, ну так это же элементарно и тут вообще делать нечего!».
И обратный пример
2) Некто, обсуждая какую-то научно-техническую проблему, заявляет, что все возможные вопросы в этой области давно уже решены (как правило, в его собственных трудах и диссертациях), и что никакие дальнейшие разработки и исследования вопроса смысла не имеют. При этом он сам и его научный коллектив почему-то оказываются неспособны не то, что собрать действующий макет, а даже осознать принципиальную текущую нерешаемость задачи в рамках уже известных наработок.
Это, конечно, не прямая аналогия; пожалуйста, не воспринимайте это буквально и лично. Но примеры характерные и вызывают у собеседников оправданные негативные эмоции. Я поэтому воздержался от комментариев, а кто-то другой, видимо, не воздержался.
Прокси-DLL это вообще какой-то костыль, который мне не нравится из эстетических соображений.
Я не так давно в рамках выполнения другого проекта писал внедрение невидимой DLL в процесс, и помню, что даже если не париться с невидимостью, мороки всё равно намного больше, чем от написания простого отладчика.
Нет, int3 не замедляет, я проверял. Даже с учётом всех танцев с откатом контекста и поиском именно того потока, который трапнулся на брейкпоинте, достаточно просто не заниматься в отладочном потоке ничем, кроме сброса вытащенных буферов памяти в очередь другого потока (который и занимается анализом — такая себе «двойная буферизация»), и тогда ни FPS ни пинг не проседает. Субъективно — по игре не заметно, идёт она под такой отладкой или нет.
Здесь ещё нет уже сейчас написанного нативного парсера Pickle, о котором я расскажу в следующей статье и нет записи пакетов.