Обход Castle, request-токен сгенерирован.

Обход Castle без браузера. Takion генерирует валидный x-castle-request-token за один вызов, чтобы ваши запросы на вход и оформление заказа проходили risk-проверку Castle.

Последнее обновление · Покрытие протестировано на живой цели Castle.

Castle вас блокирует?

Castle защищает входы, регистрации и оформления заказов от захвата аккаунтов и фрода. Каждый защищённый вызов должен нести валидный x-castle-request-token, выпущенный из сигналов браузера и сессионного cookie __cuid. Takion генерирует этот токен на своей стороне, без браузера у вас, и возвращает его готовым к прикреплению. Отправьте его вместе с запросом на вход или оформление заказа — и Castle вас пропустит.

Доступ к пробной версии ограничен

Castle защищает входы и оформления заказов, поэтому обход может открыть путь к захвату аккаунтов и платёжному фроду. Пробный доступ выдаётся не автоматически. Сначала свяжитесь с нами и расскажите о своём сценарии использования.

Как работает Castle

Castle (castle.io) — это слой защиты аккаунтов: он оценивает входы, регистрации и оформления заказов, чтобы остановить захват аккаунтов, фейковые аккаунты и злоупотребления. Он считывает характеристики браузера, поведение и паттерны запросов и ждёт, что каждый защищённый вызов будет нести валидный x-castle-request-token, выпущенный на основе этих сигналов и сессионного cookie __cuid.

Takion генерирует этот токен на своей стороне из site key страницы (значения pk_) и вашего __cuid и возвращает его готовым к отправке. Один вызов, без браузера. Вы прикрепляете x-castle-request-token / castle_token к запросу на вход или оформление заказа, несёте рядом __cuid — и запрос проходит.

  • Проверки, которые закрывает Takion
  • Скоринг риска захвата аккаунта и фейковых аккаунтов
  • x-castle-request-token / castle_token при входе и оформлении заказа
  • Привязка к сессии по __cuid
  • Сигналы характеристик браузера и поведения

Что возвращает один вызов

Один вызов эндпоинта Castle возвращает валидный x-castle-request-token и привязанный к нему __cuid — готовые к прикреплению к вашему запросу на вход или оформление заказа.

x-castle-request-token / castle_token

request-токен, который вы прикрепляете к защищённому запросу на вход или оформление заказа

__cuid

сессионный cookie, к которому привязан токен (генерируется, если вы его не передаёте)

curl -G https://castle.takionapi.tech/generate \
  --data-urlencode "api_key=$TAKION_KEY" \
  --data-urlencode "website=rockstar"          # or site_key=pk_... for any target
# → { "token": "<x-castle-request-token>", "__cuid": "<cuid>" }

Читать документацию по CastleОдин ключ на все стены. Одна структура JSON для каждого вендора.

How the Castle bypass works, end to end

No browser, no SDK on your side. Four moves from the login wall to a cleared request.

  1. 1

    You load the protected page

    Hit the login, signup, or checkout page and read the Castle script tag. It loads cdn.castle.io/v2/castle.js?pk_.... The value after the ? is the scriptID you pass along.

  2. 2

    You call /generate once

    Send the target to castle.takionapi.tech/generate: a website shortcut like twitter or rockstar, or the site_key you parsed. Add your __cuid if you already have one. One GET, no SDK.

  3. 3

    We mint the token server-side

    Takion builds the token Castle's JS would have produced from the script context and your session, then binds it to the __cuid. Nothing runs in a browser on your end.

  4. 4

    You attach and send

    Read token from the response, put it where the target expects it, carry the __cuid alongside, and Castle scores the request as a real session.

The pieces of a Castle solve, decoded

Four things move through one request. Here's what each one is:

x-castle-request-token / castle_token
the request token you attach to the protected call. Rockstar reads it as a header, X reads it as castle_token.
__cuid
the session cookie the token is bound to. Send yours, or Takion generates one and hands it back with the token.
site_key (pk_...)
Castle's public key, parsed from the page's castle.js script tag. It names the target when there's no shortcut.
website shortcut
a name like twitter or rockstar so you skip parsing the site key yourself. One of website or site_key is required.

Why request-based beats a browser here

The browser way to pass Castle is to load castle.js, let it fingerprint a real Chrome, drive the login form, and hope the behavior signals read clean. That's a headless browser per account, and account flows run at scale. Login, signup, checkout: you're firing thousands of these, not one.

Takion mints the token directly. No castle.js running, no browser to fingerprint, no mouse path to fake. One GET returns the token and the __cuid it's bound to, so a solve is an HTTP round trip instead of a full page render. Send your real User-Agent, Sec-Ch-Ua, and Accept-Language on the call and the token matches the request you actually make.

What flags a Castle request

A valid token is necessary, not sufficient. Castle scores the whole session, and these break it:

  • Token and __cuid split apart. The token is bound to the __cuid. Send them from the same session or Castle reads a mismatch.
  • Header drift. Generate the token against one User-Agent and send another and the signals disagree. Match the User-Agent, Sec-Ch-Ua, and Accept-Language on the generate call and the final request.
  • Reused token. The token is minted for one request. Generate a fresh one per login or checkout attempt, don't replay an old one.
  • Wrong placement. Rockstar wants the x-castle-request-token header, X wants castle_token. Put it where the target reads it or the call goes out without it.
  • Dirty IP or velocity. Castle also scores connection and request patterns. Hammer a login from one flagged IP and no token saves you.

The one rule that keeps you cleared

Generate the token against the exact User-Agent, Sec-Ch-Ua, and Accept-Language you'll send, and keep it with its __cuid on one session. Castle scores consistency across the whole login. Match the session it minted for and you pass.

Некоторые сайты на Castle

Castle защищает эти сайты. Takion проходит его на каждом, так что обход rockstar games это тот же один POST, что и любая другая стена.

Rockstar Games

вход в Social Club

X (Twitter)

вход

FAQ по обходу Castle

Да. Takion генерирует валидный x-castle-request-token (на некоторых сайтах он называется castle_token) из site key и вашей сессии и возвращает его готовым к прикреплению к защищённому запросу на вход или оформление заказа — вместе с __cuid, к которому он привязан.
Для большинства целей да — site key pk_ со страницы. Для распространённых сайтов у нас есть шорткат, например website=twitter или website=rockstar, чтобы вам не пришлось разбирать его самостоятельно.
Передайте __cuid своей сессии, если он у вас есть; если нет — Takion сгенерирует его и вернёт. Держите его в той же сессии, что отправляет токен.
Да. Оба используют Castle на входе. Takion возвращает токен для каждого (Rockstar отправляет его как заголовок x-castle-request-token, X — как $castle_token), а вы несёте рядом __cuid.

Любая другая стена

Запустите обход Castle уже сегодня.

Бесплатный доступ, потом один ключ на все стены. Первый вызов — меньше чем за час.