今回は、Webアプリケーションの構造調査とクライアント側のデータ隠蔽の仕組みを学ぶWeb Exploitationの入門問題「WebDecode」に挑戦しました！

ブラウザの開発者ツール（Webインスペクター）を駆使してページを構成するファイル群を走査し、HTML内に隠された難読化データを見つけ出して復元するまでのアプローチをまとめました。

1. 開発者ツールによるファイルとソースの調査

Webアプリケーションの構造を理解するため、ブラウザの標準機能である「Webインスペクター（開発者ツール）」を活用します。

• 
  ・リンクや関連ファイルの走査： トップページだけでなく、サイト内に含まれる別のページ（例: about.html など）のソースコードや、構造を構成するファイルをくまなく確認。
  
  
  ・カスタム属性の発見： about.html のソースコード内にあるセクションタグを調査したところ、通常の表示テキストとは別に notify_true="..." という怪しいカスタム属性が埋め込まれていることが判明。

2. Base64エンコード文字列の識別と特徴

発見した属性値には、英数字と記号で構成された独特の文字列が設定されていました。

• 
  エンコード方式の推測
  
  文字列例: cGljb0NURnt3ZWJfc3VjYzNzc2Z1bGx5X2QzYzBkZWRfZjZmNmI3OGF9
  
  
  ・特徴の把握： 大文字・小文字・数字が綺麗に並んでおり、記号の少なさと全体的な雰囲気から「Base64エンコード」であると仮説を立てる。

3. ターミナルを用いたBase64のデコード

特定したBase64文字列を、Linux環境のコマンドラインツールを使ってデコードし、本来の文字列を復元します。

• 
  デコードの実行
  
  echo "cGljb0NURnt3ZWJfc3VjYzNzc2Z1bGx5X2QzYzBkZWRfZjZmNmI3OGF9" | base64 -d


base64 -d コマンドにより、隠されていた機密情報を正確に抽出し、目的のテキストを取得することに成功。

4. まとめ

• 
  ・Webインスペクターを活用した、HTML・関連ファイル・カスタム属性の体系的な走査
  
  
  ・Base64エンコード特有の文字列フォーマットの識別と切り分け
  
  
  ・Linuxの base64 -d コマンドによるスムーズな復元手法の確立

フロントエンドの仕組みとクライアント側の検証手法を基礎から学べる素晴らしい問題でした。このアプローチを活かして、次のWeb問題もロジカルに攻略していきたいと思います！

一般ユーザーではアクセスできない保護されたファイルに対し、システムに許可された正当な権限（sudo設定）をどのように探し出し、アクセス権を突破したのか。そのアプローチとコマンドラインの操作手順をまとめておきます。

1. 現状の調査とパーミッションの確認

まずはリモート環境にログインし、自分自身のユーザー権限と、ターゲットとなるファイルの属性を調査します。

• 
  ・ユーザー権限の確認（id）： 現在のセッションが特権を持たない一般ユーザー（例: ctf-player）であることを確認。
  
  
  ・ファイルのパーミッション確認（ls -l）： ホームディレクトリにあるターゲットファイル（flag.txt）を確認すると、オーナーである root 以外からのアクセスが一切拒否（-r--r-----）されていることが判明。

一般ユーザーの権限のままでは直接中身を読むことができないため、システム上で許可された特権昇格のパスを探す必要が生じます。

2. sudo -l による実行可能コマンドの特定

Linux環境において、現在のアカウントに許可されている `sudo` 権限を調べるためには以下のコマンドを使用します。

• 
  特権リストの照会
  
  sudo -l
  
  
  出力結果を確認すると、パスワードの入力を必要とせず（NOPASSWD）、最高権限（ALL）で特定のプログラム（例: /bin/emacs）を実行できる設定が組み込まれていることが分かります。

3. 許可されたツールを用いたファイルの安全な閲覧

許可されたパスのプログラムを sudo 経由で呼び出すことで、root権限でファイルを直接読み込みます。

• 
  root権限でのエディタ起動
  
  sudo /bin/emacs flag.txt
  
  
  システム管理者が許可した正規のコマンドルートを通り、root権限でテキストエディタを起動してターゲットファイルをオープンします。

4. まとめ

• 
  ・id および ls -l による環境の初期偵察と、アクセス制御の仕組みの把握
  
  
  ・sudo -l を用いた、一般ユーザーに許可されている特権コマンドの精査
  
  
  ・許可されたプログラムパスを正確に指定したroot権限でのファイルオープン手法の確立

Linuxの権限周りの仕組みを体系的に実感できる素晴らしい問題でした。次回のチャレンジも、一歩ずつロジカルに攻略していきたいと思います！

前回に続き、愛用のM3 MacBook Airのターミナルを相棒に、CyLab Security Academy（旧PicoCTF）のカテゴリにある問題「Piece by Piece」に挑戦しました！

今回のテーマは、リモートサーバー上に散らばった複数のファイルパーツを回収し、正しく結合・解凍して中身を暴く「Linuxのファイル操作とアーカイブの復元」です。どのようなコマンドを組み立てて解決に至ったのか、そのアプローチをまとめておきます。

1. 「Piece by Piece」とはどんな問題？

指定されたホストとポートへSSHでリモート接続し、ログイン後のホームディレクトリを確認します。

• 
  ・接続方法： SSHを用いた非標準ポートへのリモートログイン
  
  
  ・確認されたファイル： ホームディレクトリには、実行手順が書かれた指示書（instructions.txt）と、アルファベット順に分割された複数のファイルパーツ（part_aa 〜 part_ae）が配置されていました。

指示書（instructions.txt）のヒントを読むと、「ファイルは複数のパーツに分割されたZIPファイルであること」「指定されたパスワードを用いて解凍する必要があること」が示されており、ここから具体的なコマンド操作の組み立てに入ります。

2. 2ステップで進めるファイル復元プロセス

ターミナルから標準コマンドを組み合わせて、断片化したデータを1つのアーカイブとして復元・抽出します。

• 
  1. 分割ファイルの結合（Concatenation）
  
  cat part_aa part_ab part_ac part_ad part_ae > archive.zip


catコマンドと標準出力のリダイレクト（>）を使い、順序通りに並んだ複数のパーツファイルを1つのZIPアーカイブファイルへと完全に結合します。
• 
  2. パスワード保護されたアーカイブの解凍
  
  unzip archive.zip
  
  
  指示書で指定された保護パスワードを入力し、結合して復元したZIPファイルを解凍。内部に封入されていたターゲットファイルを抽出します。

3. まとめ

• 
  ・「Piece by Piece」は、リモートサーバー上の断片化したファイル群をcatコマンドの連結によって1つのアーカイブへ復元する手法を学ぶ問題
  
  
  ・パスワード付きアーカイブに対する適切な解凍アプローチにより、隠されたターゲットファイルを抽出
  
  
  ・CUI環境でのファイル結合やアーカイブ操作など、エンジニアの基礎体力となる必須の操作手順を確認

ターミナル上での直感的なファイル操作と、ヒントから正解のコマンドを組み立てていくプロセスは非常に爽快です。次回のチャレンジもコマンドラインを駆使して華麗に攻略していきたいと思います！

1. Code Smell（コードの臭い）とは？

Code Smell とは、直ちにエラーになるわけではないものの、「可読性の低下」「修正のしづらさ（保守性の悪化）」「バグの温床」につながるコード設計上の警告サインです。

早期に察知してリファクタリング（内部構造の改善）を行うことが、健全なソフトウェア開発を保つキーとなります。

2. 代表的な Code Smell の例（7選）

• 
  ① コードの重複（Duplicated Code）
  
  【解説】同じ処理やよく似た記述が複数の場所にコピペされている状態。
  
  【リスク】仕様変更があった際に修正漏れが発生し、バグの原因になります。
  
  【改善案】共通処理をメソッドやクラスへ抽出・共通化（DRY原則の適用）します。
• 
  ② 長いクラス（Large Class / God Class）
  
  【解説】1つのクラスに大量のフィールドやメソッドが詰め込まれ、膨大な行数になっている状態。
  
  【リスク】クラスの全容を把握するのが困難になり、影響範囲の特定が難しくなります。
  
  【改善案】関連する機能ごとにクラスを分割・抽出します。
• 
  ③ 長いメソッド（Long Method）
  
  【解説】1つの関数やメソッドの中に何百行もの処理が詰め込まれている状態。
  
  【リスク】「このメソッドが何をしているか」を一目で理解できず、テストも書きづらくなります。
  
  【改善案】処理のまとまりごとに小さなメソッドへ分割（関数の抽出）します。
• 
  ④ 不適切なコメント（Bad Comments）
  
  【解説】「コードを見ればわかること」をそのまま書いた冗長なコメントや、古い仕様のまま残された嘘のコメント。
  
  【リスク】コードの変更に伴いコメントが陳腐化し、読み手を混乱させます。
  
  【改善案】「何をしているか（How）」ではなく「なぜそうしたか（Why）」を書き、コード自体を自己説明的に修正します。
• 
  ⑤ 単一責務違反（Single Responsibility Principle Violation）
  
  【解説】1つのクラスやメソッドが複数の異なる役割（例：データ取得・計算・ファイル保存など）を兼ね備えている状態。
  
  【リスク】一部の修正がまったく無関係な機能に影響を与えてしまいます。
  
  【改善案】SOLID原則の「単一責任の原則（SRP）」に従い、1つのコンポーネントには「変更する理由が1つだけ」になるよう分割します。
• 
  ⑥ 複雑な判定条件（Complex Conditional Logic）
  
  【解説】if 文の条件式に && や || が何重にも連なり、ネスト（深さ）が深くなっている状態。
  
  【リスク】どの条件で真・偽になるかの視認性が悪く、境界値の不具合が発生しやすくなります。
  
  【改善案】ガード節の利用、条件判定を独立したメソッドへ抽出、またはポリモーフィズムを活用します。
• 
  ⑦ 不適切なネーミング（Bad Naming）
  
  【解説】data, temp, x などの意図が不明な名前や、実際の挙動と異なる不正確な命名。
  
  【リスク】コードの意図を汲み取るために処理を精査する必要が生じ、解読の時間が大幅に増えます。
  
  【改善案】変数・関数・クラスの役割や戻り値が明確に伝わる、自己説明的な名前を付けます。

3. 補足解説：Code Smell と上手に付き合うポイント

4. まとめ

• 
  ・Code Smell：将来のトラブルを未然に防ぐための警告サイン。
  
  ・主な原因：コピペによる重複、膨大すぎるクラス・メソッド、意味の不透明な命名など。
  
  ・対策：リファクタリングを日々の開発習慣に取り入れ、可読性と保守性を高める。

コードを書く際は「動くかどうか」だけでなく、「不吉な臭いがしていないか」チェックする習慣を身につけましょう！

1. 入出力と関数の宣言

アルゴリズムの前提条件（入力）と、最終的に得られる結果（出力）を明記するための記述です。

• 
  Input / Output / return
  
  Input: 〇〇     // 入力や関数の引数などを記述
  
  Output: 〇〇    // 出力や関数の返り値を記述
  
  
  
  return 値       // 関数の返り値として、値を返す

2. 制御構造（繰り返し・条件分岐）

処理の流れ（ループや分岐）を構造化して表現します。

• 
  ① for文（指定回数の繰り返し）
  
  for 変数 = 値1 to 値2 do
  
      処理
  
  end for
  変数の値を「値1」から「値2」まで、1ずつ増やしながら処理を実行します。
• 
  ② while文（条件を満たす間の繰り返し）
  
  while 条件 do
  
      処理
  
  end while
  条件が「真（True）」の間、処理を実行し続けます。
• 
  ③ if文（条件分岐）
  
  if 条件 then
  
      処理1
  
  else
  
      処理2
  
  end if
  条件が真ならば「処理1」を、偽（False）ならば「処理2」を実行します。

3. 演算子とデータ構造

代入、比較、論理演算、および配列の参照方法です。

• 
  代入・比較・論理演算・配列
  
  # 代入演算
  
  変数 = 値              // 変数に値を代入
  
  
  
  # 比較演算
  
  値1 == 値2            // 値1と値2が等しければ真、異なれば偽
  
  値1 != 値2            // 値1と値2が等しくなければ真、等しければ偽
  
  
  
  # 論理演算
  
  条件1 and 条件2       // 条件1と条件2がともに真のとき真（AND）
  
  条件1 or 条件2        // 条件1または条件2のいずれかが真のとき真（OR）
  
  
  
  # 配列構造
  
  配列名[添字]           // 配列の指定された添字（インデックス）番目の要素を参照

4. 補足：疑似コードを実際のプログラムに落とし込む例

5. まとめ

• 
  ・基本構文：for / while による繰り返しと if ... else による条件分岐を明示する。
  
  ・終了タグ：end for や end if でスコープの終わりを明確にする。
  
  ・演算と参照：== や != で比較し、配列名[添字] で要素を取り出す。

アルゴリズムを学ぶ際やアイデアをコードに落とし込む前の整理に、ぜひ疑似コードを活用してみましょう！

1. 総当たりアルゴリズム（Brute Force Algorithm）

考えられるすべての条件や組み合わせを順番に試し、確実に正解を導き出す最もシンプルで確実な手法です。

• 
  特徴とメリット・デメリット
  
  ・解の確実性：すべての可能性を検証するため、解が存在すれば必ず正解（最適解）を見つけられます。
  
  ・計算量の問題：データ数や組み合わせが増えると計算時間が爆発的（指数関数的）に増加します。

2. 近似アルゴリズム（Approximation Algorithm）

すべての組み合わせを試すと途方もない時間がかかる問題に対し、「100%の最適解ではなく、十分に満足できる“正解に近い解”を素早く探す」手法です。

近似アルゴリズムは、精度の保証があるかどうかで大きく2つに分類されます。

• 
  ① 精度保証付きアルゴリズム
  
  ・得られる解が「理論上の本当の正解からどのくらいの誤差（例：真の最適解の1.5倍以内など）におさまっているか」が数学的に証明・保証されている手法です。
  
  ・品質の一定ラインを絶対に確保したい重要な計算システムなどで利用されます。
• 
  ② 発見的手法（ヒューリスティック / Heuristics）
  
  ・数学的な精度保証はないものの、「経験則」や「直感的なルール」に基づいて現実的な時間内でそこそこ良い解を導き出す手法です。
  
  ・遺伝的アルゴリズムや貪欲法（Greedy Algorithm）などが代表例です。AIやゲームの思考ルーチン、配送ルートの最適化などで広く活用されています。

3. 補足解説：NP困難問題と現実的なアプローチ

4. まとめ

• 
  ・総当たりアルゴリズム：全パターン検証。確実に正解が出るが、要素が増えると時間がかかりすぎる。
  
  ・精度保証付きアルゴリズム：正解に近い解を求め、誤差の範囲が理論的に証明されている。
  
  ・ヒューリスティック（発見的手法）：精度保証はないが、経験則を用いて高速に実用的な「良い解」を見つける。

アルゴリズムの基礎知識として、「厳密さ（確実性）」と「計算スピード（実用性）」のトレードオフの関係を理解しておきましょう！

1. ユークリッドの互除法とは？

2つの整数の最大公約数（GCD: Greatest Common Divisor）を効率よく見つけるための定番手法です。

• 
  アルゴリズムの定理
  
  2つの整数 $X, Y$ ($X \ge Y$) について、
  
  「$X$ を $Y$ で割った余りを $R$ とすると、$X$ と $Y$ の最大公約数は、$Y$ と $R$ の最大公約数に等しい」
  
  
  
  この性質を利用し、余り $R$ が 0 になるまで計算を繰り返すことで、どんなに大きな数字同士でもすばやく最大公約数を導き出すことができます。

2. Javaでの実装例（自作ロジック）

まずは、アルゴリズムの仕組みを理解するために while 文を使って自作してみましょう。

• 
  サンプルコード（GCDSample.java）
  
  public class GCDSample {
  
      public static void main(String[] args) {
  
          int x = 1071;
  
          int y = 1029;
  
          
  
          int result = getGcd(x, y);
  
          System.out.println(x + " と " + y + " の最大公約数は " + result + " です。");
  
      }
  
  
  
      // 最大公約数を求めるメソッド
  
      public static int getGcd(int x, int y) {
  
          // R = 0 となるまで、YとRを変えながらループ
  
          while (y != 0) {
  
              int r = x % y; // 剰余Rを求める
  
              x = y;         // 次の計算のためにYをXに代入
  
              y = r;         // 次の計算のためにRをYに代入
  
          }
  
          return x; // 余りが0になった時の除数が最大公約数
  
      }
  
  }

3. アルゴリズムの挙動を追う

$X = 1071, Y = 1029$ の場合の計算推移をシミュレーションしてみます。

桁数の大きな数字同士であっても、驚くほど少ないループ回数で答えに辿り着くことができます。

4. 【必見】Java標準ライブラリで一発解決！

アルゴリズムの自作ロジックを理解した上で押さえておきたいのが、Java標準ライブラリ java.math.BigInteger の存在です。

• 
  BigInteger.gcd() を使った実装例
  
  import java.math.BigInteger;
  
  
  
  public class GCDMain {
  
      public static void main(String[] args) {
  
          // valueOfを使用してBigIntegerインスタンスを作成
  
          BigInteger b1 = BigInteger.valueOf(1071);
  
          BigInteger b2 = BigInteger.valueOf(1029);
  
          
  
          // gcdメソッドを呼び出すだけ
  
          BigInteger gcd = b1.gcd(b2);
  
          
  
          System.out.println("最大公約数は: " + gcd); // 実行結果: 21
  
      }
  
  }

5. まとめ

• 
  ・基本：「$X \div Y$ の余り」を次の除数にするループを回して最大公約数（GCD）を求める。
  
  ・応用：最大公約数（GCD）がわかれば、最小公倍数（LCM）は $(X \times Y) \div \text{GCD}$ で計算可能。
  
  ・Javaの実務テクニック：BigInteger.gcd() を使えば1行で確実に実装可能。

アルゴリズムの仕組みを知ることはプログラミングの「思考力」を鍛え、便利な標準機能を知ることは「生産性」を高めてくれます。両方のアプローチをバランスよく身につけていきましょう！

今回のテーマは機械学習の基礎である「単層パーセプトロンの学習限界」。非線形なXORデータに対し、重みの更新ルールがどう働き、どこで頭打ちになるのかを実際にパラメータを操作して検証したアプローチをまとめておきます。

1. 「Perceptron Train XOR」とはどんな問題？

問題文とルールを確認します。

• 
  ・カテゴリ： AI / Machine Learning（難易度：Easy）
  
  
  ・問題文： 「Watch a perceptron learn in real time on XOR data using the classic update rule: only misclassified points trigger updates, with no weight decay. Because XOR is not linearly separable, a single perceptron cannot hit 100% accuracy. Reach 75% accuracy to prove you understand the limitation and reveal the flag.」
  
  
  ・ヒント・制約： 誤分類された点のみが重みの更新を引き起こし、重み減衰はない。XORは線形分離不可能なため単一パーセプトロンでは100%に到達せず、目標である75%の精度に到達することがクリア条件となる。

XOR（排他的論理和）は直線を1本引くだけでは綺麗に分類できない「非線形分離不可能」なデータセットです。そのため、単層のパーセプトロンでは理論上100%正解することができず、4点中3点が正解となる75%の精度がモデルの限界点となります。

2. パラメータの確認とトレーニングの実行プロセス

ブラウザ上でインスタンスを立ち上げ、以下の手順で挙動を検証します。

• 
  1. 学習率（Learning Rate）の設定
  
  Learning rate: 0.02 (デフォルト値)
  
  
  初期パラメータとして設定されている学習率を確認し、モデルがどのように重みを更新していくかのベースラインを置きます。
• 
  2. トレーニングの実行と精度の収束確認
  
  Status: Target accuracy (75%) reached.
  
  
  「Run training」を実行し、誤分類されたデータポイントトリガーによる重み・バイアスのリアルタイム更新を追跡。非線形分離の構造的限界により、数ステップで精度の頭打ち（75%）に到達することを確認します。

3. まとめ

• 
  ・単層パーセプトロンにおけるXOR問題の非線形分離の限界と、誤分類ベースの重み更新ルールをハンズオン形式で検証
  
  
  ・デフォルトの学習率（0.02）を用いたトレーニングにより、理論上の限界値である75%の精度に到達することを確認
  
  
  ・機械学習モデルの構造的制約を理論と実機の両面から理解・証明するプロセスとしての重要性

インフラやWebの脆弱性だけでなく、AI・機械学習の数理モデルの制約検証まで一貫したプロセスでドキュメント化できるのは非常に価値があります。次回のチャレンジもこの検証スタイルを貫いて攻略を進めていきます！

今回の問題は、入力値の検証の隙を突く**「OSコマンドインジェクション」**がテーマ。どのようなヒントから脆弱性を見抜き、複数の命令を組み立てていったのか、そのアプローチをまとめておきます。

1. 「ping-cmd」とはどんな問題？

問題文とヒントを見ると、次のように書かれています。

• 
  ・カテゴリ： Web Exploitation / General Skills（難易度：Easy）
  
  ・問題文： 「Can you make the server reveal its secrets? It seems to be able to ping Google DNS, but what happens if you get a little creative with your input?（サーバーに秘密を明かさせることができますか？Google DNSにpingを飛ばせるようですが、入力をちょっと工夫するとどうなるでしょうか？）」
  
  ・ヒント： 「OSのコマンドとして実行します」「一度に複数の命令出してみて」

Netcat（nc）で接続する対話型インターフェースになっており、IPアドレスの入力を求められますが、制限として「8.8.8.8しか許可していない」と表示されます。しかし、ヒントにある「OSコマンドとしての実行」や「一度に複数の命令を出す」というキーワードが、今回の最大の攻略の糸口になります。

2. 2つのステップでコマンドインジェクションを仕掛ける

M3 MacBook AirのターミナルからNetcatでサーバーに接続し、シェル文字を用いた入力の工夫を試みます。

• 
  1. 区切り文字を用いたファイル構造の偵察
  
  8.8.8.8; ls
  
  許可されているIPアドレスの後にセミコロン（;）を挟んで別のコマンドを連結し、サーバー内部のファイル一覧（flag.txt など）を確認します。
• 
  2. ターゲットファイルの読み込み
  
  8.8.8.8; cat flag.txt
  
  同様にコマンドセパレータを活用して、見つけたフラグファイルの中身を標準出力へ強制的に吐き出させます。

3. まとめ

• 
  ・「ping-cmd」は、入力値がそのままOSのシェルへ渡される脆弱性を突き、コマンドの連続実行によって目的を果たす問題
  
  ・「一度に複数の命令を出す」というヒントから、セミコロン等の区切り文字を活用する発想が重要
  
  ・問題文やヒントの行間を読み解き、想定された脆弱性アプローチを綺麗にハマらせたときの快感は格別！

入力値のバリデーションの裏側にある仕組みを想像しながら、ターミナルから一撃で攻略できると本当に気持ちが良いですね。次回のチャレンジもコマンドラインを武器に華麗に攻略していきたいと思います！

今回の問題は、特別な裏技を使うわけではなく、add・commit・push というGitの基本ワークフローを正しく実践することの重要性が試される実践的なテーマでした。どのようなアプローチで謎を解き明かしていったのか、その手順をまとめておきます。

1. リポジトリのクローンとREADMEの解析

まずは問題文の指示通り、指定されたSSH経由でGitリポジトリをローカルへクローンします。

• 
  ・カテゴリ： General Skills（難易度：Easy）
  
  ・初期調査： クローンしたディレクトリを確認すると、中には README.md が1つだけ存在していました。

その README.md を確認してみると、今回の謎を解く最大の鍵（ルール）が次のように記されていました。

過去のコミット履歴を探すのではなく、「指定された条件を満たすファイルを自分で作り、正しい手順でコミットしてプッシュする」という、Gitの基本操作がそのまま鍵になるアプローチです。

2. 基本のワークフローによる条件のクリア

サーバー側のルール（「root:root@picoctf による flag.txt のプッシュ」）をクリアするため、M3 MacBook Airのターミナル上でGitの基本操作を行います。

• 
  1. ユーザー情報の準備とコミット作成
  
  git config user.name "root"

git config user.email "root@picoctf"

echo "give me flag" > flag.txt
  
  必要な設定を整えた上で、対象となる flag.txt を作成します。
• 
  2. add / commit / push の実行
  
  git add flag.txt

git commit -m "Add flag.txt"

git push origin master
  
  お馴染みのGitワークフローに沿って、変更をステージング、コミットし、リモートサーバーへプッシュします。

3. まとめ

• 
  ・「I have built my own Git server...」は、READMEの仕様を読み解き、適切なGitワークフローを実践する問題
  
  ・日頃の開発でお馴染みの add / commit / push の基本がいかに強力かを再認識できる
  
  ・仕様に沿って正しく操作を完結させ、フラグをゲットできたときの達成感は格別！

基本に忠実なGit操作を積み上げることで、セキュリティ上の謎を鮮やかに解き明かせるのは本当に面白いですね。次回のチャレンジもコマンドラインを武器に華麗に攻略していきたいと思います！