- 112
- 44
Не знаю, кому это нужно будет, но мне нейронка декомпилировала за пару промтов это. Если кому-то нужно отредактировать какие-то функции в этом скрипте, либо вы хотите сделать с ним вообще что-либо - пишите в этой теме, нейронка всё за вас сделает. Может кому-то расширить текст надо, поменять цвет арз маркета или еще что-то
Что АРЗ Маркет собирает о вас:
Также список уязвимостей, большинство из них невозможно пофиксить, в том числе и заход с забаненного ИП с заменёнными данными, чтобы заблокировать любого из игроков в скрипте:
Что АРЗ Маркет собирает о вас:
- ник игрока;
- сервер Arizona, на котором он играет;
- номер своей лавки LavkaUid;
- список предметов на продаже;
- количество каждого предмета;
- цены продажи;
- список предметов на скупке;
- количество и цены скупки;
- версию ArzMarket;
- данные авторизации API: authKey, authToken, authClient, myServerId;
- торговую статистику: предмет, цена, количество, действие покупка/продажа, сервер;
- некоторые данные аккаунта ArzMarket/премиума и UID, связанные с авторизацией и опытом;
- beta-ключ при проверке Beta-версии.
Также список уязвимостей, большинство из них невозможно пофиксить, в том числе и заход с забаненного ИП с заменёнными данными, чтобы заблокировать любого из игроков в скрипте:
- Marketplace доверяет данным клиента. Клиент сам формирует username, serverId, LavkaUid, товары, количество и цены, после чего отправляет JSON на /api/insertMarketplace. В самом запросе не видно отдельной подписи этих данных. Если backend не перепроверяет их, возможны поддельные или испорченные записи Marketplace.
- Идентичность игрока частично строится на данных клиента. UID извлекается из обычного сообщения /id, сохраняется локально в info_user_uid.txt, а затем используется вместе с ником в запросах ArzMarket. Это опасная архитектура, если сервер считает присланный nickname[UID] доказательством личности без дополнительной проверки.
- Привязка аккаунта также отправляет клиентские gameNickname и UID:
gameNickname = realPlayerName .. "[" .. myUid .. "]".
Защита здесь зависит от того, насколько надёжно backend проверяет keyAccept, одноразовость токена и соответствие игрового аккаунта. - Авторизация Marketplace находится в клиенте. При GET отправляются authKey, authToken, serverId, authClient и версия скрипта. Всё, что хранится и формируется на клиенте, пользователь технически может изменить. Поэтому backend не должен доверять этим значениям без серверной проверки.
- Блокировка/обход RKN частично управляется локальным флагом bannedByRkn. Его можно даже переключить командой /rknfix. Этот флаг также меняет HTTP-поведение клиента. Если какая-то серверная безопасность зависит от этого локального значения, это слабое место. Пока похоже, что это скорее сетевой fallback, а не настоящий бан пользователя.
- Marketplace имеет несколько backend/fallback-хостов. При проблемах клиент переключается между основным API, reserve API и Vercel-вариантом. Это увеличивает поверхность атаки: у всех зеркал должны быть одинаковые правила авторизации, фильтрации и блокировок. Иначе более слабый резервный endpoint может обходить защиту основного.
- Очистка Marketplace тоже инициируется клиентом. Клиент отправляет пустой объект лавки на тот же /api/insertMarketplace. Если backend недостаточно жёстко связывает запись лавки с её настоящим владельцем, теоретически возникает риск удаления/перезаписи чужих данных.
- Статистика формируется на клиенте. В коде есть отдельная отправка торговой статистики с сервером, действием, количеством и версией. Если backend использует её для рейтингов, опыта или аналитики и не валидирует независимо, она потенциально недостоверна.
- addExp выглядит особенно интересно с точки зрения доверия. Клиент сам формирует URL из realPlayerName и локально сохранённого UID и отправляет POST на reserve-api.arz.market/api/addExp/.... По клиенту невозможно понять, какие дополнительные проверки выполняет сервер. Это один из первых endpoint'ов, которые стоило бы проверять владельцу сервиса.
- Автообновление не показывает проверки цифровой подписи скачанного Lua. Loader получает JSON с updateurl, скачивает новый файл, выгружает старый и запускает скачанный. Если источник обновлений или цепочка доставки будет скомпрометирована, последствия значительно серьёзнее обычной ошибки Marketplace. HTTPS помогает при передаче, но это не замена подписи обновления.
- Beta-ключ хранится обычным текстовым файлом на диске. Loader читает его и использует для запросов к серверу разработчика. Это не обязательно критическая уязвимость, но секрет, доступный клиенту, нельзя считать по-настоящему секретным.
- Любые client-side premium/feature flags нельзя считать защитой. Пользователь полностью контролирует Lua и локальный INI. Настоящая проверка Premium, банов и доступа должна происходить на backend. По коду видно, что часть Premium действительно проверяется сервером, но насколько полно, без серверного кода определить невозможно.
Ну и да, можно спокойно регулировать вообще весь рынок цен какого-либо из товаров лишь при помощи подмена цен. Это хоть и долго будет, но очень-очень даже просто. Тем самым вы можете взвинтить ценник любого из предметов
Последнее редактирование:
