サーバーを破壊するハッカー ゲームのバックエンドはどのように作成されたか

サーバーの破壊を伴うレーザークエストがどのように計画されたかを引き続きお伝えします。 前から開始 クエストを解決する記事.

ゲームのバックエンドには合計 6 つのアーキテクチャ ユニットがあり、この記事ではこれを分析します。

1. ゲームメカニズムを担当するゲームエンティティのバックエンド
2. VPS 上のバックエンドとサイトのデータ交換バス
3. バックエンドリクエスト（ゲーム要素）からArduinoおよび現場のハードウェアへのトランスレータ
4. リレーの制御を担当する Arduino は、トランスレータからコマンドを受け取り、実際の作業を実行しました。
5. 実際のデバイス: ファン、ガーランド、フロアランプなど。
6. フロントエンド - プレイヤーがデバイスを制御する Falcon Web サイト自体

それぞれを見てみましょう。

ゲームエンティティのバックエンド

バックエンドはスプリング ブート アプリケーションとして実装されました。バックエンドには、いくつかの REST コントローラー、WebSocket エンドポイント、およびゲーム ロジックを備えたサービスがありました。

コントローラーは XNUMX つだけでした。

• メガトロン。 現在の Megatron ページは、電源を入れる前と後の GET リクエストによって送信されました。 レーザーは POST リクエストを通じて発射されました。
• ページ名で提供されるようにチルダ ページをマッピングします。 チルダは、元の名前ではなく、内部 ID とコンプライアンス情報を含むエクスポート用のページを生成します。
• 擬似高負荷サーバー キャプチャを提供するキャプチャ コントローラ。

Websocket エンドポイントは、ランプ、ガーランド、手紙などのガジェットを制御するために使用されました。 これは、デバイスの現在のステータス (オンかオフか、アクティブかどうか、壁に現在点灯している文字の色) をすべてのプレイヤーに同期して表示するために選択されました。 レーザーをオンにするタスクを少し難しくするために、同じログイン名とパスワード admin/admin を使用してガーランドとレーザーに権限を追加しました。

プレイヤーは花輪をオンにしてテストし、レーザーで同じことを繰り返すことができます。

プレイヤーを不必要な選択で苦しめないよう、このような簡単なログイン パスワードのペアを選択しました。

このタスクをもう少し面白くするために、mongodb のオブジェクト ID がルーム内のデバイス ID として使用されました。

ObjectId にはタイムスタンプが含まれます。XNUMX つのランダムな値のうち XNUMX つはデバイス識別子に基づいて取得され、もう XNUMX つはそれを生成するプロセスの PID とカウンター値に基づいて取得されます。 レーザー デバイス識別子の選択がより興味深いものになるように、識別子を一定の間隔で異なる PID プロセスで生成するが、共通のカウンターを使用したいと考えました。 しかし、最終的には、誰もがカウンタ値のみが異なる識別子から開始しました。 これにより、手順が単純になりすぎて、objectId 構造の分析が不要になった可能性があります。

バックエンドリクエストからのトランスレーター

Python スクリプト、タイマーに取り組み、ゲームの抽象概念から物理モデルに変換しました。 たとえば、「フロアランプをオンにする」→「リレー N2 をオンにする」などです。

スクリプトは RabbitMQ キューに接続し、キューから Arduino にリクエストを転送しました。 また、平行光スイッチングのロジックも実装されています。いくつかのデバイスと連動して、それらのライトが点灯します。たとえば、最初にメガトロンに電力が供給されると、ステージ ライトで照らされます。 シーン全体の映画撮影のための照明デザインについては、プロジェクトの共同プロデューサー兼プロダクション デザイナーであるイリヤ セロフの素晴らしい仕事については別の記事で説明します。

翻訳者は、タイマーを使用してシュレッダーを起動し、その画像をテレビに送信するロジックも担当しました。シュレッダー起動のタイマー、叫び声をあげるカピバラ、ゲーム終了時のコマーシャルなどです。

メガトロン トークンを生成するロジックはどのように構成されているか

テストショット

25 秒ごとに新しいトークンが生成され、10/10 の出力でレーザーを 255 秒間オンにするために使用できました。 へのリンク Megatron コードを含む github.

その後、レーザーは 1 分間冷却されました。この間、レーザーは使用できなくなり、新しいショットのリクエストは受け付けられませんでした。

このパワーはロープを焼き切るには十分ではありませんでしたが、どんなプレイヤーでもメガトロンを発射し、レーザービームが動作するのを見ることができました。

トークンの生成には MD5 ハッシュ アルゴリズムが使用されました。 そして計画はうまくいきました MD5 + カウンター + シークレットからの MD5 戦闘トークンの場合、テスト トークンの場合はシークレットなし。

MD5 は、後援者である Pavel が行った商用プロジェクトへの参照です。 ほんの数年前、このプロジェクトでは MD5 が使用されていましたが、MD5 は時代遅れの暗号化アルゴリズムであるとプロジェクト アーキテクトに伝えたところ、MD5 から MDXNUMX を使用し始めました。 私たちが可能な限り初心者のプロジェクトを作ることに決めたので、彼はすべてを覚えていて、少し参考にすることにしました。

コンバットショット

メガトロンの戦闘モードは 100% レーザー出力 3 ワットです。 これは、重りを保持していたロープを焼き切り、水槽を破壊し、サーバーに水が浸水するのに十分な2分間です。

私たちはプロジェクトの Github にいくつかのヒントを残しました。それは、テスト トークンと戦闘トークンが同じカウンター インジケーターに基づいて生成されることが理解できるトークン生成コードです。 戦闘トークンの場合、カウンター値に加えてソルトも使用されますが、これは最後の XNUMX 文字を除いてほぼ完全にこの要旨の変更の歴史に残っています。

このデータを知っていると、塩の最後の 2 つの記号を分類することができ、実際に、16 進法に変換された Lost の数値が使用されていることがわかりました。

次に、プレイヤーは (テスト トークンを分析して) カウンター値を取得し、次のカウンター値と前のステップで選択したソルトを使用して戦闘トークンを生成する必要がありました。

カウンタはテストショットごとに 25 秒ごとに単純に増加します。 これについてはどこにも書いていませんが、ゲーム内のちょっとしたサプライズであるはずでした。

キャプチャインタラクションサービス

ゲームの世界では、これはファンをオンにしてヒント付きのフリップチャートを開くためにロードする必要があるキャプチャと同じものでした。 カメラの隣には負荷監視機能を備えたラップトップがありました。

サービス 現在の負荷としてモニタリングに表示するものを計算しました。温度と CPU ファンです。 メトリクスはタイムベース データベースに転送され、grafana によって描画されます。

最後の 5 秒間にキャプチャを表示するリクエストが 50 件を超えた場合、負荷は固定 + ランダムなステップ数だけ増加します。 100% の負荷が XNUMX 分で達成できる計算になります。

実際、サービスには最終ゲームで表示されるものよりも多くのロジックがありました。CPU ファンの回転のみが見えるようにモニターを配置しました。

クエストの開始時に、彼らは Falcon の Web サイトから Grafan にアクセスできるようにしたいと考えていました。 ただし、バックエンド アプリケーション レポートからのスプリングブート メトリックも含まれており、クリーンアップする時間がなかったため、アクセスをブロックすることにしました。 それもそのはず、クエストの開始時点でさえ、一部のプレイヤーはアプリケーションが Springboot フレームワークで記述されていると推測し、いくつかのサービスの名前を調べさえしました。

ホスティングとデータバス

バックエンドからサイト (RabbitMQ が実行されていた VPS サーバー) に情報を転送するためのツール。

バックエンドとデータバスはオンのままでした 私たちのVPS。 その能力は、画面に表示されているコンピューター (2 GB の RAM を搭載した XNUMX コア VPS) に匹敵します。 ピーク負荷は数日間だけ計画されていたため、料金はリソースに対して請求されました。これは、VPS の負荷を短期間に計画しているお客様が行うことです。 その後、負荷が予想よりも高かったため、固定料金の方が収益性が高いことが判明しました。 クエストを行う場合は、回線料金を選択してください ターボ.

DDoSa からサーバーを保護するために、Cloudflare を使用しました。

VPS がすべてに敬意を持って耐えたと言うのは価値があります。

リレーの制御を担当する Arduino は、トランスレータからコマンドを受け取り、実際の作業を実行しました。

これは、プロジェクトのハードウェア部分に関する次の記事のトピックです。バックエンドは、特定のリレーをオンにするリクエストを送信しただけです。 たまたま、バックエンドはほぼすべてのエンティティを認識しており、バックエンドからのリクエストは「このエンティティをオンにする」ように見えました。 これはサイトの初期テストのために行いました (まだすべての Arduino とリレーを組み立てていませんでした)。最終的にはすべてそのままにしました。

フロントエンド

私たちはチルダを使ってサイトをすぐに作成しました。所要時間は 30 営業日で、予算は XNUMX ドル節約できました。

当初は、単純にサイトをエクスポートして不足しているロジックを追加することを考えていましたが、これを禁止する利用規約に遭遇しました。

私たちはライセンスに違反する準備ができていなかったので、XNUMX つの選択肢がありました。すべてを自分たちで実装するか、Tilda に直接連絡してプロジェクトについて話し、コードを変更する許可を得るかです。

私たちは XNUMX 番目のオプションを選択しましたが、彼らは途中まで会っていただけでなく、XNUMX 年間の無料のビジネス アカウントを与えてくれました。これには非常に感謝しています。 彼らに Sokol の Web サイトのデザインを見せるのは非常にぎこちなかった。

その結果、基本的なデバイスにリクエストを送信するためにフロントエンドに js ロジックを追加し、ゲーム要素をオンまたはオフにするためのボタンのスタイルをわずかに変更しました。

ウェブサイトのデザイン

検索の歴史については別の章で説明します。

私たちは、単なる時代遅れのサイトではなく、デザインの基本ルールをすべて違反した、まったく不快なサイトを作りたかったのです。 同時に、信憑性を維持することも重要でした。耳鼻咽喉科のストーリーを壊してはならず、著者の傲慢さを実証する必要があり、プレイヤーはそのようなサイトが存在し、クライアントを連れてくることさえできると信じなければなりませんでした。 そして彼はそれを持ってきました！ 試合の進行中に、ウェブサイトを作成したいという連絡が XNUMX 回ありました。

最初は私が自分でデザインを行い、より多くの gif や光沢のある要素を含めようとしました。 しかし、10年来のデザイナーの夫は、それを「良すぎる」と一蹴しました。 デザインルールを破るには、それを知る必要があります。

永続的な嫌悪感を呼び起こす色の組み合わせはいくつかあります。同じ豊かさの緑と赤、グレーとピンク、青と茶色です。 最終的に、ベースカラーとして赤と緑の組み合わせに落ち着き、猫のGIFを追加し、ストックフォトからソコロフ自身の写真を3〜4枚選択しました。 私の条件はいくつかだけでした。中年男性で、サイズが大きすぎるサイズの合わないスーツを着て、「プロのスタジオ写真撮影」のようなポーズをとっていることです。 テストでは、友達に見せて「どうですか？」と尋ねました。

設計開発のプロセス中、夫は XNUMX 分おきに横になり、ヘリコプターが飛び始めました。 パシャはフロントエンドの仕上げを終える間、目を保護するために開発者コンソールを画面の大部分まで開かせようとしました。

実機

ファンとライトはソリッドステート リレーを介して取り付けられているため、すぐにフルパワーでオンにならず、監視と並行して電力が増加します。

ただし、これについては次の投稿で、ゲームのハードウェア部分とサイトの実際の構築について説明します。

乞うご期待！

サーバーを破壊するクエストに関するその他の記事

• ゲーム開始
• 最初の手がかり
• 誰がシュレッダーを止めたのか、またはサーバーを破壊してクエストを完了する必要があったのか

出所： habr.com